• Resolved boxhamster

    (@boxhamster)


    Hi there,
    I saw your post about the plugin on Reddit the other day and thought I’d give it a try.
    I’m just setting it up and noticed that after the scan and then using the auto-categorisation, the cookies are indeed divvied up by type, but the counters on the categories on the left do not update. See below screenshot:
    https://ibb.co/PGDQpJwn

    Thanks for a great plugin.

Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Author fabiodalez

    (@fabiodalez)

    Thanks for the screenshot — that detail (cookies are in the right categories but the left-side counters do not refresh) made the bug locatable without needing access to your install.

    What I found. In 1.13.16 the plugin listened for cache invalidation only on the legacy faz_after_update_cookie hook. When the scanner discovers new cookies it fires faz_after_create_cookie, and that hook had no subscribers in the released build. The result is the bug you are seeing: the per-category cookie list embedded in the GET /cookies/categories response is read from a cache that nothing invalidated when the scanner created the rows, so the counters on the left keep showing the pre-scan totals even though the DB underneath has the new cookies in the right category. The fact that you have LiteSpeed Cache plus its object cache made it more visible because the stale entry can be served for longer than on a stock install, but the root cause is in the plugin, not in LiteSpeed.

    What is fixed in 1.13.17. The full lifecycle of cookie mutations (create, update, delete, plus the same for categories) now invalidates every consumer that depends on the cookie list: the Category controller cache, the Cookie controller cache, the banner template option cache, the IAB unmatched-vendors transient, and the page-cache adapters for LiteSpeed, WP Rocket, W3 Total Cache, WP Fastest Cache, WP Super Cache, Autoptimize, Hummingbird, Breeze, Cache Enabler, and SiteGround Optimize. I added a regression test that creates a cookie via REST and asserts the next GET /cookies/categories reports the new count — so this specific bug now has a permanent guard against it coming back.

    What you need to do. Update to 1.13.17 and then purge LiteSpeed Cache once (LSCache > Toolbox > Purge All), which is the same step you already know from the other thread. The object-cache flush is not strictly required after the update because the plugin now rotates its own cache prefixes on every cookie write, but it does not hurt either. After that, a fresh scan plus auto-categorisation should give you accurate counters on the left immediately.

    Best,
    Fabio

    Plugin Author fabiodalez

    (@fabiodalez)

    Quick follow-up: version 1.13.17 is out now on wordpress.org and it carries the fix for the category counters.

    After updating, every time the scanner discovers a new cookie, or you create, edit, or delete one by hand, the counters on the left side will refresh right away. Same goes for renaming or deleting a category. I also added a regression test that simulates exactly what you reported, so this specific bug now has a permanent guard against coming back in future versions.

    After update I would recommend purging LiteSpeed Cache once so the new behaviour reaches your site immediately. The object cache flush is not strictly required, but does not hurt.

    Once the update is in, a fresh scan plus auto-categorisation should show the correct numbers on the left straight away.

Viewing 2 replies - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.