Page MenuHomePhabricator

"TypeError: $.escapeRE is not a function" on many WMF wikis
Closed, DeclinedPublic


While visiting some wikis by following links from
I noticed quite a few with errors caused by the recent deprecation/removal of $.escapeRE.
These should be fixed as @ori did in
and/or by adding the missing dependency:

Event Timeline

He7d3r raised the priority of this task from to Needs Triage.
He7d3r updated the task description. (Show Details)
He7d3r added projects: JavaScript, Regression.
He7d3r added a subscriber: He7d3r.

Errors where / on which level? Is this about deployed code? Or is this about on-wiki code?

(cf. T103498, T103610)

Errors thrown in the JavaScript console, likely from local JS code (e.g. MediaWiki:Common.js, a default gadget, or another MediaWiki:Something.js imported from one of these two kinds of pages) which was previously "working", and which was broken when module jquery.mwExtension stopped being loaded by default/earlier.

If this is about fixing local JS code then it's not handled in a Phabricator task...

Krinkle closed this task as Declined.EditedJul 10 2015, 1:11 PM
Krinkle claimed this task.
Krinkle added a subscriber: Krinkle.

If they emit warnings then that's fine. It doesn't affect users. The warning serve as notice to the maintainers and wider community developer audience for those scripts to migrate at some point.

If they emit errors (e.g. escapeRE undefined) then the problem is in the script. Probably because it's not declaring its dependency on the module that provides that method (jquery.mwExtension). The reason it worked previously is likely because an unrelated module did have a proper dependency on it, but since migrated to use something else.

Always declare your dependencies. This is not a bug in the software and there's nothing feasible we can do about this.

If this is about fixing local JS code then it's not handled in a Phabricator task...

Not exactly...

This is about supporting existing MediaWiki installs in general. MediaWiki used to load mediawiki.util, and then that changed. That was a problem caused by the software for which the appropriate solution was to change the software to support that. The immediate problem and solution did not involve local scripts.

This is about adding functionality to MeidaWiki core and extensions, inspired by scripts written by the Wikipedia community. It is not a task or issue with the local scripts.

This is indeed not related to MediaWiki software, but it is related to Wikimedia Foundation engineering. We take on the responsibility to ensure our users receive code that is performant, secure and adheres to quality and usability guidelines. As such it is very much within the scope here to work on solutions to change how local scripts are maintained. This is not a task about any specific issue with a local script. Instead, this task is about improving the platform in general so that these scripts can be written and reviewed in a more effective way.

Always declare your dependencies.

I do. The problem is to get all WMF wikis to do that for code loaded by default for all visitors...

Always declare your dependencies.

I do. The problem is to get all WMF wikis to do that for code loaded by default for all visitors...

I know you do @He7d3r. You're awesome :)

Unfortunately, as you know, many wikis do not have the honour and luxury of having someone like you in their community. A lot of the existing scripts out there are outdated copy-paste forks of code that is well-maintained, but the copies are never updated.

T71445 should help devise a better process to avoid this in the future.

For the moment, there's very little we can do about this because the main problem right now isn't in the prevention. It's in the existing code already out there. Our typical engineering-related announcements do not reach anyone that is aware of those scripts. Because those scripts were copied from one wiki to another by users that are not familiar with programming and likely forgotten about. Those users may not even be active anymore.

I'm going to revive the Resource Walker tour over the next few weeks. This will help establish a better baseline by sweeping clean all wikis and leave us with a state where all code is either looked after, loaded from elsewhere, or removed. No exceptions.

I'll rewrite the checklist with new instructions and recommendations, but keep an eye on this one:

I'll also dedicate some time on this during the hackathon at Wikimania in Mexico City next week.

He7d3r set Security to None.
He7d3r added a subscriber: ori.