Acutally, when moving a file from one gallery to another and the file already exists, theres is an warning ("image already exists") if the file already exists. When mass-moving images between galleries, this is not practical, becaus i can´t see which images are affected/duplicates.

Is it possible to simply overwrite the existing files when they are already in the target-gallery?

regards

I assume you mean the move utiltiy on albums ("Gallery" means the whole site in ZP terms)? No, that is not possible right now except hacking. We'll see if we can add some kind of dialogue to choose. I'll put that on our list.

You could alternatively move images directly via FTP but that has some disadvantages if you need data entered on the backend to move with them.

A future function would be great, but a dialouge won´t be necessary for this special case -do you have a hint for me, where to start coding?
As an alternative, can i add - by "hacking" - the filenames of the duplicates in the message ("image already exists")? I not used to the zp php core files, maybe you have a hint for me where to start?
Thanks!

That is not that easy and would require quite a lot hacking which I cannot recommend. We have a 'move_object' filter in the base PersistentObject class but that only fires when an object can successfully be moved.

The actualy process of bulk actions is handled in the admin function processImageBulkActions(). You'll see the switch with the actions. You perhaps could "hack" that to return the image names that could not be moved. Not sure if that works with the return value of it. But perhaps a error log entry using debuglog() might do as well. Note that the image class copy() method returns integers, 2 would mean the file already exists in the desired place.

I do have a question. You say you are bulk moving images from one album to another and need to know which ones were not moved because of the duplicate in the destination album. Is this correct?

But wouldn't the images that were not moved simply be the ones still left in the source album? (There does seem to be a flaw in the process since it aborts upon the first duplicate. But that is easily fixed in the bulk actions code.)

There does seem to be a flaw in the process since it aborts upon the first duplicate.

Indeed and same for copying. Will look into that asap.

The support build aka 1.6a has this fixed and also includes the affected images on failure in the error messages.

Are there any different/special requirements for installing the ?
When running setup.php i get nothing else but a message that the script will install Zenphoto the support-build.

You mean it stops afterwards? In any case 1.6a requires PHP 7+ but generally it should work if 1.5.9 does. If that's not it please review your logs as it can be lots of things. Also note 1.6a is not intended for live sites yet.

The backend seems to work. The frontend shows ablank page.
Maybe there are some builds missing? I tested upgrading from version 1.5.9. (fresh install) with php 7.4.27

If you geet a blank page there is usually a PHP fatal error. Review the logs please.

Also disabale third party plugins and if you don't use any of the officail themes remove the third party theme as well.

Yes, I get a php-warning:
WARNING: Cannot modify header information - headers already sent by (output started at /[..]/htdocs/login-2022/zp-core/class-maintenancemode.php:169) in /[...]/zp-core/functions-basic.php on line 1952
header called from redirectURL (functions-basic.php [1952])
from maintenance_mode.php [50]

and ...

Cannot modify header information - headers already sent by (output started at /[...]/login-2022/zp-core/zp-extensions/uploader_jQuery/class-uploadhandler.php:1210) in /[...]/zp-core/zp-extensions/uploader_jQuery/uploader.php on line 64

header called from uploader.php [64]

. ..when uploading images from the backend.

The maintenance mode change is rather new. Do you have any maintenace mode active currently?

Got it, there is a failure at line 37 in the index.php

So no issue on our end? On line 37 of the root index.php the rss placeholder starts in 1.6a.

Yes, that´s correct, it´s an issue with the rss-placeholder. My Host does not allow error reporting (!), tested it localy yesterday.

I will have a look at the maintainance mode warning next.
The maintainance mode is activated automatically after upgrading

Really weid because the root index.php comes first, there should really be no headers before it… Looking forward what you may find out… (Really strange that your host does not allow error reporting…)

The maintainance mode is activated automatically after upgrading

Yes, that is new. It was recommended to do this manually to avoid trouble cause by site access during that so we thought it a good idea to do this automatically.