Cms Laravel Package

Getting Started

LavaLite CMS is not a library you composer require into an existing Laravel app — it is a full Laravel application skeleton with a modular CMS bolted on. The first mental shift is to treat it like a project template, not a package.

Minimal bootstrap:

git clone https://github.com/LavaLite/cms.git my-site
cd my-site
composer install
cp .env.example .env
php artisan key:generate
# configure DB_* in .env
php artisan migrate --seed
php artisan storage:link
php artisan serve

Then log into /admin with the credentials documented in the README / database/seeders (change them immediately).

Where to look first, in order:

1. composer.json — see the lavalite/* packages that make up the CMS (page, menu, block, blog, slider, setting, user, contact, etc.). Each is a self-contained module.
2. config/app.php — the service providers that wire those modules in.
3. vendor/lavalite/<module> — read one module top-to-bottom (start with page or blog) to understand the conventions: routes, controllers, repositories, models, migrations, and Blade views.
4. resources/views and the public theme directory — the frontend layer you will actually redesign.
5. routes/web.php — the entry points for the public site.

First useful use case: stand up a multilingual marketing/content site — create pages, wire the main menu, publish blog posts — then extend it with a small custom module for whatever domain data your client actually needs (e.g., "services" or "team members"). That exercise touches every part of the stack you'll use daily: admin CRUD, migrations, Blade rendering, routing, and localization.

Implementation Patterns

Follow the module anatomy. Every lavalite/* module ships the same shape: a Providers/ service provider, Routes/, Http/Controllers/ (admin + frontend), Models/, Repositories/ (LavaLite leans on a repository pattern rather than fat Eloquent controllers), Database/Migrations/, Resources/views/, and Resources/lang/. When you need to add a feature, copy the structure of the closest existing module rather than inventing your own layout — you'll inherit its admin conventions, breadcrumbs, flash messaging, and permission checks for free.

Add domain features as your own module. Don't cram new tables into an existing lavalite/* package. Create packages/<vendor>/<module>/ with a PSR-4 autoload entry, its own service provider registered in config/app.php, its own migrations, an admin route group, and admin menu entries. This keeps upgrades of the upstream modules clean and mirrors how the CMS itself is built.

Reuse the admin CRUD pattern. The daily loop is: model + migration → repository → admin controller (index/create/store/edit/update/destroy) → Blade form using the same Bootstrap form markup the CMS uses → frontend controller/route → frontend view. Match the existing conventions exactly; the admin theme's JS and validation rely on them.

Multilingual content. LavaLite stores content per locale and resolves the active locale at request time. The practical pattern: add a language selector to the admin form, persist a language/locale column (or translation rows), scope frontend queries by the active locale, and add a middleware or route prefix (/en/..., /fr/...) to set App::setLocale(). Keep slugs locale-aware and always define a fallback locale so untranslated pages still render.

Menus, blocks and sliders are configuration, not code. Manage navigation and reusable content fragments through the admin, then render them in Blade via the helpers/facades the respective modules expose (e.g., a menu rendered by slug). Resist hardcoding nav in templates — clients expect to edit it without a deploy.

Override, don't edit vendor. To customize a module's views or config, publish them (php artisan vendor:publish --provider="...") or register a view namespace override in your own provider. Same for config: publish into config/ and edit there. Treat vendor/lavalite/* as read-only so composer update doesn't nuke your work.

Integrate like any Laravel app. Add your own routes and middleware in app/, use policies/gates for anything beyond the built-in role system, wire queues and mail as usual, and deploy as a normal Laravel application (env, storage link, config:cache, route:cache).

Gotchas and Tips

• It is an application, not an installable package. With zero dependents and a 2023 last release, do not plan to composer require lavalite/cms into a modern Laravel app. If you already have an app, you're merging two codebases — budget for that.
• Age and maintenance risk are the headline. Pin your PHP and Laravel versions early and verify composer install resolves cleanly before committing. Assume some dependencies are dated (Bootstrap + jQuery frontend, LaravelCollective-style HTML helpers) and plan whether that's acceptable for your project.
• Never edit files under vendor/lavalite/. Your changes vanish on the next composer update. Fork the module into packages/, publish views/config, or override via view namespaces.
• Seeders contain default admin credentials. Change them and rotate before any non-local deploy; audit the seeded roles/permissions too, since the role model drives admin access across all modules.
• Caching hides module changes. After adding routes, providers, or publishing views, run php artisan optimize:clear (or config:clear, view:clear, route:clear). Stale route caches are the most common "my new admin page 404s" cause.
• Route collisions between modules. Multiple modules register route groups; use php artisan route:list when something resolves unexpectedly, and namespace your own routes with a prefix to avoid shadowing a CMS route.
• Multilingual edge cases: missing translations silently fall back, per-locale slugs can 404 if the middleware isn't applied to every route, and any caching layer must vary by locale. Always test with a non-default locale.
• Debugging workflow: route:list to confirm registration, config('...')/dd() inside the module's service provider to confirm boot order, and Laravel's log for repository/query errors. Because modules live in vendor, stack traces point there — read them as if they were your own code.
• Extension points to prefer: your own service provider for routes/middleware, published config for behavior toggles, view namespace overrides for markup, model events/listeners for hooks into CMS entities, and a custom module for anything schema-level. These all survive upstream updates far better than patching.