I encountered the same problem as Olaf and Klaus with plugins physically disapearing :  on an old test site that I wanted to update to v.16.1 in December. I also tested more advanced versions of PHP, up to 8.5. Apart from the plugins distributed with the Piwigo core, they were all activated but missing: these 50 plugins had simply disappeared from the server !
According to the forum response, I had to reload them all via FTP. I did that, but I also had to downgrade my PHP to version 8.2.30.

Schneider-Fotografie wrote:

As always: after updating, please clear your caches:

- Piwigo: Tools → Maintenance → Clear compiled templates

Correct me if I am wrong, but aren't those the templates that can be used for linking images off site?
Like this: https://www.lotroshots.net/_data/i/uplo … 16c-xx.jpg

I can never delete that and there are hundreds more.

Last edited by homdax (2026-02-06 13:45:16)

This file does the job, thank you Olaf.

Yes, for sure. This will be included in the next release.
Since I don’t use Piwigo 15.7 anymore, I didn’t hit the issue on my side.

Schneider-Fotografie wrote:

homdax wrote:

Schneider-Fotografie wrote:

As always: after updating, please clear your caches:

- Piwigo: Tools → Maintenance → Clear compiled templates

Correct me if I am wrong, but aren't those the templates that can be used for linking images off site?
Like this: https://www.lotroshots.net/_data/i/uplo … 16c-xx.jpg

I can never delete that and there are hundreds more.

,

Hi homdax
No — “Clear compiled templates” is not related to image links in /_data/i/....

- Compiled templates = Smarty’s internal template cache (generated PHP from .tpl). Clearing it only helps when UI/templates don’t update after an upgrade. It doesn’t delete any images.

- The files you link to (/_data/i/upload/...jpg) are image derivatives / cached resized images (thumbnails/websize etc.). Those are recreated automatically whenever someone (or a bot) requests them, so they can come back even after deletion.

So: clearing compiled templates is safe and unrelated to the hundreds of /_data/i/ image files.

Regards,
Olaf

Hm, long time misunderstanding there.... geez

They come back after the deletion... with the exact same URL and size ?

I wish Piwigo could add how hotlinked images are affected by Maintenance actions in this section of the manual: https://doc.piwigo.org/administration-p … go-gallery

But that is of course not related to you plugin, so perhaps a bit off topic for this thread.

thanks

Last edited by homdax (2026-02-10 10:34:58)

windracer wrote:

One of my Piwigo sites was getting pounded today by someone ... it wasn't showing up as a bot in my Apache logs but something was crawling my site (thousands of requests similar to 'GET /photos/index.php?/tags/4997-tagname1/start-15&rvts=15 HTTP/1.1" 200 5263' scanning through all my tags or something).

So I installed this plugin (and turned on flood protection but not sure that was necessary) and it soon locked everything down and performance on my site went back to normal. All the IPs were from the 172.xxx.xxx.xxx range:

https://www.windracer.net/outgoing/piwigo/pwg-byb01.jpg

I did notice the plug-in blocked a lot of user agents like bots though:

https://www.windracer.net/outgoing/piwigo/pwg-byb02.jpg

Is that expected behavior? These were all listed as 'unknown' bots but it makes me wonder if User-Agents like these could also signify legitimate traffic. Should I just click 'block' on the IPs instead?

But yeah, this seems to work great, thank you!

Hello windracer
What you’re seeing is generally expected behavior.

Why the plugin blocks after “only 5 requests”:
In most cases this is not “5 requests per day” — it’s “5 requests within a very short time window” (seconds) and/or on the same pattern (e.g. tag pages). When something is crawling quickly (thousands of requests), a small burst threshold can trigger fast and stop the load immediately.

About “unknown bots” and strange User-Agents:
“Unknown” just means the User-Agent isn’t on the known/verified list. Attackers and scrapers often rotate User-Agents, and many use very old or fake browser strings. A browser-looking User-Agent does not automatically mean legitimate traffic — anyone can spoof it.

Should you block the IPs instead?
Usually you don’t need to block IPs manually unless the same IP keeps coming back and causing problems. The better approach is:

- keep flood/rate protection enabled (that stops aggressive crawls quickly),
- and only block individual IPs if they repeatedly reappear or if they ignore limits.

Also, don’t block an entire range like 172.x.x.x — that’s a huge public range and could cause collateral damage. Block only specific offending IPs if needed.

Recommended settings (safe for real visitors):

- Use a rate limit that targets bursts (e.g. too many requests in a few seconds/minute) to stop crawlers.
- If possible, exclude static assets (images/CSS/JS) from the flood counter so normal browsing doesn’t trigger blocks.
- Consider temporary blocks (minutes/hours) instead of permanent IP bans.

Bottom line: the plugin blocking lots of “unknown” User-Agents during a heavy crawl is normal and often exactly what you want. Focus on behavior (request rate/pattern), not just the User-Agent string.

Regards,
Olaf

Whitelist of recommended allowed bots: the font in the table is so tiny that the entries cannot be read.

Please change the font-size accordingly.

Klaus