Skip to content

What is CPalius?

CPalius is a CMF built on PHP 8.4 and Symfony 7.4 LTS: a Content Management Framework. More accurately, it is an application core. It provides everything a site needs in common (users, permissions, content model, multilingual support, media, search, security, updates, admin panels) out of the box; your job is to write the actual product on top of it, as a module.

This page explains what CPalius is, what it is not and which problem it solves. The following pages cover each part in detail.

First, what it is not

CPalius is not a blog engine. It includes a Blog module, but Blog is not part of the core; it is a module that runs on top of it. Tomorrow you can switch Blog off and put a booking system, a culture portal or a documentation site in its place, and the core stays the same.

CPalius is not a CMS that tries to replace WordPress either. It does not offer a ready-made plugin marketplace, millions of installations or thirty years of user habits. What it offers is different: the skeleton of an application, in a secure and auditable form.

CPalius is not a framework either. It does not hand you a blank canvas like Symfony or Laravel. The parts that get rewritten in every project (authentication, permissions, admin panel, media library, multilingual support) already work out of the box.

What does CMF mean?

Think of three approaches side by side:

Approach Strength Weakness
Classic CMS Rich ready-made plugins, quick start Heavy schema, growing technical debt, wide attack surface
Plain framework Clean code, full control Authentication, permissions, admin panel and media from scratch every time
CMF (CPalius) Ready-made enterprise components + clean core + isolated modules The plugin ecosystem is still small

The weakness in the last row is noted honestly: CPalius is a new product and its module store is still growing. In return, the most tedious and riskiest eighty percent of writing an application from scratch is already done.

What the core provides

Content and data. The Node entity keeps title, slug, status and language for content such as pages, posts and news in a single table; custom fields live in a JSON column. Fields that must be queried are written to a separate flat index. For business records (vehicles, invoices, bookings), entities marked with #[CpResource] and backed by real SQL columns are used. Details: Content model.

Field system (Field API). You define field types such as text, number, date, choice, image, file, entity reference and rich text; forms, validation, display and the search index are generated automatically.

Multilingual support. Languages are managed from the database (AACP → Languages). Content is linked with translation groups, and the UNIQUE(slug, locale) constraint prevents URL collisions on multilingual sites. Interface texts come from translation files and can be edited inside AACP.

Users and permissions. Roles do not work with a ROLE_ADMIN check in code but with capability names such as node.post.edit.own and forum.post.delete.any. A capability that is not defined is denied. Roles live as YAML files under cp-content/config/sync/ and travel with Git. Details: Permission system.

Two admin panels. Studio (/admin) serves content teams, AACP (/aacp) serves system administrators. Menus are registered by modules with attributes. Details: Panel tour.

Security. A request-scanning WAF, CSP with nonces, malware scanner, audit log, password policy, login defense, API keys and rate limiter, SSRF-protected webhooks. Details: Security.

Updates. Signed (Ed25519) release information, maintenance mode, locking, atomic file writes, database backup and automatic rollback on failure. Details: Update system.

Module and theme store. You can browse a signed catalogue with images and install from it; every package passes a contract check before installation.

Infrastructure services. Cron, queue, webhooks, email templates, notifications, revision history, recycle bin, backups, cache (Redis, Memcached and Varnish support), SEO and sitemap, search providers, theme system, widget areas, data migration framework.

The "the core never dies" principle

This is CPalius's most distinctive design decision. A third-party module may be faulty; that must not bring down your site or your admin panel. For this:

  1. Active modules are read from a static file without asking the database.
  2. Before a module is activated it goes through build and YAML checks in an isolated process; if it fails, it is not activated.
  3. At runtime, if a module's hook, route or event listener throws, the error is caught, written to the quarantine log and the request continues.
  4. There is a recovery console that works even if the database is down.

Details: The core never dies.

Who is it for?

  • Developers building modules or products: If you are writing a booking system, a directory or a portal and do not want to write users, permissions, media and a panel.
  • Agencies: Those who want to use the same core for many clients and deliver each client a different module and theme.
  • Enterprise teams: For internal applications that need security auditing, traceability and controlled updates.

If you have a ready blog site and only want to publish posts, CPalius does that too (with the Blog module), but its real strength does not start there.

Product model

Part How it is offered
Core Main product
Modules (Portal, Forum, Docs, …) Separately; free or paid
Themes Starter themes ship with the core, the rest are separate

cpalius.com is both the showcase of the product and proof that the product runs on itself: this documentation site is published with the Docs module.

Positioning

"An application core that extends safely." Someone writing a module knows their module cannot break the core; someone running the site knows they can still reach the panel even if a module breaks.

Next steps

Last updated: 13.10.2026