Forum Replies Created

Viewing 15 replies - 1 through 15 (of 633 total)
  • Plugin Author docjojo

    (@docjojo)

    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.

    Plugin Author docjojo

    (@docjojo)

    Thank you, already fixed.
    Will be available with next update.

    Plugin Author docjojo

    (@docjojo)

    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

    Plugin Author docjojo

    (@docjojo)

    Glad to hear, thank you!

    Plugin Author docjojo

    (@docjojo)

    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 4 months ago by docjojo.
    Plugin Author docjojo

    (@docjojo)

    opcache.memory_consumption

    You do not specify units in the config; PHP assumes MB by default for this directive.
    So try changing to opcache.memory_consumption=512M

    However v1.8.31 has a parser to even except values with a unit – so please update.

    Fragmentation:

    “APCu doesn’t provide a standard fragmentation metric. Any percentage would be an approximation and different tools calculate it differently, which tends to confuse more than it helps. For that reason I’m not planning to display a fragmentation %.”

    Plugin Author docjojo

    (@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.

    Plugin Author docjojo

    (@docjojo)

    what do you mean by “post cannot be found” ?

    404 ?
    does a cache entry exist for the post id?

    Need more info, context and maybe a screenshot to understand.

    https://screen2.link/

    Plugin Author docjojo

    (@docjojo)

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

    Please download latest version and let me know.

    Plugin Author docjojo

    (@docjojo)

    Thank you for your feedback.

    1.

    This should only happen when you save settings. So it should be rare.
    As the plugin can’t tell what has changed on your system, the check runs on every save on/off this is to prevent accidentally deleting/overwriting existing page cache.

    2.

    Very good, you are right.
    Will be changed on next update.

    3.

    For memory the threshold is 50% so as long as your usage is >50% you will get the hint.

    4.

    Difficult to say without context, but you can try:

    opcache.use_cwd=0
    opcache.revalidate_path=0

    If your memory usage is above 75%, increase opcache.memory_consumption

    Your opcache.jit_buffer_size is much too high!
    8 or even 1 MB will probably be enough (check usage) – or disable JIT, as WP will almost not benefit from JIT at all.

    Plugin Author docjojo

    (@docjojo)

    Great to hear that, thank you!

    Forum: Plugins
    In reply to: [atec Backup] Clean up
    Plugin Author docjojo

    (@docjojo)

    Hello,
    it deletes any backup that is older than 30 days.

    I can add “14” – but DB backups are usually small so rather not be so detailed.

    Plugin Author docjojo

    (@docjojo)

    Also i can remove the data stored, if you provide the first digits block of your IP.

    Plugin Author docjojo

    (@docjojo)

    Thank you for the report.
    I found the issue and fixed it in the new version.
    However there is only and integrity check on activation, no further data is being sent during use.

    Anything else i can help with?

    Also, could you turn this into a support request not a review, please?

    Plugin Author docjojo

    (@docjojo)

    Can you provide your site name?

    Install atec-debug and check for errors?

Viewing 15 replies - 1 through 15 (of 633 total)