Feature Proposal: Add configuration parameters {HomeWebName}, {ConfigWebName}.

Motivation

Whenever no web name is specified the {UsersWebName} is used as a default. However that might not be a desirable choice for sites that want to store the main site in the Main web while separating out the user profiles in a Users web (for example). Now, when the site is accessed via http://mysite.com will Foswiki default to Users.WebHome. However it should render Main.WebHome instead.

This is desired outcome is possible to implement using HomePagePlugin by setting {HomePagePlugin}{SiteDefaultTopic}. This will be used when accessing the site's root. Any other api calls to normalizeWebTopicName will still default to {UsersWebName}.

A common approach is to add a redirect to the web-servers config from / to /Main/WebHome (or wherever the main site is located). Problem is that this adds YARE (yet another redirect) also known as DBR (death by redirects). This is directly affecting the SEO scoring of a site. A web-server already may have been redirecting a couple of times, e.g.

1. http://mysite.com
2. https://mysite.com
3. https://www.mysite.com
4. https://www.mysite.com/Main/WebHome

The first three can be fixed in the web-server config already. Not so the last one. Every redirect we can omit is good for the site in terms of SEO.

Basically, this is a clean-up of the api. Defaulting to {UsersWebName} totally makes sense in a standard setup, not so as soon as you set {UsersWebName} to some other value in an attempt to separate a main site from all user profiles.

As per discussion on the release meeting we decided to invent a new %HOMEWEB% macro as well. All links in the System web will be changed similarly from

%SCRIPTURL{"view"}%/%USERSWEB%/%HOMETOPIC%

To

%SCRIPTURL{"view"}%/%HOMEWEB%/%HOMETOPIC%

All use of %USERSWEB% and {UsersWebName} is reserved to only refer to the web where the user profiles are located. Nothing else. This also means that defaults generated in Foswiki.spec will be changed from

$Foswiki::cfg{LocalSitePreferences} =  '$Foswiki::cfg{UsersWebName}.SitePreferences';

to

$Foswiki::cfg{LocalSitePreferences} =  '$Foswiki::cfg{HomeWebName}.SitePreferences';

Description and Documentation

Desired outcome is to move implement a {HomeWebName} configuration parameter that defaults to {UsersWebName} but lets you separate it out and use it as a proper default potentially different from the {UsersWebName} setting. HomePagePlugin will have to be adjusted to take {HomeWebName} into consideration while processing its own {HomePagePlugin}{SiteDefaultTopic}.

This also adds more flexibility to those that don't like HomePagePlugin for whatever reason.

Examples

Impact

Replace {UserWebName} with {HomeWebName} in:

• lib/Foswiki.pm
• lib/Foswiki.spec
• lib/Foswiki/Func.pm

Implementation

-- Contributors: MichaelDaum - 19 Apr 2016

Discussion

Additional configuration variables / macros

With some discussion on security related issues, it makes sense to extend this proposal a bit further, and completely separate (or allow separation) of the roles of User registration, a home landing page, and the site configuration topics.

This proposal could be extended to support the following:

User registration topics, custom left bar, etc.	%USERSWEB%	{UsersWebName}
Default landing page, "Home" web	%HOMEWEB%	{HomeWebName}
Configuration, template overrides, System overrides, etc.	%CONFIGWEB%	{ConfigWebName}

The ConfigWebName could also be added to the top of the {TemplatePath}, to prevent any overrides of site-wide templates.

From what I can see, splitting into 3 variables would have no impact at all provided they are set to the same value. New installations should be encouraged however to at least split configuration / template overrides out of Main and into a separate config name.

The Config Load code would be set for existing sites to set undefined variables to defaults so that it is transparent for existing installations. New sites would ship and split out the a new SiteConfig web. I'm wondering if we should make it a "hidden" web - _SiteConfig, with the leading underscore? That makes it much less likely to collide with an existing web.

Config variable	Upgraded sites	New installations
{UsersWebName}	Main	Main
{HomeWebName}	Main	Main
{ConfigWebName}	Main	System/Config

-- GeorgeClark - 06 Mar 2018

Actually, underscore webs are reserved as template webs. We should use something else, probably. How about Config?

-- MichaelDaum - 06 Mar 2018

I thought that _ prefixes were a generic way to hide things in store, that was also used by template webs. I definitely didn't want to collied with templates, but was trying to hide the web from general listings, also avoid colliding with any existing names? Looking at the Foswiki::WebFilter code, you are spot on. So _ is out.

Adding a webname is going to cause someone issues, and Config is such a common word, it seems likely to collide. I don't like the idea of putting things in System, but what about System/Config subweb?

-- GeorgeClark - 06 Mar 2018

Yep, good idea.

-- MichaelDaum - 06 Mar 2018

My initial implementation of {ConfigWebName} defaults to System/Config location. MichaelDaum pointed out that will break the VirtualHostingContrib symlinks. Also, this location causes issues for anyone deploying in a container like Docker. A better default will probably be to move it to {HomeWebName}/Config, removing it from the System web path.

List of topics overridden by the %CONFIGWEB% location:

• Main.SitePreferences (And no longer shipped. Created on demand from System.SitePreferencesTemplate)
• %USERSWEB%.UserRegistration
• %USERSWEB%.GroupTemplate
• System/WebStatisticsTemplate
• %USERSWEB%.CommentPluginTemplate (optional)
• %USERSWEB%.InterWikis

-- GeorgeClark - 16 Apr 2018

This proposal was waiting too long for some actions, i.e. on implementing %HOMEWEB. Most of the previous actions have been on %CONFIGWEB ... which frankly weren't the primary intend of this proposal. The original idea was to differ the location of a "home" of a site from its users, i.e. be able to have all users in a separate web totally independent of the main entry point of the site ... which is not the case atm.

This proposal was later extended to cover configuration topics also being located in the same web by default. This is a lot more complicated and thankfully has been already implemented by George by piggy-packing this proposal.

Implementing the original proposal is going to be a lot easier and less intrusive.

Goal is to only use the %USERSWEB variable for users and groups and not for anything else such as config topics.

-- MichaelDaum - 19 Sep 2023

Commenting is disabled while not logged in