Files
WooNooW/BACKEND_INTEGRATION_NEEDED.md
dwindown 4471cd600f feat: Complete markdown syntax refinement and variable protection
 New cleaner syntax implemented:
- [card:type] instead of [card type='type']
- [button:style](url)Text[/button] instead of [button url='...' style='...']
- Standard markdown images: ![alt](url)

 Variable protection from markdown parsing:
- Variables with underscores (e.g., {order_items_table}) now protected
- HTML comment placeholders prevent italic/bold parsing
- All variables render correctly in preview

 Button rendering fixes:
- Buttons work in Visual mode inside cards
- Buttons work in Preview mode
- Button clicks prevented in visual editor
- Proper styling for solid and outline buttons

 Backward compatibility:
- Old syntax still supported
- No breaking changes

 Bug fixes:
- Fixed order_item_table → order_items_table naming
- Fixed button regex to match across newlines
- Added button/image parsing to parseMarkdownBasics
- Prevented button clicks on .button and .button-outline classes

📚 Documentation:
- NEW_MARKDOWN_SYNTAX.md - Complete user guide
- MARKDOWN_SYNTAX_AND_VARIABLES.md - Technical analysis
2025-11-15 20:05:50 +07:00

7.8 KiB

⚠️ Backend Integration Required

Issues Found

Issue #1: Incorrect Template Count in UI

Problem: The Staff Notifications page shows "9 templates" but there are only 7 staff events.

Location: admin-spa/src/routes/Settings/Notifications/Templates.tsx line 132

Current Code:

<Badge variant="secondary" className="text-xs">
  {allEvents.length} {__('templates')}  // ❌ Shows ALL events (customer + staff)
</Badge>

Root Cause:

  • allEvents combines ALL event types (orders, products, customers)
  • It doesn't filter by recipient type (staff vs customer)
  • Shows same count for both customer and staff pages

Expected:

  • Customer page: Should show 9 templates (customer events only)
  • Staff page: Should show 7 templates (staff events only)

Solution Needed: The backend API /notifications/events needs to return events grouped by recipient type, OR the frontend needs to filter events based on the current page (staff/customer).


Issue #2: Old Templates Still Being Used

Problem: After reloading multiple times, the email templates shown in the editor are still using the OLD format, not the new improved markdown templates.

Current State:

  • New templates exist: includes/Email/DefaultTemplates.php
  • Backend still using: includes/Core/Notifications/DefaultEmailTemplates.php

Evidence: The old DefaultEmailTemplates.php uses HTML-heavy syntax:

'body' => '[card type="hero"]
<h1>' . __('New Order Received!', 'woonoow') . '</h1>
<p>' . __('You have received a new order...', 'woonoow') . '</p>
[/card]'

The new DefaultTemplates.php uses clean markdown:

return '[card type="hero"]

New order received!

A customer has placed a new order. Please review and process.
[/card]'

Root Cause: The backend API controller is still calling the old DefaultEmailTemplates class instead of the new DefaultTemplates class.


Required Backend Changes

1. Update Default Templates Integration

Option A: Replace Old Class (Recommended)

Replace includes/Core/Notifications/DefaultEmailTemplates.php with a wrapper that uses the new class:

<?php
namespace WooNooW\Core\Notifications;

use WooNooW\Email\DefaultTemplates as NewDefaultTemplates;

class DefaultEmailTemplates {
    
    public static function get_template($event_id, $recipient_type) {
        // Map event IDs to new template structure
        $eventMap = [
            'order_placed' => 'order_placed',
            'order_processing' => 'order_confirmed',
            'order_completed' => 'order_completed',
            'order_cancelled' => 'order_cancelled',
            'order_refunded' => 'order_cancelled', // Map to cancelled for now
            'low_stock' => 'order_placed', // Placeholder
            'out_of_stock' => 'order_placed', // Placeholder
            'new_customer' => 'customer_registered',
            'customer_note' => 'order_placed', // Placeholder
        ];
        
        $newEventId = $eventMap[$event_id] ?? $event_id;
        
        // Get templates from new class
        $allTemplates = NewDefaultTemplates::get_all_templates();
        $templates = $allTemplates[$recipient_type] ?? [];
        
        if (isset($templates[$newEventId])) {
            return [
                'subject' => NewDefaultTemplates::get_default_subject($recipient_type, $newEventId),
                'body' => $templates[$newEventId],
            ];
        }
        
        // Fallback
        return [
            'subject' => __('Notification from {store_name}', 'woonoow'),
            'body' => '[card]New notification[/card]',
        ];
    }
}

Option B: Update API Controller Directly

Update the API controller to use the new DefaultTemplates class:

use WooNooW\Email\DefaultTemplates;

// In the get_template endpoint:
$templates = DefaultTemplates::get_all_templates();
$subject = DefaultTemplates::get_default_subject($recipient_type, $event_id);
$body = $templates[$recipient_type][$event_id] ?? '';

2. Fix Event Counts in API

Update: includes/Api/NotificationsController.php

The /notifications/events endpoint should return events with recipient type information:

public function get_events($request) {
    $events = [
        'orders' => [
            [
                'id' => 'order_placed',
                'label' => __('Order Placed'),
                'description' => __('When a new order is placed'),
                'recipients' => ['customer', 'staff'], // ← Add this
            ],
            [
                'id' => 'order_confirmed',
                'label' => __('Order Confirmed'),
                'description' => __('When order is confirmed'),
                'recipients' => ['customer', 'staff'], // ← Add this
            ],
            // ... etc
        ],
        'customers' => [
            [
                'id' => 'customer_registered',
                'label' => __('Customer Registered'),
                'description' => __('When customer creates account'),
                'recipients' => ['customer'], // ← Customer only
            ],
            [
                'id' => 'customer_vip_upgraded',
                'label' => __('VIP Upgraded'),
                'description' => __('When customer becomes VIP'),
                'recipients' => ['customer'], // ← Customer only
            ],
        ],
    ];
    
    return rest_ensure_response($events);
}

3. Update Frontend to Filter Events

Update: admin-spa/src/routes/Settings/Notifications/Templates.tsx

// Determine recipient type from current page
const isStaffPage = window.location.pathname.includes('/staff');
const recipientType = isStaffPage ? 'staff' : 'customer';

// Filter events by recipient
const filteredEvents = allEvents.filter((event: any) => {
  return event.recipients && event.recipients.includes(recipientType);
});

// Use filteredEvents instead of allEvents
<Badge variant="secondary" className="text-xs">
  {filteredEvents.length} {__('templates')}
</Badge>

Event Mapping

Customer Events (9 total)

  1. order_placed → Order Placed
  2. order_confirmed → Order Confirmed
  3. order_shipped → Order Shipped
  4. order_completed → Order Completed
  5. order_cancelled → Order Cancelled
  6. payment_received → Payment Received
  7. payment_failed → Payment Failed
  8. customer_registered → Customer Registered
  9. customer_vip_upgraded → VIP Upgraded

Staff Events (7 total)

  1. order_placed → New Order
  2. order_confirmed → Order Confirmed
  3. order_shipped → Order Shipped
  4. order_completed → Order Completed
  5. order_cancelled → Order Cancelled
  6. payment_received → Payment Received
  7. payment_failed → Payment Failed

Testing Checklist

After backend integration:

  • Navigate to Customer Notifications → Templates
  • Verify "9 templates" badge shows
  • Open any customer event template
  • Verify new markdown format is shown (not HTML)
  • Navigate to Staff Notifications → Templates
  • Verify "7 templates" badge shows
  • Open any staff event template
  • Verify new markdown format is shown
  • Test saving a template
  • Test resetting a template to default
  • Verify preview shows correct formatting

Priority

HIGH PRIORITY - These issues prevent the new templates from being used and show incorrect information to users.

Estimated Time: 1-2 hours to implement and test


Summary

What Works:

  • Frontend email builder
  • Markdown parser
  • Preview system
  • New template files created

What Needs Fixing:

  • Backend not using new templates
  • Template count incorrect in UI
  • Event-to-recipient mapping needed

Once Fixed:

  • Users will see new improved templates
  • Correct template counts
  • Better UX overall