Laravel Cms Core Laravel Package

Getting Started

1. Install and pin deliberately. composer require czim/laravel-cms-core — because the package is archived, check its composer.json constraints against your Laravel/PHP versions and pin the exact version ("czim/laravel-cms-core": "x.y.*"). Expect to run an older Laravel or maintain a fork.
2. Register the provider. On Laravel 5.5+ auto-discovery usually picks up Czim\CmsCore\Providers\CmsCoreServiceProvider; on older versions add it to config/app.php. Verify with php artisan about or by resolving the core from the container.
3. Publish and migrate. Publish the config and migrations before touching anything else:

   php artisan vendor:publish --provider="Czim\CmsCore\Providers\CmsCoreServiceProvider"
   php artisan migrate
   

   Inspect the published config/cms-core.php — module registration, cache, auth, and page/menu settings live there.
4. Read the contracts first. The package is contract-driven. Start in Czim\CmsCore\Contracts\ (core, modules, pages, menus, cache, auth, media, API). Those interfaces tell you what is stable enough to depend on; concrete classes are implementation details.
5. First use case: resolve the core and a page repository from the container, create a draft page with a slug, publish it, then add a catch-all route that looks the slug up and renders it. That exercises the core, the page layer, and the routing integration in one pass.

Implementation Patterns

• Build features as modules. The core is a module host: implement the module contract/Module base class, register it in config/cms-core.php, and let its boot method register routes, menu entries, permissions, and API endpoints. Keep one module per feature so enable/disable is a config change rather than a code change.
• Depend on interfaces, bind implementations. Inject PageInterface/repository contracts rather than concrete Eloquent classes. In your own service provider, $this->app->bind(...) the core contracts to your implementations so upgrades and forks stay manageable.
• Page workflow: create → attach slug/locale → save as draft → publish. Treat publishing as a state transition and fire your own events around it for cache invalidation, sitemap regeneration, and search indexing.
• Menus as trees. Use the menu/menu-item layer to build navigation rather than hand-rolling a pages query. Resolve the tree once per request, eager-load children, and cache the rendered result keyed by menu handle + locale.
• Cache through the core manager. Wrap expensive page/menu/API lookups in the cache contract rather than calling Cache::remember directly, so the CMS's own cache-clearing hooks (on save/publish/module change) reach your entries.
• Admin/API integration. Use the core's auth and API managers when you need admin-gated endpoints or versioned API surfaces; this keeps permission checks and response conventions consistent with the rest of the CMS.
• Route integration: register the public catch-all page route last in your route file so it does not swallow admin, API, or asset routes.

Gotchas and Tips

• Archived means frozen. There will be no security or compatibility fixes. Budget for a fork, keep a changelog of local patches, and avoid building new long-lived features directly on vendor classes.
• Config caching bites modules. After editing the module list in config/cms-core.php, run php artisan config:clear (and cache:clear in production). A cached config is the most common reason a newly registered module "doesn't exist."
• Publish before migrate. Running migrations before publishing can leave you with partial tables; if tables already exist, publish only the config (--tag=config) and port migrations selectively.
• Contract drift when swapping models. If you replace a core model, implement the full contract — including relations and accessors the CMS itself calls — or you will get failures deep in menu/page rendering rather than at bind time.
• Slug and locale uniqueness. Enforce uniqueness on (slug, locale) at the database level, not just in validation; concurrent saves otherwise produce ambiguous lookups.
• N+1 in menus and revisions. Menu trees and revision histories are the usual performance traps. Eager-load children and limit revision queries to the admin context.
• Debug from the container. php artisan tinker then app('cms.core') (or resolve the module manager) to inspect registered modules and bindings; log module boot order when routes or menu items go missing.
• Extension points to prefer: contracts, config, module classes, and model events. Avoid editing files under vendor/ — with an archived package, those edits are effectively permanent and untracked.
• Route order matters. The page catch-all must be registered after admin/API routes; otherwise the CMS backend becomes unreachable and looks "broken" after a fresh install.