Adding Javascript into the MediaWiki page

We cannot add JavaScript to a wiki page. According to this MediaWiki page, all JavaScript scripts are disabled on a wiki page.

One possible way of adding a global JavaScript to the site, we may edit (by request) the MediaWiki:Common.js here to apply the script of parsing the reading list JSON.

See example: https://en.wikipedia.org/wiki/MediaWiki:Common.js

Additional note

Please note that a logged-in user can install User scripts which is only available for the account owner and will not be visible to other users.
Example of a custom user script: https://en.wikipedia.org/wiki/User:Cooltey/test.js

By adding general scripts in MediaWiki:Common.js, every page on mediawiki.org can insert the scripts.

Adding javascript into Central Notice

If we want to add a new "banner" via Central Notice, we have to go through the request process:
https://meta.wikimedia.org/wiki/CentralNotice/Request

By reading through the guideline, I feel the Central Notice may not be suitable for our purpose which is parsing JSON format reading lists and we may have a very high chance of getting rejected by the community.

Creating an extension

To create a MediaWiki extension, we can follow the following steps to create one:
https://www.mediawiki.org/wiki/Manual:Developing_extensions

Looks like we can create a SpecialPage for parsing the reading list JSON.
https://www.mediawiki.org/wiki/Manual:Special_pages

and we can add simple HTML to the following extension file:
https://www.mediawiki.org/wiki/Manual:Special_pages#OutputPage.php

After creating the extension, it will require the other team to install the extension and help us to create the special page, which may take much longer compared to the first approach, which is adding JavaScript to MediaWiki:Common.js.

In T316837#8219574, @cooltey wrote:

After creating the extension, it will require the other team to install the extension and help us to create the special page, which may take much longer compared to the first approach, which is adding JavaScript to MediaWiki:Common.js.

MediaWiki:Common.js is not an appropriate place for feature-specific code like this to live. That code gets loaded by every user of a given wiki and should be kept as minimal as possible.

This feature is probably better handled as a new MediaWiki extension, one that sets up a new Special page. Within that page you could do anything you want basically, but you will have to go through a process to get a new extension approved and deployed. A Special:ReadingList page would have access to the MW database and PHP classes, so you could load all article preview data without needing to rely on JS at all (might be useful if a lot of Android users can't or do not wish to run JS on their devices). If you go the PHP route, I'd recommend using Mustache templates to generate the necessary markup; it will be a lot more readable than imperatively building everything in PHP.

• Pros: this is the most "MediaWiki" way; you can support users without JS
• Cons: getting a new extension approved and deployed takes time and requires coordination with other teams; developing software inside of MediaWiki may be a challenge if the team is more familiar with mobile development; some ongoing maintenance will likely be needed over time

Alternatively, you could use something like Netlify to quickly stage and deploy a stand-alone Reading List page (though the URL should still be something that the Foundation controls, otherwise it might seem suspicious to users). Since this page would be completely separate from MediaWiki, you could probably deploy it more quickly (and update as needed) but you would not have direct access to the database or any server-side methods. Instead you'd probably need to rely on client-side API requests to populate the page with the info you need. If you decided on this approach, using Vue.js and Codex (MediaWiki's new Vue-based UI component library) might be worth considering.

• Pros: Netlify is a great service, other teams already use it for various things; could enable very rapid development and deployment; you would not be tied to MW releases so you could update as needed; a static HTML/CSS/JS "app" has fewer requirements around security and maintenance
• Cons: still should live under an official WMF domain; you will need to rely on JS since you won't have access to the server, and there may be issues with performance or browser support if your users are on older devices

Thank you for your feedback @egardner! I agreed MediaWiki:Common.js is not an appropriate way in this case and really appreciate that you've put the pros and cons to each suggestion 🙂

As Jon and Kosta mentioned in the Slack thread, it would be easier to use the existing ReadingList extension and we can also work on this WIP patch.. We will get more info from Jon next week.

Use Portals

The Portals can only have static HTML content with some basic JavaScript, which does not allow to write PHP code on the HTML page.

The way of deploying a static HTML page as a Portal, we can have Jan Drewniak's help to deploy and setup Apache config in order to show the page in a specific URL, e.g. (https://www.wikipedia.org/app/readinglists)

Use the existing ReadingLists extension

The current Extension:ReadingLists does not have a special page, and we can follow the example (or wait for Jon Robson's follow-up patch ) to create a special page from the ReadingLists extension.

This will save some time on creating a new extension but will still need to go through the process of reviewing and deploying to the Wikipedia sites.

Additional Notes

1. If we are going to create a special page, we will need to think about the template and also the possible language issues (one reading list with articles from different wiki sites) in a list.
2. We can follow this special page for its template and layout: https://en.m.wikipedia.org/wiki/Special:Nearby
3. We may also be able to build a WordPress page under the https://wikimediafoundation.org/ domain.

Hi @JTannerWMF

After the discussion with engineers, we would like to recommend going forward in the direction of updating the current ReadingLists extension.

The patch that @Jdlrobson created basically covered the functions that we need:

1. Display a preview of a reading list.
2. Decode the encoded reading list from a URL.
3. Use the current ReadingLists extension to create a SpecialPage:

For more detail, please check this: T313269#8243335

The next step:

1. Talk to the PM in the Web team about this.
2. Talk to the iOS team and let the engineers know about it.
3. Have an engineer start working on the patch (pick the import + display functions, or create a new patch) and corporate with @Jdlrobson.

Thank you for this incredible work @cooltey !