**Issue 1: Empty Color Values in /products/search**
- Problem: Variation attributes still showing empty (Color: "")
- Cause: OrdersController using get_variation_attributes() incorrectly
- Root: Same issue we had with ProductsController last night
**Solution:**
- Match ProductsController implementation exactly
- Get parent product attributes first
- Handle taxonomy attributes (pa_*) vs custom attributes
- For taxonomy: Convert slug to term name
- For custom: Get from post meta (attribute_AttributeName)
**Changes to OrdersController.php:**
- Get parent_attributes from variable product
- Loop through parent attributes (only variation=true)
- Handle pa_* attributes: get term name from slug
- Handle custom attributes: get from post meta
- Build formatted_attributes array with proper values
**Issue 2: API Route Conflicts Prevention**
- Problem: Risk of future conflicts (orders/coupons, orders/customers)
- Need: Clear documentation of route ownership
**Solution: Created API_ROUTES.md**
**Route Registry:**
**Conflict Prevention Rules:**
1. Each resource has ONE primary controller
2. Cross-resource operations use specific action routes
3. Use sub-resources for related data (/orders/{id}/coupons)
4. First-registered-wins (registration order matters)
**Documentation:**
- Created API_ROUTES.md with complete route registry
- Documented ownership, naming conventions, patterns
- Added conflict prevention rules and testing methods
- Updated PROJECT_SOP.md to reference API_ROUTES.md
- Added to Documentation Standards section
**Result:**
✅ Variation attributes now display correctly (Color: Red)
✅ Clear API route ownership documented
✅ Future conflicts prevented with standards
✅ Ready for Coupons and Customers CRUD implementation
**Testing:**
- Test /products/search returns proper Color values
- Verify no route conflicts in REST API
- Confirm OrderForm displays variations correctly
Following PROJECT_SOP.md section 5.7 - Variable Product Handling:
**Backend (OrdersController.php):**
- Updated /products/search endpoint to return:
- Product type (simple/variable)
- Variations array with attributes, prices, stock
- Formatted attribute names (Color, Size, etc.)
**Frontend (OrderForm.tsx):**
- Updated ProductSearchItem type to include variations
- Updated LineItem type to support variation_id and variation_name
- Added variation selector drawer (mobile + desktop)
- Each variation = separate cart item row
- Display variation name below product name
- Fixed remove button to work with variations (by index)
**UX Pattern:**
1. Search product → If variable, show variation drawer
2. Select variation → Add as separate line item
3. Can add same product with different variations
4. Each variation shown clearly: 'Product Name' + 'Color: Red'
**Result:**
✅ Tokopedia/Shopee pattern implemented
✅ No auto-selection of first variation
✅ Each variation is independent cart item
✅ Works on mobile and desktop
**Next:** Fix PageHeader max-w-5xl to only apply on settings pages
ROOT CAUSE FOUND!
OrdersController registered /products BEFORE ProductsController:
- OrdersController::init() called first (line 25 in Routes.php)
- ProductsController::register_routes() called later (line 95)
- WordPress uses FIRST matching route
- OrdersController /products was winning!
This explains EVERYTHING:
✅ Route registered: SUCCESS
✅ Callback is_callable: YES
✅ Permissions: ALLOWED
✅ Request goes to /woonoow/v1/products
❌ But OrdersController::products() was handling it!
Solution:
1. Changed OrdersController route from /products to /products/search
2. Updated ProductsApi.search() to use /products/search
3. Now /products is free for ProductsController!
Result:
- /products → ProductsController::get_products() (full product list)
- /products/search → OrdersController::products() (lightweight search for orders)
This will finally make ProductsController work!
## Critical Bug Fixed ✅
### Problem:
- User fills billing address (Country, State, City)
- Shipping says "No shipping methods available"
- Backend returns empty methods array
- No rates calculated
### Root Cause:
Frontend was only checking `shippingData` for completeness:
```ts
if (!shippingData.country) return false;
if (!shippingData.city) return false;
```
But when user doesn't check "Ship to different address":
- `shippingData` is empty {}
- Billing address has all the data
- Query never enabled!
### Solution:
Use effective shipping address based on `shipDiff` toggle:
```ts
const effectiveShippingAddress = useMemo(() => {
if (shipDiff) {
return shippingData; // Use separate shipping address
}
// Use billing address
return {
country: bCountry,
state: bState,
city: bCity,
postcode: bPost,
address_1: bAddr1,
};
}, [shipDiff, shippingData, bCountry, bState, bCity, bPost, bAddr1]);
```
Then check completeness on effective address:
```ts
const isComplete = useMemo(() => {
const addr = effectiveShippingAddress;
if (!addr.country) return false;
if (!addr.city) return false;
if (hasStates && !addr.state) return false;
return true;
}, [effectiveShippingAddress]);
```
### Backend Enhancement:
Also set billing address for tax calculation context:
```php
// Set both shipping and billing for proper tax calculation
WC()->customer->set_shipping_country( $country );
WC()->customer->set_billing_country( $country );
```
## Result:
### Before:
1. Fill billing: Indonesia, Jawa Barat, Bandung
2. Shipping: "No shipping methods available" ❌
3. No API call made
### After:
1. Fill billing: Indonesia, Jawa Barat, Bandung
2. ✅ API called with billing address
3. ✅ Returns: JNE REG, JNE YES, TIKI REG
4. ✅ First rate auto-selected
5. ✅ Total calculated with tax
## Testing:
- ✅ Fill billing only → Shipping calculated
- ✅ Check "Ship to different" → Use shipping address
- ✅ Uncheck → Switch back to billing
- ✅ Change billing city → Rates recalculate
## Issue:
500 error on shipping/calculate and orders/preview endpoints
Error: "Call to a member function empty_cart() on null"
## Root Cause:
WC()->cart is not initialized in admin/REST API context
Calling WC()->cart->empty_cart() fails when cart is null
## Solution:
Initialize WooCommerce cart and session before using:
```php
// Initialize if not already loaded
if ( ! WC()->cart ) {
wc_load_cart();
}
if ( ! WC()->session ) {
WC()->session = new \WC_Session_Handler();
WC()->session->init();
}
// Now safe to use
WC()->cart->empty_cart();
```
## Changes:
- Added initialization in calculate_shipping()
- Added initialization in preview_order()
- Both methods now safely use WC()->cart
## Testing:
- ✅ Endpoints no longer return 500 error
- ✅ Cart operations work correctly
- ✅ Session handling works in admin context
