I started getting “Invalid album instantiation” errors, only in the last two days, under the album validity check in zp-core/class-album.php (line 1297) for any album with “&” in it. The album still loads in the Zenphoto gallery, but it fails if I try to cache album images or refresh album metadata under the Album tab, and view thumbnails or apply a sort order under the Image order tab in Admin.

What’s weird is that the thumbnail images for the folder will not load if I go to Image order tab, but if I go to the Images tab first, they will load, and then if I go back to Image order they will load, though it will still not apply a sort, just fail to a white screen.

I also have gotten “Undefined index” errors when I’ve cleared the cache by individual album.

The only thing that has changed since this started is that some images have been replaced with those that have had keywords added in the metadata in Adobe Bridge (though not all folders showing errors have had images replaced). That’s the reason I’ve been trying to refresh the metadata and cache by album. In the past I would do it gallery-wide from the Overview tab, and maybe that is also the reason it wasn’t generating the errors? I also renamed a few existing tags in Zenphoto.

I’ve tried refreshing the database, cleaning up cache sizes, and resetting all of the album/file permissions for the entire gallery. The albums do exist in the file system, and as I said, some of the folders and their images are unchanged and have worked in Zenphoto for nine years.

This is in 1.5.7.


Some of the errors I’m getting in the debug.log-

{389038:Sat, 03 Apr 2021 11:57:58 GMT}
USER ERROR: Invalid album instantiation: 1998/Name1_ does not exist. in /host/zenphoto/zp-core/class-album.php on line 1297
trigger_error called from Album->_albumCheck (class-album.php [1297])
from Album->__construct (class-album.php [1267])
from newAlbum (class-album.php [26])
from admin-refresh-metadata.php [83]
{392476:Sat, 03 Apr 2021 11:59:00 GMT}
USER ERROR: Invalid album instantiation: 1998/Name1_ does not exist. in /host/zenphoto/zp-core/class-album.php on line 1297
trigger_error called from Album->_albumCheck (class-album.php [1297])
from Album->__construct (class-album.php [1267])
from newAlbum (class-album.php [26])
from cacheImages.php [44]
{409702:Sat, 03 Apr 2021 12:02:04 GMT}
NOTICE: Undefined index: album in /host/zenphoto/zp-core/admin-edit.php on line 135
{107324:Sun, 04 Apr 2021 05:49:18 GMT}
USER ERROR: Invalid album instantiation: 2001/Name2_ does not exist. in /host/zenphoto/zp-core/class-album.php on line 1297
trigger_error called from Album->_albumCheck (class-album.php [1297])
from Album->__construct (class-album.php [1267])
from newAlbum (class-album.php [26])
from admin-albumsort.php [21]

So you have album folder or image file names like `myalbum&something` or `myimage&something,jpg`, right? `&` is nonallowed character in album folder and image file names as it is used to separate query values (like the URLs that are rewritten by modrewrite like `index.php?album=album%image=image.jpg`).

So you are confusing this. You need to rename your album folder names and image file names to remove that char and possibly other special chars and also spaces. (I am not talking about the title!). This is also better and recommended for SEO. Use the included plugin seo_cleanup for this.

You also should enable the seo_friendly plugin - which should be on by default actually - that will clear names on uploading from thte backend. If you upload bypassing the backend like via FTP you have to run the seo_cleanup plugin again.

Well, like I said, it works on the front-end fine. It both loads the album and caches the images. It is only certain things, not all, that do not work when trying to make changes for individual albums.

Some of the albums already had custom sort orders, so at some point in the past it worked.

From a new user’s point of view, to be using a system that is file system-based, their expectation might be that they can just FTP their images into it and it will work. I know there are specifications on what can and cannot be used in a URI ([RFC 3986](https://tools.ietf.org/html/rfc3986)), I wish there was a clear list of forbidden characters that Zenphoto does not support.

For example, I’ve recently found that filenames with domains in them will not display. So say, “screenshot from example.com.jpg” will not work.

Also, I thought [this issue with the “&” character had been fixed](https://github.com/zenphoto/zenphoto/issues/465)?

I have found seo_cleanup to be way too destructive for me. First, there is no options for how you would like the character replacement to act. It is only on or off. Most other web exporters give you many different options when it comes to how you want your filenames treated.

Second, there is no warning of what the changes are going to be. Once you click the button, it is off to the races, and there is no easy way to undo what it has done. When I tried it in the past it instantly messed up thousands of pictures. Ideally it should give you a list of proposed changes and a way to opt-out of those changes before it makes them.

I found a solution that works for me, without having to rename everything to almost MS-DOS restrictions. By temporarily renaming the folder in Zenphoto to not include the “&” character you can do custom sorts. You can then rename it back in Zenphoto and it will keep the sort order.

Going forward, I will try not to use the “&” character, it is not worth the hassle.

Thanks Malte for getting back to me, even on a holiday weekend.

> I wish there was a clear list of forbidden characters that Zenphoto does not support.

As mentioned it is just best practice to avoid such charactters all togehter. This is not really a "Zenphoto problem" but a general one.

The front end may use modrewrite so there are no & query type urls visible. The backend does only use query based URLS so there are plenty of & which then breaks the URLs. Although they should be escaped.

And these are not MS-DOS restriction but arise from the fact that the whole internet is basically English based which has still its problems with non English chars.

> `screenshot from example.com.jpg`

I have to try this. It is also best practice to avoid spaces and dots in filenames except the suffix. This is probably rather a problem of the image processor and its filenames.

If you FTP you naturlly bypass everthing Zenphoto clears.

> I have found seo_cleanup to be way too destructive for me. First, there is no options for how you would like the character replacement to act. It is only on or off. Most other web exporters give you many different options when it comes to how you want your filenames treated.

I always strongely recommend to use a staging (local) mirror site to test larger changes before applying on a live site.

Well, the most used CMS used by millians also does not offer anything here to adjust by default and does the same acually (our tool is even modeled after that). You can look at the character catalog of plugin itself what it does and if needed even create your own. Basically it try to replace all special chars and spaces.

I made tests with an album folder and filenames with `&` in it and also with a `screenshot from example.com.jpg` file name. All work normally on the front and backend, both on my local MAMP test server and also on our own server on a test install. Refreshing metadata also works.

What are your charset settings, especially the filesystem charset? (Options > Images)

I can confirm that all is working normally, both on MAMP and on my webhost.

Thank you both for trying it. I went back and looked over the screenshot that was causing problems and noticed it contained another character in the filename, a pipe “|”, so that was what was causing it to not load, not the .com in the name. Sorry for any confusion with that.

Charset and Filesystem Charset are both set to Unicode (UTF-8) on both my MAMP test server and my live shared hosting server.

I tested the “&” in folder names on 1.5.8RC in MAMP 6.3. On the front-end, if a folder name included both spaces and “&”, say “Name & Another”, with URL options-mod rewrite turned off *or* on, thumbnails would not load or cache, but the image preview would load and cache on the image page.

That said, cacheManager was as able to cache all image sizes.

If the folder name included no spaces, but still had “&”, thumbnails *and* the image preview would load and cache on the front-end.

On both folder names, with spaces and without, image sort and refresh metadata by album refused to work. The errors were always stopping at the “&” character.

{2088:Wed, 07 Apr 2021 06:25:36 GMT}
USER ERROR: Invalid album instantiation: 1998/Name does not exist. in /Applications/MAMP/htdocs/zenphoto158test/zp-core/class-album.php on line 1297
trigger_error called from Album->_albumCheck (class-album.php [1297])
from Album->__construct (class-album.php [1267])
from newAlbum (class-album.php [26])
from i.php [61]
{2088:Wed, 07 Apr 2021 06:26:04 GMT}
USER ERROR: Invalid album instantiation: 1998/Name_ does not exist. in /Applications/MAMP/htdocs/zenphoto158test/zp-core/class-album.php on line 1297
trigger_error called from Album->_albumCheck (class-album.php [1297])
from Album->__construct (class-album.php [1267])
from newAlbum (class-album.php [26])
from admin-albumsort.php [21]


Under Options-General-URL options, I get the following message in MAMP and on my live server-
“Setup did not detect a working mod_rewrite facility.”
Even though on both, it is enabled, it showed that it was enabled twice during setup on both, and you can see it is working if you turn on the the mod rewrite option.


I went ahead and removed all “&” characters in folder names on my live server, to try to eliminate any future issues. I noticed when I did that it cleared up another issue I was having with sitemaps. Before when I ran sitemap-extended, it would act like it was successful, but it would only create two files with no real links and without actually creating the sitemap. Once the character was removed from all folders, sitemaps are now actually created.

Thanks for the info. Pipes `|` are of course also kind of "special char".

> “Setup did not detect a working mod_rewrite facility.”

The problem is that there is no real way of checking if modrewrite is really working via PHP or else. All we can try is testing if a rewritten URL works which is what setup tries to do. Sometimes it fails although it is working. In that case you have to try it. On MAMP it certainly works.

Sitemaps are XML and very strict regarding specific characters. Actually all should be escaped to be valid there. Will try to reproduce that.

However still it saves a lot of hassle to clear chars from everything that may appear in URLs (it also looks better ).