Weave Code
Laravel Pages Laravel Package
archtechx/laravel-pages
Laravel Pages provides a lightweight way to add static pages to Laravel apps. Define pages and their Blade views, register routes automatically, and apply layouts, middleware, and clean slugs for about, legal, and marketing content.
Easily add routes to your Laravel app by creating Markdown or Blade files
Frequently asked questions about Laravel Pages
- How do I install archtechx/laravel-pages in a Laravel application?
- Install it with Composer using composer require archtechx/laravel-pages, then publish any config, migrations, or views that your installed version ships with. Run your migrations so the pages table exists, then create your first Page record with a slug and the Blade template it should render. From there the package handles route resolution and rendering using standard Laravel conventions, so no custom routing code is required.
- Which Laravel versions does archtechx/laravel-pages support?
- Version 0.3.0 adds Laravel 11 support and removes Laravel 8 support, so Laravel 8 applications must stay on the 0.2.x line or upgrade the framework first. The release notes only call out Laravel 11 and the removal of Laravel 8, so confirm Laravel 9 and 10 support against the package's Composer constraints and CI before standardizing. Check the required PHP version in composer.json as well, since it typically moves alongside Laravel 11 support.
- Does archtechx/laravel-pages register page routes automatically?
- Yes, the package registers and resolves routes from page slugs automatically, so you do not write a route for every page you create. Because these are normal Laravel routes, you should run php artisan route:cache and route:clear in staging to confirm caching behaves as expected, and rebuild the cache after deploying page changes. If you need custom prefixes or domains, review the configuration and route registration code in your installed version.
- How is archtechx/laravel-pages different from a CMS like Statamic or Filament?
- This package is a lightweight primitive for database-backed static pages: an Eloquent Page model, slugs, publish status, and Blade rendering. It is not a full CMS and does not provide editorial workflows, media libraries, approvals, headless content delivery, or multi-tenant publishing out of the box. Teams that need rich editing should build a small admin layer on top of it or choose a full CMS instead.
- How do I publish or unpublish a page and what happens to its URL?
- Pages carry publish and unpublish status controls on the Eloquent model, so you toggle a status field rather than deleting the record. Unpublished pages should stop resolving publicly, but verify the exact behavior in your installed version, for example whether the route returns a 404 or the page is simply excluded from listings. If results look stale in a cached production environment, clear and rebuild your route and view caches after changing status.
- How do I render a page with a custom Blade view or layout?
- Each page stores the Blade view or template it should render, so different pages can point at different views while sharing your application's layout. Keep the templates in resources/views and reuse your existing Blade components, slots, and sections. Because rendering goes through Laravel's view layer, standard view caching applies, so clear cached views after deploying template changes.
- Does archtechx/laravel-pages include an admin UI for managing pages?
- No, the package provides the Page model, routing, and Blade rendering primitives rather than a management interface. You create the CRUD screens yourself with plain Blade, Filament, Nova, or a similar tool, and protect those screens with your own policies and middleware. The tradeoff is a bit more work up front in exchange for full control over the editing experience and permissions.
- Is upgrading from v0.2.x to v0.3.0 a breaking change?
- Yes for Laravel 8 users: 0.3.0 drops Laravel 8 support and adds Laravel 11, which is a breaking change even though the version number only moves a minor digit on a pre-1.0 package. The changelog is minimal and does not describe schema changes, route behavior changes, config changes, or migration steps, so review the actual diff and test the upgrade on a branch. Republish config or views only if the release requires it, run any migrations, clear route, config, and view caches, and regression-test your page URLs and rendered content.
- How should I test page routes and rendering with this package?
- Use Laravel's HTTP tests: create Page records directly or through a factory, request the slug URL, and assert the expected status and rendered Blade output, including a 404 or redirect assertion for unpublished pages. Add tests around route caching and middleware interactions if your application relies on them in production. Also check the package's own CI and test coverage for your Laravel version before trusting a release, since the changelog does not describe test coverage in detail.
- How do I add middleware, authorization, or localization to page routes?
- The package aligns with native Laravel routing, so middleware can usually be attached through route groups or package configuration, which covers concerns like auth, throttling, and locale detection. Per-page authorization and localized slugs or content are not described in the release notes, so implement and verify those behaviors explicitly in your application. If you operate multiple sites or locales, test how slug resolution behaves before relying on it in production.
Weaver
How can I help you explore Laravel packages today?