Page MenuHomePhabricator

Sites resource loader module's cache should be invalidated when site config changes
Closed, ResolvedPublic

Description

The resource loader module for site details should be invalidated whenever the configuration of sites changes. Otherwise the changes won't be propagated to JavaScript until the resource loader's cache is purged for some other reason.


Version: master
Severity: minor

Details

Reference
bz40655

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:52 AM
bzimport set Reference to bz40655.
bzimport added a subscriber: Unknown Object (MLST).

Some resources in mediawiki have a version number that is included in the URL referenced from the main HTML. When the resource is updated, that version number gets bumped and causes a new URL to be used for the resource, effectively circumventing the stale cache.

Is such a system available for resources in general? It seems like it would be useful...

Closing. Please reopen if this still needs to be done.

Nothing has been done here. Not sure how critical this is.

This isn't critical just because the SiteList does not change that often. But it should definitely be fixed and, from what I see, should be very easy to fix. ResourceLoaderModule provides a whole bunch of nice and very simple methods to do that. I think a combination of getModifiedHash and getModifiedTime is needed. See ResourceLoaderLanguageDataModule for an example and do the same in SitesModule.

However, low priority, so I won't take this for now.

Lydia_Pintscher removed a subscriber: Unknown Object (MLST).
Lydia_Pintscher removed a subscriber: Unknown Object (MLST).

@Lydia_Pintscher Please do not just “Decline” a task without an explanation why. This is irritating.

I am declining based on Thiemo's comment and the fact that we didn't have resources to work on it for 2 years.

@Lydia_Pintscher According to Thiemo, “it should definitely be fixed”. There will always be some non-critical issues for long periods of time in almost any serious software project and that's fine.

Also no reason to decline this according to the Mediawiki bug report life cycle:

A report is given the Declined status when the problem can not be reproduced, when missing information has not been provided, or when an acceptable workaround exists to achieve a similar outcome as requested. This status is also set when there's a consensus that implementing a particular bug report or feature request would be a bad idea. For example, when a report contradicts a particular project's scope or the principles of the project and fixing would be barred from approval by the project's Developers/Maintainers (or product managers, if existing). Depending on the specifics, a user preference, a global configuration variable, a re-implementation, or forking the code can be alternatives to marking a report as declined.

If that gets into the way of your team's internal planning then you could e.g. simply introduce a new tag signaling that your team has currently no intentions to fix this but leave it open for other developers and as proof that this is a valid issue.

Please leave this closed unless you have a patch for it. We are not going to work on it and no-one else has done so either since _2013_. I am cleaning tickets like this off so people can actually find the ones they should be working on.

TheDJ reopened this task as Open.EditedApr 24 2017, 10:16 AM
TheDJ subscribed.

I can't agree with that. That's not how it works. Please create a "Wikidata doesn't want to work on this tag".

Just because people aren't working on this, doesn't mean they shouldn't be working on it.

Based on the code I see in https://phabricator.wikimedia.org/diffusion/EWBA/browse/master/lib/includes/Modules/SitesModule.php and https://phabricator.wikimedia.org/diffusion/EWBA/browse/master/lib/includes/Modules/SitesModuleWorker.php this is fixed for a long, long time. If this impression is wrong then the most minimal information needed to work on this (especially if a volunteer should work on this) are steps to reproduce. Without a comment stating something like "yes, I'm still able to reproduce this, and here is how" this ticket is indeed invalid.

This was fixed by @hoo with commit: a68e08c143cc75d305f66dc55fd8fa61ddb5f705
change-id: I8e4831552bf5e3ace8e6c84cd4869abbff92d92e

Danwe changed the task status from Invalid to Resolved.EditedApr 24 2017, 3:25 PM

Marked as resolved as pointed out by TheDJ.

@thiemowmde Just for the record: "Declined" and "Invalid" are two different things.

Without a comment stating something like "yes, I'm still able to reproduce this, and here is how" this ticket is indeed invalid.

Not exactly. A ticket agreed upon as an actual issue could e.g. change its status...

  • ...to “declined” with a comment stating sth. like “No, I am not able to reproduce this (and never have been)!"
  • ...to “resolved” with a comment stating sth. like “I am no longer able to reproduce this!”

If you really rely on a more detailed description on how to reproduce an issue then you should set the ticket to “stalled”. If no one provides the information after some period of time it can be set to “declined”.