Last changed by: ZenphotoCMS internal request

I have a user who has a personal instance of ZenPhoto to manage Neuropathology images. He has been building his image atlas for over 10 years and the collection has over 30,000 images in it. Since January, random sub sets of albums have been having all of their meta data erased. It has happened four times in two months, and I can't seem to track down what is causing it.

I initially thought it was him breaking or changing things, but the most recent incident happened when I know for a fact that he had not been making any changes as I was still restoring the data from the last time information went missing. This rules out user interference, as he is the only user, and tells me it must be a ZenPhoto software or server problem.

Reviewing the Database in MySQL, it looks like all the entries for the affected albums have been deleted and then recreated. The IDs for the albums are all the newest listed. The only information in ZenPhoto is the date the images were changed, which is identical for all of them, and the Last Change by: ZenphotoCMS internal request.

This leads me to believe that ZenPhoto is seeing these albums as new or edited and removing / recreating the entries in the Database for them. If they are new though, why would the old data be deleted and not simply new data created? And if they were just edited, why is it deleting the meta data completely and making a new DB entry?

If anyone has any insights or suggestions on what could be causing this, it would be greatly appreciated.

ZenPhoto: 1.6.1
Server: Windows Server 2022 Standard
MySQL: 8.1

Tags:

Comments

  • acrylian Administrator, Developer

    The only thing I could think of is some kind of server update by the host that somehow made Zenphoto recognize the albums/images as news. That could be a server move that cause trouble with file permissions. As you hopefully know Zenphoto is file system based and matches the database with the file system and not the other way round.

    Hard to say from the outside. Best review your logs. ZP's own but also the server PHP error log the access log and thte MySQL log if you have access to them. Otherwise ask your host.

    If all images/albums are in place within the albums folder you could re-import a database backup which you hopefully setup to be performed (either by ZP's own tool or some server sider or host service).

    Note at the end. 1.6.1 is not the latest version and Zenphoto has not been testsed with MySQL 8+ as we don't have access to that yet sadly (our own server uses MariaDB). In 1.6.3 we fixed an issue with it for the search engine. We don't know about other actual incompatibilities but don't know. Also we actually don't test Zenphoto with Windows servers.

  • Thanks for reaching out to help! It is appreciated. We have been digging through and checking the things you recommended.

    There isn't anything in the PHP or MySQL logs.

    One question that came up from our system admin, what exactly is ZenPhoto looking at / for in the file system to see if the albums and images are new? If we could narrow down what ZenPhoto is looking for, then it could help isolate what is causing the problem.

    Also - there was this in the ZenPhoto debug log:

    USER DEPRECATED NOTICE: Parameter usage of zpFormattedDate (called from template-functions.php line 2746) is deprecated. Using strftime() based date formats strings is deprecated. Use standard date() compatible formatting or a timestamp instead. in C:\Websites\SchmidtImageAtlas\zp-core\functions\functions-basic.php on line 2212
    trigger_error called from deprecationNotice (functions-basic.php [2212])
    from zpFormattedDate (functions.php [305])
    from printImageMetadata (template-functions.php [2746])
    from include (image.php [107])
    from include (index.php [128])
    from index.php [79]

    Since this is a date-related warning, we were wondering if this could contributing to the issue were the system might be seeing the items as changed?

  • acrylian Administrator, Developer

    Zenphoto's gallery part is file system based so it considers new what it didn't "discover" there previously and then updates the database. The ID is the "discovery" order. The date might be the file time but also from metadata if existing. Some info about that: https://www.zenphoto.org/news/caching/

    Internal requests would be such discovery. It could be a file permisson issue or some server upgrade/moving by the host not right.

    The deprecation notice would not cause such an internal request. It's a PHP 8+ date formatting deprecation. However you should fix the usages of that. Either you use custom code or some custom datte format defined on the backend options you need to update. Se the release notes. Note that 1.6.5 is the latest version and we are heading to 1.6.6 already.

Sign In or Register to comment.