Last modified: 2014-10-22 08:49:02 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T37472, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 35472 - ResourceLoader cache is broken after moving MediaWiki
ResourceLoader cache is broken after moving MediaWiki
Status: NEW
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
1.17.x
All All
: Normal enhancement with 2 votes (vote)
: Future release
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-25 19:55 UTC by Krinkle
Modified: 2014-10-22 08:49 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Krinkle 2012-03-25 19:55:42 UTC
When MediaWiki is moved (physically on-disk that is, the web-facing paths are not relevant in this case) the ResourceLoader cache that contains links to file paths (specifically the contents of the module_deps table) are not purged in anyway.

I'm not sure what the right way to detect a purge-need is, but it's causing php errors like the following (Thanks to JasonJarde for reporting this on IRC):

PHP Warning:  filemtime(): stat failed for /home/user/oldpath/wiki/resources/jquery.ui/themes/vector/images/button-down-green.png in /home/user/oldpath/wiki/includes/resourceloader/ResourceLoaderFileModule.php on line 380

...because those paths no longer exist.

For now I recommended JasonJarde to manually DELETE all contents of the module_deps table and that fixes the problem.


* Possibly related bugs: bug 34752
* See also https://www.mediawiki.org/wiki/Manual:Moving_a_wiki (which mentions nothing about this)

Possible solutions I can think of:
* Somehow detect that paths have changed
* Create a maintenance script to clear this cache

I'm not a fan of the latter because a move may not be the only cause for this and when possible I'd like to avoid a manual fix. Having to run a maintenance script is automated in some way, but it still requires manual intervention and knowing that that script has to be ran. ResourceLoader should be able to figure out the caching.
Comment 1 Mark A. Hershberger 2012-09-28 21:53:35 UTC
release is imminent.
Comment 2 Krinkle 2013-03-06 05:51:34 UTC
See also bug 44524.
Comment 3 Daniel Robbins 2014-06-25 20:25:26 UTC
The simplest solution would be to add module_deps to the list of SQL caches that  maintenance/update.php wipes when it runs.

According to http://www.mediawiki.org/wiki/Manual:Update.php, update.php already wipes a variety of caches stored in SQL, including the other ones related to ResourceLoader. It seems that maybe module_deps should have been added to this list.

Adding m along with doc changes instructing wiki admins to run update.php after a wiki migration/restore/move, this problem is solved for everyone.

I think it's much more intuitive to continue to have update.php take care of the SQL cache issue in one feel swoop rather than have a separate command for module_deps.
Comment 4 Daniel Robbins 2014-08-26 21:27:52 UTC
Bump on this. This is a pretty ugly bug when dealing with wiki migrations. See my comment above on an easy fix.
Comment 5 Andre Klapper 2014-08-26 22:22:58 UTC
Krinkle: Does the approach in comment 3 sound feasible?

Daniel: If the approach gets an OK and if you feel like cooking up a patch, see https://www.mediawiki.org/wiki/Developer_access and https://www.mediawiki.org/wiki/Git/Tutorial
Comment 6 Krinkle 2014-08-26 23:14:16 UTC
Yes. If update.php already cleans other tables the same way, let's just add this one to it.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links