Core Laravel Package

Product Decisions This Supports

• Build vs. Buy for Restaurant Tech: Justify adopting TastyIgniter/core as a foundational layer for a B2B restaurant ordering/reservation platform instead of building from scratch. The package provides pre-built admin panels, extension systems, and core workflows (e.g., table reservations, geolocation), reducing dev time by 60–80% for MVP features.
• Roadmap Acceleration: Prioritize Phase 1 (Core Platform) by leveraging the package’s extension system to modularize features (e.g., payments, loyalty) as reusable components, enabling parallel development.
• Embedded & White-Label Admin Experiences: The new suppressNavigation option on AdminController (v4.4.5) lets us render admin screens without the header/sidebar. This unlocks embedded operator views — e.g., a delivery-driver console, kitchen display summary, or a partner-facing portal iframe — without forking the admin layout or maintaining custom Blade templates. Useful for the $500–$2,000/year white-label SaaS tier, where partners want our chrome, not ours.
• Monetization Strategy: Use the admin panel and customization tools to offer white-label solutions for small restaurants. suppressNavigation strengthens this by making per-controller branded shells a configuration flag rather than a build.
• Compliance & Security: Mitigate risks in user-generated content (e.g., menu descriptions, email templates) via the TemplateSandbox, aligning with PCI-DSS for payment integrations and GDPR for reservation data. v4.4.5 upgrades enshrined/svg-sanitize from ^0.22 to ^1.0 — a major version bump that materially changes SVG sanitization behavior (previously an explicitly called-out edge case).
• Tech Stack Standardization: Standardize on PHP 8.3–8.4 + Laravel to attract mid-tier dev talent and reduce hiring costs, while the package’s geolocation providers (Google/Nominatim) simplify location-based features.

When to Consider This Package

• Adopt If:
  • You’re building a restaurant tech platform (ordering, reservations, menus) and need pre-built admin interfaces without reinventing Laravel’s scaffolding.
  • Your target market includes SMBs who lack dev resources—use the extension system to offer plug-and-play features (e.g., delivery tracking, POS integrations).
  • You need operator-facing views embedded in another product surface — suppressNavigation (v4.4.5) removes the need to build a parallel admin UI for partner portals or kiosk-style screens.
  • You require multi-language/currency support out of the box (e.g., for international chains) with fixes like zero-decimal currency formatting.
  • Your security team prioritizes template sanitization over custom solutions, given the TemplateSandbox’s XSS protections. Note (v4.4.5): SVG handling now runs on svg-sanitize ^1.0 — re-validate any SVG upload/menu-image flows before adopting, as the major bump may alter allow/deny behavior.
  • You’re targeting Laravel 12 compatibility and need minimal migration effort (e.g., for existing Laravel apps).
• Look Elsewhere If:
  • Your project is non-restaurant (e.g., e-commerce, SaaS)—the package’s domain-specific features (e.g., table reservations, kitchen workflows) may not apply.
  • You need real-time sync with external systems (e.g., kitchen display systems) beyond the package’s event-driven architecture.
  • Your team lacks Laravel/PHP expertise—the package assumes familiarity with Eloquent, Blade, and Laravel’s service container.
  • You require headless APIs—the package is admin-heavy with limited GraphQL/REST endpoints. (suppressNavigation improves embedding, but it is still server-rendered Blade, not a headless contract.)
• Avoid If:
  • You’re building a highly customized ordering system where the package’s default workflows (e.g., order status transitions) would require extensive overrides.
  • Your scaling needs exceed the package’s monolithic architecture (e.g., microservices for payments, inventory).
  • You cannot absorb a transitive dependency major bump (svg-sanitize 0.22 → 1.0) in the current sprint — schedule the upgrade and regression pass explicitly rather than letting it land silently.

How to Pitch It (Stakeholders)

For Executives: *"TastyIgniter/core lets us launch a restaurant ordering platform in 3 months instead of 12 by using its pre-built admin panel, extension system, and geolocation tools. For example:

• Admin Panel: Ready-made dashboards for reservations/orders cut UI dev time by 70%.
• Partner Portals at Near-Zero Cost: The new suppressNavigation flag (v4.4.5) lets us reuse those same dashboards inside a partner-branded portal — a config change, not a second frontend. That's directly revenue-enabling for our white-label tier.
• Extensions: Add features like loyalty programs via plugins (e.g., igniter:install) without custom builds.
• Security: The TemplateSandbox automatically sanitizes user-generated content (e.g., menu descriptions), and v4.4.5 hardens SVG handling via a major svg-sanitize upgrade. Cost: ~$5K for a white-label SaaS tier, with $20K/year in dev savings. ROI: 4x faster time-to-market for [Product X]."*

For Engineering: *"Key leverage points for v4.4.5+:

1. Admin Panel: Use the built-in navigation system (with permissions field) to scaffold role-based access. New: set suppressNavigation on AdminController to drop the header/sidebar for embedded/portal views — no layout fork, no template overrides. Tradeoff: those screens lose global nav, so supply your own breadcrumb/back affordance and confirm permission checks still run at the controller level, not just via nav visibility.
2. Extensions: Deploy features like payments via Composer (composer require tastyigniter/payments). Caveat: Test extension conflicts early—some rely on core hooks.
3. Geolocation: The Google/Nominatim providers handle autocomplete + distance calculations for delivery zones. Note: Cache responses to avoid API costs.
4. Dependency Upgrade (action required): enshrined/svg-sanitize moved ^0.22 → ^1.0. Treat as a breaking change surface: audit any SVG ingestion (menu logos, uploaded assets), pin in composer.lock, and run a regression pass on sanitize output before merging. Also exercise the console command confirmation prompts fix if your deploy scripts pipe into artisan — confirm prompt behavior didn't shift in CI.
5. Templates: The TemplateSandbox replaces manual Str::of() calls for sanitizing email templates or menu descriptions. Warning: Override sanitize() if you need custom rules, and re-check your allowlist against svg-sanitize 1.0. Recommendation: Start with the TastyIgniter app repo for a full stack example, then extract core modules (e.g., OrderService) for your project. Upgrade path from v4.3.1 → v4.4.5 is small in code but not dependency-free — budget half a day for the SVG regression."*

For Security/Compliance: *"The TemplateSandbox (v4.2.3+) mitigates XSS in user-generated templates by default, and v4.4.5 upgrades svg-sanitize to ^1.0, tightening the SVG attack surface that we previously flagged as an edge case. Alignment:

• PCI-DSS: Sanitizes dynamic content in order confirmation emails.
• GDPR: Protects reservation data in customizable forms.
• Required action: The 0.22 → 1.0 bump is a major version — treat prior SVG test fixtures as stale. Re-run XSS payload tests against TemplateSandbox::sanitize() with real SVG samples (logos, icons, uploaded assets) and confirm no rendering regressions for legitimate content. Limitations: The sandbox still uses HTML Purifier-like defaults — audit TemplateSandbox::sanitize() for your specific edge cases. Pair with Laravel’s validate() for additional input checks. Note that AdminController::suppressNavigation is presentational only — do not rely on it as an access control or data-exposure boundary; permissions must remain enforced server-side."*