NAROLLES

Hello @barb0ss

Good news: I managed to complete the full bulk compression process.

I only had two blocking images during the run. After identifying and excluding them, I was able to resume the process, and fortunately the bulk compression did not restart from zero. That was very helpful.

I still have a few comments that may help improve the user experience.

I am not yet completely sure I understand the difference between the two buttons:

• “Run Bulk Squeeze”
• “Repeat Run Squeeze”

This may partly be a translation or wording issue.

From what I observed, “Run Bulk Squeeze” can be paused, but after pausing it, I had to refresh the page before I could reactivate or resume it properly.

The “Repeat Run Squeeze” button seems to trigger a different kind of compression pass. I noticed some labels or expressions on the images such as “fat xxx” — if I understood correctly — but I am not entirely sure what this means in the workflow.

One other point: when the process gets stuck on a specific image, it is not very easy to immediately see that there is a real blockage. It may be useful to make this more visible, for example with a clearer warning, a retry counter, or an indication that the same media item is being processed repeatedly.

In any case, thank you again for your help. After cleaning the media library and excluding the problematic files, the process finally completed successfully.

Best regards,
Luc

Hello @barb0ss 

Thank you for your clear and detailed reply.

I tried several times with the timeout increased to 180 seconds and the WebP quality/compression setting lowered to 73%, but I still cannot get the bulk compression process past around 76% of the media library.

The process repeatedly gets stuck on what appears to be the same image. It tries to compress the same media item many times, then the queue no longer progresses.

I also tried squeezing the blocking image individually, and I checked whether the issue could be related to the filename length or special characters. I am not sure whether the problem comes from a few specific images, from long filenames, from a browser/session timeout, or possibly from a server-side security rule.

I also found this critical error in the WordPress logs:

2026-06-22T10:32:11+00:00 Critical
Uncaught DivisionByZeroError: Division by zero in:

/wp-content/plugins/squeeze/inc/helpers.php:411

Backtrace: 0 /wp-content/plugins/squeeze/inc/handlers.php(248): SqueezeFree\SqueezeHelpers->get_comparison_table() 1 /wp-includes/class-wp-hook.php(341): SqueezeFree\SqueezeHandlers->update_attachment() 2 /wp-includes/class-wp-hook.php(365): WP_Hook->apply_filters() 3 /wp-includes/plugin.php(522): WP_Hook->do_action() 4 /wp-admin/admin-ajax.php(192): do_action() 5 {main}

Could this DivisionByZeroError be related to the bulk compression getting stuck?

Also, is there currently any CLI solution, WP-CLI command, or safe server-side method to process the remaining images without relying on the browser tab? With a media library of more than 51,000 images, the browser-based process is quite difficult to complete reliably.

If there is no CLI option, is there a safe way to mark problematic images as skipped, or to identify the exact images causing the DivisionByZeroError so I can manually exclude them from future bulk runs?

Thank you again for your help.

Best regards,
Luc

Hello @pierrelannoy ,

After multiple tests and verifications, I was able to clearly identify the root cause of the issue encountered.

The problem was related to the CSS scope. The CSS needed to be applied at the global site level. When it was injected at a more local level (page or component level), it was being affected by the object cache mechanism, which resulted in inconsistent and unpredictable behavior on the front end.

Once the CSS was moved to a global scope, all interference with the object cache was eliminated, and the site returned to normal, stable operation.

Thank you for your support and assistance.

Hello, @pierrelannoy

Here are the details of the hosting environment:

• Hosting provider: PlanetHoster (HybridCloud / N0C)
• Server type: Dedicated environment (not shared)
• Architecture: Virtualized instance (no Docker, no Kubernetes)
• Web server: Appache acceleration LiteSpeed
• Operating system: Linux
• PHP: PHP 8.4 (with OPcache enabled)
• Object cache: APCu (via APCu Manager plugin)
  → Redis and Memcached are installed but currently disabled due to conflicts
• CMS: WordPress
• Page builder: Elementor (cache disabled)
• Load balancing: No load balancer (Il y aurait CloudLinux qui pourrait balancer les ressources entre les différents compte N0C sur le serveur, toutefois, puisque vous avez un seul compte, la charge n’est pas équilibré entre ceux-ci.)
• CDN: None (no Cloudflare or external CDN)
• Traffic: Moderate, mostly B2B audience
  
  https://www.awesomescreenshot.com/image/58200787?key=e595781d1cb622b861e1f05b696ed631
  
  https://www.awesomescreenshot.com/image/58201042?key=6acd9ad270b48b448fb9aa7dfacd1902

Subject: Clarification regarding the “Global Logout” button and WordPress session tokens

Hello, Hi @joelcj91

After further investigation on our side, we have identified the root cause of the behavior we observed regarding the “Global Logout” button displayed on some user accounts.

This functionality is actually based on the native WordPress core session (token) management system, and not on a mechanism introduced by your plugin. The presence of this button simply depends on whether multiple active session tokens exist for a given user.

On my side, there was therefore an initial misunderstanding, as I first assumed this behavior was coming directly from Loggedin – Limit Concurrent Sessions, whereas it is in fact a feature provided by WordPress itself.

That being said, your plugin is still working as expected and remains very useful: it properly interacts with WordPress session tokens, especially when resetting a user’s sessions or limiting concurrent logins, which is exactly the intended effect in our use case.

I just wanted to share this clarification with you for information.

Thank you for your work and your support.

Best regards,

Hello
I am the only administrator, apart from support staff interventions.
The list of blocked users could be used to activate, for example via an email (provided an automation plugin can handle this).
thanks