Last modified: 2014-11-18 18:07:14 UTC
Now that image renaming is possible, it should be activated on WMF wikis and most importantly on Commons. It has been asked for a few years now. As bug 709 is closed, this bug can help tracking the remaining issue before enabling $wgAllowImageMoving. Currently I see bug 14117, bug 14928, bug 15008, bug 15114 and bug 15574. Thanks !
Removed first 3 dependencies, as they are image redirects bug, not image moving
*** Bug 16834 has been marked as a duplicate of this bug. ***
Comment from Victor Vasiliev at bug 16834: Please enable image moving on all Wikimedia projects since it's pretty stable now. I've done some testing: * Moving a simple image with 1 entry in the history -- works * Referring to it from a old title -- works * Moving image with a large histry -- works * Protection from moving images to an incompatible extension -- works * Protection from moving images to an invalid filename -- works * Moving over another file -- didn't work, fixed, should work in trunk * Merging two images with large histories -- got one awful bug when one version of image was multiplied 8 times in the history. Can't reporduce it. Works in all other cases, but it's possible to create a case when the latest version of the image is earlier than the previous, because only old versions are sorted. * Splitting histories -- works If you have any other test cases, tell me their results or just suggest them here.
How about the two bugs supposedly "blocking" this one? i.e. bug 15114 and bug 15574. Don't really know about them, just asking.
(In reply to comment #4) > How about the two bugs supposedly "blocking" this one? i.e. bug 15114 and bug > 15574. Don't really know about them, just asking. Bug #15114 is marked as Resolved/Works for Me so that one should be fine.
Removing "tracking bug" annotations, since this is a request for a config change, not a tracking bug. Probably ready to go, though I have the vague impression we turned it partially on then tripped it back out for some issue... was that resolved?
Nobody seems to remember anything specific, so let's see if it's all better. :D Have set $wgAllowImageMoving on on all our wikis now... Default group perms will be limiting it to sysops only.
Disabled due to reports of data corruption/loss in some moves.
I suspect that this will cause problems for Wikisource, because we are using the ProofreadPage extension, which relies on stable names. Moving a single djvu file and removing the redirect might break hundreds of pages on Wikisource. And the person doing this on commons will, in general, not be aware of it.
Why would anyone remove the redirect? Commons had better be smart enough not to do that on a regular basis. It will break *everyone*'s sites, including third-party sites that are impossible to track.
Deleting file redirects is probably not high on the list of tasks Commons sysops will be doing. (In reply to comment #9) > I suspect that this will cause problems for Wikisource, > because we are using the ProofreadPage extension, which > relies on stable names. Nothing should assume that a file on Commons will have a given or stable name. Doing so is wrong. I'm not sure what the context is for the ProofreadPage extension is, but in particular, templates which assume that an audio file will have a certain naming scheme are totally stupid, broken by design, and should be expected to fail for reasons discussed at length on Commons. If that's analogous to what the extension you refer to does then it needs to be fixed. However, this is outside the scope of this bug.
Why would it be stupid to assume that a file can continue to be accessed by the same name in the future?
(In reply to comment #12) > Why would it be stupid to assume that a file can continue to be accessed by the > same name in the future? > Because file names are subject to change (yes, even on Commons and even before file renaming was enabled), e.g. when a file is deleted because it is a duplicate or when a file is moved to a different name for whatever reason. We have had lengthy discussion on Commons about why it is bad to assume files have names following a certain pattern. Renaming files is pretty common (check [[commons:Category:Media requiring renaming]]), there is a bot that does this task and there is also a bot which corrects links to the old files. Preventing these bots from doing so is the project's problem, they will then have to live with file redlinks. We have had talks about why file redirects on Commons are evil and should only be used in very special (rare) cases and not on a regular basis.
Patterns aren't at issue. Not fucking people over by removing existing files is at issue.
Note I will desysop anyone I see removing redirects without a very good reason -- it's extremely user-hostile and makes the project less useful.
(In reply to comment #14) > Patterns aren't at issue. Not fucking people over by removing existing files is > at issue. > As I said, there are various reasons why file names can change. We try to keep inclusions intact by running a bot which changes the file name on the local projects. If some projects disallow this bot from doing its work, there's not much we can do. Anyway, this seems to be a bit off-topic and not really related to whether image renaming can be enabled but rather to when image renaming should be done. (In reply to comment #15) > Note I will desysop anyone I see removing redirects without a very good reason > -- it's extremely user-hostile and makes the project less useful. > File redirects are discouraged on Commons, mainly because they break CheckUsage. File moving has so far been done without redirects and I don't think that this will change in the future. Though admin are strongly encouraged to leave a note in the deletion log about where the duplicate/new file can be found.
(In reply to comment #16) > (In reply to comment #14) > > Patterns aren't at issue. Not fucking people over by removing existing files is > > at issue. > > > > As I said, there are various reasons why file names can change. We try to keep > inclusions intact by running a bot which changes the file name on the local > projects. If some projects disallow this bot from doing its work, there's not > much we can do. Anyway, this seems to be a bit off-topic and not really related > to whether image renaming can be enabled but rather to when image renaming > should be done. > Doesn't help a damn bit for reusers outside of WMF scope.
(In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #14) > > > Patterns aren't at issue. Not fucking people over by removing existing files is > > > at issue. > > > > > > > As I said, there are various reasons why file names can change. We try to keep > > inclusions intact by running a bot which changes the file name on the local > > projects. If some projects disallow this bot from doing its work, there's not > > much we can do. Anyway, this seems to be a bit off-topic and not really related > > to whether image renaming can be enabled but rather to when image renaming > > should be done. > > > > Doesn't help a damn bit for reusers outside of WMF scope. > If they have basic experience with MediaWiki, they will have a look at the deletion log and find the correct file name. If they don't, I'm sorry for them, but there's not much we can do. File redirects break our own tools, IMHO we should first think of our own projects and after that of the reusers.
Or make your tools work better and take account for redirects? Redirects are a basic functional aspect of MW designed to aid in user-friendliness. Refusing to make redirects because your tools break is just being lazy tool-makers.
(In reply to comment #18) > If they have basic experience with MediaWiki, they will have a look at the > deletion log and find the correct file name. If they don't, I'm sorry for them, > but there's not much we can do. File redirects break our own tools, IMHO we > should first think of our own projects and after that of the reusers. ... Are you serious? *Not breaking links* helps everyone, ESPECIALLY US FIRST AND FOREMOST. If CheckUsage is broken, fix CheckUsage. If CheckUsage can't or won't be fixed, let us know so we can replace it with something that works. The user-hostile attitude of "well you can hunt around for hours trying to figure out why the link broke, nothing we can do" is completely unacceptable for a project like Wikimedia which has the explicit aim of getting useful and interesting material into peoples' hands. Sometimes it's necessary to let a suboptimal situation go for a while when there's limited attention, but this isn't one of them -- this is a case where you're advocating *spending active effort to hurt users* by breaking links, and this is not a position the Wikimedia Foundation can support.
(In reply to comment #20) > (In reply to comment #18) > > If they have basic experience with MediaWiki, they will have a look at the > > deletion log and find the correct file name. If they don't, I'm sorry for them, > > but there's not much we can do. File redirects break our own tools, IMHO we > > should first think of our own projects and after that of the reusers. > > ... > > Are you serious? > > *Not breaking links* helps everyone, ESPECIALLY US FIRST AND FOREMOST. > > If CheckUsage is broken, fix CheckUsage. > > If CheckUsage can't or won't be fixed, let us know so we can replace it with > something that works. > > The user-hostile attitude of "well you can hunt around for hours trying to > figure out why the link broke, nothing we can do" is completely unacceptable > for a project like Wikimedia which has the explicit aim of getting useful and > interesting material into peoples' hands. > > Sometimes it's necessary to let a suboptimal situation go for a while when > there's limited attention, but this isn't one of them -- this is a case where > you're advocating *spending active effort to hurt users* by breaking links, and > this is not a position the Wikimedia Foundation can support. > See http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/Archives/User_problems_7#User:ChristianBier (see my contribution, 5th comment from botton of the ChristianBier section) for a more detailed explanation why redirects don't work with CheckUsage. If this can be fixed, great! Another reason to not use redirects is the additional pages which provide more attack space for vandals. I don't know whether some of you remember the situation with [[File:Red pog2.svg]]. This was basically a redirect to [[File:Red pog.svg]], which was at that time created only for use on the English Wikipedia to bypass the server's image cache for Red pog.svg. However, this is used in a template for geolocation (the infobox thingies showing you the location of a city etc., this file is the red dot marking the location), so it is heavily used on en-wp. To make things worse, other projects copied this template (with the redirect as red dot file) from en-wp, so loads of project suddenly used the redirect. The actual file was protected from editing, because changes to this file can break a huge number of sites all across the WMF projects. The redirect, however, was not protected, so a user uploaded a file over the redirect. This file was now included instead of the actual red dot. Luckily the newly uploaded file was just a slightly modified red dot, but it could also have been a vandalized image. Protecting a file will then mean also finding all redirects for this file and protecting those as well. Same goes for unprotection. I don't think this is a very practical solution. Another way to address this issue would IMHO be to always display a deletion log excerpt on non-existing image pages. This way reusers would not have to find the logs on their own, just to find out what happened to their file.
Summary of problem: Third-party CheckUsage tool has limited functionality, and doesn't currently handle a lot of things well including image redirects. Chris's suggested solution: Break all existing links and tell people they just can't rely on using anything from Commons. My suggested solution: Fix or replace third-party CheckUsage tool so it meets its own requirements of checking image usage.
May I point to the long existing but untested/unreviewed extension http://www.mediawiki.org/wiki/Extension:GlobalUsage ? Could solve the problem...
(In reply to comment #23) > May I point to the long existing but untested/unreviewed extension > http://www.mediawiki.org/wiki/Extension:GlobalUsage ? > > Could solve the problem... \o/ bug 18059 <- added to my review list
(In reply to comment #22) > Summary of problem: Third-party CheckUsage tool has limited functionality, and > doesn't currently handle a lot of things well including image redirects. > Not only that, I also mentioned redirects giving more opportunities for vandal attacks. How should we take care of those? Also think of several consecutive renames, which give a pretty long chain of image redirects. How far will the software follow those? And are there ways to find redirects which are breaking because the software won't follow the complete chain? > Chris's suggested solution: Break all existing links and tell people they just > can't rely on using anything from Commons. > This was the way we always did it. I'm not saying it's great, but I can't see why this suddenly is such a big issue. I also gave a hint how I think this could by fixed (display deletion log on non-existing image pages), what about that? > My suggested solution: Fix or replace third-party CheckUsage tool so it meets > its own requirements of checking image usage. > If that can be done, great! If we can get MediaWiki to do this job, even better! However, some sort of CheckUsage is vital for the operation of Commons, so I don't think a policy change will be possible before we have a tool that actually works.
(In reply to comment #25) > Not only that, I also mentioned redirects giving more opportunities for vandal > attacks. How should we take care of those? Also think of several consecutive > renames, which give a pretty long chain of image redirects. How far will the > software follow those? And are there ways to find redirects which are breaking > because the software won't follow the complete chain? We have the same issues with templates: protected templates may be accessed via unprotected redirects, and those redirects may be vandalized. Also, templates may be moved twice, which will create double redirects. Have anyone *ever* complained about template redirects and recommended everyone to avoid them? I can hardly believe they do, though they have all those issues. So: 1) Protect critical redirects 2) Run double redirect fixing bots.
(In reply to comment #25) > Not only that, I also mentioned redirects giving more opportunities for vandal > attacks. How should we take care of those? Protect all image names that are heavily used. Including redirects. This is not a difficult proposition in the scale of things. If you make a mistake, revert it (it's a wiki, right?) and try harder next time. (Lightly-used redirects to heavily-used images need not be protected.) > Also think of several consecutive > renames, which give a pretty long chain of image redirects. How far will the > software follow those? As with ordinary redirects, I assume this will only be followed one step by default. > And are there ways to find redirects which are breaking > because the software won't follow the complete chain? Ideally, Special:DoubleRedirects would work for this. I haven't looked at the image redirect implementation, so I don't know if it will automatically work, but I don't see why it wouldn't if it uses the redirect table sensibly. Even if you couldn't easily find the double redirects and so they sometimes broke for a while by mistake, it's rather better for end users than *deliberately deleting* them, wouldn't you say? > This was the way we always did it. I'm not saying it's great, but I can't see > why this suddenly is such a big issue. Because people found out about it who haven't lost sight of the fact that the purpose of Commons does not end with Wikimedia projects. > I also gave a hint how I think this > could by fixed (display deletion log on non-existing image pages), what about > that? If I link to an file on Commons, THAT LINK SHOULD WORK FOREVER. It should work whether I'm linking from a Wikimedia project or not. I should not have to spend any time at all debugging the fact that suddenly an image (which may have been added long ago by someone else to a site I'm now responsible for maintaining, for instance) stopped working. I should not be expected to know what a deletion log is or how to figure out where the image page is. I should not have to ever think about the image again after I add it, as long as it still exists somewhere on Commons. This is the *point* of redirects. They are necessary for Commons to be a reliable resource for third parties. And there is *no* legitimate reason to not use them. > If that can be done, great! If we can get MediaWiki to do this job, even > better! However, some sort of CheckUsage is vital for the operation of Commons, > so I don't think a policy change will be possible before we have a tool that > actually works. Assuming that this will happen in the relatively near future, this is an acceptable temporary position.
Images are moved at commons. When an image is moved, there's a bot which fixes the use on all projects. Where's the problem? ThomasV noted a potential problem, which should be fixed either on ProofreadPage or the fixing bot. I see no point in keeping the redirect on many use cases: names whicha are wrong and/or misleading, non-descriptive filenames which do goo to anyone... As far as there is no usage left, the Process works. Threatening to desysop on deleting a redirect makes no good. BTW, current CheckUsage is just a semi-permanent workaround while waiting bug 1394 (from 2005!!) to be fixed.
(In reply to comment #27) > > And are there ways to find redirects which are breaking > > because the software won't follow the complete chain? > > Ideally, Special:DoubleRedirects would work for this. I haven't looked at the > image redirect implementation, so I don't know if it will automatically work, > but I don't see why it wouldn't if it uses the redirect table sensibly. Probably not. It's a hodgepodge of FileRepo and ImagePage code. Needs some tidying up (and docs).
(In reply to comment #28) > Images are moved at commons. > When an image is moved, there's a bot which fixes the use on all projects. > Where's the problem? The problem is that non-Wikimedia projects also use images from Commons, and the bot will not fix them. Reference: http://images.google.com/images?q=site%3Acommons.wikimedia.org
(In reply to comment #30) > The problem is that non-Wikimedia projects also use images from Commons, and > the bot will not fix them. No. The problem is that a bot is needed. MediaWiki should automatically update the links. Including when it comes from a ForeignAPIRepo and not a ForeignDBRepo.
You mean, like, . . . by allowing image redirects? No links should have to be changed. The old links should work forever unless there's some compelling reason to change them.
GUYS! This is not what the bug is about & is not helpful to anyone in any way.
Image/file renaming ('movefile' permission) is currently enabled for sysop group, but not for regular users. Do we want to open it to autoconfirmed or something, or just stick with sysops?
Ok, missed $wgAllowImageMoving being off. :P Now enabled for reals. :) Same as noted above; for sysops only by default.
