Page MenuHomePhabricator

the --comment-ext=".XXX" option of importImages.php fails to import the metadata text
Closed, InvalidPublic

Description

A command of the type:

sudo -u www-data php ./maintenance/importImages.php --conf ./LocalSettings.php --comment-ext=".meta" --user="XXX" /var/www/v-species/o/tmp

imports only the images, ignoring a metadata text (for the corresponding wiki page) having (in this case) the extension ".meta". This happens regardless of whether the combination is:

x.jpg
x.meta

or

x.jpg
x.jpg.meta

Docu page is http://www.mediawiki.org/wiki/Manual:ImportImages.php

No solution found.


Version: 1.18.x
Severity: normal

Details

Reference
bz33984

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:08 AM
bzimport set Reference to bz33984.
bzimport added a subscriber: Unknown Object (MLST).

Can't replicate using 1.18wmf1, just used importImages.php earlier today with --comment-ext=txt.

Is it --comment-ext=".meta" or --comment-ext="meta"?
I tried both originally and just a minute ago retested both options with mediawiki 1.18.1. The result is:
No error message, just

Importing test23.png...done.
Found: 1
Added: 1

and the file metadata page and the upload comment contain:
(Importing image file)

Mediawiki version: http://species-id.net/openmedia/Special:Version

I used --comment-ext=txt. No quotes, no leading period on the extension.

Example of a text-metadata file which fails to import (without error message) on importImages.php

Attached:

Tried: using the commandline without quotes and leading period, using a three-letter extension (mta) instead of 4 letter (meta), using the 3 letter with x.png.meta for the image file x.png - no success, in all cases the meta file is ignored without error message. Attaching a metadata file example, with the request to Chad: can you test whether it is actually the kind of files that causes problems, rather than the way to specify the comment-ext?

Closing the bug - the bug was due to a local misconfiguration (not helpful to report, it is truly local: we have a unique process to cache media from commons, because the API-access to wmf commons it often severaly overload; we are willing to share that code, but only then will any insight into the bug be useful to others.).

My sincere apologies to those who investigated the bug. In the end it did help us to realize that the problem must be local, so thanks!