- homepage page.tsx was passing productLocale (SR/EN) instead of locale (sr/en) to ProductCard
- ProductShowcase default locale was "SR" instead of "sr"
- ProductBenefits default locale was "SR" instead of "sr"
These caused URLs like /en/SR/products/... when clicking products
Created src/lib/i18n/locales.ts as single source of truth for:
- SUPPORTED_LOCALES array
- LOCALE_COOKIE name
- DEFAULT_LOCALE
- LOCALE_CONFIG (labels, flags, Saleor locale mapping)
- Helper functions (isValidLocale, getSaleorLocale, getLocaleFromPath)
Updated all files to use centralized constants:
- middleware.ts
- Header.tsx
- ProductCard.tsx
- sitemap.ts
- root layout and locale layout
- routing.ts
Benefits:
- Adding new locale only requires updating ONE file (locales.ts)
- No more hardcoded locale lists scattered across codebase
- Cookie name defined in one place
- Type-safe locale validation
- Added hreflang alternates to root layout for all locales (sr, en, de, fr)
- Added hreflang alternates to [locale] layout for all locales
- Updated sitemap to include all locale variants for every page
- Google will now properly index all language versions
The navLinks were using localePath which was derived from locale
but the switchLocale was using pathname directly. This caused
mismatch when switching languages.
Changes:
- Root page.tsx now detects browser language (Accept-Language header)
and cookie preference to redirect to correct locale (/sr or /en)
- Middleware handles old Serbian URLs (/products, /about, etc.) with
301 redirects to /sr/* while respecting locale cookie
- Header component now includes language switcher dropdown with
flag icons (Serbian and English)
- Language selection sets NEXT_LOCALE cookie and persists preference
Behavior:
- User visits / → redirects to /sr or /en based on cookie/browser
- User selects English from dropdown → cookie set, redirects to /en/*
- User visits /products with en cookie → /en/products (301)
- User visits /products with sr/no cookie → /sr/products (301)
- Root / now uses next-intl locale detection to redirect based on
Accept-Language header (English browser → /en, Serbian → /sr, etc.)
- Old Serbian URLs (/products, /about, etc.) still redirect to /sr/* with 301
- English URLs (/en/*) remain unchanged
Redirect old Serbian URLs (without /sr/ prefix) to new /sr/ URLs:
- / → /sr (301)
- /products → /sr/products (301)
- /about → /sr/about (301)
- /contact → /sr/contact (301)
- /checkout → /sr/checkout (301)
English URLs (/en/*) remain unchanged. This preserves SEO value
as Google treats 301 as permanent redirect passing ~90-99% PageRank.
WARNING: This change breaks existing SEO URLs for Serbian locale.
Changes:
- Migrated from separate locale folders (src/app/en/, src/app/de/, etc.)
to [locale] dynamic segments (src/app/[locale]/)
- Serbian is now at /sr/ instead of / (root)
- English at /en/, German at /de/, French at /fr/
- All components updated to generate locale-aware links
- Root / now redirects to /sr (307 temporary redirect)
SEO Impact:
- Previously indexed Serbian URLs (/, /products, /about, /contact)
will now return 404 or redirect to /sr/* URLs
- This is a breaking change for SEO - Serbian pages should ideally
remain at root (/) with only non-default locales getting prefix
- Consider implementing 301 redirects from old URLs to maintain
search engine rankings
Technical Notes:
- next-intl v4 with [locale] structure requires ALL locales to
have the prefix (cannot have default locale at root)
- Alternative approach would be separate folder structure per locale
- Add comprehensive Serbian translation file (sr.json) with all UI strings
- Add comprehensive English translation file (en.json) with all UI strings
- Update Serbian root pages (/, /products, /products/[slug], /about, /contact) to use getTranslations()
- Update English pages (/en/*) to use getTranslations()
- Replace all hardcoded strings with translation keys
- Add middleware.ts for locale detection (URL path, cookie, Accept-Language)
- Update routing.ts to include en, de, fr locales
- Update layout.tsx with NextIntlClientProvider and dynamic lang attribute
- Create EN/DE/FR homepages, product listings, product details, about, and contact pages
- Serbian remains at root URL (/products, /about, /contact)
- English at /en/*, German at /de/*, French at /fr/*
- Fix checkoutLinesDelete mutation: use 'id' param and 'linesIds' instead of 'lineIds'
- Fix viewport metadata warning: move to separate viewport export in layout.tsx
- Add sizes prop to checkout Image with fill
- Fix CartDrawer init checkout useEffect to prevent re-render loops
- Various product detail improvements
- Reviews scroll continuously (alternating left-to-right and right-to-left)
- 50 varied Serbian customer reviews praising Manoon products
- Mentions Anti-age Serum, Day Serum, Night Serum, Morning Glow, Anti-age Set
- Scroll effect similar to As Seen In banner
The merge function was concatenating products on each query, causing
4 products to become 8, then 12, etc. Changed to replace incoming
data instead of merging.
- NEXT_PUBLIC_WOOCOMMERCE_URL → NEXT_PUBLIC_SALEOR_API_URL
- Remove WooCommerce consumer key/secret (not needed for Saleor public API)
- Saleor API is public, no authentication required
- Fix newsletter subscribe box centering on homepage
- Fix header overlap on product pages (pt-[72px] instead of pt-[100px])
- Add scroll-mt-[72px] for smooth scroll anchor offset
- Add HeroVideo component with video hero placeholder
- Add REDESIGN_SPECIFICATION.md with 9-phase design plan
- Clean up globals.css theme declarations and comments
- Update Header with improved sticky behavior and cart
- Update ProductDetail with better layout and spacing
- Update CartDrawer with improved slide-out cart UI
- Add English translations for updated pages
- Various CSS refinements across pages
- Add suppressHydrationWarning to html and body elements
- Prevents FoxClocks and other extensions from causing errors
- Extensions modifying DOM won't break React hydration
- Add parseDescription() helper to extract text from EditorJS JSON
- Update getLocalizedProduct to use parsed description
- Fix product descriptions showing raw JSON on frontend
- Create ErrorBoundary component to catch extension errors
- Ignore TronLink and other chrome-extension errors
- Prevent extension conflicts from crashing the app
- Fix syntax error in Checkout.ts (extra semicolon)
- Update NewHero.tsx to use Saleor types and store
- Update page.tsx to use Saleor getProducts
- Add Saleor API domain to next.config.ts images config
- Create checkout page with form validation
- Implement shipping/billing address forms
- Add Cash on Delivery (COD) payment method
- Integrate Saleor checkout completion mutation
- Add order success page with confirmation
- Handle checkout errors gracefully
- Display order summary with line items
- Create Saleor checkout store (Zustand + persist)
- Update CartDrawer to use Saleor checkout
- Update Header to use Saleor checkout store
- Update ProductDetail with Add to Cart functionality
- Add checkout initialization on app load
- Handle checkout line add/update/delete operations
- Add error handling and loading states
- Update ProductCard to use Saleor Product type
- Update products listing page to fetch from Saleor
- Update product detail page with Saleor integration
- Add language switching support (SR/EN)
- Add SEO metadata generation
- Implement static params generation for all product slugs
- Add availability checking based on variant quantity
- Init containers clone and build fresh code on each pod start
- Webhook triggers kubectl rollout restart on git push
- This provides true auto-deploy without requiring Docker registry
The Docker-based CI/CD approach is the industry standard but requires:
- Proper container registry (GHCR, Docker Hub) with HTTPS
- Or complex local registry setup with containerd HTTP configuration
The init container approach works reliably for now. To enable auto-deploy:
1. Flux detects git changes in 30s (via webhook)
2. Kustomization applies new config
3. Manually run: kubectl rollout restart deployment/storefront -n manoonoils
For true auto-deploy, consider:
- Setting up GHCR with proper auth
- Using GitHub Actions to build/push images
- Using Flux ImageUpdateAutomation
Or simpler: A post-deploy webhook that triggers rollout restart.
- Add Dockerfile for building Next.js images
- Replace init-container deployment with standard deployment
- Add kustomization with image tag tracking
- Add deploy.sh script for CI/CD pipeline
This enables proper GitOps auto-deployment:
1. Build image with commit hash tag
2. Push to GHCR
3. Update kustomization.yaml image tag
4. Flux detects change and restarts pods
Unchained