- What is capell-app/core used for in a Laravel application?
- capell-app/core is the platform package for Capell CMS. It provides the shared content model for sites, domains, languages, pages, page URLs, layouts, themes, blueprints, media records, and redirects, plus the package registry, settings infrastructure, install and upgrade orchestration, and extension contracts. Use it when your Laravel app needs Capell's domain records and extension API. It deliberately ships without an admin UI or public rendering layer.
- Does capell-app/core include the Filament admin panel or frontend rendering?
- No. Core is a domain and platform package only. The Filament admin panel and editor workflow live in capell-app/admin, public request handling and HTML rendering live in capell-app/frontend, and browser installer routes live in capell-app/installer. Installing core alone gives you models, services, contracts, commands, and migrations, not a ready-made CMS interface.
- What PHP and Laravel versions does capell-app/core support?
- The README lists PHP 8.4 and shows a Laravel compatibility badge sourced from Packagist. Because Laravel support can change between releases, check the package's composer.json constraints or the Packagist page before adding it to an existing application. Test the install against your target Laravel version in a clean project first.
- How do I install capell-app/core with Composer?
- Run composer require capell-app/core and let Laravel package discovery register the service provider. Then run the package migrations and settings migrations against your database. Capell's install and upgrade commands handle orchestration for the wider platform, so follow the sequence documented at docs.capell.app rather than running migrations ad hoc in production.
- What database tables and migrations does capell-app/core add?
- Core ships migrations for the shared Capell schema, covering sites, domains, languages, pages, page URLs, layouts, themes, blueprints, media records, redirects, package state, and upgrade log records, plus settings migrations. Review those migrations against your existing schema before running them, especially if you already have tables with similar names. Test in an isolated database or staging copy if you are adding core to an existing application.
- Does capell-app/core support multi-site and multilingual content?
- Yes. The shared content model includes sites, domains, languages, pages, and page URLs, which is how Capell represents multiple sites and localized page routing. Core owns these records and their contracts, but public routing and rendering are handled by capell-app/frontend. Adding the frontend and admin packages gives you the full editing and delivery experience.
- What extension points does capell-app/core expose for custom logic?
- Core provides model-level contracts, package manifest validation, a package registry, settings schemas, subscribers, render blocks, and maker registration. These are the intended hooks for first-party and third-party add-ons, so build against them rather than patching core classes. Check the documentation site to confirm which contracts are stable for your installed version.
- Can I use capell-app/core as a headless CMS backend?
- Yes, in the sense that core gives you the content domain records and services without imposing an admin UI or HTML renderer. You would expose your own API or delivery layer over the Capell models and can add capell-app/admin separately for editing. For public rendering out of the box you would also install capell-app/frontend.
- What Artisan commands does capell-app/core register?
- Core registers install, upgrade, rollback, package cache, component cache, doctor, faker, and maker commands. These cover orchestration, cache rebuilding, diagnostics, fake data generation, and scaffolding. Running doctor after install or upgrade helps catch configuration and schema problems early.
- How are upgrades and rollbacks handled in capell-app/core?
- Core owns upgrade orchestration, records an upgrade log, and exposes upgrade and rollback commands. Pin the package version in composer.json and review release notes before upgrading, because core touches shared schema and package state. Test the upgrade path against a staging copy of the database before running it in production.