WARNING* This plugin breaks functionality for wordpress editors after EVERY scan

  • Resolved neodan

    (@neodan)


    4 months, 2 weeks ago

    I want to highlight a critical issue with the CookieYes plugin for WordPress that could seriously undermine your site’s compliance efforts and documentation. Every time you run a new cookie scan, CookieYes completely overwrites your existing cookie list with only the cookies discovered in that specific scan. This means any cookies you manually added—such as those set for logged-in users, WordPress admins, or added via page builders and plugins—are instantly wiped out if the scanner doesn’t detect them during that session. There is no warning before this happens and no built-in way to merge, import, or bulk re-add cookies after a scan.

    For websites hosted on WPEngine or similar providers with a CDN, or for sites built with a pagebuilder, this isn’t just a compliance risk—it’s a major operational threat. Running a CookieYes scan can instantly remove cookies that are essential for site stability, login access, and backend management. One automated scan can break your admin workflows or even your staging environment. If we had known this limitation before purchasing, we would have never chosen CookieYes. This is a serious issue that needs urgent attention!

    You lose the ability to reliably track cookies that aren’t visible to guest users or the scanner, making it nearly impossible to maintain a complete, compliant record without painstaking manual work after every scan. Other cookie compliance tools like Complianz and OneTrust do preserve manual cookie entries, but CookieYes currently offers no such protection. If you rely on manual entries for compliance, be extremely cautious—a single scan can erase hours of work and break website functionality.

    We set the scan frequency for weekly. After the scan ALL cookies were wiped that we manually added. Why does CookieYes assume those cookies are no longer required? We manually added and labeled several necessary cookies that are critical for operating our website and managing updates. These included:

    1. A load balancing cookie set by AWS, directing traffic to healthy backend instances.
    2. A cookie that maintains login authentication for WPEngine staging and development sites.
    3. A cookie similar to AWSALB but dedicated to ensuring CORS requests are routed properly.
    4. A security cookie for logged-in WordPress users.

      Every one of these cookies is vital for functionality, yet all were deleted from our CookieYes cookie manager after running a scan. This is not just an inconvenience—it’s a direct threat to maintaining compliance and operational stability.

      Luckily we have accurate documentation and we were able to manually add in the cookies that are necessary from a webhosting and wordpress perspective. CookieYes does not have ability to mass import cookies back! OneTrust keeps manual cookies; supports manual import/export and merge. This is not on the roadmap for CookieYes at the time of writing this post.

      In the dashboard there is a banner that says “We continuously monitor our scanning software to ensure its ongoing effectiveness, security, and accuracy. However, we advise you to run a quick manual check to determine if there are any cookies on your site that our scanner couldn’t detect. Instructions on how to check cookies on your website manually.”

      CookieYes tries to cover themselves with a warning telling users to “run a quick manual check” for any cookies the scanner couldn’t detect. But this advice is honestly unrealistic for any real-world website. Manual checks are not a viable solution—there is no practical way to catch every cookie across every user type, page, and scenario. Critical cookies for admins, editors, staging environments, or complex integrations simply won’t appear in a guest session scan. Expecting site owners to manually re-add these every time is unrealistic, especially for large or enterprise sites. This is not just an inconvenience—it’s a design flaw that puts sites at risk and undermines the entire purpose of automated compliance tools. The whole point of a cookie scanner is to avoid this manual, error-prone work—not force it on users after every scan!
    • This topic was modified 4 months, 2 weeks ago by neodan.
    • This topic was modified 4 months, 2 weeks ago by neodan.
Viewing 2 replies - 1 through 2 (of 2 total)
  • Thread Starter neodan

    (@neodan)

    4 months, 2 weeks ago

    Nevermind tthe issue was copying configuration from staging to main site. It copies the banner configuration not the cookie manager configuration as well.

    Plugin Support Nick

    (@nickcysupport)

    4 months, 2 weeks ago

    Hi there,

    Thanks for raising this concern and for sharing the details of your experience.

    To clarify, the plugin does not delete cookies that are manually added to your cookie list. Those entries will remain unless you remove them yourself.

    The issue you experienced may be related to cookies that are temporary or not present on the website at the time of the scan. If a cookie is not active during the scan session, it won’t be detected and therefore will not appear in the automatically discovered list.

    However, if you want to ensure that a specific cookie remains in your list even when it isn’t detected in a scan, the best approach is:

    1. Add the cookie manually in the cookie list from the Cookie Manager section of your account.
    2. Delete the auto-detected entry for that cookie (if present) from the cookie list.

    Manually added cookies in the cookie list of your account will not be overriden or rewritten by future scans, even if they are not active on the site at that time.

    If you’d like us to look into this more closely for your specific setup, you’re welcome to share your site URL here in the thread if you’re comfortable doing so, and we can check what happened. Alternatively, if you’d prefer to keep it private, you can reach out to us here.

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

You must be logged in to reply to this topic.