Unable to Batch add photos after upgrade to 1.4.3...

[gmc]

Tried searching the boards for an answer... Didn't see one similar...

Upgraded my test webserver from 1.3 to 1.4.3... Updated custom theme per instructions... tested viewing albums - and all looked fine...
Upgraded my production server following same process... again viewing albums worked fine...

Then I tried to batch add new photos...
First it would not allow me to batch add from the albums/pictures directory - where all my photos where placed in the past (subdirectories there).  I now see a note not to ftp to that directory - so created a new folder under albums... and uploaded there...

Returned to batch add files...
selected location, album, photos.. but was unable to add.

Turned on debug for admin - received attached detail.
Confirmed all folders under album directory are 775 (which appears acceptable as 755 and 777 are both acceptable...)

Ran versioncheck - found no relevant differences:
albums/edit/index.html missing (have index.php... can't have index.html on my sever or php won't be used)
albums/edit/no_FTP-uploads_into_this_folder!  missing (not in distribution - but appears to just be an informational message)
albums/pictures/no_FTP-uploads_into_this_folder!  (same as above)

Did a new install to new database/folder - and all works fine - so appears to be upgrade related...

Looking for suggestions... I need to correct this upgrade - and have one more site to upgrade as well - don't want to make the same mistake twice...
Thanks for any assistance you can provide...
Greg

[Joachim Müller]

Confirmed all folders under album directory are 775 (which appears acceptable as 755 and 777 are both acceptable...)

My guess is that you only checked what the permissions are set to using your FTP app (using the "properties" dialog) - this is not an option, as the FTP client is on most servers not capable to determine what the actual permissions are, so a default setting is being displayed. Instead, apply the chmod settings as suggested, even when they already appear to be set up correctly. Wether it's 777 or 755 you have to CHMOD to can't be anwered by the docs, however it's not true that both are acceptable: probably only one setting will work for you, the other won't (depending on your webserver's setup, not on coppermine). The only option for you is to apply one CHMOD setting, then test if things work as expected. If the test fails, try the other setting. For details, you might want to ask your webhost, as (in rare cases) there may be ownership issues (your webhost has to CHOWN the folder for you then).

Joachim

P.S. You were never meant to FTP-upload into the userpics folder, in no coppermine version ever. We're just enforcing this policy by hiding the userpics folder when batch-adding

[gmc]

Thanks for the reply...

I actually verified the CHMOD settings via my webhosting providers Control Panel.  It displayed as drwxrwxr-x  which is 775... My provider will not allow me to set 777 - nor would I want that from a security standpoint.
The new install of 4.3.1 (separate database, separate folder) works fine with 775...

I did explicitly set 775 on the albums folder and all subfolders.  Still wouldn't add... 
As 755 drwxr-xr-x is LESS authority - can't see any reason why that would help.

Did notice in comparing the two installs - the upgrade is not successfully displaying the thumbnails in the picture selection dialog:
http://gallery.gmcdesign.com/searchnew.php?startdir=photos/2005blueangels

Also producing these additional messages not in my previous attachment in the debug:

/include/functions.inc.php
Notice line 2661: Undefined variable: i
Notice line 1918: Undefined index: url_prefix
Notice line 1918: Undefined index:

/searchnew.php
Notice line 100: Undefined variable: sel_album  (repeated)
Notice line 168: Undefined variable: fullimagesize  (repeated pair - this line and next)
Notice line 169: Undefined variable: fullimagesize

/include/media.functions.inc.php
Notice line 53: Undefined index: php
Notice line 56: Undefined index: php


When attempting to add pics, it also does not display the graphic indicating success/failure and produces following in debug:

/searchnew.php
Notice line 465: Undefined variable: edit_pics_content


I did change theme to Classic with same results - to make sure my custom theme wasn't causing the problem.

Greg

[Joachim Müller]

do as suggested in the upload troubleshooting of the docs then, so supporters can take a look. Disable notices display, it doesn't hold relevant information for you, it's a dev-only feature.

[gmc]

Followed doc for troubleshooting upload.
http single file upload works fine for me...

Set up account 'cpgsupport' password 'support' as a registered user and a Test Album for which you can upload to... but since that part is working - don't think it will help much...

Batch add is still failing.
Greg

[gmc]

I have set up a test copy of my gallery... and recreated the problem there..
On trying to load - receive message for each picture 'click for details or to reload'
Clicking for details results in a '500 Server Error' message.

My hosting provider has looked at the 500 server error... and they identified the problem!

Their response is:
" The problem was caused by your PHP scripts requiring too much memory in order to execute. Our system administrators did a bit of testing, and after increasing the memory limit per PHP process to 60MB, the issue has been resolved. Please let us know if you need any further assistance."

Everything appears to be working at the moment...  I did downsize the pictures quite a bit before uploading... as they come from a 6.1 Megapixel camera.  Maybe not enough?  or the upgrade requires just enough additional memory to push over the limit (they didn't say what the limit was...)

Thanks for the help...
Greg

[Joachim Müller]

what's the point of adding 6 MPixel shots to your gallery without resizing them first on your client?
Anyways, is your issue solved then?

[gmc]

I'm sorry... if you re-read my post you will notice I said that I *DID* resize my photos before uploading them...

It does appear everything is working now...
Greg