I copied some pictures in the galleries folders, executed the "quick local synchoronization" and noticed that afterwards I can't access some of the pictures in piwigo.
There seems to be two problems with that.
- If the filename contains a space or an Umlaut or similar (I tried it with the "ñ" character) the thumbnail doesn't get created.
- If the filename contains a space there's the additional problem, that the space gets converted to a "%20" in the url which is correct so far. But it seems like i.php is verifying the request url directly against "$conf['sync_chars_regex']", so right now it is necessary to also add the "%" character to the sync_chars_regex variable so avoid the "Invalid chars in request" message.
Offline
This is a known issue -
See the paragraph 'Cons' under the heading ...by FTP (about a third of the way down this page
http://piwigo.org/doc/doku.php?id=pwg24 … ture&s[]=galleries
Offline
hello
in fact it's not really an issue because it was initially done to prevent incompatibility url ; utf8 was not a standard
but when you say
If the filename contains a space
did you allow that character in $conf['sync_chars_regex'] ?
Offline
yes of course i activated the characters sync_chqrs_regex. the \s stands for any kind of spaces...
right now it looks like that:
$conf['sync_chars_regex'] = '/^[a-zA-Z0-9-_.\sÀÁÂÃÄÅàáâãäåÒÓÔÕÖØòóôõöøÈÉÊËèéêëÇçÌÍÎÏìíîïÙÚÛÜùúûüÿÑñ!\(\)\&\°]+$/';
when I also add the % character I can avoid the "Invalid chars in request" message as i wrote above.
Offline
as i wrote part of the problem is that i.php verifies the request url directly against "$conf['sync_chars_regex']" which is a problem because spaces and umlauts are escaped in the request.
Just for testing purpose i changed line 202 to
foreach (preg_split('#/+#', rawurldecode($req)) as $token)
hence adding the rawurldecode call.
Like that the "Invalid chars in request" message wont appear anymore assuming the characters were correctly added to $conf['sync_chars_regex'] .
still the thumbnails won't be showed, because they never got created.
I guess there is a similar error in the thumbnail creqting function. Propably using the still urlencoded picture path as argument.
I will look into that once I find an usable computer... ;-)
Offline
thx for the feedback,
we will investigate too
Offline
ok, i got as far as I could by only using a text editor over an ssh connection...
The error seems to be all in the file i.php (at least all the ones I found so far).
In the array $page the paths to the pictures are stored as urlencoded strings.That means any function accessing the filesystem can't find the path
e.g.
@filemtime($page['src_path']); // about line 402 @filemtime($page['derivative_path']); //about line 410
This happens at several places in the code (my line number from above are maybe not absolut exact anymore, since I did a lot of editing of the code for debugging purpose...).
Each time the variable should be deencoded using the rawurldecode function:
rawurldecode($page['src_path'])
Or what propably would be a lot better is to directly store the paths in the variable as unencoded string, and only encode them, when it is used to generate html links to the files.
Additionaly there is a problem in about line 455
SELECT * FROM '.$prefixeTable.'image WHERE path=\''.$page['src_location'].'\'
Again the rawurldecode is missing, and additionally there should be set a "./" in front of the path since that's the way it is stored in the database (I don't know how that query in the actual form ever worked anyway):
SELECT * FROM '.$prefixeTable.'images WHERE path=\'./'.rawurldecode($page['src_location']).'\'
I somehow managed that it acidentaly created some thumbnails using the batchmanager to debug (the filenames had %20 and similarstuff in it) but it still doesn't work correctly, but I just don't wanna continue debuging this way...
But I think you get the general picture, and I think for the developpers, especially with a real debugging environment it should be quite easy to fix that...
Just make a decision if in general you want to store path names in the variables as the real path names (good practice in my opinion) and only encode them, if used for html output (this already seems to be the case anyway, since they are stored unencoded in the database, but the gallery pages generated contain them in the encoded form), or if you really want to already store them encoded, and each time you access the filesystem want to decode them.
It can be that for the synchronization function the errors are at an other place in the code, but it was just a lot easier for me to use the batchmanager, since like that I only needed to reload the page instead of renaming files all the time... But I guess it will be similar errors there (even I can not see any reason you should get encoded strings when you're only working on the filesystem level).
Last edited by RMM (2012-07-10 18:46:02)
Offline
I didn't read entierly your post but thx for your contribution
if you need http://piwigo.org/dev/browser
and when you will finish : http://piwigo.org/bugs/
Offline
I created a patch and attached it to the bug report http://piwigo.org/bugs/view.php?id=2686
I post that also here since I never got any reaction to my bug report ;-).
Would be great if it could be incorporated into 2.4.4
like that the new $conf['sync_chars_regex']-feature finally would make some sense (at least for linux users... see bug report)
Offline