docjojo

Thank you for the feedback — you’re absolutely right, and we’ve improved this in the latest update.

Each profiler tab now has a “How to use” help tooltip (ℹ️) next to the Enable profiler switch. It walks through the workflow step by step:

1. Turn on Enable profiler
2. Open the page you want to measure (e.g. your homepage for frontend, or any admin screen for backend)
3. Return to the profiler and click the reload button (↻) in the title bar

The hint is tailored per tab (Processes, Pages, Hooks, Translations), and the Queries tab has its own note since it works a bit differently.

We also renamed the toggle from “Profiler active” to “Enable profiler” so it reads as an action, not a status.

Hope that makes profiling easier — and thanks again for taking the time to review.

https://screen2.link/6rfRNFGqAU71.png

What do you mean?
The free version supports FILE storage and shows all other storage options as PRO.

https://screen2.link/8M6tQN14fJ2I.png

Thank you.
Found the issue and fixed it.
Will be avail with next update.
Regards, C.

Hello,

Thank you for the detailed report and for narrowing this down so clearly.

You are correct that the issue can appear only for non-logged-in visitors (cached responses) and not for admins (cache bypass). We reviewed our page-cache output path and found that our frontend debug marker could interact badly with some layouts/builders (including Elementor-based pages), which could contribute to blocked pointer interactions.

We have now adjusted the page-cache output behavior:

• removed the frontend debug injection logic (green marker / debug script)
• kept cache diagnostics via response headers (<code class=””>X-Cache, <code class=””>X-Cache-ID, <code class=””>X-Cache-Type, <code class=””>X-Cache-Enabled) instead
• kept the attribution footer in a non-blocking form (<code class=””>pointer-events:none on wrapper)

What we recommend on your site:

1. Update to the next plugin build containing this fix.
2. Flush the page cache after update.
3. Test again as a non-logged-in visitor (private window).

If the issue still appears after cache flush, please send us:

• one affected URL
• response headers from the failing request
• a screenshot of the exact element path in DevTools (Elements panel) for the blocking node

With that, we can verify whether another theme/plugin wrapper is creating the overlay and provide a targeted compatibility fix.

Thanks again for the high-quality report — it helped us improve this quickly.

Hello,

thank you for your question — this is a very good point and can indeed be confusing.

In general (WordPress core behavior):

• The object cache works via the object-cache.php drop-in and does not depend on WP_CACHE.
• The WP_CACHE constant is required for page caching, as it enables loading of advanced-cache.php very early in the WordPress bootstrap process.

For atec Cache APCu:

• The object cache works independently and does not require WP_CACHE.
• The page cache uses the standard WordPress mechanism (advanced-cache.php), and therefore WP_CACHE is required for it.

However:

• The plugin automatically sets or removes define( 'WP_CACHE', true ); when page caching is enabled or disabled.
• It also installs/removes the corresponding advanced-cache.php file.

Therefore, you do not need to add WP_CACHE manually.

Conclusion:

• For object cache: WP_CACHE is irrelevant.
• For page cache: WP_CACHE is required — but the plugin manages this automatically, so no manual action is needed.

Best regards

We need to be precise in what we are talking about.
If you changed opache settings and mem is still 0 you most likely have another .ini overwriting settings. Try atec-system-info and check which settings are effective.
Also flush the opcache so scripts get reloaded.

As for APCu, if you mean cache misses – that depends on the cache usage. Are you using it as an object cache or for storage? Or both?
A miss only means that data is not stored but requested. So if some script run apcu_fetch(“foo”) but never apcu_store(“foo”, “bar”) … that will always result in high misses.

But the main issue is most likely that APCu is per PHP worker not per machine. If you have multiple workers running, you might hit different cache per request, thus you will get different results and only over time reach a higher hit rate – if ever.

Remember: High APCu miss rates are a natural side-effect of per-worker caches, not a sign of misconfiguration.

That said, your 128M may be too high, depending on your pm.max_children and machine memory.

MC to you too.

• This reply was modified 5 months, 2 weeks ago by docjojo.

Hard for me to tell what is going on.
What you show is only JS debug info.
You can disable the debug info in the settings.

404 would be a browser not showing the page – that’s a different story.
Maybe post your URL so i can check.

Did you ever hide the msg by clicking the X on the right?

Please download latest version and let me know.