Hi,
I'm trying to fix an old MediaWiki installation, where a few hundred images are located at ./images; they are registered at Special:Files, but the images itself are missing. The paths do not point to ./images/{image.ext}, but to something like ./images/1/15/{image.ext}. I moved a few images manually to the reported locations, which seems to work fine, but I'd like to avoid wasting several hours to create missing subdirectories etc.
I assume, when the Wiki was started, $wgHashedUploadDirectory was set initially to "false" and later changed to "true"; as I understand, there is no maintenance script to fix this. So I tried to utilize ./maintenance/importImages.php which should do the trick, I thought.
However, the script is smarter than me and checks for the existence of the files; of course, this check results in "...could not be imported; a file with this name exists in the wiki". As far as I can see, there is no switch to override this check. In the script's code, I found a routine starting with "# Check existence", which I tried to comment out; this resulted in breaking the script since I don't speak PHP.
If this is the right approach, could someone tell me, which lines I have to comment out in importImages.php or maybe even provide a quick Patch? If, however, this is complicated, don't bother, then I'll waste a few hours for manual fixing this.
Thanks & regards, -asb
Either move them all from /images/1/15/image.ext to /images/image.ext and set to false $wgHashedUploadDirectory (easy) or move them the other way, for which you will probably need a script. The subfolder pattern is /images/a/ab/ where ab are the first 2 characters of the filename's md5.
Platonides wrote:
Either move them all from /images/1/15/image.ext to /images/image.ext and set to false $wgHashedUploadDirectory (easy) or move them the other way, for which you will probably need a script. The subfolder pattern is /images/a/ab/ where ab are the first 2 characters of the filename's md5.
Thanks, but I've already read the manual page about Image Administration [1], which explains this pretty well. On the mentioned page Special:Files, I can look up the locations, where MediaWiki looks for the images, so I wouldn't have to calculate hash values for every file. However, manually moving a few hundred images this way would take several hours, and it'd be a very stupid pastime.
Thus, my idea was to utilize the importImages.php script, which should do all this by itself; I could point it to ./images and let it create the subdirectories, and sort the images to the proper hash directories. The only problem is, that wouldn't let me do this, since it thinks, that the file are already present, but at the location they would be, if $wgHashedUploadDirectory would be set to false. The script simply lacks a switch to avoid checking for existing images, or someone who understands the basics of PHP programming.
So the question was simply, how to bypass the do-the-files-exist-checking in importImages.php; this should be very simple since the script is quite well documented, but it takes some understanding of PHP, what most stupidly I don't have.
Sorry if my question was unclear.
Greetings, -asb
On 28/07/07, Agon S. Buchholz asb@kefk.net wrote:
So the question was simply, how to bypass the do-the-files-exist-checking in importImages.php; this should be very simple since the script is quite well documented, but it takes some understanding of PHP, what most stupidly I don't have.
This is now an option in the import script in trunk, and will be available in the next release. Since this isn't coming out for a while, I'm quite willing to backport the changes and provide a patch via email, but I'll need to know the release branch in use, i.e. 1.6, 1.7 - 1.10, etc.
Rob Church
On 7/28/07, Agon S. Buchholz asb@kefk.net wrote:
So the question was simply, how to bypass the do-the-files-exist-checking in importImages.php; this should be very simple since the script is quite well documented, but it takes some understanding of PHP, what most stupidly I don't have.
If you remove these lines from importImages.php
if( !$image->exists() ) {
(....code, code code...)
} else { echo( "{$base} could not be imported; a file with this name exists in the wiki\n" ); }
the check won't happen. I'm not quite sure if this has drawbacks though. For example, a normal upload of an image stores a new version of the image without overwriting the previous version, on MW nor on the filesystem. As this particular script check for the file's existence on MW, I'm wondering if proceeding without a check will cause problems.
Hope it helps.
Ciao!
Manu
Emanuele D'Arrigo wrote:
If you remove these lines from importImages.php
if( !$image->exists() ) {
(....code, code code...)
} else { echo( "{$base} could not be imported; a file with this name exists in the wiki\n" ); }
Argh, I commented out *one* line too much (the one below the comment "# Check existence"). And yes, It's working perfectly - after a few seconds, all images were imported and I could delete them from ./images. All file descriptions remained untouched, only the the file dates have changed.
I'm not quite sure if this has drawbacks though.
At least I can't see any so far. I assume, the check is mostly there to prevent idiots like me to overwrite stuff unintentionally. This makes absolute sense, considered the power of large bulk operations this script might undertake. However, there's a warnung note on [2], but the mentioned problems didn't appear on my site.
@Rob: Thanks for your offer to provide a patch, but Emanueles instructions already did the trick for me.
However, if your addition gets into the next release of MW, wouldn't it be helpful to update [1] and [2]? I'd offer to invest the time you saved me to freshen up the manual a bit ;)
[2] reads: "Note: This parameter can not be changed after the first image or file has been uploaded (or you need to move all previous uploaded pictures). It will result in php-errors (see the discussion page) if articles with the old logic try to find their pictures, since the image path is calculated an not stored in the database."
As mentioned above, this didn't happen at my site. Maybe this error is specific to XAMPP installations (I'm using Debian GNU/Linux).
If there are no objections, I'd update [1] and [2] with this workaround for switching $wgHashedUploadDirectory from "false" to "true".
Thank you very much, and thanks for providing the great utility toolkit in ./maintenance (stuff like this I'm missing most painfully in Drupal ;)
Greetings, -asb
[1] http://www.mediawiki.org/wiki/Manual:Image_Administration [2] http://www.mediawiki.org/wiki/Manual:%24wgHashedUploadDirectory
PS: Ceterum censeo MediaWikinem esse amandam ;-)
mediawiki-l@lists.wikimedia.org