batch_manager metadata sync meta_all #1125

New Issue

2026-10-05T00:32:16+02:00

adam commented

2026-10-05 00:32:16 +02:00

Hi,
I'm using Piwigo 11.1.0
I have a problem syncing IPTC tags on an updated gallery with batch manager. It pretends doing the job "Metadata synchronized from file : 12 files", but no IPTC are updated.

Workaround : it is still possible to update IPTC with:

album sync, with meta_all checked "even already synchronized photos"; and also with
edit single photo, sync metadata.

So I investigated with a fresh install, and the problem is confirmed. I would like "meta_all checked" like behaviour in batch manager, but is it what piwigo team wants ?

Within (piwigo)/local/config/config.inc.php there are still:

$conf['show_iptc'] = true; 
$conf['use_iptc'] = true;

Hi, I'm using Piwigo 11.1.0 I have a problem syncing IPTC tags on an updated gallery with batch manager. It pretends doing the job "Metadata synchronized from file : 12 files", but no IPTC are updated. Workaround : it is still possible to update IPTC with: - album sync, with meta_all checked "even already synchronized photos"; and also with - edit single photo, sync metadata. So I investigated with a fresh install, and the problem is confirmed. I would like "meta_all checked" like behaviour in batch manager, but is it what piwigo team wants ? Within (piwigo)/local/config/config.inc.php there are still: ``` $conf['show_iptc'] = true; $conf['use_iptc'] = true; ```

adam closed this issue

2026-10-05 00:32:16 +02:00

adam commented

2026-10-05 00:32:17 +02:00

IPTC is not synced by default. Some users may not want this. Instructions for enabling is in the documentation.
https://piwigo.org/doc/doku.php?id=user_documentation:metadata

IPTC is not synced by default. Some users may not want this. Instructions for enabling is in the documentation. https://piwigo.org/doc/doku.php?id=user_documentation:metadata

adam commented

2026-10-05 00:32:17 +02:00

Thank you for pointing out the documentation.
The fact is I suspect some changes in batch_manager process since Piwigo 11 update. Indeed before this update batch_manager metadata sync was working like a charm, and now, no IPTC update anymore.
I think my local/config/config.inc.php file is fine. Indeed it is well handled by both site_update process and single photo edit metadata sync. Both are updating IPTC data.
If you have any clue how to dig this bug, specificaly in batch_manager process, that would help me. Until now, I have just dropped some error_log() lines to try to figure out what's going on inside.

Thank you for pointing out the documentation. The fact is I suspect some changes in **batch_manager** process since Piwigo 11 update. Indeed before this update batch_manager metadata sync was working like a charm, and now, no IPTC update anymore. I think my local/config/config.inc.php file is fine. Indeed it is well handled by both **site_update process** and single photo edit **metadata sync**. Both are updating IPTC data. If you have any clue how to dig this bug, specificaly in batch_manager process, that would help me. Until now, I have just dropped some error_log() lines to try to figure out what's going on inside.

adam commented

2026-10-05 00:32:18 +02:00

...
Please, have a look at js code powering batch_manager page. You may find the typo (typographical error) that explains my problem, and maybe others related with "metadata syncing" in this page. I have been able to see this problem with IPTC because my configuration code binds IPTC with piwigo default metadata handling (and I watch IPTC much more than others metadatas).
I submitted a pull request to solve batch_manager metadata handling, which is currently impaired by a missing closing square braket in a jQuery statement.

... Please, have a look at js code powering batch_manager page. You may find the typo (typographical error) that explains my problem, and maybe others related with "metadata syncing" in this page. I have been able to see this problem with IPTC because my configuration code binds IPTC with piwigo default metadata handling (and I watch IPTC much more than others metadatas). I submitted a pull request to solve batch_manager metadata handling, which is currently impaired by a missing closing square braket in a jQuery statement.

adam commented

2026-10-05 00:32:19 +02:00

Nevermind. I misunderstood your original post.

Nevermind. I misunderstood your original post.

adam commented

2026-10-05 00:32:20 +02:00

If only I had described more precisely how to reproduce this bug... if only...
The confusion is maybe coming from my said "fresh install" without telling clearly I added a crafted (piwigo)/local/config/config.inc.php enabling IPTC.
Maybe, maybe, maybe... Anyhow, it seems we ended in mutual understanding.

This bug is reproducible with default EXIF metadata support, but it needs a way to edit one picture default metadata, for instance with exiftool in bash (3 lines : read, write, read):

exiftool -dateTimeOriginal ~/path_to_piwigo/galleries/directory_01/file_01.jpg ;
exiftool -overwrite_original -dateTimeOriginal='2025:01:31 00:03:09' ~/path_to_piwigo/galleries/directory_01/file_01.jpg ;
exiftool -dateTimeOriginal ~/path_to_piwigo/galleries/directory_01/file_01.jpg ;

Then use the 3 ways to update metadata to see what's going on:

page=photo-# single photo edit; or
page=site_update with sync files, both checked syn_meta and meta_all; or
page=batch_manager.

Beware, in single photo edit page, once sync metadata is done ("Synchronize metadata" button), the page does not display the updated date (another confusing thing here ! Is my browser involved ?). You need to reload the page to see the change (without syncing again), or to go to picture page in the gallery. The nice thing is, on picture page, the possibility to compare metadata from the database, and from the file. Thanks "Show file metadata" button.

If only I had described more precisely how to reproduce this bug... if only... The confusion is maybe coming from my said "fresh install" without telling clearly I added a crafted (piwigo)/local/config/config.inc.php enabling IPTC. Maybe, maybe, maybe... Anyhow, it seems we ended in _mutual understanding_. This bug is **_reproducible with default EXIF metadata support_**, but it needs a way to edit one picture default metadata, for instance with exiftool in bash (3 lines : read, write, read): ``` exiftool -dateTimeOriginal ~/path_to_piwigo/galleries/directory_01/file_01.jpg ; exiftool -overwrite_original -dateTimeOriginal='2025:01:31 00:03:09' ~/path_to_piwigo/galleries/directory_01/file_01.jpg ; exiftool -dateTimeOriginal ~/path_to_piwigo/galleries/directory_01/file_01.jpg ; ``` Then use the 3 ways to _update metadata_ to see what's going on: - page=**photo-#** single photo edit; or - page=**site_update** with sync files, both checked syn_meta and meta_all; or - page=**batch_manager**. _Beware_, in single photo edit page, once sync metadata is done ("Synchronize metadata" button), the page does not display the updated date (another confusing thing here ! Is my browser involved ?). You need to reload the page to see the change (without syncing again), or to go to picture page in the gallery. The nice thing is, on picture page, the possibility to _compare metadata_ from the database, and from the file. Thanks "Show file metadata" button.

adam commented

2026-10-05 00:32:20 +02:00

I realize this problem to be more complicated than I expected :

with my browser Firefox 85.0, I can see in debug mode XHR NS_BINDING_ABORTED errors blocking ws.php POST requests, also visible in networks tab,
there are 2 others missing closing square brackets in batch_manager.js code.

My third workaround (https://github.com/Piwigo/Piwigo/issues/1296#issue-792592214) is to go back to my piwigo 2.10.2 to get this process running well.

I realize this problem to be more complicated than I expected : - with my browser Firefox 85.0, I can see in debug mode XHR NS_BINDING_ABORTED errors blocking ws.php POST requests, also visible in networks tab, - there are 2 others missing closing square brackets in batch_manager.js code. My third workaround (https://github.com/Piwigo/Piwigo/issues/1296#issue-792592214) is to go back to my piwigo 2.10.2 to get this process running well.

adam commented

2026-10-05 00:32:21 +02:00

you may want to discuss this in the Forum. You are kind of hidden here.
https://piwigo.org/forum/viewtopic.php?pid=179606#p179606

you may want to discuss this in the Forum. You are kind of hidden here. https://piwigo.org/forum/viewtopic.php?pid=179606#p179606

adam commented

2026-10-05 00:32:22 +02:00

So I posted a new topic on the forum.
https://piwigo.org/forum/viewtopic.php?id=31001

So I posted a new topic on the forum. https://piwigo.org/forum/viewtopic.php?id=31001

adam commented

2026-10-05 00:32:23 +02:00

The problem is now coming from my browser client profile. With a brand new profile, and with piwigo 11.3.0, the bug is gone.

The problem is now coming from my browser client profile. With a brand new profile, and with piwigo 11.3.0, the bug is gone.

adam commented

2026-10-05 00:32:23 +02:00

Purely FYI, that bug is still there in 13.6.0, this issue should be reopened.
It affects Safari as well. The clumsy "workaround" described here for Firefox "works".
Would be nice if it actually worked out of the box, mass updating metadata is a small nightmare otherwise.

Purely FYI, that bug is still there in 13.6.0, this issue should be reopened. It affects Safari as well. The clumsy "workaround" described [here](https://piwigo.org/forum/viewtopic.php?pid=179678#p179678) for Firefox "works". Would be nice if it actually worked out of the box, mass updating metadata is a small nightmare otherwise.

adam commented

2026-10-05 00:32:24 +02:00

I get the problem too, with Firefox 126. Here is what happens. When you apply the action "sync metadata", the javascript initiate 1 AJAX request per 1000 photos (which is too much, I'll create another issue for that). If you have 12345 photos in your set, the javascript will initiate 13 AJAX requests. At the same time. This is not a sequence, but a parallel tasking. I don't know why and I think it should wait for the first one to finish before starting the second one. But it's not done that way and it's not really the problem here.

The problem is that after initiating those 13 AJAX request, the javascript does not wait for the response from server and validate the page form. In the case of the "sync metadata" action, the POST submit does not do anything but displaying a message "X photos synchronized" (which is fake).

Maybe a few AJAX requests will have succeeded, depending on the speed of your web browser, your internet connection and your server. Maybe no requests at all. I think all requests with a NO_BINDING_ABORTED status mean "I, the web browser, haven't had time to send the request".

@HWFord has found that in recent versions of Firefox (also apply to Safari), we need to add e.preventDefault(); in addition to e.stopPropagation();.

I get the problem too, with Firefox 126. Here is what happens. When you apply the action "sync metadata", the javascript initiate 1 AJAX request per 1000 photos (which is too much, I'll create another issue for that). If you have 12345 photos in your set, the javascript will initiate 13 AJAX requests. At the same time. This is not a sequence, but a parallel tasking. I don't know why and I think it should wait for the first one to finish before starting the second one. But it's not done that way and it's not really the problem here. The problem is that after initiating those 13 AJAX request, the javascript does not wait for the response from server and validate the page form. In the case of the "sync metadata" action, the POST submit does not do anything but displaying a message "X photos synchronized" (which is fake). Maybe a few AJAX requests will have succeeded, depending on the speed of your web browser, your internet connection and your server. Maybe no requests at all. I think all requests with a `NO_BINDING_ABORTED` status mean "I, the web browser, haven't had time to send the request". @HWFord has found that in recent versions of Firefox (also apply to Safari), we need to add `e.preventDefault();` in addition to `e.stopPropagation();`. <img width="1313" alt="Screenshot 2024-06-19 at 14 21 55" src="https://github.com/Piwigo/Piwigo/assets/9326959/a47a2b5f-a1d6-4183-9de5-9fb9fcd3d313">

Sign in to join this conversation.

master

issue-2560-people

translation

16.x

feat/embedding-based-contextual-tagging

issue-2576-search-include-ai-in-search-results

feat/search-ocr-ai

issue-2391-update-menu-design

15.x

detect-container

issue-2386-update-filters-users-activity

issue-2362-add-filters-options-in-admin

issue-2367-imagemagick7

issue-2225-quicksearch-help

14.x

issue-2164-BatchManagerUnitMode-Redesign

13.x

12.x

issue-1657-SVG_Support

issue-1703-historySearchMethod

11.x

2.10

2.9

2.8

2.7

2.5

2.6

2.4

2.3

2.2

2.1

2.0

1.7

1.3

1.6

1.5

1.4

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/Piwigo#1125