I get several error notices when saving album images (tab &tab=imageinfo).
A series lines with:
Notice: Bad image name suffix in newImage() in /home/imhotep/www/zp-core/class-image.php on line 47
And a last line:
Warning: Cannot modify header information - headers already sent by (output started at /home/imhotep/www/zp-core/class-image.php:47) in /home/imhotep/www/zp-core/admin-edit.php on line 362
My image file names are like: birthday-party-2009-17.jpg, so nothing fancy.
Images are uploaded via the Lightroom 3 plugin: ZenPhoto Publisher.
http://www.elementalshoots.com/blog/scripts/lightroom-2-zenphoto-publishing-service/
Here are three occurrences of the error. Sorry, but the error message is in french (as my website)
Backtrace: Mauvais suffixe de nom de fichier dans newImage()
newImage called
from admin-edit.php [196]
Backtrace: Mauvais suffixe de nom de fichier dans newImage()
newImage called
from admin-edit.php [196]
Backtrace: Mauvais suffixe de nom de fichier dans newImage()
newImage called
from admin-edit.php [196]
The plugin enables loading photos and managing albums directly from Lightroom 3, a photo editing app.
Given your diagnostic, sbillard, I suppose that this messes up file names in some way.
My file names are all clean (renamed via lightroom) with no spaces and no diacritical marks.
I will check if it does the same thing while uploading files in a more classic way.
I have the same problem. Just downloaded the version from nightly build, so should have the newest version.
my logs says the same:
Backtrace: Bad filename suffix in newImage()
newImage called
from admin-edit.php [197]
Refreshing the database did not help. What ever changes i make, are saved so its not a critical problem, just not very user friendly and very very annoying.
I hope there's a solution.
The problem seems to be in server settings not in zp-core.
In my case only first 200 POST variables were passed to the admin-edit.php script, and amongst them image counter (e.g. 10) and only first four images' data.
Adding following lines to .htaccess file overriden server settings and solved the problem (php_max_size is set to 64M):
php_value suhosin.post.max_vars 2000 php_value suhosin.request.max_vars 2000
Would it be possible to redesign the core in such way that the submitted forms are not so enormous?
@Harmann: the original topic was about a third party tool named ZenphotoPublisher. Is your issue related to that or what exactly? Please provide a little more info about what you did and what the exact issue was. I am not sure about what 200 post variables you are talking exactly.
kilroy and others mentioned receiving
`
Notice: Bad image name suffix in newImage() in /home/imhotep/www/zp-core/class-image.php on line 47
...
Warning: Cannot modify header information - headers already sent by (output started at /home/imhotep/www/zp-core/class-image.php:47) in /home/imhotep/www/zp-core/admin-edit.php on line 362
`
I got the same trying to apply changes I had made to images in any album of size larger than 4.
It turned out, that the reason was the size of $_POST[] array passed to the admin-edit.php script.
Default settings of my server limit it to 200 elements. However, submitted 'albumedit2' form sends much more data to the server. Script receives correct info about the number of images it should process, but only part of the image details (in my case, it was truncated somewhere in the middle of the 5th image data). In $_POST[] array there is no data for '5-filename', '6-filename', ..., 'n-filename' keys, and one gets 'Bad image name' error. Overriding server limits solves the problem.
So your report is actually about image editing itself then?
Could you post some more server info? What Zenphoto release?
I can really assure that Zenphoto works fine on normal shared hosts without any of these changes (mine has suoshin installed as well). Of course server configurations can differ much and we can't cover all.
The server uses PHP 5.2.14 and is protected with the Suhosin Extension 0.9.31.
suhosin.post.max_vars variable is by default set to 200 and that caused the problem. Most probably without this restriction Zenphoto would work correctly. I am sure it does.
I would suspect that in case of ZenPhoto Publisher problems, which are described above, the cause is the same.
Sure, probably a valuable info for some.
Just to mention I have PHP 5.2.14 and suoshin 0.9.32.1 on my server and I can't even find that post_max setting in phpinfo at all. So I assume it will probably be the default value. (I have no access to the php.ini as this is a shared host, changes can done via htaccess).
Strange is I never encountered this issue with any version of Zenphoto on that or other shared hosts. So it might also be in combination with something else.