(presumably this might need to go within MediaWiki-extensions-CommunityConfiguration (or another extension), in order to avoid MW core [soft-]depending on a specific extension?)

Yes, it should be in an extension. The extension could use the SkinBuildSidebar hook – while its intended purpose is a bit different (it’s meant for additions, not for complete overwrite), I think it’s flexible enough to serve this use case as well.

In T402395#11102801, @A_smart_kitten wrote:

(presumably this might need to go within MediaWiki-extensions-CommunityConfiguration (or another extension), in order to avoid MW core [soft-]depending on a specific extension?)

I'm not really a fan of that, as CommunityConfiguration is supposed to merely provide the platform for on-wiki configuration, it is not supposed to make use of it. I think that this would need to wait for the far-distant future, where Core would be conceptually aware of community configuration (by having relevant interfaces ready, but no actual implementation). That way, CommunityConfiguration the extension could adopt those interfaces and provide the implementation. This would allow Core to use CommunityConfiguration if it exists. In addition to that, it would also make it possible to implement alternative implementations of CommunityConfiguration, if anyone so decides in the future.

Core does something like this in several places already. For example, Core provides functions like User::isLocked (awareness of "users might be locked" at the conceptual level), but does not provide any actual implementation for locking or unlocking users – all that function does is calling a hook that CentralAuth then subscribes to. Similarly, UserRegistrationLookup lets you find the global user registration timestamp – even though Core does not implement anything like that on its own.

In addition to that, implementing this in (any) extension, whether MediaWiki-extensions-CommunityConfiguration or a brand new one, is not really advisable on its own. This is because the reading of MediaWiki:Sidebar happens in Core, and presumably would continue happening in Core. While an extension can reasonably easily write MediaWiki:SIdebar via CC-provided interfaces, Core would continue reading it directly.

This might seem fine, but CommunityConfiguration provides the infrastructure for other storage backends, which might be implemented in the future. If that happens, CommunityConfiguration-provided interfaces would serve the right configuration data with no issues, but any direct reads would stop working immediately.

Unfortunately, providing this level of awareness into Core would be a long-running (and so far, unplanned) project. However, it seems to be necessary for this kind of use-case, I'm afraid.

Then maybe another, new extension that depends on CommunityConfiguration? It’d be pretty small extension, but small extensions do exist (e.g. CharInsert, which just provides a parser tag, or SandboxLink, which includes a single link to the personal toolbar).

In T402395#11112730, @Tacsipacsi wrote:

Then maybe another, new extension that depends on CommunityConfiguration? It’d be pretty small extension, but small extensions do exist (e.g. CharInsert, which just provides a parser tag, or SandboxLink, which includes a single link to the personal toolbar).

In theory, that would be viable. However, even a new extension wouldn't be able to provide configuration via MediaWiki:Sidebar directly, as the task specifies. This is because the page would continue being read from Core (not from the extension). More specifically, the problem is MediaWiki:Sidebar would be read directly using Core's interfaces (specifically, IContextSource::msg), rather than using CommunityConfiguration's interfaces (IConfigurationProvider::loadValidConfiguration()).

This is a problem, because CommunityConfiguration makes it possible to define other configuration stores (backends for storing configuration data) than wikipage. This might include stores that are not accessible publicly (for example, a dedicated database).

If CommunityConfiguration data is read through CommunityConfiguration's interfaces, everything works correctly– CommunityConfiguration would know what configuration store is used at any given time, and it would read the data correctly. However, any direct accesses to a specific page (such as MediaWiki:Sidebar) would just stop working in that case. In other words: using the extension just for writing the configuration would only adopt CommunityConfiguration half-way. Personally, I don't think that's a good idea, even though technically possible.

That all being said...it would be possible to re-build the user-editable sidebar in an extension, using the SkinBuildSidebar hook. That way, the extension would have full control about the content of the sidebar, and could use CommunityConfiguration for that.

Whether it makes sense to have two identical features, one implemented in Core and other implemented in an extension can be subject to discussion. It certainly does not seem ideal, but it seems better than getting half-way-through by using MediaWiki:Sidebar directly. For what it is worth, Notifications are in a similar situation (notifications for watchlist changes look very different from eg. user rights changes, as one is in Core, the other one is in Echo), and it does not seem to be a good thing.

In T402395#11112978, @Urbanecm_WMF wrote:

That all being said...it would be possible to re-build the user-editable sidebar in an extension, using the SkinBuildSidebar hook. That way, the extension would have full control about the content of the sidebar, and could use CommunityConfiguration for that.

Yes, I also imagined doing that. CommunityConfiguration is built around JSON pages, one per feature, so writing many wikitext and custom-syntax pages in a feature sounds risky.

Whether it makes sense to have two identical features, one implemented in Core and other implemented in an extension can be subject to discussion. It certainly does not seem ideal

Specifically in case of CommunityConfiguration, it actually isn’t that unique: many extensions integrating with CommunityConfiguration provide a fallback configuration method (which is usually the original, LocalSettings.php-based one); what I propose is basically the same: a CommunityConfiguration-based configuration (provided by the extension) and a fallback configuration (provided by core).

For what it is worth, Notifications are in a similar situation (notifications for watchlist changes look very different from eg. user rights changes, as one is in Core, the other one is in Echo), and it does not seem to be a good thing.

Echo/Notifications is a bit different: what I propose, would result in any particular wiki using either the core configuration or the CommunityConfiguration one; the problem with Echo is that both email sending methods are in use on the same wiki.

While editing https://www.mediawiki.org/wiki/Help:Extension:Translate/Unstructured_element_translation, I realized the current system has an important feature: it allows sidebar elements to be translated. While it’s of concern on relatively few wikis (mainly the multilingual ones), it’s crucial there. CommunityConfiguration cannot handle translatable configuration values right now, can it?

(adding to the extension-requests board for visibility, as one potential way of implementing this)