Fix conflict with the YesCookie plugin

[superdav42]

Summary by CodeRabbit

• Bug Fixes
  • Improved checkout template handling to prevent unintended resets during order creation and checkout loading processes. Templates now remain stable when empty or undefined values would previously have overwritten existing settings.

[coderabbitai]

Walkthrough

Two event handlers in the checkout module now include conditional checks to prevent assigning undefined or falsy values to checkout.template_id, ensuring the template ID is only set when valid data is present.

Changes

Cohort / File(s)	Summary
Template ID Assignment Guards assets/js/checkout.js	Added conditional checks in wu_on_create_order and wu_checkout_loaded handlers to verify template_id values are truthy before assignment, preventing inadvertent clearing or invalid state updates.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 A guardian rabbit, swift and keen,
Guards templates from the space between,
No falsy values shall pass through,
Only truthy assignments stay true! ✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The pull request title "Fix conflict with the YesCookie plugin" is clearly related to the main change in the changeset. The branch name "fix-cookie-yes" corroborates this focus on YesCookie plugin compatibility. The actual changes involve adding defensive conditional checks to the checkout.js file to prevent template_id from being overwritten with undefined or falsy values, which is a reasonable fix for addressing plugin conflicts in cookie handling. The title accurately summarizes the intent at a high level without being vague or generic, and a teammate reviewing the history would understand this addresses a YesCookie plugin issue.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix-cookie-yes

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1f3606a and 422044a.

📒 Files selected for processing (1)

• assets/js/checkout.js (2 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: cypress (8.2, chrome)
• GitHub Check: cypress (8.1, chrome)

🔇 Additional comments (1)

assets/js/checkout.js (1)

18-22: Good defensive check to prevent invalid template_id assignment.

The expanded conditional ensures that checkout.template_id is only set when a valid, truthy value exists in data.order.extra.template_id. This prevents corruption from undefined or empty values that might arise from cookie consent plugins interfering with data flow.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Proper safeguard against cookie clearing by consent plugins.

The truthy check prevents the template_id from being overwritten when the wu_template cookie is cleared or set to an empty value, which can happen when cookie consent plugins like YesCookie modify cookies. This ensures the checkout state remains consistent.

Please confirm that this resolves the YesCookie plugin conflict by testing the checkout flow with the YesCookie plugin active, particularly:

• Initial page load with cookie consent banner
• Accepting/rejecting cookies
• Navigating through checkout steps

You can verify the template_id remains stable by checking the Vue instance state:

---

🏁 Script executed:

#!/bin/bash
# Search for any other cookie-related template_id assignments that might need similar guards
rg -n -C3 'template_id\s*=' --type=js -g '!node_modules' -g '!dist' -g '!build'

Length of output: 14111

---

Apply same cookie clearing guard to assets/js/template-switching.js for consistency.

The PR correctly adds a truthy check in checkout.js line 72, but assets/js/template-switching.js line 19 contains an identical cookie listener pattern without the same protection. Both listen to the wu_template cookie and both assign to template_id. This inconsistency means the YesCookie plugin conflict is only partially resolved.

Update assets/js/template-switching.js line 17-21:

wu_listen_to_cookie_change('wu_template', function(value) {
    if (value) {
        window.wu_template_switching.template_id = value;
    }
});

🤖 Prompt for AI Agents

In assets/js/template-switching.js around lines 17 to 21, the cookie listener
assigns wu_template directly to window.wu_template_switching.template_id without
a truthy guard; update the listener to check if value is truthy before assigning
(i.e., wrap the assignment in if (value) {
window.wu_template_switching.template_id = value; }) so it matches the guard
added in assets/js/checkout.js and avoids YesCookie plugin conflicts.