Front Laravel Package

Getting Started

gp247/front is the presentation layer for GP247 — the piece that turns a GP247 install into a browsable site (layouts, templates, CMS content rendering, frontend routes). Treat it as your theme/foundation layer rather than a business-logic package.

Minimal setup:

composer require gp247/front
php artisan vendor:publish --provider="GP247\Front\Providers\FrontServiceProvider"
php artisan migrate
php artisan config:clear && php artisan view:clear

Look first at, in this order:

1. config/gp247-front.php (published) — template/layout selection, route prefixes, middleware stack, asset paths.
2. The package's service provider — it tells you what gets registered: routes, view namespaces (gp247-front::...), Blade directives, and admin menu entries.
3. resources/views/ inside the package — the default template tree is your map of what's overridable.
4. Route list: php artisan route:list | grep gp247 to see which frontend URLs the package owns versus the core.

First use case to validate your install: render the home page and a CMS content page end-to-end. If the layout resolves, assets load, and the content block renders, the wiring is correct. Only then start customizing — debugging a broken install after you've added a theme is significantly harder.

Because this package has near-zero public adoption, budget time for reading source rather than searching for docs. Pin the version in composer.json ("gp247/front": "x.y.*") and avoid dev-main in anything you intend to deploy.

Implementation Patterns

Override, don't fork. The standard Laravel view-namespace pattern applies: publish views into resources/views/vendor/gp247-front/ and edit there. Keep the package untouched so composer update stays safe. If the package registers a view namespace, confirm the exact prefix before overriding — a mismatched path silently falls through to the package default, which is a confusing failure mode.

Template selection belongs in config. Point the config at your template directory rather than hardcoding layouts in controllers. This lets you flip between the stock template and your own without touching application code, and keeps multi-site setups manageable:

// config/gp247-front.php
'template' => 'mytheme',

Extend via Blade components for repeated chrome. Header, footer, nav, product teasers — wrap them once as components and reference them from layout files. When the package later changes its own partials, your components isolate the blast radius.

Compose, don't subclass. If you need behavior the package's controllers don't expose, prefer a thin application-level controller that reuses the package's views and services over extending package classes. Subclassing couples you to internals that can change between releases.

Middleware for cross-cutting frontend concerns. Locale detection, currency, cache headers, maintenance mode — register these in the package's route middleware config (or wrap its route group in routes/web.php) rather than editing package routes.

Asset pipeline. Publish the package assets, then let Vite/Mix own the build. Don't edit files in public/vendor/gp247/front directly — they'll be overwritten. Add your overrides in your own source directory and reference them from your layout.

Content workflow. For CMS-driven pages, use the admin screens to author content and keep templates free of hardcoded copy. This is the main reason to adopt the package at all — if you find yourself hardcoding marketing text into Blade, you're getting the dependency cost without the benefit.

Gotchas and Tips

• Zero dependents means zero field reports. You are the first person to hit most bugs. Read the package source for anything non-obvious rather than assuming documented behavior. Keep a local patch set (composer-patches or a fork) ready.
• Publish-then-edit collisions. If you publish config and later upgrade, your published copy won't receive new keys. Diff the package's config against yours after every update.
• View cache is your enemy during theme work. php artisan view:clear after every layout change; a stale compiled view looks identical to a broken override.
• Route ordering. If your app also defines routes under the same prefix, the package's catch-all routes can swallow them. Register your specific routes before the package's group, or restrict the package's prefix in config.
• Cache invalidation on content edits. If you enable response caching, CMS edits won't appear until cleared. Wire an observer or model event to flush the relevant tags/keys, or you'll spend an afternoon "debugging" content that was saved correctly.
• Asset 404s after deploy. Almost always a php artisan vendor:publish --tag=... that wasn't run in the deploy script, or a symlink issue. Verify the published asset path exists on the server, not just locally.
• Extension points to prefer: config values, view overrides, Blade components, and middleware. Extension points to avoid: editing vendor/, subclassing controllers, and monkey-patching service providers. The first list survives upgrades; the second list doesn't.
• Release date sanity check. A future-dated release with zero stars suggests low review. Read the changelog between versions before upgrading in production, and run the upgrade on a staging copy with your theme active — theme breakage is the most likely regression.