How shakilahmedbhuiyan/crown works
1. This is a Laravel monolith built around server-rendered Blade views plus Livewire components. The app is not a pure SPA; most user interaction is handled by Laravel HTTP routes, Blade layouts, and Livewire-backed partial updates.
2. The application has two clear UI zones: a public/guest storefront and an authenticated admin dashboard. Guest pages live under app/Http/Livewire/Guest and resources/views/livewire/guest, while admin pages live under app/Http/Livewire/Admin and resources/views/livewire/admin.
3. The domain model centers on a menu/catalog structure: FoodCategory, FoodItems, Attribute, SKU, CategoryNote, and ZipCode. These are persisted via Eloquent models and migrations, and they appear to back the admin CRUD screens and the public browsing experience.
4. The admin subsystem is implemented mostly with Livewire “page” components: category management, item create/edit/index flows, attribute tables, SKU creation, zip-code management, and an API page. The admin UI also has reusable Livewire components for header and sidebar navigation.
5. The guest-facing subsystem is focused on discovery and navigation: home, menu, category-product, and contact pages, plus shared components such as hero, navigation, category sidebar, product cards, collections, newsletter, and cart button. This suggests a content/catalog experience rather than a transaction-heavy checkout flow.
6. Authentication and account management are handled by Jetstream and Fortify. The app/Actions/Fortify and app/Actions/Jetstream classes cover user creation, password validation/reset/update, profile updates, and account deletion, while the resources/views/auth and resources/views/profile folders provide the corresponding screens.
7. Access control is enforced by middleware and role checks. In addition to standard Laravel middleware, there are custom isAdminMiddleware, isUserMiddleware, and CheckAccessToken, which indicates separate authorization paths for dashboard users and token-based API access.
8. There is an API and integration boundary around POS-related functionality. PosApi is a model, config/pos-api.php holds its settings, and the admin includes an API page. This points to an external point-of-sale integration or credential management surface inside the app.
9. Several small controllers handle cross-cutting public features: GoogleController for Google-related authentication or linkage, SitemapGeneratorController for SEO sitemap output, and EulaServiceController for serving policy/terms/EULA content from markdown sources.
10. Storage and assets are a major part of the runtime layout. Public images and uploaded files live under storage/app/public and are exposed through public/storage, while the frontend assets are built with Laravel Mix/Vite-era tooling (webpack.mix.js, resources/js, resources/css, public/js, public/css, tailwind.config.js).
11. The app uses standard Laravel infrastructure for persistence and background/runtime services: migrations and seeders define the schema and initial admin account, session and cache configuration are explicit, and the test suite focuses heavily on auth and Jetstream flows. This suggests a conventional Laravel deployment with authenticated web requests, database-backed state, and server-side rendering as the primary architecture.
Main entry points: Admin/Pages Admin pages · web.php Routes · Guest/Pages Guest pages · Models Catalog models
Components 18
UI zones
Server-rendered guest and admin experiences built with Blade and Livewire.
- Guest pages · Public storefront screens for home, menu, category browsing, and contact.
app/Http/Livewire/Guest/Pages - Guest comps · Reusable storefront pieces like navigation, hero, product cards, cart button, and sidebar.
app/Http/Livewire/Guest/Components - Admin pages · Authenticated dashboard flows for categories, items, attributes, SKUs, zip codes, and API settings.
app/Http/Livewire/Admin/Pages - Admin comps · Shared dashboard chrome such as header, sidebar, and table widgets.
app/Http/Livewire/Admin/Components - Layouts · App, guest, and dashboard layouts that wrap the server-rendered views.
resources/views/layouts - Auth screens · Login, registration, password reset, verification, and profile screens.
resources/views/auth - Policy content · EULA, terms, and policy content rendered into Blade views.
resources/markdown
Domain & data
Catalog, auth, and integration models plus persistence.
- Catalog models · FoodCategory, FoodItems, Attribute, SKU, CategoryNote, and ZipCode domain records.
app/Models - POS API · POS integration credential/state model and related config surface.
app/Models/PosApi.php - Seeders · Initial data loading, including the admin user seed.
database/seeders
Platform
Laravel runtime, security, routing, and shared infrastructure.
- Routes · Web and API route entrypoints for the application.
routes/web.php - Fortify actions · User creation, password rules, reset, update, and profile actions.
app/Actions/Fortify - Jetstream actions · Account deletion and Jetstream-backed profile lifecycle behavior.
app/Actions/Jetstream - Controllers · Cross-cutting controllers for Google linkage, sitemap output, and EULA serving.
app/Http/Controllers - Middleware · Custom access checks plus standard auth, CSRF, and request filters.
app/Http/Middleware - Providers · Service providers that register Fortify, Jetstream, routes, and app services.
app/Providers - API views · API token management and API-related dashboard screens.
resources/views/api - Storage assets · Public images, profile photos, and other persisted assets exposed through storage.
storage/app/public
Connections 22
- Routes → Guest pages: serves · Web routes mount the public Livewire pages.
- Routes → Admin pages: serves · Dashboard routes mount authenticated admin pages.
- Routes → Controllers: invokes · Specific endpoints delegate to controllers for sitemap, policy, and Google flows.
- Guest pages → Guest comps: composes · Guest pages assemble shared storefront widgets.
- Guest pages → Layouts: wraps · Guest screens render inside the guest/application layouts.
- Admin pages → Admin comps: composes · Admin pages reuse dashboard chrome and table widgets.
- Admin pages → Layouts: wraps · Admin screens render inside the dashboard layout.
- Auth screens → Fortify actions: backed by · Auth screens are powered by Fortify account workflows.
- Auth screens → Jetstream actions: backed by · Profile and account management screens rely on Jetstream actions.
- Controllers → Policy content: renders · Policy and EULA content is sourced from markdown files.
- Admin pages → Catalog models: manages · CRUD pages operate on the catalog and inventory models.
- Guest pages → Catalog models: browses · Public browsing pages read the catalog structure.
- Catalog models → Storage assets: uses media · Catalog records are associated with uploaded images and public assets.
- POS API → Admin pages: configured by · The API admin page manages POS integration state.
- Middleware → Admin pages: protects · Admin access is gated by custom role and token middleware.
- Middleware → Routes: filters · Middleware is applied at the HTTP kernel and route boundary.
- Providers → Fortify actions: registers · Fortify service provider wires auth actions into the app.
- Providers → Jetstream actions: registers · Jetstream service provider wires account management behavior.
- Providers → Routes: boots · Route and application providers initialize request handling.
- Seeders → Catalog models: seeds · Seeders initialize database state for the core domain.
- Seeders → Auth screens: supports · Seed data includes the initial admin user used by auth flows.
- API views → POS API: manages · API token screens expose the POS integration surface.