Last modified: 2014-10-23 07:29:06 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 T74389, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 72389 - abbrvThreshold mismatch between commons as foreign repo and local commons breaking images with long names
abbrvThreshold mismatch between commons as foreign repo and local commons bre...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
unspecified
All All
: Unprioritized normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-10-22 21:35 UTC by j.l
Modified: 2014-10-23 07:29 UTC (History)
7 users (show)

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


Attachments

Description j.l 2014-10-22 21:35:30 UTC
Reported on https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Image_problem

Thumbnails of several embedded image (stored on commons) fail to show on enwiki, loading the thumbnail url gives:

Error generating thumbnail

The given path of the specified thumbnail is incorrect; expected 'e/e1/US_Navy_120209-N-XD935-302_Mass_Communication_Specialist_1st_Class_Shane_Tuck,_assigned_to_the_Expeditionary_Combat_Camera_Underwater_Photo_Team,_c.jpg/220px-US_Navy_120209-N-XD935-302_Mass_Communication_Specialist_1st_Class_Shane_Tuck,_assigned_to_the_Expeditionary_Combat_Camera_Underwater_Photo_Team,_c.jpg' but got 'e/e1/US_Navy_120209-N-XD935-302_Mass_Communication_Specialist_1st_Class_Shane_Tuck,_assigned_to_the_Expeditionary_Combat_Camera_Underwater_Photo_Team,_c.jpg/220px-thumbnail.jpg'.


On commons everything looks fine. Example images which produce the bug:

File:US Navy 120209-N-XD935-302 Mass Communication Specialist 1st Class Shane Tuck, assigned to the Expeditionary Combat Camera Underwater Photo Team, c.jpg

File:1801 Cary Map of the East Indies and Southeast Asia ( Singapore, Borneo, Sumatra, Java, Philippines - Geographicus - EastIndies-cary-1801.jpg

File:Antoine-François Callet - Louis XVI, roi de France et de Navarre (1754-1793), revêtu du grand costume royal en 1779 - Google Art Project.jpg
Comment 1 Bawolff (Brian Wolff) 2014-10-23 02:35:17 UTC
Appears to be accientally caused by f7be7e6a (Abbreviation threshold for files with long names was set to 140 for commons as a foreign repo, but kept at 160 on actual commons, thus breaking all files with a name between 140-160 bytes long)
Comment 2 Gerrit Notification Bot 2014-10-23 02:42:02 UTC
Change 168239 had a related patch set uploaded by Brian Wolff:
Partial revert f7be7e6a. Change commons abbrvThreshold back to 160.

https://gerrit.wikimedia.org/r/168239
Comment 3 Bawolff (Brian Wolff) 2014-10-23 02:43:51 UTC
I wonder if it would be a good idea to also make expected name mismatches give a redirect instead of an error to prevent this sort of thing from causing explosions (And allow more mobility in changing the value in the future w/o breaking hotlinkers, or old values from parser cache)
Comment 4 Gerrit Notification Bot 2014-10-23 03:03:36 UTC
Change 168239 merged by jenkins-bot:
Partial revert f7be7e6a. Change commons abbrvThreshold back to 160.

https://gerrit.wikimedia.org/r/168239
Comment 5 Bawolff (Brian Wolff) 2014-10-23 03:20:41 UTC
CScott deployed fix, so it should be resolved now. (Some cached pages may need to have ?action=purge done to them)
Comment 6 Tisza Gergő 2014-10-23 07:29:06 UTC
(In reply to Bawolff (Brian Wolff) from comment #1)
> Appears to be accientally caused by f7be7e6a (Abbreviation threshold for
> files with long names was set to 140 for commons as a foreign repo, but kept
> at 160 on actual commons, thus breaking all files with a name between
> 140-160 bytes long)

Eventually we want to get rid of filenames in URLs completely (bug 64214). Although I suppose some form of redirect would still be needed at that point, to not break all hotlinks.

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


Navigation
Links