Philosophy

Mini CMS is not a standalone product. It is a CMS aspect on top of the Mini PHP framework — a full application framework with zero non-PSR dependencies that provides routing, templating, database, auth, validation, mail, caching, and more out of the box.

The framework comes first

You start by building a normal Mini application: routes, views, models, business logic. The CMS is layered on top without changing how the application works. Your route files, controllers, and templates are plain PHP — there is no CMS abstraction between you and the framework.

This means a Mini CMS site is a real application, not a theme. You can have custom routes with complex logic, database models with authorization rules, API endpoints, background jobs — anything the framework supports. The CMS just adds inline editing to the parts you choose.

Aspects, not plugins

Mini organizes features as aspects — Composer packages that contribute routes, views, static assets, config, and migrations via path-registry overlays. The CMS is one such aspect (fubber/mini-cms). It ships defaults for the admin panel, inline editing JS, media library, and CRUD views. Your application can override any of these file-by-file.

This overlay system means the CMS never forces you into its UI patterns. If the default admin shell doesn’t fit, override _views/cms/admin-shell.php in your app. If you need a custom entity form, point the entity at your own view. The framework’s file resolution does the rest.

Zero external dependencies

Mini implements PSR-7, PSR-11, PSR-17, PSR-18, and PSR-16 from scratch. No Symfony components, no Guzzle, no League packages. The CMS follows the same principle: all vendor JS and CSS (Bootstrap, AdminLTE, Cropper.js) is served locally from _static/admin/vendor/. No external CDNs, no tracking scripts, no cookies from third-party domains.

This is a privacy requirement. A default CMS installation must not leak visitor data to external services.

Filesystem as database

CMS content is stored as JSON and HTML files, not in a database. This is a deliberate choice:

• Git versioning — every content edit is a file change that git diff can show and git revert can undo
• Agent-friendly — an AI coding agent can read and write content files directly, no API needed
• Portable — copy the directory and you have the entire site, no database export/import
• Mergeable — content changes on different pages touch different files, so branches merge cleanly

The database is still there for structured data (models, entities, anything that needs querying). But page content — headings, paragraphs, images — belongs on the filesystem where tools can reach it.

Template-first, not schema-first

Traditional CMSes require you to define content types, fields, and schemas before you can build a page. Mini CMS inverts this: you write a template with cms_text() and cms_html() calls inline, and the CMS discovers the editable fields by rendering the page. No configuration step, no admin panel setup, no migration.

The template is the schema. Add a widget call to a view and it appears in the editor. Remove it and it disappears. Rename it and the old content stays on disk (harmlessly) while the new name starts fresh.

Don’t work around the framework

If something in Mini doesn’t work as expected, that’s a framework bug to discuss and fix — not something to patch around in the CMS. This keeps the CMS thin and the framework honest. The CMS should never contain code that compensates for missing or broken framework features.