Changed reset link URL from admin SPA to customer-spa:
- Old: /wp-admin/admin.php?page=woonoow#/reset-password?key=...
- New: /my-account#/reset-password?key=...
This fixes the login redirect issue - the customer-spa is publicly
accessible so users can reset their password without logging in first.
Added:
- customer-spa/src/pages/ResetPassword/index.tsx
- Route /reset-password in customer-spa App.tsx
EmailManager.php now:
- Uses wc_get_page_id('myaccount') to get my-account page URL
- Falls back to home_url if my-account page not found
- Created ResetPassword.tsx with:
- Password reset form with strength indicator
- Key validation on load
- Show/hide password toggle
- Success/error states
- Redirect to login on success
- Updated EmailManager.php:
- Changed reset_link from wp-login.php to SPA route
- Format: /wp-admin/admin.php?page=woonoow#/reset-password?key=KEY&login=LOGIN
- Added AuthController API methods:
- validate_reset_key: Validates reset key before showing form
- reset_password: Performs actual password reset
- Registered new REST routes in Routes.php:
- POST /auth/validate-reset-key
- POST /auth/reset-password
Password reset emails now link to the SPA instead of native WordPress.
OLD BEHAVIOR (broken):
parse_cards processed ALL [card:type] syntax FIRST, then [card type=...]
This caused cards to render out of order when syntaxes were mixed.
NEW BEHAVIOR (fixed):
Using a unified regex that matches BOTH syntaxes simultaneously:
/\[card(?::(\w+)|([^\]]*)?)\](.*?)\[\/card\]/s
Each match includes:
- Group 1: Card type from new syntax [card:type]
- Group 2: Attributes from old syntax [card type='...']
- Group 3: Card content
Cards now render in exact document order regardless of syntax used.
parseCardsForPreview was forcing text-align: center on all buttons
regardless of user alignment choice. Removed the hardcoded style
so buttons follow natural document flow alignment.
Added getAttrs functions to parseHTML in tiptap-button-extension.ts.
Now properly extracts text/href/style from DOM elements:
- data-button: extracts from data-text, data-href, data-style
- a.button: extracts text/href, defaults to solid style
- a.button-outline: extracts text/href, defaults to outline style
This fixes the issue where buttons appeared unstyled (outline
instead of solid) when editing a card that contained buttons.
Added data-button attribute selector to TipTap button parseHTML.
This ensures buttons are properly detected when text alignment is
applied, as alignment may affect CSS class detection.
Priority order:
1. a[data-button] - most reliable
2. a.button
3. a.button-outline
ROOT CAUSE:
When saving card edit in EmailBuilder, htmlToMarkdown() was called.
The old code at line 26 converted ALL <a> tags to markdown links:
<a href="url">text</a> → [text](url)
This lost TipTap button data-button attributes, converting buttons
to plain text instead of [button:style](url)Text[/button] shortcode.
FIX:
Added TipTap button detection BEFORE generic link conversion in
html-to-markdown.ts:
- Detects <a data-button...> elements
- Extracts style from data-style or class attribute
- Extracts URL from data-href or href attribute
- Converts to [button:style](url)Text[/button] format
FLOW NOW WORKS:
1. User adds button via TipTap toolbar
2. TipTap renders <a data-button data-style="solid"...>
3. User clicks Save Changes
4. htmlToMarkdown detects data-button → [button:solid](url)Text[/button]
5. Card content saved with proper button shortcode
6. On re-edit, button shortcode converted back to TipTap button
ROOT CAUSE:
Frontend blocksToMarkdown outputs NEW syntax:
- [card:type]...[/card]
- [button:style](url)Text[/button]
But backend EmailRenderer.php only had regex for OLD syntax:
- [card type="..."]...[/card]
- [button url="..."]Text[/button]
FIXES:
1. parse_cards() now handles BOTH syntaxes:
- NEW [card:type] regex first (extracts type from :type)
- OLD [card type="..."] regex for backward compatibility
2. render_card() now handles BOTH button syntaxes:
- NEW [button:style](url)Text[/button] regex
- OLD [button url="..."] regex for backward compatibility
3. Card types properly styled with inline CSS:
- hero: gradient background
- success: green background + border
- info: blue background + border
- warning: yellow background + orange border
4. Buttons rendered with full inline styles + table wrapper
for Gmail/email client compatibility
Button modals in both RichTextEditor and EmailBuilder filtered
for _url variables only, excluding reset_link. Updated filter to
include both _url and _link patterns.
Files changed:
- rich-text-editor.tsx line 415
- EmailBuilder.tsx line 359
ROOT CAUSE (from screenshot DevTools):
href="<span style=...>[login_url]</span>" - HTML span inside href attribute!
Flow causing the bug:
1. parseCardsForPreview converts [button url="{login_url}"] to <a href="{login_url}">
2. sampleData replacement runs but login_url NOT in sampleData
3. Variable highlighting injects <span>[login_url]</span> INTO href="..."
4. HTML is completely broken
FIXES APPLIED:
1. Added missing URL variables to sampleData:
- login_url, reset_link, reset_key
- user_login, user_email, user_temp_password
- customer_first_name, customer_last_name
2. Changed variable highlighting from HTML spans to plain text [variable]
- Prevents breaking HTML attributes if variable is inside href, src, etc.
ROOT CAUSE: Complete flow trace revealed syntax mismatch:
- blocksToMarkdown outputs NEW syntax: [card:type], [button:style](url)Text[/button]
- markdownToBlocks ONLY parsed OLD syntax: [card type="..."], [button url="..."]
This caused buttons/cards to be lost when:
1. User adds button in Visual mode
2. blocksToMarkdown converts to [button:solid]({url})Text[/button]
3. handleBlocksChange stores this in markdownContent
4. When switching tabs/previewing, markdownToBlocks runs
5. It FAILED to parse new syntax, buttons disappear!
FIX: Added handlers for NEW syntax in markdownToBlocks (converter.ts):
- [card:type]...[/card] pattern (before old syntax)
- [button:style](url)Text[/button] pattern (before old syntax)
Now both syntaxes work correctly in round-trip conversion.
Root cause: parseCardsForPreview was called TWICE in generatePreviewHTML:
1. Line 179 - correctly parses markdown to HTML including buttons
2. Line 283 - redundantly called AGAIN after variable highlighting
After first call, variable highlighting (lines 275-280) replaced unknown
variables like {login_url} with <span>[login_url]</span>. When the second
parseCardsForPreview ran, the [login_url] text was misinterpreted as
shortcode syntax, corrupting button HTML output.
Fix: Remove the redundant second call to parseCardsForPreview at line 283.
The function is already called at line 179 before any variable replacement.
- Added multiple htmlToMarkdown patterns for TipTap button output:
1. data-button with data-href/data-style attributes
2. Alternate attribute order (data-style before data-href)
3. Simple data-button fallback with href and class
4. Buttons wrapped in p tags (from preview HTML)
5. Direct button links without p wrapper
- Button shortcodes now correctly roundtrip:
RichEditor -> HTML -> [button url=... style=...] -> Preview/Email
- All patterns now explicitly include style=solid for consistency
1. API Route Fix (NotificationsController.php):
- Changed PUT to POST for /templates/:eventId/:channelId
- Frontend was using api.post() but backend only accepted PUT
- Templates can now be saved
2. Contextual Variables (EventRegistry.php):
- Added get_variables_for_event() method
- Returns category-based variables (order, customer, product, etc.)
- Merges event-specific variables from event definition
- Sorted alphabetically for easy browsing
3. API Response (NotificationsController.php):
- Template API now returns available_variables for the event
- Frontend can show only relevant variables
4. Frontend (EditTemplate.tsx):
- Removed hardcoded 50+ variable list
- Now uses template.available_variables from API
- Variables update based on selected event type
1. Auto-login after checkout:
- Added wp_set_auth_cookie() and wp_set_current_user() in CheckoutController
- Auto-registered users are now logged in when thank-you page loads
2. ThankYou page guest buttons:
- Added 'Login / Create Account' button for guests
- Shows for both receipt and basic templates
- No more dead-end after placing order as guest
3. Forgot password flow:
- Created ForgotPassword page component (/forgot-password route)
- Added forgot_password API endpoint in AuthController
- Uses WordPress retrieve_password() for reset email
- Replaced wp-login.php link in Login page
Changed Checkout page order success handling:
- Before: SPA navigate() to thank-you page (cookies not refreshed)
- After: window.location.href + reload (cookies refreshed)
This ensures guests who are auto-registered during checkout
get their auth cookies properly set after order placement.
1. ThankYou page - Go to Account button:
- Added for logged-in users (next to Continue Shopping)
- Shows in both receipt and basic templates
- Uses outline variant with User icon
2. Wishlist merge on login:
- Reads guest wishlist from localStorage (woonoow_guest_wishlist)
- POSTs each product to /account/wishlist API
- Handles duplicates gracefully (skips on error)
- Clears localStorage after successful merge
1. Logout flow:
- Added confirmation dialog (window.confirm)
- Changed to API-based logout (/auth/logout)
- Full page reload after logout to clear cookies
- Added loading state during logout
2. Login flow (already correct):
- Uses window.location.href for full page redirect
- Redirects to /store/#/my-account after login
1. Temp password for auto-registered users:
- Store password in _woonoow_temp_password user meta (CheckoutController)
- Add {user_temp_password} and {login_url} variables (EmailRenderer)
- Update new_customer email template to show credentials
2. WC page redirects to SPA routes:
- Added redirect_wc_pages_to_spa() in TemplateOverride
- Maps: /shop → /store/#/, /cart → /store/#/cart, etc.
- /checkout → /store/#/checkout, /my-account → /store/#/account
- Single products → /store/#/products/{slug}
3. Removed shortcode system:
- Commented out Shortcodes::init() in Bootstrap
- WC pages now redirect to SPA instead
1. Added missing base variables in get_variables():
- site_name, site_title, store_name
- shop_url, my_account_url
- support_email, current_year
2. Fixed social icon URL path calculation:
- Was using 3x dirname which pointed to 'includes/' not plugin root
- Now uses WOONOOW_URL constant or correct 4x dirname
3. Added px-6 padding to EmailBuilder dialog body
4. Added portal container to Select component for CSS scoping
1. Dialog Portal: Render inside #woonoow-admin-app container instead
of document.body to fix Tailwind CSS scoping in WordPress admin
2. Variables Panel: Redesigned from flat list to collapsible accordion
- Collapsed by default (less visual noise)
- Categorized: Order (blue), Customer (green), Shipping (orange), Store (purple)
- Color-coded pills for quick recognition
- Shows count of available variables
3. StarterKit: Disable built-in Link to prevent duplicate extension warning
The RichTextEditor useEffect was comparing raw content with editor HTML,
but they differed due to whitespace normalization (e.g., '\n\n' vs '').
This caused continuous setContent calls, freezing the edit dialog.
Fixed by normalizing whitespace in both strings before comparison.
StarterKit 3.10+ now includes Link by default. Our code was adding
Link.configure() separately, causing duplicate extension warning and
breaking the email builder visual editor modal.
Fixed by configuring StarterKit with { link: false } so our custom
Link.configure() with specific options is the only Link extension.
1. EmailBuilder: Fixed dialog handlers to not block all interactions
- Previously dialog prevented all outside clicks
- Now only blocks when WP media modal is open
- Dialog can be properly closed via escape or outside click
2. DefaultTemplates: Updated new_customer email
- Added note about using 'Forgot Password?' if link expires
- Clear instructions for users
1. EmailRenderer: Added button parsing with full inline styles
- Buttons now use table-based layout for email client compatibility
- Solid and outline button styles with custom colors from settings
2. DefaultTemplates: Updated new_customer template
- Added 'Set Your Password' button for auto-registered users
- Uses {set_password_url} variable for password reset link
3. EmailRenderer: Added set_password_url variable
- Generates secure password reset link for new customers
- Also added my_account_url and shop_url to customer variables
- BaseLayout.tsx: Updated 4 guest account links
- Wishlist.tsx: Updated guest wishlist login link
- All now use Link to /login instead of href to /wp-login.php
- Created Login/index.tsx with styled form
- Added /auth/customer-login API endpoint (no admin perms required)
- Registered route in Routes.php
- Added /login route in customer-spa App.tsx
- Account page now redirects to SPA login instead of wp-login.php
- Login supports redirect param for post-login navigation
1. Remove wishlist setting from customer settings (now in module toggle)
- Removed from CustomerSettingsProvider.php
- Removed from Customers.tsx
2. Remove auto-login from REST API (causes cookie issues)
- Auto-login in REST context doesn't properly set browser cookies
- Removed wp_set_current_user/wp_set_auth_cookie calls
3. Fix cart not clearing after order
- Added WC()->cart->empty_cart() after successful order
- Server-side cart was not being cleared, causing re-population
- Frontend clears local store but Cart page syncs with server
- Use clearCart() from store instead of iterating removeItem()
- Iteration could fail as items are removed during loop
- clearCart() resets cart to initial state atomically
- After creating new user account, immediately log them in
- Uses wp_set_current_user() and wp_set_auth_cookie()
- Provides smoother UX - customer is logged in after placing order
- Shop page and other customer pages need to read module settings
- Settings are non-sensitive configuration values (e.g. wishlist display)
- POST endpoint remains admin-only for security
- Fixes 401 errors on shop page for /modules/wishlist/settings
- When 'Auto-register customers as site members' is enabled
- Creates WP user account with 'customer' role for guest checkouts
- Links order to existing user if email already registered
- Sets WooCommerce customer billing data on new account
- Triggers woocommerce_created_customer action for email notification
- Add public /checkout/order/{id} endpoint with order_key validation
- Update checkout redirect to include order_key parameter
- Update ThankYou page to use new public endpoint with key
- Support both guest (via key) and logged-in (via customer_id) access
- Add Campaigns list page with table, status badges, search, actions
- Add Campaign editor with title, subject, content fields
- Add preview modal, test email dialog, send confirmation
- Update Marketing index to show hub with Newsletter, Campaigns, Coupons cards
- Add routes in App.tsx
- Remove inline submenu expansion for Marketing
- Keep it consistent with Appearance and Settings (simple buttons)
- Description provides enough context about what's inside
- Add Marketing section to More page with Newsletter and Coupons submenu
- Remove standalone Coupons entry (now under Marketing)
- Add submenu rendering support for items with children
- Use Megaphone icon for Marketing section
- Module 1 (Module Management): Changed from Planning to Built
- Added Module Management to 'Already Built' section
- Marked Product Reviews as not yet implemented
- Updated last modified date
Implements direct-to-cart functionality for landing page CTAs.
Features:
- Parse URL parameters: ?add-to-cart=123
- Support simple products: ?add-to-cart=123
- Support variable products: ?add-to-cart=123&variation_id=456
- Support quantity: ?add-to-cart=123&quantity=2
- Auto-navigate to cart after adding
- Clean URL after adding (remove parameters)
- Toast notification on success/error
Usage examples:
1. Simple product:
https://site.com/store?add-to-cart=332
2. Variable product:
https://site.com/store?add-to-cart=332&variation_id=456
3. With quantity:
https://site.com/store?add-to-cart=332&quantity=3
Flow:
- User clicks CTA on landing page
- Redirects to SPA with add-to-cart parameter
- SPA loads, hook detects parameter
- Adds product to cart via API
- Navigates to cart page
- Shows success toast
Works with both SPA modes:
- Full SPA: loads shop, adds to cart, navigates to cart
- Checkout Only: loads cart, adds to cart, stays on cart
User feedback: 'SPA means Single Page, why 4 pages?'
Correct architecture:
- 1 SPA entry page (e.g., /store)
- SPA Mode determines initial route:
* Full SPA → starts at shop page
* Checkout Only → starts at cart page
* Disabled → never loads
- React Router handles rest via /#/ routing
Changes:
- Admin UI: Changed from 4 page selectors to 1 SPA entry page
- Backend: spa_pages array → spa_page integer
- Template: Initial route based on spa_mode setting
- Simplified is_spa_page() checks (single ID comparison)
Benefits:
- User can set /store as homepage (Settings → Reading)
- Landing page → CTA → direct to cart/checkout
- Clean single entry point
- Mode controls behavior, not multiple pages
Example flow:
- Visit https://site.com/store
- Full SPA: loads shop, navigate via /#/product/123
- Checkout Only: loads cart, navigate via /#/checkout
- Homepage: set /store as homepage, SPA loads on site root
Next: Add direct-to-cart CTA with product parameter
Complete WooCommerce-style page architecture implementation:
Backend (already committed):
- API endpoint to fetch WordPress pages
- spa_pages field in appearance settings
- is_spa_page() checks in TemplateOverride and Assets
Frontend (this commit):
- Added page selector UI in Appearance > General
- Dropdowns for Shop, Cart, Checkout, Account pages
- Loads available WordPress pages from API
- Saves selected page IDs to settings
- Info alert explaining full-body rendering
UI Features:
- Clean page selection interface
- Shows all published WordPress pages
- '— None —' option to disable
- Integrated into existing General settings tab
- Follows existing design patterns
How it works:
1. Admin selects pages in Appearance > General
2. Page IDs saved to woonoow_appearance_settings
3. Frontend checks if current page matches selected pages
4. If match, renders full SPA to body (no theme interference)
5. Works with ANY theme consistently
Next: Test page selection and verify clean SPA rendering
