Larrock Core Laravel Package

Getting Started

1. Install via Composer — composer require fanamurov/larrock-core. Before running it, open the package’s composer.json and confirm the Laravel/PHP version constraints. Larrock packages were built around older Laravel releases, so expect to adjust illuminate/* constraints or pin Laravel accordingly.
2. Register the service provider — check whether Fanamurov\LarrockCore\LarrockCoreServiceProvider is auto-discovered. On older Laravel versions, add it manually to config/app.php. Also look for any facades/aliases the provider registers.
3. Publish config, migrations, and assets — run the vendor publish command for the provider (config, migrations, views, public assets). Inspect the published config/larrock*.php file first; it usually exposes admin route prefixes, middleware, and component toggles.
4. Migrate and seed — php artisan migrate. If the package ships seed data (admin user, default pages), run the seeder.
5. Where to look first — src/ for the service provider, base models, base admin controller, and traits; routes/ for admin routes; resources/views/ for the admin layout; config/ for the knobs you’ll actually touch.
6. First use case — stand up the admin panel and create a small CRUD section (e.g., pages or a catalog) by extending the package’s base model and admin controller. This exercises routing, middleware, views, and persistence in one pass and shows you how much the package gives you vs. what you extend.

Implementation Patterns

• Extend, don’t edit — treat the package’s base model and base admin controller as contracts. Subclass them for each content type, override $fillable, $table, validation rules, and the view namespace. Keep vendor files untouched.
• Trait-based composition — Larrock-Core typically exposes traits for things like image handling, SEO fields, slugs, and ordering. Add these traits to your models to get admin form fields and storage behavior without re-implementing them.
• Component registration — LarrockCMS is component-oriented (menu, SEO, media, etc. live in sibling packages). Register your own admin sections the same way the core does: via the service provider (menu entries, route groups, view namespaces) rather than hardcoding links in Blade.
• Admin middleware — wire the package’s admin auth middleware into the route group. If you have an existing auth setup (Breeze/Jetstream/custom guard), map it to the guard the package expects rather than running two parallel auth systems.
• View overrides — publish views and override only the specific Blade files you need. Use view()->addNamespace() or the published view path so your overrides win without forking the package.
• Validation and form definitions — centralize per-model validation rules so the admin controller and any API/front-end controller share them. Avoid scattering rules across controllers.
• Events/observers for cache — if the package caches menus, SEO, or page trees, hook model events (saved, deleted) to invalidate those caches. This is where most “stale admin content” bugs come from.
• Integration with sibling Larrock packages — install core first, verify admin boots, then add components one at a time. Each addition should be followed by config:clear, route:list, and a manual admin smoke test.

Gotchas and Tips

• License is ambiguous (NOASSERTION) — get legal sign-off before shipping this in a commercial product. The repo doesn’t declare a standard OSI license in a machine-readable way.
• Age and version drift — expect friction with modern Laravel (typed properties, new container APIs, removal of legacy helpers). Budget time for pinning versions or patching provider registration.
• Route collisions — the admin prefix and route names may clash with your app’s routes. Check php artisan route:list immediately after install; adjust the config prefix or middleware before adding more routes.
• Migration ordering — when multiple Larrock components ship migrations referencing each other (users, media, pages), run them in the order the docs imply. If foreign keys fail, publish migrations and adjust timestamps rather than editing vendor files.
• Config caching surprises — after publishing config, always php artisan config:clear and route:clear. Many “my setting isn’t applied” reports trace back to a stale cache.
• Asset publishing — admin CSS/JS often lives in public/vendor/.... If the admin looks unstyled, re-publish assets and verify the public symlink/storage link.
• Debugging checklist — (1) is the provider registered? (2) do routes appear in route:list? (3) are migrations run? (4) are views/assets published? (5) is the admin middleware guard resolving a user? Walk that list before digging into source.
• Extension points to prefer — base classes, traits, published config, published views, and service-provider bindings. Avoid monkey-patching via Composer patches unless you’re prepared to maintain them.
• Documentation is likely Russian-first and sparse — read the source and the sibling packages’ READMEs; the service provider and route files are usually more accurate than the wiki.
• Isolate the package — wrap it behind your own admin routes/controllers where practical. That keeps the blast radius small if you later replace Larrock-Core with a bespoke admin or with Filament/Nova.