Page MenuHomePhabricator

Avoid MagicWord/LCStore cost from WikiEditor in startup module (resourceLoaderGetConfigVars hook)
Closed, ResolvedPublic


This is currently being re-computed and refetched every few minutes in the startup module without caching. Overall, the data does not appear to be critical to page views or otherwise needed before we can fetch modules on any page on any wiki.

Rather, it should be bundled with the ext.wikiEditor module that needs it, which already bundles the consumer of this data (jquery.wikiEditor.toolbar.config.js).


Slows down computation of the startup module on cache miss.

Increases bandwidth cost on all pages in the path towards loading interactive features, which delays VisualEditor and Popups (a little bit).

Event Timeline

Krinkle updated the task description. (Show Details)

Moving this would be fairly simple by using the packageFiles and data-provider callback feature it provides.

That would basically allow turning the resourceLoaderGetConfigVars and getMagicWords callbacks (at WikiEditorHooks.php#190) into a data.json virtual file, with a versionCallback that returns just the array of magic word IDs (without localisation, given we require back-compat there, it doesn't need to be resolved for the cache key of the module).

The prerequisite for this simple change is for the ext.wikiEditor module to first convert from a scripts FileModule to a packageFiles FileModule. That could be done in a quick way by listing the files as-is and then invoking them from an index file, but one may want to at-the-same-time also separate the declaring of logic form UI side-effects and only include the declaring of logic. In that case, the change would be more involved.

Change 524635 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/WikiEditor@master] Convert ext.wikiEditor module to packageFiles

Change 524635 merged by jenkins-bot:
[mediawiki/extensions/WikiEditor@master] Convert ext.wikiEditor module to packageFiles

Hello. This change broke $.wikiEditor.modules.toolbar.config.getDefaultConfig() usage in my widely used script for talk pages. Thanks to getDefaultConfig(), wikiEditor could have been used for any textarea of choice. I had to hardcode the toolbar config like this:, adding 42KB to the code size. Please tell is there a nicer way to overcome this. @Catrope @Krinkle

@Vort reports that customising signature button code via mw.config.set('mw.msg.wikieditor', '~~\~~'); also broke likely due to this change. Is there a viable replacement for that, too? It was used by some people in Russian Wikipedia (including me), and now there’s no easy way to customise it.

Original topic:Википедия:Форум/Технический#Кастомизация_подписи

Krinkle triaged this task as High priority.Aug 26 2019, 6:48 PM

Confirmed via a recent flame graph that the performance issue is resolved;

@Jack_who_built_the_house It should be possible to bind WikiEditor to any text area and retain the default configuration indeed, without having to duplicate it. Note that this ability has never been documented or supported (to my knowledge) this worked by accident previously and restoring it might take a while. I've filed T231244 for this. Patch welcome. Should be straight-forward to do.

@stjn The config key used by WikiEditor was a private one. It existed to transport the signature used by ~~~~ in wikitext. It can be changed via Special:Preferences. Changing it only for WikiEditor is not a currently available feature. This previously worked by accident. If changing it via Special:Preferences does not work, please report a separate task with details.

For anyone interested, I've solved this in my script with these two commits.