DEV Community: Luca Mauri

Messages on Mediawiki sidebar with Javascript

Luca Mauri — Fri, 26 Mar 2021 16:59:21 +0000

This is the story of a seemingly simple and straightforward modification to a user interface that led me far away from where I started and that taught me lessons I'd like to share with the community here.

During the development of LUA code for the Wiki I manage, I often needs to see raw data from my custom Wikibase instance, thus presented in JSON format.
Wikibase allows a very simple way of accessing JSON representation of any given item by accessing the EntityData special page with the syntax

/Special:EntityData/Q1.json

Every time the user needs to access this page is necessary to go to the list of special pages, or remember the syntax and manually write the URL taking note of the item's number.
This is clearly inconvenient, so I looked for a better way to easily get the JSON I needed.
The sidebar of a Wikibase instance, under Tools group, contains a link named Concept URI, handy to quickly get the URI of the item in the main page. From here I took the idea of creating a link on the sidebar to easily reach the JSON content I needed.

Easy start

I was already familiar with the sidebar customization as explained in Mediawiki website, but in the past I used to make static modifications, like adding external links. In this case, on the contrary, I needed a way to dynamically generate a link and only for specific pages.

By attentively reading further that same document it became clear to me I could add a code fragment in MediaWiki:Common.js file to programmatically generate the link. The code example basically does already what I wanted to, I simply had to add a code to get the specific page information, like:

var conf = mw.config.get([
    'wgServer',
    'wgWikibaseItemId',
    'wgPageName'
]);

then generate the URL and call the function exactly like the example:

ModifySidebar('add', 'toolbox', messageName, conf.wgServer + '/wiki/Special:EntityData/' + ItemName[1] + '.json');

and that was it.
It worked fine, it seemed I solved the problem in a few minutes.

Just one question

But then I asked myself: what about internationalization? The code example simply created a tag with the fixed text specified in name parameter, but my Wikibase instance is normally accessed both in Italian and English, so it would ideally need multi-language support.

Again, seemingly easy thing to do: MediaWiki provides a standard mechanism to use messages: the code contains placeholders string only, while the actual content of the string is defined in the user interface.
So I wanted to create a message called something like t-menu-label and being able to customize it by writing text in the pages:

MediaWiki:T-menu-label\it
MediaWiki:T-menu-label\en
MediaWiki:T-menu-label\de
and so on…

I originally looked at the documentation on message handling, but, with that instructions, I was only able to handle messages within the code.
I couldn't find a way to let the user customize messages with the MediaWiki: mechanism explained above.

Look closer

It unfortunately took me a lot of effort to understand that I should have used a different approach to the problem. In fact the method I needed to use was the one explained in the message documentation.
When I first read it, I was under the impression that this only was necessary to load default messages from MediaWiki core, so I discarded it as a way to use my own custom message.
I was wrong: this system can be used to load any message from MediaWiki: if the one requested does not exist in MediaWiki core, then it can be created as a custom one as explained above.

The final solution

With this new understanding, I was finally able to put together the needed code to achieve my desired result.
Let's jump at it, with some comments.

Call it

jQuery(sideJSONMessage('t-wb-json'));

function sideJSONMessage(messageName) {
    jQuery.when(mw.loader.using(['mediawiki.api', 'mediawiki.jqueryMsg']), jQuery.ready ).done( function() {
        new mediaWiki.Api().loadMessagesIfMissing([messageName, 'tooltip-' + messageName]).done( function() {
            AddJSONLinkToSidebar(messageName);
        });
    });
}

This fragment of code starts the whole chain of events by identifying the name of the event to load, check that all the APIs are loaded and then proceeding to read the said message.

t-wb-json is both the name of the message and the element ID of the HTML tag we'll create, this follows the conventions already in use in the sidebar.
So, the menu Concept URI is identified by t-wb-concept-uri, my custom menu:

belongs to Tools group
pertains Wiki Base
is about a JSON data output

Thus t-wb-json, in short.

Beside messageName, another message called 'tooltip-' + messageName will be loaded. This will be useful to further describe the menu item, as explain later below.

Check page type

function AddJSONLinkToSidebar(messageName) {
    var conf = mw.config.get([
    'wgServer',
    'wgWikibaseItemId',
    'wgCanonicalNamespace',
    'wgPageName'
    ]);

    var PageName = conf.wgPageName;
    var nameSpace = conf.wgCanonicalNamespace;
    var nameSpaceList = ['Item', 'Property', 'Lexeme']

    if (nameSpaceList.indexOf(nameSpace) > -1) {
        var ItemName = PageName.split(':');
        AddItemToSidebar('toolbox', messageName, conf.wgServer + '/wiki/Special:EntityData/' + ItemName[1] + '.json');
    }
}

With mw.config.get we can obtain all the useful information about the Wikibase instance and the current context.
All these data are needed to create the link, but first of all is necessary to check that the page actually represent an item, otherwise the JSON output would be meaningless and then non-existent.

Update 2021-04-01
I wrote a better code to check for the page type. The previous iteration used to analyze the substring for the text item, now I make use of wgCanonicalNamespace to programmatically check the page namespace in more consistent way.

Do the job

function AddItemToSidebar(section, idName, link) {
    var target;

    try {
        switch ( section ) {
            case 'languages':
                target = 'p-lang';
        break;
        case 'toolbox':
                target = 'p-tb';
                break;
            case 'navigation':
                target = 'p-navigation';
        break;
            default:
                target = 'p-' + section;
                break;
        }

        var node = document.getElementById( target )
        .getElementsByTagName( 'div' )[0]
            .getElementsByTagName( 'ul' )[0];

        var aNode = document.createElement( 'a' );
        var liNode = document.createElement( 'li' );

        aNode.text = mw.message(idName).text();
        aNode.setAttribute( 'href', link );
        aNode.setAttribute( 'title', mw.message('tooltip-' + idName).text());

        liNode.appendChild( aNode );
        liNode.id = idName;

        node.appendChild( liNode );

    } catch( e ) {
        // let's just ignore what's happened
        return;
    }
}

First of all, the function identifies the proper UL object by using the name of the section and then referencing the first DIV. Then a new LI is created to contain the A link.

All the magic happens in

aNode.text = mw.message(idName).text();

and in

aNode.setAttribute( 'title', mw.message('tooltip-' + idName).text());

where the text of the link is set by reading the message loaded in the first fragment of code, above.
In the same way, another message with the same label prefixed by tooltip- (again, loaded above in the first step) is assigned to title attribute: this will thus be shown as a tool-tip on mouse over.

Finally, the node is given the same name as the message as id attribute, for naming consistency, and all the element are properly concatenated into the DOM.

Setting the text

Now that the code is ready, it is necessary to set the proper text for the messages. Remember that the code will ask Mediawiki engine for two messages called t-wb-json and tooltip-t-wb-json: if they are not set, a placeholder will be shown.

To fill them, let's simply create two pages named MediaWiki:T-wb-json and MediaWiki:Tooltip-t-wb-json. Their content will become the label and the tool-tip of the link, respectively.
This will work in the wiki's primary languages, but additional languages can simply be set by using subpages with the ISO code of the language, so we can create the pages

MediaWiki:T-wb-json/it
MediaWiki:T-wb-json/de
MediaWiki:T-wb-json/fr
…
MediaWiki:Tooltip-t-wb-json/it
MediaWiki:Tooltip-t-wb-json/de
MediaWiki:Tooltip-t-wb-json/fr
…

and fill them with the text in the proper language.

Experiment more

This experience taught some interesting lessons about the inner workings of MediaWiki messages interface: a seemingly easy code actually hides a lot of complexity in research.

Another lesson I learnt is to experiment more and don't stop where I think the point is, because sometimes the point is somewhere, as I saw here.

Finally, I must unfortunately point out again that MediaWiki documentation is fragmented and not always very clear to the final user.

Auto-updating field in CorelDraw

Luca Mauri — Wed, 17 Feb 2021 22:35:30 +0000

It is common feature of several applications to have so-called fields: small chunk of text that shows contestual data. Common examples are current date, number of page or file name: thigs that we often print in header or footer of documents.
This is a functionality so commond that we take it for granted in all applications.

On great use of them is to auto update the Title block in technical drawings.
Below a common example of a block containing date, filename and layout name: all these data are predefined fields in applications such as AutoCAD, so it's very easy to add them.

In other design software these fields does not exists, so it is necessary to came up with a custom solution. In this case I will replicate the behaviour of a AutoCAD Title block in CorelDraw. I am going to use VBA so the same logic might apply to other applications with the appropriate modification to syntax.

When to run it

First of all it is necessary to decide when to trigger the update. I resolved to do this right before saving and printing. This way the data on the block are updated in the stored version of the file and on paper.

So, in the VBA editor, I modified the BeforeSave and BeforePrint events:

Private Sub Document_BeforePrint()
    Call UpdateTextFields
End Sub

Private Sub Document_BeforeSave(ByVal SaveAs As Boolean, ByVal FileName As String)
    Call UpdateTextFields
End Sub

The function

The first step is to store the names of the field in an array of string.
Then the procedure iterates among all the pages to search for the appropriate text boxes in the whole document.
Once found one of the box, the content is updated according to the name (and, by extension, to the type) of the box.
Here's the full code:

Private Sub UpdateTextFields()
    Dim CurrPage As Page
    Dim CurrShape As Shape
    Dim Texts(2) As String
    Dim CurrText As Variant
    Dim Output As String

    Texts(0) = "TextDate"
    Texts(1) = "TextPageName"
    Texts(2) = "TextFileName"

    For Each CurrPage In ActiveDocument.Pages
        For Each CurrText In Texts
            Set CurrShape = CurrPage.Shapes.FindShape(CurrText)
            If Not CurrShape Is Nothing Then
                Select Case CurrText
                    Case Texts(0)
                        Output = Format(DateTime.Now, "Short Date")
                    Case Texts(1)
                        Output = CurrPage.Name
                    Case Texts(2)
                        Output = ActiveDocument.FileName
                End Select
                CurrShape.Text.Story = Output
            End If
        Next
    Next
End Sub

The function looks in all the document's pages the three textbox named as in the array. If the text exists, then it will replace the content with the proper value.conta

Apart from the obvious code, a point of interest here is the property Text.Story that actually contains the text.

System.Text.Json in action with practical example in VB.net

Luca Mauri — Sun, 16 Aug 2020 11:35:19 +0000

XML is almost 25 years old and it is now a format that is widely-known to the point that also non tech-savvy people have at least a vague notion of it. The format was originally meant to encode documents in a format that is, of course, machine-readable, but that is friendly enough to also be human-readable.
It has been criticised for its complexity and the difficulty to exchange data structure between application.

For this reason, the format known as JavaScript Object Notation (JSON) came to prominence as a less verbose (albeit less human-readable as well) alternative for data interchange.
In this article I am going to show the creation of a JSON data structure to be used to programmatically create (or modify) an item on a WikiBase instance using the WikiBase API with VB.net.

JSON in .NET

Before NET Core 3.0 and .NET Framework 4.7.2 using JSON in .NET was much more complicated than, say, XML. The choices were to use the somewhat limited JavaScriptSerializer class, that was specifically designed for AJAX-enabled applications, or move to the popular Json.net library.
Starting with the above-mentioned versions, however, .NET finally started to offer a serious implementation of classes intended for JSON manipulation.
This has been announced in the .NET Blog, in a post called Try the new System.Text.Json APIs that I suggest you read if you like to know more about the implementation.
In the rest of this article I will show you a practical use of this new component.

The problem

For a project of mine, I need to massively create and edit items into a WikiBase-enabled MediaWiki installation. WikiBase is the extension that powers WikiData, but can be used on custom wiki site as well.
Any WikiBase-equipped site (WikiData included, of course, if you are wondering) allows interaction through WikiBase-specific API.
To programmatically access and edit MediaWiki content I already used the excellent DotNetWikiBot framework so I decided to expand it, using its already existing infrastructure to add WikiBase-specific functions (work is still underway on this project, but I will eventually release it as opensource, ideally integrating it into existing code).

Data into WikiBase are easily accessible as a JSON formatted data by accessing the EntityData special page like, for instance:

https://www.wikidata.org/wiki/Special:EntityData/Q96482610.json

When using the API, JSON data are of paramount importance to create or edit entities or part of them. Thus, handling JSON into my .NET application was crucial.

My first task was to create a set of Properties into the WikiBase instance, so I needed to use the wbeditentity module following the example

Create a new property containing the json data, return full entity structure
api.php?action=wbeditentity&new=property&data={"labels":{"en-gb":{"language":"en-gb","value":"Propertylabel"}},"descriptions":{"en-gb":{"language":"en-gb","value":"Propertydescription"}},"datatype":"string"}

The data parameter containing the JSON data.

The solution

My application is a form-based one as I need to easily interact with the interface and be able to read and store results in various controls.
So first of all I needed to add the System.Text.Json (in contrast, this library is already part of the .NET Core 3.0) via the NuGet package.

This library allows object serialization, but this is too complex for my needs, as I would prefer manipulating the DOM without the need of creating corresponding classes in my code. While the solution might seem less elegant than having the full JSON structure created as .NET structure in classes and then simply serialize them into JSON with a single command, the reality is that the sheer code needed to create all the classes would have been much more than the one needed to directly handling the JSON DOM.
That being said, it remains the fact that JSON serializer is very useful and might be object of a future article.

First steps

So the first steps to me were to familiarize with the Utf8JsonWriter method so I started converting the C♯ example to the following VB.net example:

Pay special attention at the Writer.Flush() method that can easily be overlooked, but that is critical for the stream to be filled with actual data.
As this worked as intended, I could proceed with the final version of the subroutine

The practical code

In order to create a Property in Wikibase you need to provide JSON data as a parameter to the API call to set the labels (in the proper language), the related descriptions and [datatype](https://www.wikidata.org/wiki/Help:Data_type) defining the type of the data the property will contain.

An example would be:

{
  "datatype": "string",
  "labels": {
    "en": {
      "language": "en",
      "value": "Label"
    },
    "it": {
      "language": "it",
      "value": "Etichetta"
    }
  },
  "descriptions": {
    "en": {
      "language": "en",
      "value": "Description"
    },
    "it": {
      "language": "it",
      "value": "Descrizione"
    }
  }
}

With labels and descriptions in English and Italian.

I started by creating an helper class like this:

Class LabelsWithDescription
    Public ReadOnly Property Culture As String
    Public ReadOnly Property Label As String
    Public ReadOnly Property Description As String

    Sub New(Culture As String, Label As String, Description As String)
        Me.Culture = Culture
        Me.Label = Label
        Me.Description = Description
    End Sub
End Class

Please note that this class cannot be serialized as it is: it holds all the necessary information, but not in the right structure. So it will only help creating the structure. As mentioned above, creating the proper structure in VB and then serialize it would have been more complicated and time consuming in comparison to writing the DOM directly. At least this is the case for the current example, of course this depends on the situation and the reader must evaluate this on a per-case basis.

Let's start to initialize the objects:

Sub New(IndentOutput As Boolean)
    Dim WriterOption As JsonWriterOptions

    With WriterOption
        .Indented = IndentOutput
    End With

    MemStream = New System.IO.MemoryStream
    JSONWriter = New Utf8JsonWriter(MemStream, WriterOption)
End Sub

We are creating here

a Utf8JsonWriter that actually format and writes data
its WriterOption (needed to chose if indent the cose for readability, or minify-it with no spaces) and
the MemoryStream holding result.

An now, finally, the function doing the job:

Function PrepareNewItemData(ItemLabels As List(Of LabelsWithDescription), DataType As String) As String
    With JSONWriter
        .WriteStartObject()
        .WriteString("datatype", DataType)

        .WriteStartObject("labels")
        For Each Label As LabelsWithDescription In ItemLabels
            .WriteStartObject(Label.Culture)
            .WriteString("language", Label.Culture)
            .WriteString("value", Label.Label)
            .WriteEndObject()
        Next
        .WriteEndObject()

        .WriteStartObject("descriptions")
        For Each Label As LabelsWithDescription In ItemLabels
            .WriteStartObject(Label.Culture)
            .WriteString("language", Label.Culture)
            .WriteString("value", Label.Description)
            .WriteEndObject()
        Next
        .WriteEndObject()

        .WriteEndObject()
        .Flush()
    End With
    Return Encoding.UTF8.GetString(MemStream.ToArray())
End Function

The first couple of commands basically start writing

{
  "datatype": "string",

The tricky parts comes afterwards where the method .WriteStartObject("labels") output the fragment

  "labels": {

in the JSON structure, allowing other content to be added to this "node".
The two For Each basically uses the same strategy to create an Object with the name of the language and the related Labels, in the first cycle, and Descriptions, in the second cycle.

The final .WriteEndObject() basically closes the whole data fragment and the very important .Flush() commits actual data to the stream that can be converted to string with .GetString.

Now we can put everything to work with:

Dim JSONTest As New JSONEditor(False)
Dim LabelsList As New List(Of JSONEditor.LabelsWithDescription)

LabelsList.Add(New JSONEditor.LabelsWithDescription("en", "Label", "Description"))
LabelsList.Add(New JSONEditor.LabelsWithDescription("it", "Etichetta", "Descrizione"))

MessageBox.Show(JSONTest.PrepareNewItemData(LabelsList, "string"))

The output will be

{"datatype":"string","labels":{"en":{"language":"en","value":"Label"},"it":{"language":"it","value":"Etichetta"}},"descriptions":{"en":{"language":"en","value":"Description"},"it":{"language":"it","value":"Descrizione"}}}

our intended JSON payload as above, but in minified format.

Conclusion

System.Text.Json is intended to be a easy-to-use, fast and integrated alternative to third-party JSON editors. This first adventure using it was a bit bumpy mainly because of the lack of detailed documentation and real examples on the internet, basically, I guess, because it is very new and not yet much used.
Nevertheless it seems to me using is is really worth the minor pain of searching and experimenting.
With this little story of mine I hope having helped other users to get start with it a little faster than I originally did.

Organize Interwiki and Sites in MediaWiki for best efficiency

Luca Mauri — Sat, 25 Apr 2020 13:14:23 +0000

Within the scope of MediaWiki, InterWiki links and the sites table seems to have little in common, on the contrary in this article I will explain how a unified management of this two features can simplify working with both and clear the readibility.

Anatomy of Interwiki

Interwiki links are special links that allows to reach a page on a MediaWiki installation on any kind, such a custom one, or any Wikipedia site.
This functionality works an a MediaWiki installation out of the box as several InterWiki links are defined by default. So you can immediately use links like these

[[wikipedia:Jean-Luc Picard|Jean-Luc Picard on English Wikipedia]]
[[memoryalpha:Jean-Luc Picard|Jean-Luc Picard on English ''Memory Alpha'']]

to call pages on a foreign wiki – in this specific example, the English Wikipedia and the English Memory Alpha wikis – without using external links.

You might notice something strange in the above wikilinks: the prefixes followed by the colon symbol and then a title of the page.
These prefixes instruct the MediaWiki installation to link a page in another site running MediaWiki, it has several advantages against a plain HTML external link, readability and the lack of "external website" warning on save, among the others.
A complete explanation on interwiki links is on the manual, for those interested. For the moment be content to know that the magic is done by the information matched with the iw_prefix in the interwiki table in the database.
Keep this information in mind for later in this article.

SiteLinks and `site` table

The site database table is of paramount importance for another feature called "SiteLinks". While you might be familiar with SiteLinks as a feature of WikiData, linking any item to pages on sites of the Wikipedia family, in general terms those are special links coming from any MediaWiki site with Wikibase installed to any other MediaWiki installation.

SiteLinks needs first to be enabled and configured in the WikiBase Repo with a string like:

$wgWBRepoSettings['siteLinkGroups'] = [ 'wikipedia', 'mywikigroup', 'anothergroup' ];

The "groups" mentioned in the above configuration are defined in the sites table we discussed before: each groups contains one or more site with a unique identifier named site_global_key

So, now that we know the two characters, we can proceed with their story.

Organise things

If you had a look at the database titles you might have noticed some common properties:

iw_prefix and globalid both are kind of unique identifiers for wiki
iw_url and page_path both points to the basic page address on the wikis

There is a clear advantage in using a unified notation for iw_prefix and globalid so the same prefix can be used both in InterWiki and SiteLinks.
So I resolved to create a kind of master table of sites I wanted to use in my wiki, that looked like this:

globalid / iw_prefix	group	page_path / iw_url	iw_api	file_path	languagecode	description
enma	wikia	https://memory-alpha.fandom.com/wiki/$1	https://memory-alpha.fandom.com/api.php	https://memory-alpha.fandom.com/$1	en	Memory Alpha (inglese)
enwiki	wikipedia	https://en.wikipedia.org/wiki/$1	https://en.wikipedia.org/w/api.php	https://en.wikipedia.org/w/$1	en	Wikipedia (inglese)

I then wrote a small utility to extract data from this table (which I organized in a |-separated CSV file for simplicity) and create three thing:

a group of SQL statement to insert interwiki prefixes as explained in the manual
a XML file to be imported in the sites table with the maintenance script importSites.php. This is not the only way to populate the sites table, but in my experience I found it to be the easiest one
a code fragment in LUA to be used in custom modules

Below you can see the result from the example above.
The query for interwiki:

INSERT INTO interwiki (iw_prefix, iw_url, iw_api, iw_wikiid, iw_local, iw_trans) VALUES ('enma', 'https://memory-alpha.fandom.com/wiki/$1', 'https://memory-alpha.fandom.com/api.php', '', 0, 0);
INSERT INTO interwiki (iw_prefix, iw_url, iw_api, iw_wikiid, iw_local, iw_trans) VALUES ('enwiki', 'https://en.wikipedia.org/wiki/$1', 'https://en.wikipedia.org/w/api.php', '', 0, 0);

The XML to be imported in sites

<?xml version="1.0"?>
<sites xmlns="http://www.mediawiki.org/xml/sitelist-1.0/" version="1.0">
  <site type="mediawiki">
    <globalid>enma</globalid>
    <group>wikia</group>
    <path type="page_path">https://memory-alpha.fandom.com/wiki/$1</path>
    <path type="file_path">https://memory-alpha.fandom.com/$1</path>
    <languagecode>en</languagecode>
  </site>
  <site type="mediawiki">
    <globalid>enwiki</globalid>
    <group>wikipedia</group>
    <path type="page_path">https://en.wikipedia.org/wiki/$1</path>
    <path type="file_path">https://en.wikipedia.org/w/$1</path>
    <languagecode>en</languagecode>
  </site>
</sites>

Finally, the variable definition in LUA code:

local VariableName = {  
    enma = 'Memory Alpha (inglese)',
    enwiki = 'Wikipedia inglese'    
}

Now make them work together

The source of information for the wiki pages is an entity in WikiBase: the raw sitelinks data for the entity are:

{
  "entities": {
    "Q27": {

      […]

      "sitelinks": {
        "enma": {
          "site": "enma",
          "title": "Jean-Luc Picard",
          "badges": [],
          "url": "https://memory-alpha.fandom.com/wiki/Jean-Luc_Picard"
        },
        "enwiki": {
          "site": "enwiki",
          "title": "Jean-Luc Picard",
          "badges": [],
          "url": "https://en.wikipedia.org/wiki/Jean-Luc_Picard"
        }
      }
    }
  }
}

I then created a function in a custom LUA module:

function p.SiteLinksInterwiki() 
    local AllLinks = {}

    local Item = mw.wikibase.getEntity()

    local SiteLinks = Item['sitelinks']
    local Titles = {
        enma = 'Memory Alpha (inglese)',
            enwiki = 'Wikipedia inglese'
    }

    for _, SiteLink in pairs(SiteLinks) do
        local TitleLabel

        TitleLabel = Titles[SiteLink['site']] or SiteLink['site']

        AllLinks[#AllLinks + 1] = "* [[:" .. SiteLink['site'] .. ":" .. SiteLink['title'] .. "|''" .. SiteLink['title'] .. "'']], " .. TitleLabel
    end

    return table.concat(AllLinks, string.char(10))
end

Note this function cycles through all members of sitelinks node and uses the site field as prefix for the interwiki link and to determine the label to be shown after it.

💬Conclusion

While this might seem a small details at first sight, in fact this trick greatly improves consistency and thus readability and code cleanliness.
It also gave me the chance to deepen my knowledge of both mechanisms.

Put OAuthAuthentication back to work

Luca Mauri — Sat, 18 Apr 2020 15:39:59 +0000

The MediaWiki extension OAuthAuthentication allows a user to login on a wiki delegating authentication to another one using the extension OAuth.
The power of this extension is that allows us to run multiple wikis in a single family without asking the user to create user for each one of them. In the extreme situation, it even allows to delegate the login from any custom wiki to the most used wiki: Wikipedia.
By the way, OAuth is the technology used by the foundation to allow single-sign-on on the several sites of the Wikipedia family.

The problem

Unfortunately OAuthAuthentication extension suffer from some issues: in particular, since MediaWiki version 1.34, it cannot be used out of the box because of some unsolved incompatibilities with part of the code in the MediaWiki core that were deprecated since the extension was originally created.
There is already an effort to modify it to put it back to work as explained in this Phabricator ticket, but this is a long term solution: it looks it is in the working since years and not yet ready to ship.
Since I needed teh extension up and running for a custom project of mine, I looked for a ad-interim solution, which I found with some googling around and some copy and paste.
The solution explained below is by no means elegant, it is not even a real solution: is a workaround.
It looks it works in my environment so I thought about sharing it.

Working around

After having installed everything as explained in extension's page, let's start by modifying the file OAuthAuthentication/handlers/AuthenticationHandler.php: in function doCreateAndLogin transform the code fragment:

    $exUser->addToDatabase( wfGetDB( DB_MASTER ) );
    $u->setCookies();
    $u->addNewUserLogEntry( 'create' );

    wfResetSessionID();

    return \Status::newGood( $u );

into the following

    $exUser->addToDatabase( wfGetDB( DB_MASTER ) );
    $u->setCookies();
    $u->addNewUserLogEntry( 'create' );

    // Modified as per https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/OAuthAuthentication/+/251930/33/handlers/AuthenticationHandler.php    
    // wfResetSessionID();
    $u->getRequest()->getSession()->resetId();

    return \Status::newGood( $u );

In function doLogin transform the code fragment:

    wfResetSessionID();

    return \Status::newGood( $u );

into the following

    // Modified as per https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/OAuthAuthentication/+/251930/33/handlers/AuthenticationHandler.php
    //wfResetSessionID();
    $request->getSession()->resetId();

    return \Status::newGood( $u );

In the commented code you can see where I took the modification for the deprecated wfResetSessionID() function.

Another possible issue you may incur in is the one explained in this other Phabricator ticket that is also worth working-around.
In file OAuthAuthentication/specials/SpecialOAuthLogin.php let's modify the function execute: the fragment

    $this->getContext()->setUser( $u );
    $wgUser = $u;

    $lp = new \LoginForm();
    // Call LoginForm::successfulCreation() on create, or successfulLogin()
    $lp->$method();
        break;

should become

    $this->getContext()->setUser( $u );
    $wgUser = $u;

    // Modified as per https://phabricator.wikimedia.org/T207351
    //$lp = new \LoginForm();
    // Call LoginForm::successfulCreation() on create, or successfulLogin()
    //$lp->$method();

    $r = new \ReflectionMethod('\SpecialUserLogin', 'successfulAction');
    $r->setAccessible(true);
    $r->invoke(new \SpecialUserLogin());
        break;

As mentioned, this is very dirty, but it is quick and makes the extension workable again till a more permanent solution (probably with a new release) is found.

If you are interested in further development on this, keep an eye on the already mentioned extension's page and Phabricator ticket.

Learning how to share what you learnt

Luca Mauri — Fri, 17 Apr 2020 14:50:01 +0000

My main project at the moment is a custom MediaWiki installation that hosts a hyper-textual guide to Star Trek. It is something similar to the widely-known Memory Alpha, surely in a smaller size, but it is in italian language and based on a standard modern version of MediaWiki. Furthermore, this project is heavily integrated with WikiBase, a substantial extension to MediaWiki that provides database-like capabilities and it is the cornerstone of open data for Wikipedia being the base of WikiData.

MediaWiki and LUA

Basic usage of data from WikiBase is very easy, but any complex access to data needs custom coding in LUA. LUA is provided as a language for customising MediaWiki through an extension called Scribunto. WikiBase comes with a LUA Scribunto interface that allows easy manipulation.
There is a manual on how to use the LUA interface that lists and explain all the object model, but IMHO fails in providing enough examples.
So I started the painful experience, so familiar to all developers, of trials and errors till I found a way to make everything work.

While the LUA code I was writing was specific to my project, I started thinking it could also be made more generic and maybe useful to other users, so i thought a way to share it.
Being on a public Wiki, the code was accessible to anyone (but editable only to members, just as a passing comment) so already shared, in sense. Nevertheless, the truth is, in practical terms, that our wiki is about a niche product of a niche of the entertainment industry; incidentally the wiki is also written in italian, reducing its potential readership even more.
I needed a better idea.

How to share

WikiTrek is a GitHub "organization" already, so the first thing I thought was to publish the LUA code on a dedicated repository. At first I started to copy and paste the code manually, so each time I made a modification to LUA code, I copied and pasted it.
It was very inefficient and prone to errors.

A better approach would have been to transfer data automatically from the wiki pages to GitHub.
First important thing was not to reinvent the wheel, so I started looking for a ready-to-use PHP library to interact with GitHub and found PHP GitHub API pretty soon. It is an excellent library to perform any kind of operations on GitHub using ready-made PHP classes.

Finding the right way

So I started playing around with PHP GitHub API and, in a couple of hours (documentation and examples of that library might benefit from some work, but this is another story), I had a proof-of-concept small application to manipulate GitHub via that API.
My original plan was to write a MW Maintenance script and run it on the server periodically using cron or maybe MW own scheduler.
The more I looked into this solution, though, the more complicated it became.
After a few days of alternatively banging my head against the problem and thinking about it, I came up with a different solution.

I started looking into extension development and found out there is a class of extensions using Hooks allowing to inject custom PHP code at certain event. Most prominent example of these events is PageContentSaveComplete and that was all I needed: by intercepting a page when it is saved, I could have taken the content to send it to GitHub.
Bingo.

Building the extension

First step was to familiarise myself with the extension development: MediaWiki documentation on the topic is vast and – as unfortunately often happens with that project – not completely structured.
I found the two most important thing to master:

the intricacy of Extension registration using the extension.json file and
the handling of custom settings via configuration variables

Once I understood the basics of extension development, I had to tackle some issues about the on the working of the extension:

I wanted only some pages to be transferred, so I found a way to select the pages belonging to Module: namespace only
All the pages with code on them ends up in the Module: namespace, so I needed to select only specific pages, otherwise I would have copied code belonging to other extensions or template or whatever, most likely code non even written by contributors to the site. I resolved to do so by introducing a custom keyword to look for in the page.
I implemented a mechanism to not save the pages if the edit is marked as "Minor"

Firstly I hard-coded all of the above for testing purpose: by the end of the projects, I made all options user-customisable variables that can be handled in Localsettings.php

Closing words

The result of all this effort is an extension that I called PageToGitHub (or P2G, in brief). I don't expect this to be used by someone else as it address a very specific feature that is hardly to be found elsewhere.
Nevertheless I am very satisfied with it because, apart of solving the original issue I had, the journey to create it helped me to improve my (otherwise very limited) PHP skills and guided me to better understand inner MediaWiki mechanisms.
Beside, of course, allowing me to write this post and start my humble contribution to DEV community.

DEV Community: Luca Mauri

Messages on Mediawiki sidebar with Javascript

Easy start

Just one question

Look closer

The final solution

Call it

Check page type

Do the job

Setting the text

Experiment more

Auto-updating field in CorelDraw

When to run it

The function

System.Text.Json in action with practical example in VB.net

JSON in .NET

The problem

The solution

First steps

The practical code

Conclusion

Organize Interwiki and Sites in MediaWiki for best efficiency

Anatomy of Interwiki

SiteLinks and site table

Organise things

Now make them work together

💬Conclusion

Put OAuthAuthentication back to work

The problem

Working around

Learning how to share what you learnt

MediaWiki and LUA

How to share

Finding the right way

Building the extension

Closing words

SiteLinks and `site` table