- Is yajra/cms-core a complete CMS for Laravel?
- No. yajra/cms-core is a lightweight foundation of contracts, repositories, base Eloquent models, traits, and an auto-discovered service provider, not a finished CMS. It does not render admin screens or define routing; actual CMS behavior comes from sibling packages such as cms-page, cms-menu, and cms-media or from your own code. Treat it as scaffolding for building a custom back office rather than a drop-in product.
- How do I install yajra/cms-core in a Laravel app?
- Run composer require yajra/cms-core, then check composer.json for extra.laravel.providers so the provider is auto-discovered or register it manually. Publish the config first and review it, then publish migrations and run migrate only after confirming schema ownership. Commit the published files immediately so they become part of your application.
- Which Laravel versions does yajra/cms-core support?
- The package's composer.json is the authoritative source; check its illuminate/support and PHP constraints before committing. There is no external documentation or published compatibility matrix, so verify against your target Laravel major. Treat any Laravel upgrade as a source audit rather than relying on a community signal.
- Should I publish the yajra/cms-core migrations?
- Publish them selectively and commit the files before running migrate, because once your app writes to those tables upstream migration edits can silently diverge. Ideally the published migrations carry Schema::hasTable() guards and are treated as your own schema thereafter. If schema overlap with your own design is below roughly 70 percent, use the contracts and traits as reference and write your own tables.
- How does yajra/cms-core model pages, posts, and custom content types?
- It provides reusable contracts, repository abstractions, base models, and traits that you compose into content types rather than shipping fixed page and post entities. You implement the repository contracts and subclass the base models to make your storage decisions. The sibling packages cms-page, cms-menu, and cms-media add concrete behavior if you need it.
- What are the main technical risks of adopting yajra/cms-core?
- The top risks are one-way schema ownership, zero dependents and little community support, single-maintainer lineage, undocumented global scopes on base models, and default repositories that may ship without eager loading. Auto-discovery absence is a low-severity risk because it surfaces as an interface-not-found error. Contain the blast radius by depending on your own interfaces with a thin adapter to the package.
- How do I bind yajra/cms-core contracts to my own implementations?
- Create one dedicated service provider that reads a config map of contract to implementation and registers every binding in a single file. That file becomes the authoritative list of couplings in your application. Confirm the package's config actually drives class resolution rather than hard-coded classes before leaning on it.
- Can I use yajra/cms-core for headless delivery or multi-tenancy?
- It fits poorly for headless delivery, multi-tenancy, or a non-Laravel service boundary because those concerns are outside its scope. The package assumes a Laravel modular monolith where you bring routing and the admin UI. For internal tooling, editorial workflows, and blog or marketing backends it is a reasonable seam layer.
- Do yajra/cms-core repositories eager load, and does the settings repository cache?
- The default repositories likely ship without eager loading, so N+1 queries can appear on the first realistic admin listing; verify and add eager loading in your implementations. Whether the settings repository caches is undocumented and must be confirmed from source. Write integration tests around the queries you depend on.
- How do I test and maintain a CMS built on yajra/cms-core?
- Write integration tests around your contract bindings, migrated schema, repository queries, and any global scopes registered on the base models. Because the source is the documentation, record every convention and binding in your own docs so knowledge does not leave with one engineer. Define the exit plan in one sentence and keep package access behind a thin adapter.