Page MenuHomePhabricator

Pages lose their required ResourceLoader modules after being purged on 1.24wmf5
Closed, ResolvedPublic

Description

test wikidata with broken formatting

Item pages are appearing unformatted on test.wikidata, especially with no javascript.

With javascript, the TOC does not have wikibase formatting.

I experienced the same issue on my dev wiki. Restarting memcached (clearing resource loader cache) fixed the issue for me.

I assume the issue is related to some change in core, as new core code was deployed to test.wikidata and no changes in Wikibase.


Version: unspecified
Severity: major

Attached:

Details

Reference
bz65375

Event Timeline

bzimport raised the priority of this task from to Unbreak Now!.Nov 22 2014, 3:15 AM
bzimport added a project: MediaWiki-Interface.
bzimport set Reference to bz65375.
bzimport added a subscriber: Unknown Object (MLST).
aude created this task.May 15 2014, 10:38 PM
aude added a comment.May 16 2014, 12:05 AM

there also is an issue with missing / wrong styling for pages with Geshi syntax highlighting

http://snag.gy/vhfGe.jpg

seems extension resources are sometimes not being loaded or something

To reproduce this bug locally:

  1. Have SyntaxHighlight_GeSHi installed ('master' version will do)
  2. Checkout mediawiki/core branch origin/wmf/1.24wmf4
  3. Save a page with <syntaxhighlight> tag
  4. Checkout mediawiki/core branch origin/wmf/1.24wmf5
  5. Refresh the saved page. Observe that the styles are still correct.
  6. Purge the saved page. STYLES BREAK.
  7. Null-edit the saved page. Styles fix themselves.

Trying these steps and bisecting pointed me to f359cdf61462782743a87943938ef4cce78b2647. I'd appreciate if someone could verify the reproduction steps, because that's just too weird.

To clarify, the module loading process – load.php and friends, mw.loader.load() calls in JS – works correctly: it's just that the pages do not load these modules (load.php invocations are missing from HTML source).

(In reply to Bartosz Dziewoński from comment #2)

Trying these steps and bisecting pointed me to
f359cdf61462782743a87943938ef4cce78b2647. I'd appreciate if someone could
verify the reproduction steps, because that's just too weird.

Explanation: bug 56911 comment 6.

Do not change visibility modifiers (other than "var" to "public") on classes that are serialized for storage in the DB or a cache (unless, of course, the cached objects are invalidated and any performance implications are addressed).

This includes ParserOutput::$mHeadItems.

Reverted in I12a60b5cc52a07a6deabcbf47c7c99cd2faac3c3.

Seems fine now on test.wikidata.org