Page MenuHomePhabricator

mw:extension:Listings needs to be able to override defaults for listing format and parameters
Closed, ResolvedPublic


Author: carlb613

patch to allow template to override default Wikivoyage listing format

The format of a Wikivoyage listing tag, as generated by [[mw:extension:listings]], is hard-coded and rather inflexible. A mechanism is needed to allow the parameters or presentation style to be changed without editing the PHP code each time.

The listings are tags (eat, drink, see, do, buy, sleep) for historical reasons. All behave identically; the parameters are fed into Listings.body.php where private static function listingsTag( $aType, $input, $args, $parser ) is effectively a template written in hard-coded PHP.

There has already been at least one request on [[voy:Wikivoyage_talk:Listings]] to change this hard-coded format but that can't be done if there's no way to override the listingsTag() function.

I propose, simply, to change listingsTag() to look for a plain, standard template. If one exists, call it and let it deal with formatting the listing; if not, proceed as before.

The change requires inserting the following code into Listings.body.php at the start of the listingsTag() function:

private static function listingsTag( $aType, $input, $args, $parser ) {

		 * if a {{listings}} template exists, feed tag name and parameter list to template verbatim and exit
		if ( !wfMessage( 'listings-template' )->inContentLanguage()->isDisabled() )
			$ltemplate = wfMessage( 'listings-template' )->inContentLanguage()->text();
		if ( $ltemplate != '' ) {
			$inputtext = '{{' . $ltemplate . '|type=' . $aType;
			foreach ($args as $key => $value)
				$inputtext .= '|' . $key . '=' . $value;
			$inputtext .= '|' . $input . '}}';
			$out .= $parser->internalParse( $inputtext );
			return $out;

		 * if no pre-defined template exists, generate listing from parameters normally

Version: master
Severity: normal




Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 12:53 AM
bzimport set Reference to bz43220.
bzimport added a subscriber: Unknown Object (MLST).

carlb613 wrote:

Listings.body.php with patch applied to allow template to override listing format

When the patch is initially applied, the extension continues to operate as it always has... until [[mediawiki:listings-template]] is created and set to the name of a template (ie: "listing" for [[voy:template:listing]], which would work well with this code were the leading "* " removed from the template).

Once the listings template is defined, listingsTag() generates {{ listings-template | type= (eat, drink, sleep) | name=...and any other parameters, passed through as-is| listing $input text... }}, feeds it to the parser to expand the template to output text and then exits without doing much of anything else - effectively shutting down the hard-coded output formatting built into the extension.


Hi! Thanks for your patch!

You are welcome to use Developer access

to submit this as a Git branch directly into Gerrit:

Putting your branch in Git makes it easier for us to review it quickly.
Thanks again! We appreciate your contribution.

carlb613 wrote:

How do I get this fix verified and code reviewed for deployment?

It has been sitting in 'git' untouched since Dec 22, 2012 7:27 PM and it *is* needed if Wikivoyage is to add wp="" (to link from an individual listing to a Wikipedia article on a landmark) or any other new fields using the template.


Someone with access must approve it. It seems that Matthias Mullie should really be the person to ask, though technically others (,members) are capable of it.

Matthias Mullie approved that change - is this bug fixed now?

carlb613 wrote:

If by "approved" this means "currently waiting for deployment", that would remove patch-needs-review and add a shell request to deploy this to Wikivoyage?

By approved it means currently in the master version of the code, so marking this bug as RESOLVED FIXED.

As for when Wikimedia updates their copy of the extension... Well, this seems like an enhancement to me so I doubt it'll be deployed before 1.21wmf9 phase 2.