Weave Code
Voyager Frontend Laravel Package
pvtl/voyager-frontend
Voyager Frontend extends Laravel Voyager with a public-facing site layer. It provides frontend routes, controllers, and Blade views for Voyager-managed content such as pages and posts, plus configurable templates and menu rendering to help build content-driven Laravel sites without leaving the Voyag...
The Missing Front-end for The Missing Laravel Admin 🔥
Frequently asked questions about Voyager Frontend
- What is pvtl/voyager-frontend and what does it add to Laravel Voyager?
- Voyager Frontend is a companion package that adds a public-facing site layer on top of Laravel Voyager. It provides frontend routes, controllers, and Blade views for Voyager-managed content such as pages and posts, plus configurable templates and menu rendering. It is intended for monolith Laravel apps already using Voyager as their admin and CMS layer, not for headless or API-first setups. The package is archived and was last released in January 2020.
- How do I install Voyager Frontend with Composer in a Laravel app?
- It installs via Composer under the package name pvtl/voyager-frontend, but it only makes sense in a Laravel application that already has Voyager installed and configured. Because the package is archived, expect manual work for service provider registration, route and config publishing, and asset setup rather than a guided installer. Validate the composer.json constraints against your Laravel, PHP, and Voyager versions first, and install on a branch with pinned versions. Run it in a non-production environment before committing to it.
- Which Laravel, PHP, and Voyager versions does Voyager Frontend support?
- The repository does not publish a clear compatibility matrix, and its last release was January 2020, so official support is effectively limited to the Laravel, PHP, and Voyager versions current at that time. Before installing, read composer.json for the actual version constraints and compare them with your app's locked Laravel, PHP, and Voyager versions. Modern Laravel releases are unlikely to be supported without patching, so treat any newer-version install as an experiment that needs full testing.
- How do I publish and configure Voyager Frontend routes, templates, menus, and assets?
- Configuration is handled through the package's published config, Blade views, and template and menu conventions layered on top of Voyager's BREAD content. Expect to publish config, views, and assets with Laravel's vendor:publish command, then adjust routes and templates to match your site structure. Menu rendering and page or post templates are typically driven by Voyager records and package config rather than a separate admin UI. Because documentation is archived and sparse, review the package source directly to confirm the available options.
- Is Voyager Frontend still maintained, and is it safe to use in production?
- No. The package is archived, last released in January 2020, and has no upstream security patches, Laravel or PHP compatibility updates, or bug fixes. Treat it as a reference implementation or a time-boxed scaffold rather than a strategic production dependency. If you must use it, fork it, pin dependencies, and budget internal ownership for upgrades and security review.
- Does Voyager Frontend handle public authentication, forms, or admin-only UI?
- The package is described as adding public routes, controllers, and Blade views for Voyager-managed pages and posts, plus templates and menus, not as an authentication or form-handling system. Any login, registration, contact forms, or admin-only UI would typically come from Voyager itself or your own Laravel code. Because the code is archived and untested against modern Laravel, review its routes and middleware carefully to confirm what is actually public and where authorization boundaries sit.
- Does Voyager Frontend work with Inertia, Livewire, or a Vue or React SPA?
- It is built around server-rendered Blade views, frontend routes, and Voyager content conventions, so it fits a monolithic Laravel plus Voyager plus Blade stack. It is not designed for Inertia, Livewire, Vue or React SPAs, or headless CMS delivery, and there is no indication of a JSON API layer. If your team standardizes on those stacks, use it only as a reference for wiring Voyager content into your own controllers and views.
- What should I test before deploying Voyager Frontend (routes, middleware, content rendering)?
- Smoke-test public routing first, including route collisions with your existing app routes and behavior with route caching enabled. Then verify middleware and auth boundaries, asset loading, menu rendering, and page or post output from Voyager records. Review dependency versions for known CVEs and check behavior after Laravel or Voyager upgrades. Test coverage is not documented for the package, so plan your own automated and manual checks before deploying.
- What are the alternatives to Voyager Frontend for a public Voyager-backed site?
- If you want to stay on Voyager, custom Voyager-backed controllers and Blade views are the most direct alternative and give you full control over routing, middleware, and templates. Otherwise, consider a maintained Laravel CMS or headless CMS and render content through your own frontend layer. Voyager Frontend is best treated as a reference implementation for wiring Voyager content into a public site rather than a long-term dependency.
- Can I fork Voyager Frontend and maintain it internally?
- Yes, forking into an internal namespace is the sensible path if you decide to keep using it. Pin Composer constraints, isolate its routes, config, and middleware, and document a replacement plan built on custom Voyager-backed controllers or views. Add CI, an ownership model, and upgrade runbooks so security patches and Laravel or Voyager compatibility work have a clear owner. Treat the fork as internal code you maintain, not as an archived dependency.
Weaver
How can I help you explore Laravel packages today?