-
Notifications
You must be signed in to change notification settings - Fork 6
Description
Hi, thank you for creating this plugin! It's really well written and easy to understand.
I was wondering if you'd be open to a PR that would allow it to be used on cached websites. Currently, it may leak PII data and ecommerce cart/order content on pages with public cache.
I've been thinking about ways to tackle this issue:
-
Simple approach: Disable the code that outputs user-specific data on pages that can be cached. This could be determined by a user-defined filter and is easy to implement.
-
Advanced approach: Ensure customer data never goes into the HTML. This is harder to implement correctly.
Let me dive into the details of the second approach, as the first seems self-explanatory.
I've identified 4 ways where dynamic data may be cached:
- One-off events triggered by cookies (user registration/login, purchases)
- One-off events on dynamic pages (begin checkout)
- Cart operations (currently
add-to-cart,view-cart) - Always-present data like
user_data(if enabled in settings)
1. Cookie-triggered events
While using cookies to trigger events is a good idea, I would avoid outputting this data in the footer since we can't guarantee it won't be cached. In most cases it will be fine, but I can easily imagine someone making a purchase, paying, and never returning to the thank you page. If they open the home page later just to check something, and we're unlucky, the order data could end up cached in the home page footer.
Instead of using wp_footer to output this code, we should create an AJAX endpoint that JavaScript consumes when it detects the cookie. This JS could be generic, listening for cookie changes and deleting cookies after use.
2. One-off events on dynamic pages
I think we can keep the code as is for these.
3. Cart operations
This is tricky as it's theme-dependent. I suggest providing users with tools to integrate this into their theme in a cache-aware and theme-specific way. In my case, add-to-cart seems okay, and Shoptimizer saves the cart in local storage, so I could use that to trigger events browser-side.
4. Always-present data
I don't see a good way to address this without either:
- Storing data in local storage (not GDPR compliant)
- Creating an endpoint consumed by ssGTM (might slow down the website if it triggers the WP stack)
So I would disable this feature on cached websites.
Let me know what you think and whether you'd be willing to accept a PR to address this.
P.S. Could we also remove the jQuery dependency? I'm moving towards a jQuery-free frontend, and many current plugins are trying to avoid it as well.