Last modified: 2014-11-17 09:21:00 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 709 - Cannot rename/move images and other media files.
Cannot rename/move images and other media files.
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
unspecified
All All
: Normal enhancement with 73 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 4654 4877 6149 7808 8684 10734 15734 17149 (view as bug list)
Depends on: 786
Blocks: 14130
  Show dependency treegraph
 
Reported: 2004-10-14 08:25 UTC by Serge van den Boom
Modified: 2014-11-17 09:21 UTC (History)
35 users (show)

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


Attachments

Description Serge van den Boom 2004-10-14 08:25:00 UTC
There is no option to rename/move an image or other media file.

While this seems to be a known problem, it didn't appear to have a bug report. It does now.
Comment 1 Mark Clements (HappyDog) 2005-03-21 00:32:42 UTC
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.
Comment 2 David Benbennick 2005-06-28 19:02:22 UTC
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 ...
Comment 3 Jamie Hari 2005-11-12 02:48:06 UTC
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.
Comment 4 Rob Church 2005-11-14 10:34:56 UTC
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.
Comment 5 Ævar Arnfjörð Bjarmason 2006-01-18 18:00:49 UTC
*** Bug 4654 has been marked as a duplicate of this bug. ***
Comment 6 Brion Vibber 2006-02-05 18:47:25 UTC
*** Bug 4877 has been marked as a duplicate of this bug. ***
Comment 7 brianna.laugher 2006-02-17 15:33:14 UTC
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!
Comment 8 BugMeNotLovesWiki 2006-02-17 15:57:50 UTC
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 !
Comment 9 Daniel Arnold 2006-02-17 16:24:09 UTC
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. 
Comment 10 sanbec 2006-02-19 16:52:42 UTC
(In reply to comment #9)
I completely agree this comment
Comment 11 Edward Z. Yang 2006-05-07 00:27:17 UTC
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.
Comment 12 brianna.laugher 2006-05-07 05:20:41 UTC
(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.
Comment 13 Steve Bennett 2006-05-07 21:00:12 UTC
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.
Comment 14 Borgx 2006-05-11 03:18:21 UTC
Yes. yes. this is a important feature. A lot of users upload images from
en.wikipedia with different name.
Comment 15 Rob Church 2006-05-11 09:22:56 UTC
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.
Comment 16 Filip Maljkovic [Dungodung] 2006-05-31 13:24:43 UTC
*** Bug 6149 has been marked as a duplicate of this bug. ***
Comment 17 prodigion 2006-10-15 01:14:16 UTC
This bug is two years old, will it ever be fixed?
Comment 18 Greg Hurrell 2006-10-15 11:30:00 UTC
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
Comment 19 Brion Vibber 2006-10-15 18:07:40 UTC
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.
Comment 20 Jamie Hari 2006-10-20 01:56:47 UTC
What is the roadmap version that the image storage restructuring is planned for?
(1.9.0, 2.0.0, etc?)
Comment 21 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-10-20 01:59:51 UTC
It appears to have been planned for 1.7. 
<http://www.mediawiki.org/w/index.php?title=MediaWiki_roadmap&diff=26560&oldid=26490>
Comment 22 Edward Z. Yang 2006-10-20 02:01:50 UTC
Which, of course, has come and gone. Someone ask Brion on IRC sometime.
Comment 23 Nux 2006-10-27 14:21:58 UTC
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.
Comment 24 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-10-27 19:54:22 UTC
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.
Comment 25 Daniel Arnold 2006-11-03 17:06:14 UTC
@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.
Comment 26 Jamie Hari 2006-11-03 18:05:28 UTC
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.
Comment 27 Greg Hurrell 2006-11-04 11:29:05 UTC
(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.
Comment 28 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-11-04 23:00:33 UTC
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.
Comment 29 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-11-04 23:13:58 UTC
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.
Comment 30 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-11-05 00:27:38 UTC
*** Bug 7808 has been marked as a duplicate of this bug. ***
Comment 31 prodigion 2006-11-08 07:24:30 UTC
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?
Comment 32 Duncan Harris 2007-01-06 13:22:54 UTC
So this depends on there being image redirects -- has anyone filed that as a bug?
Comment 33 Rob Church 2007-01-06 17:40:44 UTC
(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.
Comment 34 Rob Church 2007-01-18 10:14:10 UTC
*** Bug 8684 has been marked as a duplicate of this bug. ***
Comment 35 Jamie Hari 2007-05-26 16:43:26 UTC
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?
Comment 36 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-27 06:03:37 UTC
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.
Comment 37 Casey Brown 2007-07-29 01:33:38 UTC
*** Bug 10734 has been marked as a duplicate of this bug. ***
Comment 38 oscar 2007-07-29 01:44:46 UTC
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
Comment 39 Voyagerfan5761 / dgw 2007-10-05 07:58:36 UTC
Renaming files = necessity for any program that works with files, especially in its own little structure.
Comment 40 Omegatron 2007-10-05 13:30:36 UTC
(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. 

Comment 41 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-10-07 01:43:43 UTC
(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.
Comment 42 Eric 2007-10-23 11:45:06 UTC
A Commons user alerted me to this template for renaming media: http://commons.wikimedia.org/wiki/Template:Rename
--Eric
Comment 43 Benn Newman 2007-10-23 12:14:21 UTC
(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.

Comment 44 Siebrand Mazeland 2007-10-23 13:15:17 UTC
(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
Comment 45 Voyagerfan5761 / dgw 2007-10-23 13:19:36 UTC
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.
Comment 46 Siebrand Mazeland 2007-10-23 13:27:36 UTC
(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.

Comment 47 Voyagerfan5761 / dgw 2007-10-23 13:34:22 UTC
(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?
Comment 48 Omegatron 2007-10-23 14:01:39 UTC
(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.
Comment 49 Rocket000 2007-11-15 16:12:17 UTC
(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.
Comment 50 Thomas Bleher 2008-01-25 10:22:18 UTC
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?
Comment 51 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-01-25 18:00:56 UTC
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).
Comment 52 Thomas Bleher 2008-01-25 18:19:35 UTC
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?
Comment 53 Thomas Bleher 2008-01-25 18:26:32 UTC
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. 
Comment 54 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-01-25 18:43:36 UTC
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 )
Comment 55 Thomas Bleher 2008-01-26 12:08:51 UTC
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.
Comment 56 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-01-27 00:47:15 UTC
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.
Comment 57 Victor Vasiliev 2008-01-27 06:40:29 UTC
I don't think we should care about users who makes direct links to files. They should use Special:Filepath instead.
Comment 58 Voyagerfan5761 / dgw 2008-01-27 06:45:49 UTC
(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.
Comment 59 Victor Vasiliev 2008-01-27 06:53:23 UTC
Also, note that Special:Filepath already supports current image redirects implementation.
Comment 60 Daniel Friesen 2008-01-27 07:22:08 UTC
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.
Comment 61 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-01-27 15:51:03 UTC
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.
Comment 62 Victor Vasiliev 2008-01-27 17:20:52 UTC
Image backend *is* rewritten (filerepo-work branch was merged on 30 May 2007), thumbnailing version of special:filepath already exists: it's thumb.php
Comment 63 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-01-27 17:39:19 UTC
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.  :)
Comment 64 prodigion 2008-03-21 17:31:25 UTC
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?
Comment 65 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-03-21 18:30:16 UTC
Yes, correct, if that's fixed up and enabled.  There's still more to do, of course.
Comment 66 Victor Vasiliev 2008-03-21 20:09:06 UTC
(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
Comment 67 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-03-21 20:10:51 UTC
(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.
Comment 68 Victor Vasiliev 2008-04-06 18:01:11 UTC
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).
Comment 69 Victor Vasiliev 2008-05-03 13:14:18 UTC
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.
Comment 70 Bryan Tong Minh 2008-09-26 18:02:51 UTC
*** Bug 15734 has been marked as a duplicate of this bug. ***
Comment 71 Yug 2008-09-26 18:22:30 UTC
Already 5 months since Victor Vasiliev's r34169 proposal. What about the test and enable it by default ? 
Comment 72 Bryan Tong Minh 2008-09-26 19:28:38 UTC
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?
Comment 73 Yug 2008-09-26 20:50:59 UTC
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.
Comment 74 Roan Kattouw 2008-09-26 20:53:21 UTC
(In reply to comment #73)
> User:Bryan from commons
He and Bryan Tongh Minh (comment #72) are the same guy.
Comment 75 George Watson 2008-10-28 14:30:46 UTC
Reopening, as this is not yet resolved.  We now have image redirects, but no easy move function.
Comment 76 Bryan Tong Minh 2008-10-28 14:47:34 UTC
It is in the software, but still needs to be enabled. See bug 15842.
Comment 77 Raimond Spekking 2009-01-24 19:02:48 UTC
*** Bug 17149 has been marked as a duplicate of this bug. ***

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


Navigation
Links