Page MenuHomePhabricator

Reupload should purge File page (aka image has malformed dimensions)
Closed, DuplicatePublic

Description

Just now someone reported in Commons that this file:

https://commons.wikimedia.org/wiki/File:%D0%A6%D0%B5%D1%80%D0%BA%D0%B2%D0%B0_%D1%81%D0%B2%D1%8F%D1%82%D0%BE%D0%B3%D0%BE_%D0%9C%D0%B8%D1%85%D0%B0%D1%97%D0%BB%D0%B0_%28%D1%81._%D0%A7%D0%B5%D1%81%D0%BD%D0%B8%D0%BA%D0%B8%29_%D0%92%D0%B8%D0%B4_%D1%96%D0%B7_%D0%B7%D0%B0%D0%B4%D1%83.JPG

is displayed on that page with the wrong dimensions (making it look completely distorted, resized and scaled out of proportion by the browser).

Both the main thumbnail on top and the top row of the File history were affected.

They've purged it and that fixed it. However it was the MediaWiki-page that needed purging, the file itself was fine.

The main reason this happens is because we link to the canonical "current" version of an image by a version-less url. As a result, when a reupload occurs that changes the dimension (e.g. a crop, rotate, whatever), and this canonical url is purged, every existing <img> referencing that url will show the image in the browser out of proportion because we hardcode the width/height everywhere.

Note:

  • The example file above has a different unrelated problem (the first revision of the file has gone missing, 404).
  • I wonder whether this is limited to the File page. I doubt it. This probably affects usage in articles as well, including cross-wiki.

Now, before someone says it is unlikely the dimensions of a file change, I"ll respond: It is unlikely that a file changes at all because (at least Commons) actively discourages re-upload. It should only be done for non-trivial changes (anything else should be done as a new upload). So the few re-uploads that do happen quite change the dimensions (e.g. fix wrong orientation, or crop away borders of some kind).


Version: 1.22.0
Severity: normal

Details

Reference
bz55431

Event Timeline

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

Yikes, this uncovers a whole range of problems. Sounds like we should:

  • Purge the File page (no matter what)

As for usage in articles (please file a different bug), we should either:

  • Use versioned urls (e.g. merge file and filearchive)
  • or; Somehow purge all usage, cross-wiki - at least if the dimensions changed.
  • or; Say both is infeasible and we will accept distorted dimensions in favour of caching.

(In reply to comment #1)

  • Use versioned urls (e.g. merge file and filearchive)

I meant here that we'd not have /8/84/Example.svg and later /archive/8/84/20080323205329%21Example.svg, but always have a direct url that stays the same.

But using actual revision ids instead of timestamps as ID would be much better, but that means we need to actually *have* file revision ids (see bug 26741).

I agree that urls should change (there are many issues this should change). However I don't think (going off the top of my head) that particular part is cached (in parser cache anyhow. It would be cached by squid if anon), so I'm not sure that such a solution would actually fix this issue. The dimensions/other file metadata is cached, which was probably out of sync (likely due to a race condition judging by timestamps).

Regarding the missing original version - that's due to a race condition that was easily triggered by upload wizard, which has now been fixed.

This is related to the "Emit page purge jobs for commons files" task in the Multimedia backlog.

Also related to "Version URLs to help stop cache problems".

Actually in this case the thumbnails are really rendered wrong – I filed this as T172556.