This functionality is actually not as easy as you describe it. That code change you describe does not take into account that the addToSidebar line is in the middle of caching code. If the sidebar cache is enabled, you can actually end up with a logged out sidebar showing to logged in users, or a logged in sidebar showing to logged out users, because that's what happens to be in the cache.

I've been considering this in my skin rewrite plans. However I still haven't been shown an example where having two sidebar versions is a valid case, that isn't actually part of a hack to work around something that should actually be fixed instead of adding this hack.

Tbh, I almost want to WONTFIX this until someone actually gives a valid example of why one would want two separate sidebars.

paolobenve wrote:

The user case is that of a wiki where unregistered users aren't allowed to edit pages: unregistered users are readers while registered users are editor.

In that case unregistered users are to be given a "reader's sidebar", with links which are appropriated to their tasks.

Registered users, on the contrary, are to be given different links in order to do their work.

About the caching, my wiki implements the double sidebar as described in the description. I'm experimenting on it, with two browser, one logged in and the other not logged it. My wiki uses memcached caching. In LocalSettings I have:

$wgMainCacheType = CACHE_MEMCACHED;
$wgParserCacheType = CACHE_MEMCACHED; # optional
$wgMessageCacheType = CACHE_MEMCACHED; # optional
$wgMemCachedServers = array (

0 => '127.0.0.1:11211',

);
$wgSessionsInMemcached = true; # optional

Loading the same page at the same time with the two browsers shows the correct (logged in or not logged in) sidebar. I.e.: apparently the caching doesn't apply to the sidebar.

paolobenve wrote:

CORRECTING MY PREVIOUS COMMENT.

I hadn't understood clearly, you were referring to sidebar caching, while I meant article caching.

I think things can be done at least in the case when $wgEnableSidebarCache isn't set, with the code:

if ($wgEnableSidebarCache || $wgUser->isLoggedIn() && $wgTwoSidebars) $this->addToSidebar( $bar, 'sidebar' );
else $this->addToSidebar( $bar, $wgAlternateSidebar );

This code treats 'sidebar' (default) as the sidebar for logged in user; perhaps it's better to consider default sidebar that for not logged in user and $wgLoggedInSidebarName the sidebar name for logged in users.

This way the code would become:

if (! $wgUser->isLoggedIn() || $wgEnableSidebarCache || ! $wgTwoSidebars) $this->addToSidebar( $bar, 'sidebar' );
else $this->addToSidebar( $bar, $wgLoggedInSidebarName );

paolobenve wrote:

Daniel, have you thought anything about this enhancement?

(In reply to comment #4)

Daniel, have you thought anything about this enhancement?

I'm still not entirely sold on this idea of the logged in sidebar being different. editor == user is actually a false assumption.

Instead of a $wgTwoSidebars I'd make it something like MediaWiki:anonsidebarwhich if non-empty overrides MediaWiki:sidebar (or both MediaWiki:sidebar-anon and MediaWiki:sidebar-user)
Similar to how we have both MediaWiki:sitenotice and MediaWiki:anonnotice

paolobenve wrote:

MediaWiki:anonsidebarwhich looks like a pretty solution!!!

Just to make it clear. Even if someone came up with a good rationale for this I wasn't planning on coding something like anonsidebar or a $wg.

My end goal is to rewrite this whole sidebar system and ditch this bad way of configuring things. If anon/user links were to be used it would be done in part of a UI with a toggle.