Capell uses essential storage for sessions, security, and interface preferences. Analytics and marketing storage stay off unless you accept them.
Cookie PolicyUse this page to understand package groups before opening detailed docs or marketplace pages. It summarises what the package manifests and public overview docs show: surfaces, database impact, commands, settings, health checks, extension points, and support posture.
The goal is not to duplicate every README. The goal is to help a maintainer know what kind of change a package introduces before they inspect the exact install guide, migration notes, or marketplace listing. The package catalogue should feel closer to due diligence than a plugin lucky dip.
Teams should quickly narrow packages by job, capability, cost, author, and support state.
A package catalogue should answer the operational questions early: what does this add, who maintains it, what does it touch, and where do I go when the install changes production behaviour?
Packages should declare migrations, models, widgets, routes, policies, views, and settings.
capabilities: widgets, routes, migrationsManifests are the short version of package due diligence. They keep install impact close to the package card instead of hiding it in code or release notes.
A package card should show Capell version, Laravel version, support status, and known constraints.
Security contact, support route, release history, and legal bundle should be close to install intent.
The install path should explain Composer changes, migrations, permissions, and rollback expectations.
This is where marketplace UX can be much stronger than a plain download button.
Read these as repeatable CMS parts, not as one mandatory bundle. A small site may only need pages and layouts; a larger publishing site may add navigation, taxonomy, media, cache, and discovery output as the maintenance path becomes real.
Premium groups are useful when the site has enough pressure to justify them: submissions, approvals, diagnostics, campaigns, email templates, search reports, renderer themes, licences, or account workflows. The group tells you where to look before you pick a specific package.
Example: a forms package may add admin screens for form definitions, database tables for submissions, frontend rendering, validation rules, notification settings, and export behaviour. The safest package install is boring to review because those effects are visible before the command runs.
Example: a forms package may add admin screens for form definitions, database tables for submissions, frontend rendering, validation rules, notification settings, export behaviour, and rollback notes. A package should make those effects visible before the install command runs.
The package manifests show the surfaces and install impact. Some are free foundation packages; Address and Site Discovery are documented separately in their product groups, so this overview treats them as foundation-adjacent building blocks rather than promising a single licence model.
Use it when editors need to arrange approved rows, columns, widgets, and reusable sections while developers keep rendering in project code.
Use it when posts, archives, tag pages, feeds, and article elements should be installable instead of rebuilt as custom project resources.
Use it when menus need to follow pages, languages, and site scope instead of living as hardcoded Blade arrays or one-off settings.
Use it when articles, resources, package records, or custom models need shared classification that search, filters, and related-content components can reuse.
Use it when a site needs consistent address records, country selectors, flags, or location fields across packages instead of repeated form fragments.
Use it when media needs a visible CMS surface, health checks, alt text discipline, and a migration story from existing Spatie Media Library usage.
Use it when editors should jump from a rendered public page back to the exact CMS record or field without exposing admin concerns to normal visitors.
Use it as the reference frontend package when a project wants Capell-shaped rendering defaults before creating a bespoke theme.
Use it when public pages need predictable cached HTML output and maintainers need to know which content changes invalidate which URLs.
Use it when public pages, detail routes, and package-owned content need consistent sitemap and discovery output for search engines and audits.
Use this checklist before production installs. It keeps package selection practical instead of turning marketplace browsing into a guess about code you have not read yet.