Set $wgAllowExternalImagesFrom to allow https://upload.wikimedia.org/wikipedia/commons/
OpenPublic

Description

Author: rd232

Description:
Please set $wgAllowExternalImagesFrom to allow https://upload.wikimedia.org/wikipedia/commons/ URLs (whatever the regex is for that...!)

This will
(i) allow Wikimedia sites to display old versions of a file without having to reupload it. This can be handy for comparison of different file versions, particularly on Commons, in image editing tutorials, etc.
(ii) allow transcluding of a specific version, to guard against later updates. This is of particular relevance for Wikinews.

I know turning on External Images or even the Whitelist would be a BIG DEAL, but this seems a small one, as it is only supposed to affect bare URLs, and there should be few if any current bare URLs pointing to upload.wikimedia. I'm assuming that cases like [http://validator.w3.org/check?uri=http://upload.wikimedia.org/wikipedia/commons/6/68/Composite_UML_class_diagram.svg This source is valid SVG 1.1!] will NOT be affected (that would be bad).

If it's possible, maybe some attempt can be made to check what if any existing uses would be affected.


Version: unspecified
Severity: enhancement

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz40095.
bzimport created this task.Via LegacySep 7 2012, 10:32 PM
Dereckson added a comment.Via ConduitSep 8 2012, 7:03 AM

I would like this change is discussed on meta. before to see it implemented.

Does the community really want this, especially Wikimedia-wide?

bzimport added a comment.Via ConduitSep 8 2012, 10:46 AM

brian.mcneil wrote:

From the point of view of Wikinews' requirements, this is a "kludge" that would address a problem we have:

Say Commons has [[File:Spread of Zombie Apocalypse.png]] and, country by country, people are developing a taste for brains.

If we publish an article [[n:Zombies reported in Paris]], including this file, then someone looking at that article should always see the version where France has just been coloured-in as infected.

If, later on, we publish [[n:New Zealand last Zombie-free nation]], then the file included there should be the more-current version leaving that as the only country not coloured in.

Unless there are far more-complex requirements that justify use of the External images parameter, I would suggest the appropriate solution is to have another parameter within [[File: ]] which accesses the version in-place on a specific date.

Thus: [[File:Spread of Zombie Apocalypse.png|date=2012-11-01|...]] could be used in one Wikinews article, and [[File:Spread of Zombie Apocalypse.png|date=2012-12-21|...]] in a later article.

That isn't really a bug, but a feature request - and seems far more logical than mucking about with the external images parameter.

bzimport added a comment.Via ConduitSep 8 2012, 11:18 PM

rd232 wrote:

Yes, I had similar thoughts initially at http://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals/Archive/2012/08#Transcluding_old_file_versions, before I thought External Images could work as a quick alternative.

Note that date isn't a sufficient identifier for files. I don't know if date+time would work, or if it would need to be a file equivalent of a revisionID as we have for pages. But expanding the wikisyntax would certainly be more elegant, and solve the presentation problem with External Images (no control over presentation).

bzimport added a comment.Via ConduitSep 8 2012, 11:48 PM

brian.mcneil wrote:

Revision ID is problematic in that I doubt it is particularly portable (think export and import to another wiki).

And yes, date may-well not be granular enough if you assume that it should be an exact revision you refer to. In that respect it should be possible to specify a date and time.

However, the behaviour of the software should be to present the version of the File: which was current at the date-time given, even if there is no version with an exact match for date-time. It should work by looking back through the revision history to identify which version was valid/current at that given point in time.

I'm glad you see this as a more elegant solution, it also has the benefit of abstracting away from the underlying data without a large processing hit. Those sort of approaches to problems generally last longer, make more sense to end-users and developers alike, and I'm sure Wikinews could wait for this if it's pencilled in as something which will be developed.

Rillke added a comment.Via ConduitSep 13 2012, 2:30 PM

Currently, for old file versions MediaWiki actually use the timestamp (date+time) to identify a single version. This already led to problems (2 files uploaded under the same name at the same time).

Each file revision should have a unique ID and you should be able to find the file with this unique ID....

As an interim solution, one could allow using “archive”-versions by URL. But this markup is nothing, I like to see inside a Wikipedia Article, just for discussion, ...

Aklapper added a comment.Via ConduitFeb 27 2013, 11:47 PM

(In reply to comment #1)

I would like this change is discussed on meta. before to see it implemented.

Still missing a discussion in order to proceed, plus an URL to it.

MZMcBride added a comment.Via ConduitFeb 28 2013, 8:18 AM

I thought the FlaggedRevs MediaWiki extension already covered Wikinews for historical images. I seem to remember it having the ability to do a "point in time" snapshot of pages, including templates and images. If FlaggedRevs is insufficient, that's probably a separate bug in the FlaggedRevs extension or its Wikinews configuration.

Regarding this bug, I'm very hesitant to see $wgAllowExternalImagesFrom used in this way, mostly as it seems like a kludge, and it'll sacrifice one of the saner parts of our home-grown image inclusion syntax: image usage tracking (both local and global [Wikimedia wiki-wide]). To me, that's a deal-breaker.

And, for what it's worth, as I recall, Commons and any other Wikimedia wiki can already do this locally. The whitelist at [[commons:MediaWiki:External image whitelist]] presumably works. I know it works on mediawiki.org (cf. [[mw:MediaWiki:External image whitelist]]). It's still not a great idea, though.

bzimport added a comment.Via ConduitFeb 28 2013, 11:33 AM

rd232 wrote:

"The whitelist at [[commons:MediaWiki:External image
whitelist]] presumably works. " - I presumed that too, but it doesn't. $wgAllowExternalImages and $wgEnableImageWhitelist both default to false and neither is set to true on Wikimedia.org. Hence this bug request, which seemed a safer way of opening that door than allowing the whitelist.

MZMcBride added a comment.Via ConduitFeb 28 2013, 6:00 PM

(In reply to comment #8)

"The whitelist at [[commons:MediaWiki:External image whitelist]] presumably
works." - I presumed that too, but it doesn't. $wgAllowExternalImages and
$wgEnableImageWhitelist both default to false and neither is set to true on
Wikimedia.org.

From https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=includes/DefaultSettings.php;hb=HEAD:


$wgEnableImageWhitelist = true;

The default setting is true. And it's not overridden by Wikimedia's configuration files.

Again, I don't think it's a good idea to use this whitelist, but it _is_ enabled on Wikimedia Commons and every other Wikimedia wiki. You're free to play around with it at [[testwiki:MediaWiki:External image whitelist]] (I've gone ahead and made you an admin there).

cscott added a comment.Via ConduitMay 29 2014, 7:40 PM

Adding myself to the cc, since any change to the default image whitelist would probably have to be mirrored in parsoid.

Add Comment