Project CSP/Store metadata in a different MCR slot

The purpose of storing metadata in a different MCR slot is to separate different aspects of a page so that

• each aspect can have its own optimal user experience
• supporting the CSP features is less complex and more reliable

What is an MCR slot?

With the MCR feature MediaWiki provides a way to store content in multiple slots on a single page. We are used to having one slot, the 'main' slot. This is the slot you can edit when you hit 'edit' or 'edit source'. With MCR additional slots, e.g. the 'metadata' slot, can be defined in a wiki through an extension. A slot typically has a name and a content-model. The content-model defines what kind of content the slot is for. This can be wiki-text, but also other kind of content, such as JSON. Let's assume an additional slot called 'metadata' with wiki-text content.

What does metadata in a different slot look like?

Metadata in a different slot looks the same as it looks in the main slot: as a template call with parameters. So when you would have

{{Article metadata
 |Title=Store metadata in a different MCR slot
 |Author=Ad Strack van Schijndel
 |Status=Draft
 |Archived=No
 }} 

in the source code (main slot), exactly the same wiki-text would end up in the metadata slot.

How do you edit content in another slot?

The content in another slot can only be edited through an extension. There is no standard UI, or 'edit metadata source' available for the user.

We have adapted WSForm for use with multiple slots. In the definition of a form you can specify in which slot the data is stored. We have also developed the extension 'WSSlots' that enables definition of slots in LocalSettings.php and provides parser functions to retrieve information from slots. WSSlots is needed to have the form fields filled with the current values.

What is done with the content of another slot?

By default nothing is done with that content. Where the content of the main slot is parsed and shown on the page, the content of additional slots just sits there. You need extensions to get the content out of it and do something with it.

When the slot is used for storing metadata, such as our 'metadata' slot, the trick is to have SemanticMediaWiki parse the metadataslot (as well or only that slot) and produce the properties of the page. We have developed an addition to SemanticMediaWiki that does just that. The metadataslot is parsed as usual by MediaWiki, which results in having properties with the page as usual.

For this the content of the template 'Article' would look like this:

{{#set: Title={{{Title|}}}|Author={{{Author|}}}|Status={{{Status|}}}|Archived={{{Archived|}}} }}

This is probably only part of what would be in an 'Article' template when called on the main slot. After all, the template would then also responsible for showing the information on the page. In the CSP approach this is done with another template in a different UI component.

Do changes in other slots appear in the history?

Difference in page history shows the slot name if it is not 'main'.

They do and the change looks as usual. The only difference is the name of the slot when it is not the main slot.