Page MenuHomePhabricator

different boilerplates per namespace
Open, MediumPublicFeature


patch for per-namespace boilerplates

A customer requested to be able to define a different set of boilerplates per namespace.

I implemented this by using Mediawiki:Multiboilerplate-<namespacenumber>, for example Mediawiki:Multiboilerplate-12 contains page templates for the help namespace. The main namespace still uses Mediawiki:Multiboilerplate (without "-0").

Additionally I introduced a new config variable


to enable the per-namespace boilerplates (default is disabled for backwards compatibility).

The patch for MultiBoilerplate.php is attached.

Version: unspecified
Severity: enhancement




Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:01 PM
bzimport set Reference to bz22759.

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

sumanah wrote:

Adding "need-review" keyword to indicate patch awaits review. Regrets on the wait.

This is an updated patch that works with MediaWiki 1.27.

Note that I didn't find an obvious place to add

+/* Whether or not to use per-namespace boilerplates. Uses Mediawiki:Multiboilerplate-<namespacenumber>,
+ * for example -12 for the help namespace. No -0 suffix for main namespace.
+ * Requires $wgMultiBoilerplateOptions = false to work.
+ */
+$wgMultiBoilerplatePerNamespace = false;

and therefore simply dropped this part of the patch.

Also note that I only tested with $wgMultiBoilerplatePerNamespace = true ;-)

@Cboltz, first of all: thanks!

Secondly, what version did you patch against? Both master and 1.27 branches were slightly reworked, and your patch doesn't match them (it has the "$things" variable, for example).


  1. The location for the usage comment is in the file, under "Configuration".
  2. I think you are missing a check for the existence of the message. The regular 'Multiboilerplate' message is guaranteed to exist, as we define it in the i18n files, but the namespace ones are not.
  3. How about updating SpecialBoilerplates so it can display these as well?

My patch is based on MultiBoilerplate-REL1_27-27901e1.tar.gz which I downloaded via (for 1.27) the same day I uploaded the updated patch here.

IIRC (tested some years ago with an old MediaWiki version, so you might want to re-test) non-existing messages give you an empty result, which is the same as an existing empty message - no boilerplates for this namespace.

To also answer questions 1 and 3 - I don't use SpecialBoilerplate and also don't really need the documentation in README for this change, so my overfilled TODO list says that I probably won't have time to update them in the near future ;-)

Hi Cboltz, I definitely symphatize with the overfilled todo - my queue never empties too - but this means the patch is just not good enough to make it into the code, which requires proper documentation and no loss of functionality.

Having undocumented functionality is of course not useful, and even harmful. Not keeping SpecialBoilerplate up-to-date with other changes in the extension makes it obsolete, and while I personally do not use it, some do.

As the maintainer I'd like to see this extension gain more functionality, but as a user I do not personally have a need for it. Therefore I do not know if I will find the time to make the required changes.

I believe you should have a vested interest in getting your patch merged, because then you won't need to keep your own fork / update your patch - this is always true in OSS, I believe - but that's your own choice. Thank you for sharing the code with all of us anyway!

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 12:24 PM