Page MenuHomePhabricator

Configure JsonConfig for pattern Web2Cit/data/**/*.json in metawiki's "Main" namespace
Open, Needs TriagePublic

Description

As discussed on the Advisory Board mailing list, assigning the "JSON" content model to our configuration files in Meta would enable (1) the code editor (instead of the wiki editor), and (2) a cleaner box visualization of these JSON files. This is currently the case with our configuration files in the "User" namespace, which are used by the sandbox endpoint of Web2Cit-Server.

Is there a way we can make all files following the pattern Web2Cit/data/**/*.json be assigned the "JSON" content model?

Is this how files ending in .json are assigned the "JSON" content model in the "User" namespace, whereas those ending in .js are assigned the "JavaScript" content model?

We have asked these questions here.

Note that JSON5 and YAML files (T302694) may not be supported equally. As stated in the mailing list thread mentioned above:

On the other hand, we have an open task to natively support JSON5, a format that supports comments. Even though this seems to be supported by Ace, the task to support this in MediaWiki's code editor is still unresolved (T127682).

Regarding YAML, it seems to be supported by Ace, but it doesn't seem to be supported by mediawiki code editor. However, if we manage to have the content model of our json configuration files set to "JSON", then the possibility of using the code editor, and the excellent box formatting, may make using YAML less useful.

Event Timeline

diegodlh added a subscriber: Pcoombe.

As pointed out by @Pcoombe, a way to do this would be with the JsonConfig Mediawiki extension. This is currently used by Dashiki dashboards to specify configurations in Meta, under the Config namespace. See for example this dashboard, configured here.

Hence, a way to do this for Web2Cit would be adding something like the following to Wikimedia's CommonSettings.php:

$wgJsonConfigModels['JsonConfig.Web2Cit'] = null;
$wgJsonConfigs['JsonConfig.Web2Cit'] = [
  'namespace' => 0,
  'nsName' => false,
  'pattern' => '/^Web2Cit\/data\/.+\.json$/',  // just wondering whether `config` would be more appropriate than `data` here
];

Maybe controlled by some wmgEnableWeb2CitData flag in InitialiseSettings.php, to make sure that this is not enabled by default but for metawiki only.

Given that this would require changing Wikimedia servers configuration, I'm adding the Wikimedia-Site-requests project, and updating the title to make it more specific.

Alternatively, we could follow an approach similar to the one followed by Dashiki dashboards, although we would need to move our configuration files from (Main:)Web2Cit/data/**/*.json to Config:Web2Cit:\**/*.json. The following configuration should do the trick in this case:

$wgJsonConfigModels['JsonConfig.Web2Cit'] = null;
$wgJsonConfigs['JsonConfig.Web2Cit'] = [
  // no need to specify namespace, "Config" is used by default
  'pattern' => '/^Web2Cit\:.+\.json$/',  // requiring the .json extension at the end in case we support other configuration file formats (T302694)
];
diegodlh renamed this task from Assign "JSON" content model to configuration files in Web2Cit/data/ to Configure JsonConfig for pattern Web2Cit/data/**/*.json in metawiki's "Main" namespace.Apr 11 2022, 7:41 PM

Get the Data: namespace enabled on metawiki.

There are issues with the Data: namespace on wikis outside Commons (T252711) but I don't believe that would affect Web2Cit as the information is never queried from wikitext. (and don't go to Commons for reasons outlined in T309350)

Hi @Yurik, @matmarex and @aude! I'm pinging you here because I saw you have edited Wikimedia's CommonSettings.php with Extension:JsonConfig related lines.

Do you think it would be possible to edit either CommonSettings.php or InitialiseSettings.php as suggested above to enable JsonConfig for pattern Web2Cit/data/**/*.json in the Main namespace on meta-wiki? Do you think it makes sense?

If yes, I would appreciate it if you could let me know what steps should be followed to request and approve such changes.

Using the Config: namespace would not work at the moment because these files should be editable by anyone.

Thank you!

Hey, I'm not much of an expert, but it seems that it would be possible. I am not sure how the JsonConfig extension would cope with pages already existing under those titles with a non-JSON content model, though.

I would suggest proposing a patch for the operations/mediawiki-config repository to enable this on the beta cluster at first, get it deployed (How to submit a patch for backport), test there, and if it works as desired, do the same thing for the production wikis.

Alternatively, you could change the content model of each page individually using https://meta.wikimedia.org/wiki/Special:ChangeContentModel, but you'd need a Meta-Wiki administrator to do it (unless T85847 is somehow resolved soon).

Hi, @matmarex! Thanks for your suggestions and sorry for my long delayed follow up.

I would suggest proposing a patch for the operations/mediawiki-config repository to enable this on the beta cluster at first, get it deployed (How to submit a patch for backport), test there, and if it works as desired, do the same thing for the production wikis.

Thank you for this recommendation. I reviewed the documentation available but I'm a bit confused about what the right procedure would be to propose config changes, test them on the beta cluster, and have them deployed to production. I read I could ping @thcipriani on IRC for questions, but I'm new to IRC and wasn't sure whether it was the right place to ask these many questions:

  • You mean I should propose a patch for InitialiseSettings-labs.php or CommonSettings-labs.php files (note the -labs suffix)? Is this the right way to have to have changes deployed to the beta cluster first?
  • Should these changes be commented on Gerrit as -1 as suggested here? Couldn't find this anywhere else.
  • Should I go through the backport window process for these -labs.php changes to be deployed to the beta cluster as well?
  • After confirming changes work on the beta cluster, should I submit another patch changing the production config files (and reverting the -labs.php changes) and repeat the backport window process?
  • During the backport window deploy, it says I should have my test cases ready to run. I guess it just means checking that the config files worked as expected? Or it means something else?

I hope you can help me better understand the process! Thanks :)