What is "the Single Edit bulk-editing page"?
And what exactly are you doing there?

Here is the console trace when I try to save the page in Firefox.

POST    http://[my domain]/admin.php?page=batch_manager&mode=unit
Status    403 Forbidden
Version    HTTP/1.1
Transferred    1.44 KB (1.20 KB size)
Referrer Policy    strict-origin-when-cross-origin

So it sounds like a potential CORS problem. Once again, saving a single photo works fine. It's only when mode=unit that a 403 results. I've been going through the code and nothing is obvious, nor do there appear to be any permissions issues on the files on my host. I would think if it were a permissions issue on a base file then no saving would work.

I'll try the page in another browser since Firefox is especially sensitive to CORS issues. If it works there then that's the cause.

EDIT: It throws a 403 in Edge as well. So it's not just Firefox. Could still be CORS of course, but it's not restricted to one browser.

Last edited by TabulaRetina (2021-05-15 15:14:32)

> trigger the a**l-retentives in future?
> Awesome passive-aggressive tone, by the way.
> I've been developing software for decades
> I recommend you save the condescension

Awesome. Thank you for telling that you do not want my help so I won't waste time on this.

I just asked what exactly you were doing where because I did not understand. You king of condescension.

Zentalquabula wrote:

Works for me. What are your permissions for batch* in the admin folder?

-rwxr-xr-x 1 www-data www-data 20543 Jan 22 17:13 batch_manager_global.php
-rwxr-xr-x 1 www-data www-data 22586 May 14 16:17 batch_manager.php
-rwxr-xr-x 1 www-data www-data  6914 Jan 22 17:13 batch_manager_unit.php

Same values here. As I say, it's only the "unit" save that fails. Every other kind of save works fine. So I don't think it's a file permission issue, unless one of the pages invoked by the "unit" save has an issue. Is there an include file that only that page uses?

This worked on my host two versions ago. It broke in the previous version. Absolutely nothing changed in my environment, and I updated Piwigo the way I always do (through the upgrade link inside the program admin interface). Something changed recently in the release that broke this for me. Maybe only for me, or maybe I'm the only person posting about it. But I'd love for the Piwigo team to tell me what they changed either in batch_manager_unit.php or in one of the files loaded by that page that would cause such a specific 403 denial.

No, it's only gotten worse. Not only has this not been fixed, but now when I try to save metadata on an Album (such as changing its name) I also get the error page. Basically the application is continually decaying into uselessness.

I followed the suggestion here a while back to put the application behind an SSL certificate, and that did sod-all to fix it. The developers have the attitude that if it works on their setup then c'est la vie for everyone else. I've pointed out to them before that their page routing code has assumptions in it which will cause it to break under various configurations, but again, they can't be bothered to address that. Once I find a replacement for Piwigo that I can migrate all my existing gallery data into, I'll be on it in a heartbeat.

I've given up on expecting the developers to address this, or even to respond. And experience has shown that even if they do respond, it will just be to put the blame back on the users. I say this not only as a user, but as a developer who creates applications for public use and who addresses all user concerns. Part of a dying breed, clearly.