Problems with albums and images 26 May 2013 / Updated: 04 May 2020
Thumbnails/sized images are not generated and/or the server crashes
- VGA Image, 640 x 480 pixels => needs ~4.1 MB Memory
- SVGA Image, 800 x 600 pixels => needs ~4.8 MB Memory
- 1 MP Image, 1024 x 798 pixels => needs ~6.3 MB Memory
- 2 MP Image, 1600 x 1200 pixels => needs ~11.7 MB Memory
- 6 MP Image, 2816 x 2112 pixels => needs ~22.6 MB Memory
- 8.2 MP Image, 3571 x 2302 pixels => needs ~41.7 MB Memory
Workaround 1: Re-configuring your server to work with large image files (5MB to 10MB)
Tutorial written by Aladio (https://github.com/zenphoto/zenphoto/issues/169)
The aim of this tutorial is to help the intermediate user configure PHP and setup large image files so they may be uploaded and displayed properly using Zenphoto.
The following 5 settings need to be verified or changed in the php.ini file, found on your web server, in order to run Zenphoto with large image files.
Note: You should confirm with your web-host that these settings are supported and how much server memory is available! If you are on a shared host you probably might not be allowed/able to changes these.
Find memory_limit and set it to 128M
; Maximum amount of memory a script may consume (128MB)
memory_limit = 128M
Find post_max_size and set it to a big number so you can upload multiple large files.
; Maximum size of POST data that PHP will accept.
post_max_size = 1G
Find file_uploads and set it to On.
; Whether to allow HTTP file uploads.
file_uploads = On
Find upload_max_filesize and set it to a big number so you can upload multiple large files.
; Maximum allowed size for uploaded files.
upload_max_filesize = 1G
Find max_file_uploads and set it to upload multiple files at once.
; Maximum number of files that can be uploaded via a single request
max_file_uploads = 20
Fix "413 Request Entity Too Large" errors
- For Apache web servers, the directive which determines what the allowable HTTP request size can be is LimitRequestBody.
More info: https://httpd.apache.org/docs/2.0/mod/core.html#limitrequestbody
- For Nginx web servers, the directive which determines what the allowable HTTP request size can be is client_max_body_size.
More info: https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size
Setting up Large Image Files (5MB to 10MB)
Horizontal or Landscape Images (height < width)
If you are able to make the above changes to your php.ini file, large landscape image files should display fine when running Zenphoto.
Vertical or Portrait Images (height > width)
Large portrait image files must be rotated properly or PHP will run out of memeory while Zenphoto is trying to rotate and resize your image. You will see a box containing the name of the image instead of the image itself if the error occurs. (See below for directions on how to debug images).
Zenphoto reads the EXIF data contained in the image file to determine the image orientation. If the EXIF orientation property is set to anything but 1, Zenphoto will try to rotate your image. If the image is a large one the process will fail.
There could be many reasons for this, so the best way to diagnose this problem is to view the actual image error itself. You can do this by adding '&debug' to the image URL zenphoto uses to process the image.
To do that, locate the failed image in your gallery (it should show just the filename with a box around it, in place of the image), then right-click it and choose 'Copy Image Location' (Firefox; in IE, choose 'properties' and copy the image URL from there).
Then, paste that URL into your address bar, and at the end of it, type "&debug" without quotes. Press enter to see the image processor's error message. If you need help diagnosing it, feel free to post on the support forums.
Workaround 2: Use Imagick instead of the GD libary
Since Zenphoto 1.3 you can also switch to Imagick (ImageMagick) which may require less memory, and at least won't share memory with Apache. If your server supports this you can enable it via a checkbox on Options > Image.
Browser connection issues
Another problem is that browsers often make two requests per server at the same time to speed up image loading. This is perfectly normal, but if two requests for that 8-megapixel image are made and both need processing, then the memory requirement is doubled. The only way around this is to limit the number of requests your browser makes. In Firefox, this can be done by going to about:config as the URL and searching for the network.http.max-persistent-connections-per-server option and setting it to 1.
Corrupt image files
Sometimes the cause can also be a corrupt image file. That can happen sometimes if you upload via FTP or a general program error. Try opening the file with an editor and re-saving it.
If you are using EXIF or IPTC metadata this data can be corrupted. That can happen if your editor or camera embeds it wrong or by encoding issues. Try to open the file with an editor and try to re-save it.
Images have wrong colors
First, most older web browsers ignore color profiles. Newer ones generally can handle them.
Second, there are two aspects of color space. The first is the RGB values of the pixels. Then there is a color profile which may be associated with an image. So you can have pixels which are sRGB or adobeRGB or some other "color space". If the pixels are not sRGB then typically the web programs will not display the color correctly. If they are, then things should be fine.
Zenphoto does resizing of images with image processing libaries that are installed on your server. Zenphoto supports two of them:
- GDlibary: This is the default libary which is most commonly availabe on servers. GD does NOT support or preserve color profiles embeded in images.
- Imagick libary (since 1.3): This is capable to preserve color profiles but the recommendation to use sRGB still persists.
Also take a look here:
The number of thumbnails on a theme's album view do not match theme settings
When a theme specifies a setting for the number of image (or album) thumbnails to display in a "row", the thumbnails per page will be rounded up to the nearest multiple of that specification. Prior to the 1.3.2 release setting these were done via the normalizeColumns() function. Post 1.3.2 the settings are on the theme options tab.
Deleting an albums fails on the backend
This may be caused by some files within the folder of that album that should not be there like for example the hidden/invisible .DS_Store files the finder of Mac OS X creates. They may be transfered with upload folders or archives. You would have to delete these files directly via ftp. Best is to avoid uploading them in the first place.
Thumbnails for videos (or other non standard image files) are not created
Zenphoto is not able to generate thumbnails from videos and shows therefore a default replacement image. There is no way at all to do this automatically with PHP without installing a native extension on your server itself. But you can do it manually:
- Make a screenshot from your movie
- Put the image named as the movie (for example: movie named movie.mp4, image named movie.jpg — lower case suffixes are required!) into the album folder where your movie is located.
Same principle works for all non image content used by plugins like audio files, text objects or file formats added by the anyFile plugin. We call these images "video thumbs" respectively in general "sidecar images".
Only for videos: If you run your own server and are able to install native PHP packages you might be able to setup ffmpeg to create thumbnails from videos. Our user wcroth55 wrote a short tutorial about that (scroll down to section IV):
Note: The thumb is determined by filename minus suffix. So if you have
movie.mp4 and an image
movie.jpg both will get it as the thumb. Name your non-image files individually to avoid this.
The image rotate button on the backend is grayed-out
The GD graphics libary on your server is missing support for image rotation. You have to contact your host about that.
Images are not displaying after installation
There are a number of reasons why you photos might not display after installation and setup.
- You may need to check your permissions on your albums directory and cache directory. Permissions for Zenphoto files and folders
- It could be that PHP Safe Mode is enabled. Your ISP will need to help you with this configuration.
- Check your .htaccess file if you're using Apache, and make sure you have the correct path for the RewriteBase line at the top. If you're not using Apache or it doesn't seem to be working, reset your mod_rewrite option.
- Search the ZenphotoForums for help, or start a new topic there. Zenphoto has a very helpful community, so don't be shy!
Trouble with file/folder names containing accented characters
It is best you avoid using accented characters in your file or folder names. It is really unnecessary to use them in file/folder names since you can edit the title to use whatever characters you like. Your site viewers see the title, not the file/folder name.
The technical explaination is that Zenphoto stores its data in UTF-8 format in the database. But your files ystem probably uses some other character set, most likely ISO-8859-1. So when Zenphoto gets the name of the image (filename) or the album (folder name) the character set of that string will not be UTF-8. This is OK as long as the string also does not contain any characters which are invalid in UTF-8. Unfortunately many accented characters from ISO-8859-1 are not valid when interpreted in UTF-8 so when the string is stored into the database MySQL truncates it at the first non UTF-8 character.
Current versions of Zenphoto will handle conversion of file system character strings to UTF-8 representation. However Zenphoto assumes that the filesystem characterset is ISO-8859-1, so if yours is in some other character set, things still will not work. Another player in this drama is the character set assumed for image URIs. Most servers seem to use ISO-859-1 even though the page claims to be in UTF-8. If your server actually assumes UTF-8 for these, you need to change the UTF8 image URIs option on the gallary configuration tab.
The images are in /zenphoto/albums/Myalbum but the URL says /zenphoto/Myalbum
The URLs are correct as Zenphoto makes them. They aren't supposed to have albums in them because they aren't pointing to the folder! They're rewritten by the Apache module mod_rewrite, which translates URLs into script arguments, in this case, inputs to Zenphoto. Read the next question to find out how this works.
Opening full images in Colorbox or another overlay script does not work
If you see some weird messy text showing instead of the full image you need to disable the full image protection on the backend options (Options > Images > Full Image Protection). These "box" scripts need to access the full image directly which naturally is not possible if it is protected.
Embedded images in Zenpage articles or pages are broken
To avoid overhead, embedded images are converted to direct links to cached images instead of the i.php image processor urls. If you clear the cache those naturally are broken afterwards.
To repair those enable the cacheManager plugin and access its button "cache images" on the admin overview page. Then access the tab "cache stored images".
The "albums" on the front- and/or backend are slow
Additionally to the reasons above: If you have lots of albums and subalbums with lots of images the reason could be the "album thumbnail". That is the thumbnail that represents an albums. What you can try:
- Disable the automatic thumbnail selection and set it to a fixed image. You can do this on each album or globally on the gallery options. Otherwise Zenphoto will randomly choose one from all images within this album including subalbums. Since it has to process uncached images this slows down depending on the size of the image.
- Disable the option "gallery > visual thumb selection" and "gallery > subalbum thumb selection". Both are normally off by default.
- On the image pages you can choose how many images to show per page and speed up its loading.
All this is related to caching the resized images.
This text by www.zenphoto.org is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Code examples are released under the GPL v2 or later license