Wikimedia Bugzilla is closed!

In particular it is important to be able to retain the image history if the name
needs to be changed for some reason.  It should work identically to the 'move
page' feature.

I assume the reason this hasn't been implemented yet is that you'd 
have to make "image redirects" work right.  Challenging, but not 
impossible ...

To the best of my knowledge this is still an issue in 1.5.0.
Also, this should be a high priority. (There are several votes)
Updating bug.

No, votes don't determine what happens on our implementation of BugZilla; the
most they're used for is to watch particular bugs, but they're generally
ignored. This is a normal priority enhancement still.

*** Bug 4654 has been marked as a duplicate of this bug. ***

*** Bug 4877 has been marked as a duplicate of this bug. ***

This would be a truly welcome feature, especially at Commons. To rename an image
at the moment people have to (0) get someone to explain it to them (usually they
expect the Move tab should work as it does for articles), (1) upload the image
again with the correct title and information, (2) delete the image (if an admin)
or tag the bad image as redundant or speedy delete or something like that. If
they're not an admin, then an admin has to review the image, make sure it is not
being used in any project and that it's not a mistake (ie, the uploader was the
person who tagged it), and then delete it. A one-step process would be really,
really welcome, especially as Commons becomes the real media centre for all
projects and people stop uploading free images locally. 

Thankyou devs!

Commons admins move images all day and all night. Currently they need to go
through torturous hoops.

I can imagine they must have enormous RSI now. I tried it for a short while
today. I can't imagine how they survive this  24/7 !

I only can agree with the other Commoners commenting here. I do not overestimate it if I say that 
this is a critical feature to the success of Wikimedia Commons. Why? Here some details: 
 
* Currently if you have an exact duplicate image (which happens quite often), you have to relink 
every local image by hand in every local wiki to one of the images and then delete the other one. 
The way determining where an image is lused is luckily currently somewhat solved via the external 
"check usage" function at the Toolserver. 
* Also very often you need to clean up image names like "Image:12345HGK.jpg". These names are often 
from digital camera images that were directly uploaded. Currently you have to other choice than 
downloading and reuploding it again and do the procedure for redundant images... 
* For the job of relinking images some people use bots. In my eyes bots show the lack of a feature 
of the MediaWiki software that is so urgently needed that people create such a crutch in order to 
reduce the pain quickly. You can see this with the interwiki links very well and with image 
relinking there is the same as well. Those bots produce a lot of clutter in the article history, 
produce avoidable load on the wikimedia servers if the feature would exist and cause anger in case 
something went wrong and of course the relinking bots do not work perfect. They forget wikis and 
are not available to most people as they are far to complicated. 
 
The result is: 
* Wikimedia Commoners do the hard work of hand relinking which could be spend better with other 
much more important things like checking copyvios, uploading new images, improving the user 
expierence in Wikimedia Commons itself and so forth... 
* Many image holes in Wikipedia articles. 
* Many frustrated Commoners and many frustrated Wikipedians. 
* Wikimedia Commons does thus not get that much accepted within many Wikipedias and many people are 
thus promoting agressively against Wikimedia Commons. 
 
So Wikipedia is now the largest encyclopedia Wikimedia Commons has the chance to become the largest 
and best media ressource of the world and we really need this feature (among others) to achieve the 
vision of Wikimedia Commons. 

(In reply to comment #9)
I completely agree this comment

A hack solution would be to create a script that copies the imagefile to a
temporary directory, deletes it from the database, and then "reuploads" it from
the server itself (like [[meta:SpecialUploadLocal]]), all done automatically.
I've done this on a local wiki installation where reuploading a 3.5 MB file
would be too painful. Maybe I'd be able to add this functionality, must investigate.

(In reply to comment #11)

Allowing image RDRs to work is probably hoping too much (just keep it in mind
for the future :))... but just some basic move ability would be more than
welcome as the problem primarily occurs about 10 seconds after someone has
uploaded a file, and they then notice/realise the name is wrong somehow. In this
case RDR is not necessary because the file hasn't been put in use yet.

Agree with everything, I would really like this. One reason for wanting to
delete that may not have been mentioned:
*Occasionally, you may upload something of a sensitive nature, by accident. Eg,
you grab the wrong photo from the directory and end up with your face (or worse)
on Commons. You should be able to delete this immediately, as the uploader of
the file.

Not being able to rename also makes it much more likely that files will be badly
named, or fail to follow any convention, because it's too much work. Case in
point, I uploaded an image of a statue of Louis XIV. At the time, I thought it
was Francois I and named it accordingly, then linked to it. Now, to  fix it, I
would have to upload the new one, fix the links, and tag for speedy delete the
old one. No thanks.

Yes. yes. this is a important feature. A lot of users upload images from
en.wikipedia with different name.

I think it's about time to point out this extract from
http://en.wikipedia.org/wiki/Wikipedia:Bug_reports#Etiquette, which is linked to
from the main page of this tracker.

"Contribute useful comments; useless comments (i.e. advocacy) decrease the
signal to noise ratio"

Take the hint, people.

*** Bug 6149 has been marked as a duplicate of this bug. ***

This bug is two years old, will it ever be fixed?

I would be interested in working on this. Can anybody clarify what the "torturous hoops" referred to in comment #8 above are? Anybody familiar 
with the database schema available to comment on exactly what would be entailed? Any more information about "image redirects" (see comment 
#2), "Challenging, but not impossible"? With a little bit more information I could have a try at implementing this.

I've searched the web for info on this and found very little, apart from stuff like this: "Currently there is no easy way to rename an image — 
they will not "Move" to new titles in the ways that articles will." (http://en.wikipedia.org/wiki/Wikipedia:Image_use_policy)

Looks like at a minimum changes would need to be made in the following files:

http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3/includes/SpecialUpload.php
http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3/includes/Image.php

And possibly here as well:

http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3/includes/ImageFunctions.php
http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3/includes/ImagePage.php

After the image storage backend is restructured this will be trivial.
Don't bother working on it on the current system, we won't support it.

What is the roadmap version that the image storage restructuring is planned for?
(1.9.0, 2.0.0, etc?)

It appears to have been planned for 1.7. 
<http://www.mediawiki.org/w/index.php?title=MediaWiki_roadmap&diff=26560&oldid=26490>

Which, of course, has come and gone. Someone ask Brion on IRC sometime.

Maybe there could be a future to rename a file by sysops?

This would simply rename the file without checking usage or things like that so
someone would have to worry about that and sysops have to do this anyway.

This feature would most probably lower server load as reuploading of pictures
incorrectly usually means:
1. Get the file from the server
2. Reupload with the wanted name
This can reach about 8MB (for 4MB picture) and could be reduced to 0MB.

Plus the database is getting bigger beacuse of luck of this feature. History of
the file stays in the db (avaible for undelete) including the picture itself
(not sure about thumbs) and a new copy is made. So instead of simply changing
the image table you have to change about 4 db tables including creating new entries.

The issue is rewriting the image code to support this, not any concerns over
usage problems.  See comment #19.  When this is implemented, presumably either
it will be implemented together with image redirects, or image moving will be
somehow restricted as you suggest.  Those who will do the rewriting know the
benefits of this bug, of which server load is the least.  They just haven't
gotten around to it yet.  Please be patient, it will happen eventually and no
sooner.

@Simetrical: Great. This is definitely not the way to solve problems. There are some people that are willing to 
solve that problem. Invite those people working on it. Point out *what* what you expect and what are you currently 
working on related to it so that there is not a waste of time and efforts. Saying "sometime it will be solved" 
doesn't work. Don't work alone. That's exactly why so many things get delayed. Not because anyone of the developers 
is lazy -quite the contrary- but because you don't really encourage people just joining. Have a look at KDE how they 
attract people? Did their open commit style ever harm them? No.

Daniel,

I very much agree this needs to be fixed sooner than later, but this IS open
source. Anyone, at any time, can feel free to submit patches (etc) for review.
Certainly, even at KDE, not everyone can commit to the CVS.

I have full faith, despite previous disagreements, in Brion and crew.

Regards,

Jamie.

(In reply to comment #26)
> I very much agree this needs to be fixed sooner than later, but this IS open
> source. Anyone, at any time, can feel free to submit patches (etc) for review.

Yes, in theory, but the developers on this thread have pretty much said, "don't work on this; we're not 
interested in you doing anything, nor in providing you with information on how you could provide help 
in a form that we would accept." Two comments to illustrate:

(In reply to comment #24)
> Those who will do the rewriting know the
> benefits of this bug, of which server load is the least.  They just haven't
> gotten around to it yet.  Please be patient, it will happen eventually and no
> sooner.

(In reply to comment #19)
> Don't bother working on it on the current system, we won't support it.

I know nothing about the image backend rewrite.  If someone with sufficient
knowledge of SQL and so on would offer to do it, probably Brion would be happy
to lay out the requirements and review changes, although I'm not one of the core
devs, don't set priorities or policies, and can't vouch for anyone else working
on MediaWiki doing anything in particular.  If someone would like to offer their
services, they should wait on irc://irc.freenode.net/mediawiki/ for brion or
TimStarling to come on and ask about helping.

Hmm, I see how what I said before might have been construed as saying we aren't
interested in outside help.  Didn't mean that, I *assume* we are.

*** Bug 7808 has been marked as a duplicate of this bug. ***

I have tried searching for information on the backend rewrite, but apart from
the link in comment #21, I cannot find any information.  Can someone please
provide a link to any kind of tracking information?  If there is a bug filed for
that, shouldn't this depend on it?

So this depends on there being image redirects -- has anyone filed that as a bug?

(In reply to comment #32)
> So this depends on there being image redirects -- has anyone filed that as a bug?

It depends upon more than just image redirects; as Brion previously stated, we
want to rework the whole image storage backend so that it uses the new FileStore
mechanism (what we're using for deleted images at the moment). Once this is
done, then we can think about the mechanics of how moving a media file would
work - and yes, we will then require image redirects.

*** Bug 8684 has been marked as a duplicate of this bug. ***

Has there been any progress on this?

Something else that will need to be considered is 'shared image repositories'. If you move an image, how will other wikis that share this repository be 'notified' of the change and still properly display the image?

Tim is currently doing the image backend rewrite.  Given comment #19, I assume that it will be fixed when that is, probably in not too long.

*** Bug 10734 has been marked as a duplicate of this bug. ***

retaining the complete file history including the orinigal uploader (author) seems almost mandatory under the licenses, so a fix like this would be a great improvement not only for easy-to-use but from a legal perspective as well

Renaming files = necessity for any program that works with files, especially in its own little structure.

(In reply to comment #35)
> Something else that will need to be considered is 'shared image repositories'.
> If you move an image, how will other wikis that share this repository be
> 'notified' of the change and still properly display the image?

Redirects.  The same way it works for pages that have been moved.  The old links still work. 

(In reply to comment #36)
> Tim is currently doing the image backend rewrite.  Given comment #19, I assume
> that it will be fixed when that is, probably in not too long.

Note that I was wrong here, he was rewriting something totally different.  No idea when this will actually get done.

A Commons user alerted me to this template for renaming media: http://commons.wikimedia.org/wiki/Template:Rename
--Eric

(In reply to comment #42)
> A Commons user alerted me to this template for renaming media:
> http://commons.wikimedia.org/wiki/Template:Rename
> --Eric
> 

That solves the problem of indicating which media needs to be renamed and does not help at all in the renaming.

(In reply to comment #43)
> (In reply to comment #42)
> > A Commons user alerted me to this template for renaming media:
> > http://commons.wikimedia.org/wiki/Template:Rename
> > --Eric
> > 
> 
> That solves the problem of indicating which media needs to be renamed and does
> not help at all in the renaming.

Yes it does. We are working on a bot that will re-upload the tagged image and tag the old one bad name for processing with Universal replace of CommonsDelinker. Betacommand is working on the bot and we expect it to go 'live' within a few weeks. Functional specifications are at http://commons.wikimedia.org/wiki/Commons:MediaMoveBot

Nevertheless, the ability to rename files is basic to any file manager, and losing the history of a file (unless one copies and pastes it from the old image to the new) is quite annoying. For smaller wikis, bots might not be feasible. Whether the maintainers lack the expertise to write one (me), the resources to keep one running all the time (also me), or are ignorant that there is such a possibility (not me, actually), file renaming should be possible without complex workarounds. Especially since this bug has been around for over three years.

(In reply to comment #45)
> Nevertheless, the ability to rename files is basic to any file manager

Yes, we know that. So who's willing to cough up the $20k or so that is needed to put a skilled coder to work to realise the functionality, because the Wikimedia Foundation has not deemed it important enough to get it done sinse this issue was reported. Any other input is just repeating what was said above and does not bring solving this issue any further. Also see Comment #15.

(In reply to comment #46)
> ...who's willing to cough up the $20k or so that is needed
> to put a skilled coder to work to realise the functionality...
> 

If I had such money, or the kind of programming skills required, I'd be quite willing. Personally, I doubt it would cost quite so much, but point taken. I'll go forget my Bugzilla password, OK?

(In reply to comment #44)
> Yes it does. We are working on a bot that will re-upload the tagged image and
> tag the old one bad name for processing with Universal replace of
> CommonsDelinker.

Helpful, but don't lose sight of the fact that this is a workaround.  We really need image description pages that don't have file name extensions or specific file types associated with them, and then we need to ability to move them to different names.

(In reply to comment #46)
> Yes, we know that. So who's willing to cough up the $20k or so that is needed
> to put a skilled coder to work to realise the functionality

I'd donate some.  I'd donate more money to bounties on specific bugs than I would give to the Foundation.  Always best to know where your money is going.  Maybe Bugzilla needs a feature for "voting" with promises of cash for the people who fix the bug being voted for?  :-)  As I understand it, votes are largely ignored by the developers as it is.

(In reply to comment #48)
> I'd donate some.  I'd donate more money to bounties on specific bugs than I
> would give to the Foundation.  Always best to know where your money is going. 
> Maybe Bugzilla needs a feature for "voting" with promises of cash for the
> people who fix the bug being voted for?  :-)  As I understand it, votes are
> largely ignored by the developers as it is.

Great idea! I'd donate more, too. (This bug in particular would get plenty.) Let us put our money on where we want it to go. It's a great motivator. :)

And $20K? That's seems like too much.

FWIW: Support for image redirects is in the code now (although disabled for now).

So one thought crossed my mind today:
It should be relatively easy to support image renames by extending the WebStore extension:
* Images pages get moved like any other pages (adding a redirect and so on)
* The thumbnail cache is purged and the image file is moved to the new location in the filesystem
* When someone asks for the old image file, apache generates a 404 file not found.
** The WebStore extension intercepts this,
** checks if the image is actually a redirect
** if yes, it sends a 302 permanent redirect to the new image file name instead
** if not, it sends the original 404.

Would that work?

You can't intercept 404s without edits to the web server's configuration.  Currently we only require configuration edits for pretty URLs (where it's impossible to do it without them).  We shouldn't have to add that requirement for image moves; it should Just Work(TM).

It's true that you need to configure your webserver in order to intercept 404s.

However, I don't see that as a real problem: 
The redirect code already creates links to the new file for Media: links.
So if you move an image file and can't/don't change the webserver, what breaks?
As far as I can see, only two things:
* external direct links to the image file will be broken
* old (cached) versions of pages referencing the image will break.

I don't think there's anything you can do about that, short of serving every media file through some php script and always linking to that script, which is ugly and will probably kill performance.

So, I think the best way forward will be to tell people:
Install an appropriate 404 handler and be happy
OR Accept that external links to your image files will break when you move an image.
(+ there will be some short breakage whenever a page is requested and the image is moved before the browser has loaded the image. Then the user will have to reload the page. Such is life)

Another possibility: Use symlinks. These would avoid the need for a 404 handler.
But symlinks are nonportable, so they aren't a full solution, either.

Symlinks or a 404 handler would at least fix the problem for Wikipedia, which would already be a huge step forwards.

Or have I missed anything?

I should add that configuring a 404 handler is as simple as adding the line
  ErrorDocument 404 /extensions/WebStore/404-handler.php
to the appropriate config file. It can even be done using a .htaccess file, which
MediaWiki could ship.
So, assuming that the user uses Apache as his webserver and has the rights to install
a 404 handler, the operation really is relatively trivial. 

We almost certainly don't want to ship anything that might override user webserver configuration, unless *maybe* it were completely transparent (which I don't think this would be).  We could just symlink() where available, and where not available we could make copies of the files.  Keeping copies doesn't scale well to 500 redirects to the same file, but you can use an OS that provides symlinks, or provide your own symlink-equivalent function in LocalSettings.php (via a hook, say).

(NTFS does support symlinks, incidentally, and always has.  NT is certified POSIX-compatible.  PHP doesn't allow it for Windows anyway, for whatever reason.  Maybe you need some special trickery to access the Unix subsystem when compiling.  But it should allow it for Vista and Server 2008, sooner or later -- as of NT 6.0, CreateSymbolicLink() is part of the Win32 API.  http://msdn2.microsoft.com/en-us/library/aa363866(VS.85).aspx )

I don't think we should support copying of files - this will just lead to problems. E.g., to take your example, if you have 500 redirects to a 10MB file, and someone uploads a new version of the file, MediaWiki will have to copy 5GB of data around.

For systems which don't support symlinks, we could provide an option so sysadmins can either disable image moves, or enable them without symlinks, with a big warning sign that external links to those files will stop working (unless they configure an appropriate 404 handler or similar).

As for Windows: I know that it has symlink support, although I've heard some horror stories about it (I think Explorer still doesn't handle them properly or at least doesn't allow creation or manipulation of them. But that may have changed with Vista.). Someone actually using Windows (i.e. not me :) should investigate this, to see how confusing symlinks are to the average admin and if Windows includes tools to work with them.

Well, first of all, I just read somewhere that symlinks are currently creatable only by admins in Windows, until apps actually support them.  Which is a good idea, if you don't have to own a file to link to it, since (e.g.) having an admin run a program to delete your home directory which contains a symlink to C:\ is a bad idea if the program blindly follows symlinks.

Second of all, I realized symlinks are unacceptable anyway.  Apache can be configured not to follow symlinks at all when serving pages, and I'm sure it often is so configured (maybe that's even the default in some cases, I forget).  So they're out.  So are hard links, because there's no guarantee that the files are all on the same partition.

Third of all, when the image backend gets done, images are supposed to be stored by a hash of the image content, not the image name, so this entire issue is moot then, as comment 19 says.

Until then, the only way I can think of that should work out of the box for *anyone* is to copy the files.  The question is whether a) that's acceptable enough to enable by default; or b) it should just be considered hopeless to make this work out of the box until the image backend rewrite, and we should make this an option that requires configuration for the time being.  I guess you're right, the latter is more reasonable, unless someone can think of some other way to do this seamlessly.  Given that, a 404 handler is probably the most reliable and universally workable way to do it.

I don't think we should care about users who makes direct links to files. They should use Special:Filepath instead.

(In reply to comment #57)
> I don't think we should care about users who makes direct links to files. They
> should use Special:Filepath instead.
> 

I completely agree, especially since Special:Filepath would make a good core feature someday. Hopefully sooner rather than later, of course.

Also, note that Special:Filepath already supports current image redirects implementation.

I agree to, [[Special:Filepath]] would be perfect for replacing direct file links. And would make a great addition to core in that aspect for image moving.

However, before adding it in, perhaps we should add a little extra to it.

We should also think about thumbnails, when an image moves of course the name of the thumbnails will change to. Not only that, but the same ones won't exist and an issue could arise if someone was using a old thumbnail link to embed the image into the page.

It would perhaps be a good idea to add thumbnail syntax to Special:Filepath. This would allow for linking to thumbnails using the indirect method, in addition to the actual images. As a bonus, perhaps the special page could also call the code to generate a thumb when you try to view it. In this way thumbs will be created when an image is moved and thumbnails become nonexistant, and it will also add the benefit that wiki which upload logos or icons or other images will not need to upload scaled down versions to be able to embed them into certain locations.

As we all know, the image backend is being rewritten. So, whether we force everyone to start using a Special:Filepath page, we do hard moving of image files breaking embeded links and make people change them, or we just wait and let every file link break when the entire image structure is altered the one thing that doesn't change is that at some point in time, we're going to be breaking many direct image links.

So, IMHO rather than just letting it eventually break, make it break once in a way that it will not break again. In other words, add Special:Filepath, and get people to slowly start adopting it. The great advantage of the special page is that whether an image page move ability is added in the future, someone wants to link to a smaller version of an image and be guaranteed the thumb has been generated if the image does exist, or the entire specs of the image file structure changes the links that point to the special page will not break as they will automatically adapt to all those changes.

The universal WWW convention is to copy the image's URL.  URLs should not (ideally) ever become invalid as long as the resource still exists.  I don't think it's acceptable to say that everyone should just use some totally different method from how their browser is actually given a link to the image, which we have no effective way of informing them of.  In practice it might be necessary to do that in some cases, but it's not the right way to do it, and should be avoided if reasonably possible.

Image backend *is* rewritten (filerepo-work branch was merged on 30 May 2007), thumbnailing version of special:filepath already exists: it's thumb.php

Nope, different rewrite.  See comment 41.  The backend rewrite will change the way the files are actually stored, including storing them by content hash.  filerepo was a *different* file code rewrite.  :)

I noticed in the 1.12 changelog the following line:
* Support redirects in image namespace
Doesn't that bring us significantly closer to getting this bug fixed?

Yes, correct, if that's fixed up and enabled.  There's still more to do, of course.

(In reply to comment #64)
> I noticed in the 1.12 changelog the following line:
> * Support redirects in image namespace
> Doesn't that bring us significantly closer to getting this bug fixed?
> 

Yes, as soon as Brion will check and enable this feature

(In reply to comment #66)
> Yes, as soon as Brion will check and enable this feature

Has he given a timetable for when he'll look at it?  If not, and you're sure you've addressed all his objections, I'd just re-enable it yourself, if I were you.

I assign this bug to myself. I've done some work on it, hope I'll be able to do more (and of course fix all issues with image redirects).

Fixed in r34169. This is currently experimental, and need more testing. I'll ask Brion to enable it on testwiki. After testing this will be VERIFIED and enabled by default.

*** Bug 15734 has been marked as a duplicate of this bug. ***

Already 5 months since Victor Vasiliev's r34169 proposal. What about the test and enable it by default ? 

Some more testing is required. We did some extensive testing back in July, but I dunno what changed since then. Victor, is there any progress on this?

User:Bryan from commons noticed me that you may need testers for this image rename function, and you need to grant them sysop rights. I think wikigraphists from the graphic labs may be interested to test this function as soon as possible, to allow it to work on commons earlier ;)
Let me know if you need such testers.

(In reply to comment #73)
> User:Bryan from commons
He and Bryan Tongh Minh (comment #72) are the same guy.

Reopening, as this is not yet resolved.  We now have image redirects, but no easy move function.

It is in the software, but still needs to be enabled. See bug 15842.

*** Bug 17149 has been marked as a duplicate of this bug. ***