Manual:How to make a MediaWiki skin/Migrating SkinTemplate based skins to SkinMustache

From mediawiki.org

As part of the 1.35 release in 2020, the SkinMustache class was added to MediaWiki core. This development makes it possible to use Mustache templates to make skins. It should appeal to skin developers who do not wish to use PHP, or would like to reduce their dependency on PHP. This tutorial aims to demonstrate the steps you may need to convert a PHP based SkinTemplate skin to SkinMustache.

Step 1: Use Skin Registration[edit]

Previously, a skin would need to declare a Skin PHP class that extends the SkinTemplate. It would need to define several properties that were used to define the skins internal key and the associated PHP template.

Since 1.35, this information can be defined at time of skin registration.

The new registration process for skins is more powerful.
File SkinTemplate - old registration process SkinTemplate - new registration process
skin.json
{
    "ValidSkinNames": {
        "monobook": "MonoBook"
    }
}
{
    "ValidSkinNames": {
        "monobook": {
			"class": "SkinMonoBook",
			"args": [
				{
					"scripts": [
					    "skins.monobook.scripts"
					],
					"styles": [
					    "skins.monobook.styles"
					],
					"name": "monobook",
					"template": "MonoBookTemplate"
				}
			]
        }
    }
}
SkinMonobook.php
class SkinMonoBook extends SkinTemplate {
	/** Using MonoBook. */
	public $skinname = 'monobook';
	public $stylename = 'MonoBook';
	public $template = 'MonoBookTemplate';

	public function initPage( OutputPage $out ) {
	    parent::initPage( $out );
	    $out->addModules( 'skins.monobook.scripts' );
		$out->addModuleStyles( 'skins.monobook.styles' );
	}
}
class SkinMonoBook extends SkinTemplate {
}

Historically, skins have required the creation of 2 PHP classes. With the new registration process, you need at most 1 PHP class.

When declaring a skin, it's possible you can set the class value to "SkinTemplate" to use the default core interface:

{
    "ValidSkinNames": {
        "monobook": {
			"class": "SkinTemplate",
			"args": [
				{
					"name": "monobook",
					"template": "MonoBookTemplate"
				}
			]
        }
    }
}

If your Skin contains hooks, we recommend pulling those out into a separate file.

Here is an example for Monobook: gerrit:701142

Step 2: Unlock the power of templating[edit]

To follow this next step, it's assumed that a little knowledge of the Mustache template language has been acquired. At minimum, you should know the following Mustache basics described in the example below:

{{ str }} <!-- renders escaped string -->
{{{ html-str }}} <!-- renders RAW HTML -->

<!-- accesses data inside an associative array of the form { 'key' => 'hello' } -->
{{#array-data}} 
{{ key }} <!-- renders hello -->
{{/array-data}}

<!-- for boolean values -->
{{#is-talk-page}}
<!-- conditional rendering if is-talk-page is true -->
{{/is-talk-page}}

Hello World[edit]

Create a Mustache file with the relative path templates/skin.mustache

<div>
    <h1>My first Mustache skin</h1>
    <p><strong>Hello world!</strong></p>
</div>

To use the SkinMustache class, declare the class property as SkinMustache.

{
    "ValidSkinNames": {
        "monobook": {
			"class": "SkinMustache",
			"args": [
				{
					"name": "monobook"
				}
			]
        }
    }
}

Load the skin in your browser and you should see the contents of your Mustache file.

In MediaWiki versions prior to 1.37 you should also define templateDirectory and template:
{
    "ValidSkinNames": {
        "monobook": {
			"class": "SkinMustache",
			"args": [
				{
					"name": "monobook",
					"templateDirectory": "skins/Monobook/templates/",
                    "template": "skin"
				}
			]
        }
    }
}

Using a custom class[edit]

To aid migration, you'll want to use your own custom class that extends SkinMustache, at least as an interim step and start redirecting the code from your skin template into templates.

Create a new skin class that extends SkinMustache, for example for the MonoBook skin this might be named SkinMonoBook.

When using a PHP based template e.g. MonoBookTemplate, the skin developer is expected to implement an execute function that echoes HTML.

<?php
class MonoBookTemplate extends BaseTemplate {
    public function execute() {
        $html = $this->get( 'headelement' );
        $html .= $this->get( 'bodytext' );
        $html .= $this->getTrail();
		$html .= Html::closeElement( 'body' );
		$html .= Html::closeElement( 'html' );
        echo $html;
    }
}

In SkinMustache, the approach is different. We provide an associative array of template data that is passed to a Mustache template.

In the example that follows, we set new data to pass to the Mustache template

<?php
class SkinMonoBook extends SkinMustache {
    public function getTemplateData() {
        $data = parent::getTemplateData();
        $data['html-hello'] = '<strong>HELLO WORLD</strong>';
        return $data;
    }
}

With this change we can make the following change to our template to output the data.

Template which doesn't use template data Template using newly added template data
<div>
    <h1>My first Mustache skin</h1>
    <p><strong>Hello world!</strong></p>
</div>
<div>
    <h1>My first Mustache skin</h1>
    <p>{{{ html-hello }}}</p>
</div>

Using this technique we can bridge our old skin with SkinMustache.

First we may need to refactor our execute method to separate out a function that returns a string which represents the body of the skin. It's important to note in SkinMustache, you are restricted to templating the content of the body tag.

Original BaseTemplate BaseTemplate for usage in SkinMustache
<?php
class MonoBookTemplate extends BaseTemplate {
    public function execute() {
        $html = $this->get( 'headelement' );
        $html .= $this->get( 'bodytext' );
        $html .= $this->getTrail();
		$html .= Html::closeElement( 'body' );
		$html .= Html::closeElement( 'html' );
        echo $html;
    }
}
<?php
class MonoBookTemplate extends BaseTemplate {
    public function getHTML() {
        return $this->get( 'bodytext' );
    }
    public function execute() {
       /* This function needs to be present to implement BaseTemplate
         but is unused since we are using SkinMustache.
         The getTrail, headelement and closing body tags
         will be handled by SkinMustache.
       */
    }
}

In SkinMustache with this refactor done, we can extend the data we pass to a template as demonstrated with the html-hello example above. We can add a new template variable html-quick-template-migration which can be rendered inside our skin.mustache as raw HTML.

<?php
class SkinMonoBook extends SkinMustache {
    public function getTemplateData() {
        $data = parent::getTemplateData();
        $tpl = $this->prepareQuickTemplate();
		return $data + [ 'html-quick-template-migration' => $tpl->getHTML() ];
    }
}

Step 3: Embrace data[edit]

At this point you should have a skin implementing SkinMustache which is leveraging BaseTemplate to generate HTML. The PHP inside your PHP template that implements BaseTemplate should be possible with Mustache.

SkinMustache skins are data driven, which we believe gives better flexibility in how you want to render the data. The data is informed by skins in the wild. This data is documented elsewhere at Manual:SkinMustache.php#Template data.

There is little guidance on this step, other than explore how you can generate HTML code identical to your code in BaseTemplate using only the data and templates. Challenges you face while doing this should be raised on the talk page to help others.

Step 4: Fill out the missing data[edit]

During step 3 you may find HTML you are trying to generate cannot be rendered using the data inside SkinMustache. Hopefully from step 2 however you've realized you are not limited to the data you pass to your template.

However, it's useful for us to know about data that was missing, as it's likely your skin is doing something unique that may benefit other skins.

Simply by your code existing, you've communicated bits of data that would be helpful but you are invited to explicitly file Phabricator ticket requesting the data you need.