Thanks for the responses, Brad. Is there some documentation somewhere for which modules are loaded by default and which ones aren't (e.g. mediawiki.api)?


On Thu, Mar 12, 2015 at 10:22 AM, Brad Jorsch (Anomie) <bjorsch@wikimedia.org> wrote:
On Wed, Mar 11, 2015 at 7:28 PM, Jason Ji <jason.y.ji@gmail.com> wrote:
So it's strange, about ten or fifteen minutes after I posted that, the error went away while I was fiddling with something or other. One of those really strange (and terrible) magically disappearing bugs... so the following is no longer urgent, but more for my own edification.

Ah, caching issues! If I recall correctly, debug=true bypasses some internal ResourceLoader caching. debug=false tries to check file mtimes and such to avoid serving stale caches, but sometimes it gets confused.

For my own local development, I sometimes use a shell script that clears memcached and redis and runs the clearMessageBlobs.php script from the WikimediaMaintenance extension. You probably wouldn't want to do all that on a production server, though.
 
You're right that I never load mediawiki.api. (However, I'm still not loading it and the problem has resolved itself.) But why would I need to load mediawiki.api, and not other mediawiki JS modules? I've been able to use other mw modules in JavaScript without any issues (example: mw.user for getting tokens, or mw.config to get various $wg variables).

Some stuff is loaded by default, but I don't think mediawiki.api is part of that. For something as commonly used as mediawiki.api, though, you might be getting lucky in that something else on the page might be loading it for you.


--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation

_______________________________________________
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api