Laravel Pages Laravel Package

Getting Started

Start by confirming your Laravel and PHP versions. In v0.3.0 the package adds Laravel 11 support and drops Laravel 8 support, so use ^0.3 on Laravel 9/10/11. If you are still on Laravel 8, either remain on ^0.2 or upgrade Laravel first.

Minimal setup:

1. Require the package with Composer using the version constraint appropriate for your Laravel version.
2. Publish the package’s config, migrations, and any documented views/assets using the vendor:publish tags or provider shown in the package README.
3. Review config/pages.php first, then run the migrations.
4. Register the package’s page route or add your own catch-all route near the bottom of routes/web.php, after more specific routes.
5. Create a first page record through tinker, a seeder, or your own admin CRUD, then visit its slug.

The first practical use case is managed content pages: legal pages, marketing pages, landing pages, and simple informational pages where editors create records instead of developers adding routes and Blade files for every page. Look first at the package README, the published config, the Page model, the migration schema, and the controller/view resolution logic. Those define the day-to-day extension points.

Implementation Patterns

Use the package as a content model plus routing layer, not as a full CMS unless your app already supplies admin UI and authorization.

Common patterns:

• Template-based rendering: store a template key or view name on each page, resolve it in a controller or presenter, and fall back to a default page view. This lets editors choose between layouts such as default, landing, or legal.
• Catch-all routing: register the page route last so it does not swallow /admin, /api, authentication routes, or other application routes. Constrain the slug parameter if the package supports it, and decide whether nested slugs like legal/privacy are allowed.
• Published/draft workflow: add or use a published flag, expose only published pages publicly, and provide an authenticated preview route for drafts. Keep preview logic separate from the public route.
• Admin CRUD: build a small resource controller around the package model. Validate slug uniqueness, required title/content fields, template existence, and publication state. Use policies or middleware for access control.
• SEO fields: store meta title, description, canonical URL, and Open Graph data on the page or in a related structure. Pass them into the layout from the page presenter.
• Navigation integration: query published pages with scopes and ordering columns for menus, sitemaps, and footer links. Cache these queries if they run on every request.
• Cache invalidation: if you cache rendered pages or page lookups, clear relevant cache entries on page save, delete, publish, and unpublish using model events.
• Custom page model: if the package permits it, extend the base model to add relationships, scopes, accessors, and domain-specific behavior rather than modifying vendor code.
• View resolution: keep template resolution in one place—a presenter, controller method, or dedicated resolver—so the public route, preview route, and tests all behave consistently.

For Laravel 11 projects, treat v0.3.0 as a compatibility release rather than a feature release. Verify package discovery, republish config only if needed, and diff any published config against the new default before deploying.

Gotchas and Tips

• Laravel 8 is no longer supported in v0.3.0. Do not run a blind composer update on a Laravel 8 application. Pin ^0.2 or upgrade the application first.
• Laravel 11 support does not mean every Laravel 9/10 setup is automatically safe. Check the package’s Composer constraints for PHP and illuminate/* versions, especially if you use older PHP versions.
• Route order matters. A page catch-all route must come after explicit routes, auth routes, API routes, and admin routes. Test reserved paths such as /login, /admin, and /api.
• Slug collisions are a content problem and a routing problem. Enforce uniqueness at the database and validation layers, and reserve application paths so editors cannot create pages that shadow real routes.
• If you cache page output, invalidation is mandatory. Hook into save/delete/publish events; otherwise editors will publish changes and see stale pages.
• Do not trust raw HTML from page content unless editors are trusted. Sanitize user-supplied HTML or render it through a safe markup pipeline.
• Draft previews need authorization. A common mistake is adding a “preview” query parameter that lets anyone view unpublished content.
• When upgrading from v0.2.x, run the test suite and check published migrations/config for drift. Even compatibility releases can expose assumptions about service providers, route registration, or view namespaces.
• Keep customizations in your app: custom controllers, presenters, views, policies, and model subclasses are easier to maintain than patching vendor files.
• Use the package’s extension points—config, custom model, route/controller overrides, and view resolution—before forking. If the package does not expose a needed hook, wrap it in your own service rather than coupling business logic directly to vendor internals.