Ti Theme Orange Laravel Package

Technical Evaluation

Architecture Fit

• First-party theme for TastyIgniter, not a general Laravel package. Orange is a presentation layer plus a set of Livewire components (CartBox, Checkout, Booking, OrderPreview, ListMenuItems, CategoryList, LocalHeader, FulfillmentModal) that bind directly to TastyIgniter models and settings. It is only usable if the roadmap already includes TastyIgniter as the ordering platform; it is not a drop-in UI kit for a bespoke Laravel app.
• Stack assumptions are explicit and modern: Blade + Livewire ^3.7 + Bootstrap 5. That is a good fit for an existing Laravel 10/11 codebase and a poor fit if the storefront is Vue/React/Inertia or runs Bootstrap 4.
• Customization model is theme-level, not application-level: Theme Editor options (checkout flow single vs two-page, securityRedirectPage, hide-unavailable menu items, footer visibility) are configuration, while layout and behaviour changes require Blade/Livewire overrides. A TPM should treat "theme options" as the supported customization surface and everything else as a maintained fork.
• Value proposition is time-to-market, not novelty. For a restaurant/delivery storefront the expensive parts are the cart, option validation, fulfillment scheduling, delivery-area checks and checkout state — Orange already encodes these. Building equivalents from scratch is a multi-quarter effort.
• Technical risk concentration is in the checkout path. Release history shows repeated defects in exactly the highest-blast-radius areas: order total persistence on payment-method change (v4.1.5, v4.1.8), delivery address required/validation logic (v4.2.0, v4.2.1), cart tip TypeError (v4.1.9), checkbox option cart merge (v4.0.10), ASAP/LATER restriction enforcement (v4.1.11). These are revenue-affecting, so the theme must be treated as a transaction-critical dependency, not a cosmetic one.
• Security surface is real and acknowledged: GDPR cookie output escaping (v4.1.6 XSS) and the v4.3.0 forgot-password timing-equalization fix. Both are customer-facing endpoints, meaning patch SLAs apply.
• Ecosystem signal is ambiguous. 6 stars and 0 Composer dependents are normal for a theme (themes are installed, not required by other packages), but they mean no third-party validation, no community fork safety net, and effectively single-vendor maintenance by the TastyIgniter core team. Mitigation is that it is first-party, which is stronger than the star count implies.

Key Questions

1. Is TastyIgniter the committed ordering platform, or is this a spike? If the latter, use Orange for a prototype only and do not let customizations accumulate.
2. Which Livewire and Bootstrap major/minor versions are in the target app today — does livewire ^3.7 force an app-level upgrade?
3. Who owns theme overrides, and will we run it as a pinned upstream theme plus an override/child layer, or a hard fork?
4. What is the acceptable patch SLA for checkout- and auth-affecting releases (sub-7 days? sub-30?)?
5. Which Theme Editor options are in scope for business stakeholders, and who approves non-option customizations?
6. Does the checkout need to integrate payment providers or fulfilment flows not covered by the theme, and if so what is the override footprint?
7. Is SEO Manager (or an equivalent) required, and does the theme's static-page/nav support cover the content model?

Integration Approach

Stack Fit

• Requires TastyIgniter v4.x on Laravel, PHP version per the core's constraints, Livewire ^3.7, Bootstrap 5. Install via Composer (tastyigniter/ti-theme-orange), activate in the admin Themes panel, then configure through the Theme Editor.
• Assets ship as compiled front-end resources; the theme's SCSS/JS overrides should flow through the host app's asset pipeline (Vite/Mix) rather than hand-edited vendor files, otherwise upgrades become unrebasable.
• Override strategy is the single most important integration decision: extend via Blade view overrides and Livewire component subclassing registered in a small first-party package, keeping vendor/tastyigniter/ti-theme-orange pristine.

Migration Path

1. Pin and freeze: add a caret constraint at the current release (^4.3), commit the lockfile, and record the exact version in the runbook.
2. Staging-first install: stand up TastyIgniter + Orange on a staging environment with representative menu, locations, order types and delivery areas before touching production.
3. Baseline the flows: capture current-state behaviour for add-to-cart (including checkbox/quantity options), single- and two-page checkout, tip entry, payment-method switching, delivery-area rejection, reservations/booking, and reorder.
4. Build the override package for any required deviation; do not patch vendor code.
5. Layer integrations: payment providers, SEO Manager, newsletter, analytics/tag manager, and any location/geocoding dependency (the "Mark Your Location" modal and nearby search lean on external geocoding — verify provider choice, rate limits and coordinate handling).
6. Cutover behind a feature flag or subdomain, with rollback to the prior storefront.

Compatibility

• Livewire minor-version drift is the most likely blocker; the app must be on ^3.7 before adoption.
• Bootstrap 5 conflicts with any legacy Bootstrap 4 admin or marketing bundle — scope CSS deliberately.
• Third-party extensions that override the same Blade views or Livewire components (SEO, payments, loyalty) will collide; enumerate them and test pairwise.
• Pagination changed to simple pagination (v4.1.2) and paginator URLs were wrapped with url() (v4.1.5) — confirm infinite-scroll or "load more" expectations with product.

Sequencing Discovery/version audit → staging install and flow baseline → override architecture → integration work → performance and accessibility pass → UAT on checkout and mobile → gated production rollout → first upstream upgrade rehearsal (do this early, not at month six, to prove the override layer survives a bump).

Operational Impact

Maintenance

• Release cadence is high and incremental: roughly 20+ tagged releases across v4.0–v4.3, with a mix of "minor improvements" and genuine defect/security fixes. Budget a recurring maintenance line — one owner, monthly upgrade review, immediate review for anything tagged security or checkout.
• Upstream version is coupled to TastyIgniter core and Livewire majors; plan on a coordinated upgrade train (core → theme → overrides) rather than independent bumps.
• The override layer is the long-term cost centre. Every override is a merge point; keep a manifest of overridden views/components and a test that flags drift on upgrade.

Support

• Single-vendor support: issues route to the TastyIgniter core tracker, not a dedicated theme repo. Escalation leverage is limited; assume self-support with a Laravel/Livewire engineer of your own.
• No community volume to lean on (6 stars, 0 dependents) — you will not find Stack Overflow answers for theme-specific defects. Internal documentation of quirks is mandatory.
• Because fixes ship frequently and undocumented, treat release notes as required reading and keep a changelog of business-relevant behaviour changes (e.g., delivery-area validation semantics, tip handling).

Scaling

• Rendering is server-side Blade plus Livewire round-trips; the scaling unit is PHP workers plus DB, not CDN. Cart, option selection and checkout each generate Livewire requests, so checkout concurrency drives capacity.
• Full-page caching interacts badly with Livewire stateful components; cache static/marketing pages and menu listings per location, keep cart/checkout uncached.
• Menu queries were optimized upstream (eager loading, category filtering by location, simple pagination) — verify query counts on large menus (hundreds of items, many options) rather than assuming.
• Geocoding for "nearby"/address features is an external dependency with rate limits and latency; it needs a timeout, cache and graceful fallback.

Failure Modes

• Checkout correctness regressions: order total mismatch on payment-method change, address required/validation logic, tip field clearing — all previously observed. Mitigate with an automated checkout test suite and a canary order flow in production.
• Fulfillment scheduling errors: ASAP/LATER restrictions and empty order-type states have caused guards and fixes; mis-enforcement means orders accepted outside operating windows.
• Cart/option integrity: checkbox options and quantity updates previously corrupted existing cart items; silent price errors are the worst outcome.
• Security exposure on customer endpoints: XSS in cookie notice output and forgot-password email enumeration both required patches; delayed upgrades are a compliance issue, not just a bug backlog.
• Upgrade blast radius: because the theme owns checkout views and components, a routine composer update can change revenue-path behaviour. Pin, rehearse, and diff.
• Override rot: abandoned customizations after an upstream refactor produce 500s on live traffic; enforce upgrade rehearsals on a schedule.

Ramp-up

• A Laravel developer with Livewire experience reaches productive theme work in roughly 1–2 weeks: theming and Blade overrides are fast, checkout internals take longer because TastyIgniter domain models (locations, order types, menus, delivery areas) must be learned.
• A developer without Livewire or TastyIgniter exposure needs 3–5 weeks and should not be the sole owner of checkout changes.
• Onboarding artefacts to produce: an override inventory, a checkout flow map, a seeded staging dataset, and a release-note review checklist tied to the upgrade runbook.