Page MenuHomePhabricator

Use the current version of files from foreign repos
Closed, ResolvedPublic

Description

On bug 15748 comment 10 Aaron wrotes, that changes from commons files does not produce a unstable version. That is right, but the stable version still shows the old file (with the old filetimestamp=). This is confusing for the user and needs a unreview/review to fix it (maybe a review would be enough, but not possible with the gui).

Please always include the current image version for images from an foreign repo. Thanks.


Version: unspecified
Severity: major

Details

Reference
bz41832

Event Timeline

bzimport raised the priority of this task from to Unbreak Now!.Nov 22 2014, 12:45 AM
bzimport set Reference to bz41832.

For files moved to commons under same name and than deleted locally this bug means, that there is no image shown in the stable version, because that specific version does not exists. This can mean many broken pages for anon (because stable version is default on dewp).

I fail to understand the bug summary, but cannot come up with a better one either. Could you try to rephrase please?

(In reply to comment #3)

I fail to understand the bug summary, but cannot come up with a better one
either. Could you try to rephrase please?

(In reply to comment #3)

I fail to understand the bug summary, but cannot come up with a better one
either. Could you try to rephrase please?

He saying two things:

  • Changes to commons files used on page X don't cause a "page needs review" type notice to page X (which is actually desired).
  • The stable version (shown to logged out users) shows the "version at time of review" version of the commons files, not their latest version. The desired workaround for dewiki having to re-review thousands of pages that use a commons file that changed is to always use the current version. This is not what happens.

When there is no interest in making this better, than please revert r68135. It is better for the user to get the hint for pending file/template changes instead of no info and using the old version.

What is to do? All file links in the stable version to foreign repos should have no filetimestamp= in the link and should always use the current version of the file.

When a file is deleted locally a file from the foreign repo should used automatically in the stable version without creating a broken file inclusion and a hint to pending files/templates.

Thanks.

There is something broken on pl.wikipedia for not logged in users, and it looks like it's related.

E.g. on http://pl.wikipedia.org/wiki/Jeziora_Afryki , "22x20px" is displayed instead of some flags, and flag on Kenya ("Kenia") is not shown at all, the flag URL is an error page.

I'll boldly raise priority, as this (or at least I think it's this, but definitely something) breaks pages for almost all readers.

(In reply to comment #6)

There is something broken on pl.wikipedia for not logged in users, and it looks
like it's related.

It is the same, but the stable version is broken, not for anon users alone (but anon users get the stable version as default, users can set it in the preferences)

http://pl.wikipedia.org/wiki/Jeziora_Afryki?stable=0
http://pl.wikipedia.org/wiki/Jeziora_Afryki?stable=1

(In reply to comment #0)

On bug 15748 comment 10 Aaron wrotes, that changes from commons files does not
produce a unstable version.

And that comment is from 2010 (just saying).

This was reported on Nov 6th. It's not clear to me from the comments if this was a new problem but I assume so as per IRC conversations.

In case this is an issue in the codebase of FlaggedRevs the recent commits can be seen here: https://gerrit.wikimedia.org/r/#/q/project:mediawiki/extensions/FlaggedRevs+-owner:L10n-bot,n,z,

It is a old issue, on the de.wp village pump we have many discussion about this.

Some links are collected as a list in the section under https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia/Archiv/2012/Woche_47#Interesse_an_Bildern_noch_vorhanden.3F

It's not really clear to me what should happen - what exactly would be the suggested solution (if feasible)?

For dewiki & plwiki, display the most recent commons file rather than the version at time of review?

(In reply to comment #10)

For dewiki & plwiki, display the most recent commons file rather than the
version at time of review?

Well, that would certainly be less unexpected than the malformed output we are getting at e.g. https://pl.wikipedia.org/wiki/Jeziora_Afryki?stable=1 , with some images missing, and some replaced with chunks of wikitext.

Looks almost like some sort of referential integrity issue. [I say this without being very familiar with flagged revs].

https://pl.wikipedia.org/wiki/Jeziora_Afryki?stable=1 (As being viewed today) is revision 33110538 (17:52, 13 October 2012‎) and was auto-sighted at the same time (17:52, 13 October 2012).

Some (not all) of its images are missing, being displayed as if the file did not exist (aka, the part immediately after the | is being displayed as the link text, as if the link was not a file link but a normal link).

Additionally one image have a thumb to an incorrect url (for example: https://upload.wikimedia.org/wikipedia/commons/thumb/archive/4/49//22px-Flag_of_Kenya.svg.png which is missing the part in the middle. This appears unrelated to flagged revisions. Flagged revisions has simply stablilized this image to a missing image. Note the missing entry at [[commons:Flag_of_Kenya.svg]] for 06:19, 21 November 2009. This should probably be investigated separately.

To pick an example, [[File:Flag of Algeria.svg]] is one of these images not being displayed and just has a "normal" link with just the parameter after the pipe.

If we look at the database, specifically the flaggedimages table, we see the corresponding row:

mysql> select * from flaggedimages where fi_rev_id = '33110538' and fi_name='Flag_of_Algeria.svg';
+-----------+---------------------+------------------+---------------------------------+

fi_rev_idfi_namefi_img_timestampfi_img_sha1

+-----------+---------------------+------------------+---------------------------------+

33110538Flag_of_Algeria.svg20100812000321healu33sru52htiec9mxn90y26mh5r9

+-----------+---------------------+------------------+---------------------------------+

However Flag_of_Algeria.svg (at commons) with timestamp 20100812000321 has sha1 of 4zxh8rze9pa662xcx6qvnjshy6w4nq6. The healu33sru52htiec9mxn90y26mh5r9 sha1 corresponds to an image with timestamp 20120317155611. Since the timestamp and sha1 are out of sync, it appears no image is used.

However, The page was (auto)-sighted in october, so one would expect that neither would be the version used, and instead the most recent version of the image, from 20120317171026 (sha1: nuyez3fxwzypk3rno0pbprxfcr06kl0) would be used. (Note: if you disregard auto-sight, the last manual sight was in december 2011 which would correspond to the 20100812000321 (4zxh8...) image).

Last of all, some images are displayed properly, but seem inappropriately stabilized to the wrong version. for [[commons:file:Flag_of_the_Democratic_Republic_of_the_Congo.svg]], the version used is 20090110091808. However, we would expect the version from 2012-06-30T03:12:56 to be used (unless auto-sights are discounted and only manual sights update which image is used).