Choose which optional cookies Capell may use.
Required for Capell to work — login, security, page rendering.
Anonymous usage telemetry to improve editor performance.
Personalization for the Capell marketing site.
Large CMS products get messy when every feature lands in one core codebase. Capell uses features added one Composer package at a time so SEO, search, forms, themes, publishing workflow, access gates, diagnostics, and marketplace features can be installed deliberately.
Packages use Laravel conventions: service providers, migrations, Actions, config, tests, manifests, render hooks, and clear extension points.
Packages are how Capell grows without stuffing every possible CMS feature into core. A package can add models, migrations, Filament resources, widgets, settings, render hooks, diagnostics, themes, docs, jobs, or marketplace metadata.
That model should feel familiar to Laravel developers. Install capability through Composer, review what it adds, run migrations, test the editor and public impact, and remove it if it no longer belongs.
Package authors should read this before designing marketplace features. Adopters should use it as a checklist before a package reaches production.
Capell extensions install, register, test, and ship like Laravel packages rather than hidden CMS plugins.
The stack stays recognisable because Capell is installed into the application, not bolted on as a separate platform.
The package model matters because not every project needs every CMS feature on day one. Install capability when it is worth owning: a publishing workflow, a form system, a search index, a theme, diagnostics, or a migration tool.
See how Capell grows through Laravel packages for SEO, search, themes, forms, publishing workflow, and operations.
Start with the practical question: what does the visitor or editor need to do next? Capell keeps that answer tied to the Laravel app, with shared structures for repeated pages and enough room for custom work when the project genuinely needs it.
Packages should make CMS capability easier to review, not harder to trust.
No. Start with the foundation you need. Add packages when SEO, search, workflow, themes, or operations deserve a dedicated capability.
Yes. Repeatable client functionality can live in Laravel packages with manifests, providers, tests, docs, and a clearly visible install impact.
No. Package internals, permissions, admin selectors, and editor metadata must stay out of anonymous public output.
Browse the extension surface, then check the developer experience behind package creation, install impact, review, testing, and removal.
Package boundary Capability arrives through Composer packages, manifests, setup commands, migrations, hooks, and tests.
Reviews
Simple feedback on keeping CMS structure inside Laravel.
One content model the Laravel app already owns
“Capell Core puts pages, URLs, layouts, media and translations behind one typed model inside the Laravel app. Content can grow without a new bespoke admin screen each time, and rendering stays in the codebase the team already maintains.”
The content model you keep, not rent
“For a site owner, Capell Core means the structure behind every page, URL and translation lives in the app you own, not a hosted account someone else controls. The site can grow for years without being tied to a vendor's roadmap.”
One core to deliver every client on
“For an agency, Capell Core is a shared content model the whole studio learns once and reuses on every build. Pages, URLs, media and translations stop being re-invented per project, and support stays predictable across the client base.”
Capell packages should behave like serious Laravel dependencies. Before a package changes a live CMS, the team should understand what it registers, what it stores, what it renders, and how it affects cache, search, workflow, and operations.
| Area | Capell shape | Developer check | Team outcome |
|---|---|---|---|
| Install impact | Packages can add migrations, config, routes, commands, resources, views, and render hooks. | Read the manifest and review setup steps before installing. | Teams know whether a package is lightweight or operationally significant. |
| Public surface | Packages may contribute frontend blocks, forms, search, SEO, or gated experiences. | Verify what can render publicly and whether the output is cacheable. | Visitors get useful features without accidental exposure. |
| Maintenance | Capability stays versioned through Composer instead of patching core. | Track updates, compatibility notes, and rollback requirements like any dependency. | The CMS can grow without becoming un-upgradeable. |
| Marketplace trust | Listings should show capability, support, compatibility, screenshots, and safety signals. | Prefer packages with clear evidence over vague feature claims. | Buyers and developers can evaluate risk before install. |
A package should say what setup work it needs, what capability it adds, and whether the team must plan data, queue, search, or cache changes before deploying.
Browse extensionsIf a package contributes forms, search, SEO, themes, gated experiences, or rendered blocks, confirm the visitor output remains clean, cache-aware, and owned by the application.
Render rulesLook for clear expectations around compatibility, rollout, rollback, diagnostics, and long-term support. Optional CMS capability still becomes production software once installed.
Site operationsShared CMS behavior belongs in package extension points; project-specific business rules still belong in the Laravel app. That split keeps packages reusable without swallowing the product.
Developer experienceCapell learning journey
Capell is a Laravel CMS split into four parts: Core, Admin (Filament), Frontend, and Packages. See how they fit your project.
Packages, developer workflow, and AI assistance.
