Page MenuHomePhabricator

Investigate adding an HTTP API to change the MobileFrontend extension config
Closed, InvalidPublic

Description

This task tracks a tech debt-y wishlist item identified by Sam and Stephen. The task itself is to investigate adding an API to allow changing the MobileFrontend extension's config by making an HTTP request. This is a very low priority wish for Android which currently updates styles from MediaWiki production code instead of the preferred local Vagrant instance just to enable MinervaApplyKnownTemplateHacks.

The task encompasses the follow work:

  • Identify a kind of generic way to change the config to another versioned config _iff_ the service is a Vagrant development instance; this effort will only be used on MobileFrontend initially but should work for other extensions as well if found to be useful later
  • Just do it or create a new task to:
    • Add a new development config, enwiki-dev.json, that uses the defaults on English Wikipedia
    • Add support to register configs; a Vagrant development instance will also register any available configs beyond config.json
    • Add API support to change a config to a given registered config
    • Update the MobileFrontend readme with a summary of the different configs, what they are, and the current configs available (config.json, enwiki-dev.json)
    • Check in with the rest of the Reading Web team to make sure you haven't introduced a security hole somehow
    • Ping Android to update their CSS sync script to use a local Vagrant instance with the new API (revert the last commit to use prod and add the API change)

Event Timeline

Niedzielski renamed this task from Investigate mechanism to allow an API to change a MobileFrontend extension config to Investigate adding an HTTP API to change the MobileFrontend extension config.Apr 25 2017, 10:31 PM
Jdlrobson added a subscriber: Jdlrobson.

We currently have a LocalSettings in our browser tests which can be included by

include_once "$IP/extensions/MobileFrontend/tests/browser/LocalSettings.php";

I'm curious what's the advantage of having an API for this. Why not just have multiple LocalSettings files that can be swapped in or out?

I wonder if there is any overlap in objectives with T160985 ?

Why not just have multiple LocalSettings files that can be swapped in or out?

This can be done but doesn't seem as automation friendly when you're a client of MediaWiki and not an extension within it. For example, the Android app depends on MediaWiki and uses Vagrant to pull down certain CSS styles. It would be convenient if, given a running Vagrant instance, it could manipulate the configuration from the outside via an API.

T160985

This task tries to minimize scope to just MobileFrontend. My thinking was that we can generalize support if it works well later (feel free to disagree and mark this as a duplicate).

With respect to wgMinervaApplyKnownTemplateHacks - due to the limitations with this config variable because of how ResourceLoader caches, a reboot of MediaWiki and a reboot of memcached is needed to apply any changes to the value.

Could you flesh out the value proposition of doing this work by listing some other use cases and what you hope doing it will achieve?

Niedzielski triaged this task as Lowest priority.EditedApr 27 2017, 3:30 AM

wgMinervaApplyKnownTemplateHacks

Sorry, I don't know how any of this works yet. That's too bad. I was hoping there would be a way to completely invalidate the resources and cache without rebooting the system.

The value is currently very minimal: 1) avoid applying a custom patch as part of an automation and 2) version control of popular custom configs. Here's the current Android script for syncing styles:

#!/usr/bin/env bash
PREFIX="https://www.mediawiki.org/w"
BASE_PATH="`dirname $0`/.."

wget "$PREFIX/load.php?debug=true&lang=en&modules=skins.minerva.base.reset|skins.minerva.content.styles|ext.cite.style|mediawiki.page.gallery.styles|mobile.app.pagestyles.android|mediawiki.skinning.content.parsoid&only=styles&skin=vector&version=&*" -O "$BASE_PATH/app/src/main/assets/styles.css"
wget "$PREFIX/load.php?debug=true&lang=en&modules=skins.minerva.base.reset|skins.minerva.content.styles|ext.cite.style|mediawiki.page.gallery.styles|mobile.app.preview.android|mobile.app.preview|mediawiki.skinning.content.parsoid&only=styles&skin=vector&version=&*" -O "$BASE_PATH/app/src/main/assets/preview.css"
wget "$PREFIX/load.php?debug=true&lang=en&modules=mobile.app.pagestyles.android.night&only=styles&skin=vector&version=&*" -O "$BASE_PATH/app/src/main/assets/dark.css"

With the new functionality, PREFIX would change to localhost and an extra cURL command would appear before the wget calls to flip the configuration. Right now, whoever runs the command has to change the configuration manually. The hope was that this would be a useful feature to offer other automations requiring versioned configurations.

Sorry, I don't know how any of this works yet. That's too bad. I was hoping there would be a way to completely invalidate the resources and cache without rebooting the system.

Not really :/ ResourceLoader will load all files, concatenate and cache the result. It wouldn't be aware if a LESS variable changed value. Same would happen if we changed a colour somewhere.

Can you have a go at rewriting the task description as a problem statement without a solution?
For instance, maybe there's a solution here where you can run a PHP script that will generate the CSS you want?

Jdlrobson moved this task from Needs Prioritization to Epics/Goals on the Readers-Web-Backlog board.

I assume this was created in phabricator as a reminder to have a conversation. It seems 'epicy' so I've added the epic tag, but I think a proof of concept would go a long way to help identify whether this is achievable.

I'm sorry I haven't moved this forward but it hasn't been a priority. I'm going to close this as invalid until a greater need arises.