Trouble-shooting the upload process.

[Joachim Müller]

This is a summary of various sticky postings taken from the cpg1.3.x support board (most of them originally posted by hyperion) that are valid for cpg1.4.x as well:

When troubleshooting uploads in CPG 1.4, you are advised to change the upload settings in the Groups console to 'Single uploads only' and to activate 'Debug mode' in the Config console.  Changing this setting negates some of the error masking done in the multiple upload setting.  This will allow you to access more detailed error messages. This is being explained in the docs that come with cpg1.4.x: http://coppermine-gallery.net/demo/cpg14x/docs/index.htm#upload_trouble
Make sure that you have read the documentation before asking any support requests.



FIRST AND FOREMOST: CHECK YOUR PERMISSIONS ON THE /ALBUMS, /ALBUMS/USERPICS, AND /ALBUMS/EDIT DIRECTORIES.  ALL SHOULD BE 777 OR 755.

If you don't know what we mean when we write 777 or 755,  you need to do a Google search on UNIX file permissions.  Windows has a similar set of file permissions. You can usually set these permissions using your FTP client.     

For those of you who skim over statements written in large letters, I will repeat to try to get your attention:

YES, WE ARE WRITING ABOUT SOMETHING THAT COULD APPLY TO YOU.   

WE REPEAT -- CHECK YOUR PERMISSIONS ON THE /ALBUMS, /ALBUMS/USERPICS, AND /ALBUMS/EDIT DIRECTORIES.  ALL SHOULD BE 777 OR 755.

YES, WE WANT YOU TO CHECK THE PERMISSIONS OF EACH FOLDER EVEN IF YOU THINK YOU HAVE ALREADY DONE THIS. YES, WE MEAN IT.   

There's a section in the docs that tries to explain permissions: http://coppermine-gallery.net/demo/cpg14x/docs/index.htm#permissions



Please keep in mind that HTTP uploads are limited by the restrictions placed upon them in PHP's configuration.

Things to check:

1. max_input_time- 60 seconds is the default time limit for uploading files.

This time limit includes the time it takes for the files to upload, so if you exceed this limit, the file will not even parse, and the browser will not get a response. You can workaround this by trying to upload smaller or fewer files, or you can try uploading over broadband. The best solution, of course, is to increase the time limit to something more in line with your needs.

2. upload_max_filesize - 2MB is the default limit for individual files.

3. post_max_size - 8MB is the default limit for post requests.

4. memory_limit - 8MB is the default size.

5. PHP's LimitRequestBody - 512KB default limit. (mainly an issue on Redhat/Apache systems.  Found in /etc/http/conf.d)

In general, upload_max_filesize < post_max_size < memory_limit in order for uploads to function properly. Coppermine may warn you if a file exceeds upload_max_filesize, but it cannot warn you if the total size of all the files exceeds the post limit or the memory limit.

6. file_uploads - This determines whether or not PHP will allow file uploads. It must be set to 'On'.

7. upload_tmp_dir - This specifies the temporary directory where PHP stores uploaded files.

The most common issue caused by this setting is an open_basedir warning.  In this situation, your server administrator has restricted the files that PHP can work with to a certain directory.  If he does not create and specify a temporary directory within the open_basedir restriction, PHP will attempt to use the OS temporary directory, and it will be rebuffed by the open_basedir restriction.

8. allow_fopen_url - This controls PHP's ability to read files using URL/URIs.  If it is disabled, Coppermine will not be able to upload from URLs.

Some notes about the different types of upload mechanisms available in CPG 1.3:

Multiple HTTP uploads are designed to handle a small number of files, and have been capped at 10.  Therefore, they are not really suited for large numbers of files unless you have control over your php.ini configuration. 

If you are looking to upload in excess of 15 or 20 files at a time, you should consider the batch add process or the XP_Publisher utility.  Each has its own drawbacks and advantages. 

The batch add process is fast, but it puts quite a load on the server and may experience timeouts.  The XP Publisher utility is slower, but it limits the load on the server.  Also, it avoids many of the pitfalls caused by the php.ini configuration by uploading each file in the set as an individual post request.

[Joachim Müller]

Batch add is limited by two php.ini settings:

1. max_execution_time - Default of 30 seconds.

If this is the issue, you will get a warning about the maximum execution time being exceeded. This error can occur if you have too many directories in /albums, or it may happen if you are trying to upload an abnormally large number of files. You may increase this setting in php.ini, or you may attempt to set the time limit in the script if the server permits.

The time limit may be changed by adding the following declaration near the beginning of the file:
set_time_limit(x);

where x is the number of seconds you desire. A setting of 0 removes the time limit restriction.  Remember that this call is subordinate to the setting in php.ini, so you cannot use it to overcome a restriction there. More information can be found in the PHP manual:

http://www.php.net/manual/en/function.set-time-limit.php

2. memory_limit - This setting has a default of 8MB. 

For more on addressing this issue see the stick topic "Allowed memory size of X bytes exhausted"

Other notes:

Batch add works by creating multiple processing threads for each image in the directory. An HTML page is then generated which creates links to the processing script. As each link is called, an image is processed.  This is a very fast process, but it very resource hungry, and some server administrators have deemed it 'insane'.  If your server administrator requests that you stop batch adding, we recommend that you consider using the XP Publish utility, multiple HTTP uploads (if suitable for your intent), or that you get a new host who can handle your needs.

Finally, you must not FTP files to the /albums/userpics directory.  Coppermine 1.3 does not permit this action, and the /userpics directory will not be available from the batch add script.  The /userpics directory is exclusively reserved for Coppermine's use.

[Joachim Müller]

Relevant php.ini settings:

Code Select Expand


; Safe Mode
;
safe_mode = Off

; By default, Safe Mode does a UID compare check when
; opening files. If you want to relax this to a GID compare,
; then turn on safe_mode_gid.
safe_mode_gid = Off

; When safe_mode is on, UID/GID checks are bypassed when
; including files from this directory and its subdirectories.
; (directory must also be in include_path or full path must
; be used when including)
safe_mode_include_dir =

; When safe_mode is on, only executables located in the safe_mode_exec_dir
; will be allowed to be executed via the exec family of functions.
safe_mode_exec_dir =



Safe mode is enhanced security environment for PHP. Coppermine has no issues with safe mode when it is properly configured for use with Coppermine.  However, safe mode configurations are often improper or designed without considering group/user/server issues for autonomous scripts. 

Two primary issues may arise in Coppermine with safe mode enabled.  The first occurs when uploading. Normally, each user receives his or her own directory for uploads, and the directory is created by Coppermine. In certain safe mode environments, the owner of the /albums directory and the server are not considered to be the same user. Thus the server is not allowed to create new directories within /albums. Coppermine can sidestep this by refraining from creating new directories if the Silly Safe Mode constant is added to /include/config.inc.php. 

Code Select Expand


define('SILLY_SAFE_MODE', 1);


This issue may also occur if safe_mode_gid is enabled, but the /albums owner and the server are not of the same group.

The second issue arises when trying to use Image Magick.  Image Magick must be within php.ini's designated safe_mode_exec_dir in order for Coppermine to be able to use IM while operating in safe mode. Also, the exec() function must not be disabled.

[Joachim Müller]

Error message "There is no album where you are allowed to upload files."

You need to give permission in both the groups panel and the album properties page for an upload to occur. Again: the documentation is the place to go for details.

[Joachim Müller]

Error Message:

Fatal error: Allowed memory size of XXXXXXX bytes exhausted at (null):0 (tried to allocate XXXX bytes) in /var/www/html/include/picmgmt.inc.php

Meaning:  You have exceeded the memory allotment given to you in php.ini

Possible causes:

This error occurs when using GD and attempting to upload a high resoltuion image.  It's not the size of the file that matters here; it's the number of pixels that determine memory use in GD. 

Solutions:

Alternative 1 (ideal):Increase the memory limit allocation in php.ini. You must be the server's administrator to do this. Also, .htaccess files cannot change this configuration setting, and it cannot be changed using ini_set(). First, you locate the following block in php.ini: 

Code Select Expand


;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;

max_execution_time = 30     ; Maximum execution time of each script, in seconds
max_input_time = 60        ; Maximum amount of time each script may spend parsing request data
memory_limit = 8M      ; Maximum amount of memory a script may consume (8MB)


Now you increase the memory limit to fir your needs. 9 to 16 MB should handle most requirements. To calculate the amount of memory an image uses, you simply multiply the pixel width and height, and then you multiply the result by the number of base colors (RGB - 3, CMYK - 4). Finally, you divide by 1048576 to get the memory usage in MB.

Here are some common image resolutions and their memory use in GD (assuming RGB):

800 x 600 - 1.37 MB
1024 x 768 - 2.25 MB
1200 x 1600 - 5.49 MB

Remember when using the above figures that the amount of memory being used by the rest of Coppermine must be taken into account, too.

If you are unable to change php.ini settings yourself, you can always ask your server administrator to change this for you.  However, many administrators will be reluctant to do so, as this setting will affect everyone on a shared server.  A higher memory limit requires reducing the number of people who can be hosted on the same server in order to maintain server stability. This reduces profitability, etc.

If you cannot change php.ini, you should read alternatives 2 and 3.

Alternative 2 (sensible):

Resize your images before uploading if you do not require high resolution images.  This saves upload bandwidth and time for you.

Alternative 3 (workaround):

You may download one of many free programs that resize images. Then resize the images to a smaller resolution (like 800 x 600) by the batch into a different folder while maintaining the same filenames.

Upload the resized images to Coppermine.  Then use your FTP client to overwrite the images with the higher resolution images. 

N.B. Users who are not members of the same group as the server may have difficulty using FTP to overwrite the files.

[Joachim Müller]

Error message: "Exec() has been disabled"

Php.ini allows the server administrator to disable certain functions. If the server administrator has disabled exec() you will not be able to use Image Magick.

You may replace exec() with passthru() if it has not been disabled as well.  Otherwise, you must use GD.

[dloftus]

Just a quick note to let you know the detailed "Trouble Shooting Upload Process" topic did the trick for me.  I never knew that resolution size impacted the upload process differently then the actual file size.  Had issues uploading larger files that were still within the file size max I entered into the admin.  After ready how to calculate resolution, I realized the memory_limit was not suffient.  So I had my php.ini file changed and all is good to go!

It was a painful process so if anyone is having issues uploading large files, take a look at that post and keep in mind memory_limit as well!

Thanks, Dan