Architecture Overview

VerdinCore brings content management, publishing, and public presentation into one deliberately integrated application.

A content management system has two very different jobs. It must give editors a comfortable place to work, and it must turn their work into reliable, readable pages for visitors. Between those two experiences sit decisions about data, access, images, navigation, metadata, and maintenance.

VerdinCore is built around that entire journey rather than treating the editor as an isolated feature. Its foundation is a PHP application built with CodeIgniter 4, backed by a relational database, with JavaScript used where a richer editing or administration experience is useful. Public content is rendered on the server through the active theme.

The architecture is intentionally straightforward to describe. That does not mean every task behind it is simple.

One application, distinct responsibilities

At a high level, VerdinCore is a server-rendered CMS with a dedicated administration experience and a theme-driven public website. The major responsibilities remain distinct even though they belong to the same application.

Layer	Responsibility	What it means in practice
Administration	Create and manage Posts, Pages, Topics, media, Content Blocks, and supported site operations.	Editors work in a purpose-built interface instead of editing database records or templates.
Application logic	Validate editorial actions, apply business rules, resolve content relationships, and enforce access decisions.	Publication state, permissions, and page structure are handled consistently on the server.
Content and media	Persist structured content and manage uploaded assets and generated image variants.	Content can be retrieved and presented in different contexts without repeatedly preparing every asset by hand.
Public presentation	Resolve public requests, select eligible content, and render pages using the active theme.	Visitors receive pages with the appropriate content, navigation, and metadata.
Maintenance	Run scheduled publication, generated files, cleanup, and other operational tasks.	Recurring work does not have to become a series of manual editorial chores.

These are logical responsibilities, not a diagram of separate servers or services. VerdinCore does not require a microservices story to explain how its parts fit together.

A PHP foundation, with JavaScript where it adds value

The backend uses PHP 8.5 and CodeIgniter 4. This foundation provides request handling, controllers, views, validation, and the supporting application structure. VerdinCore adds its own content and administrative services on top of that framework.

The administration interface combines server-rendered views with modern frontend components:

Tiptap 3 provides the editing foundation for rich content.
JavaScript ES6+ powers editor interactions and other administrative behavior.
Tailwind CSS 4 and DaisyUI 5 support the interface's styling and components.
esbuild assembles frontend assets for the administration interface and the public theme.

The data layer is designed around MariaDB/MySQL, with separate models for the major content types and their relationships.

These technologies have different jobs. Tiptap is not the entire CMS. Tailwind is not responsible for publishing rules. CodeIgniter does not determine the editorial experience on its own. The product lies in the decisions that connect them.

This also explains an important boundary: VerdinCore is not presented as a headless or API-first publishing service. Its current public experience is built around server-rendered pages and templates.

Follow a Post from editor to reader

A useful way to understand the architecture is to follow one ordinary publishing task.

Imagine an editor preparing an article with headings, a table, two images, and several assigned Topics.

Compose. The editor provides the writing environment and collects the Post's content, title, excerpt, and editorial settings.
Save. The application processes the submitted information, validates it, sanitizes supported rich-text HTML, and stores the relevant content and relationships.
Prepare media. Uploaded images pass through the appropriate media-handling path. Featured images and images within content are not necessarily processed in the same way.
Publish. The Post's status and access rules determine whether it is eligible for public requests. A scheduled Post depends on the configured maintenance process reaching its publication time.
Render. When a visitor opens an eligible Post, the application retrieves the content, applies visibility checks, prepares page metadata, and renders the appropriate public template.
Discover. Topics, related-content components, archives, and other configured presentation features can help readers continue beyond the individual article.

The important detail is that the editor does not have to manually reconstruct the article for the website. Writing, saving, and displaying content are connected parts of a single publishing workflow.

Write and enrich
       ↓
Validate and store
       ↓
Apply publication and access rules
       ↓
Render through the active theme
       ↓
Deliver the public page

This sequence is conceptual: it illustrates the responsibilities involved, not the exact order of every internal function or an additional queue of processing services.

For the editorial side of this flow, see The Visual Editor and Publishing Workflows.

Structure lives in the content model

VerdinCore does not treat every item of content as an interchangeable document.

Posts serve ongoing publication. They can be associated with Topics and surfaced through blog-style lists and discovery components. Pages provide more permanent information and can form parent–child hierarchies that determine their public paths and breadcrumb context.

Content Blocks address a different need: reusable, typed content values that a theme can request for specific presentation areas. They are not a second Tiptap document editor or an automatic drag-and-drop page builder.

Content structure	Architectural purpose
Posts and Topics	Organize published articles and connect related subjects.
Pages and parent relationships	Give lasting information a navigable hierarchy.
Content Block Groups, Blocks, and Elements	Keep selected pieces of reusable content editable while letting templates determine their presentation.
Media records and files	Associate uploaded assets with their intended uses and generated outputs.

The distinction matters because the data model can support useful public behaviors without asking editors to recreate those relationships by hand. For example, a Page's hierarchy can inform its URL and breadcrumbs, while a Post's Topic assignments can inform related-content suggestions.

Read more in Posts & Pages, Page Hierarchy, and Reusable Content Blocks.

The theme determines presentation

The public website is rendered through an active theme. Templates decide how content, navigation, shared components, and reusable block values appear to the visitor.

This creates a meaningful separation: the content model describes what the information is; the theme determines how it is arranged and presented.

It does not imply that any arbitrary theme can be installed through a public marketplace, or that a nontechnical editor can freely redesign every page. Themes are an application-level capability, and their available layouts and components determine what a particular website can display.

VerdinCore also supports configurable site identity and related settings. Those choices should not be confused with a promise of automatic multi-tenant hosting or a universal website builder.

The distinction between shared application behavior and theme-specific presentation will be explored in Themes & Rendering.

Image processing is part of the publishing system

Images are a good example of why architecture matters to the editorial experience.

A featured image may be needed in several contexts: a card on the homepage, a larger cover, and a link preview shared on another platform. An image inside the body of an article has different layout requirements again.

VerdinCore's media handling recognizes these different jobs. Its implemented processing paths generate purpose-specific image variants, including AVIF outputs for responsive site presentation and a separate sharing image for featured content.

This is more than file conversion. It reduces the number of image-preparation decisions an author must make for routine publishing. It also gives templates outputs intended for their particular layouts.

We will cover the editing experience in Images & Media and the technical processing model in Image Processing Pipeline.

Access rules belong on the server

A website needs more than a dashboard that hides buttons from unauthorized users. Administration actions and public content access must be evaluated on the server.

VerdinCore uses CodeIgniter Shield for authentication and authorization. Its administrative routes and content operations apply defined permissions, including distinctions between managing all Posts and editing one's own content. Public content requests also check publication and audience access rules.

There is a deliberate separation between these concerns:

Editorial permissions determine who can create or manage content and operate administrative functions.
Publication state determines whether an item is published, scheduled, a draft, or archived.
Audience access determines whether a published item is eligible for the public or requires an authenticated member.
Discoverability determines whether an otherwise accessible item is included in ordinary listings and navigation.

These controls are related, but none is a substitute for the others. An Unlisted Post, for example, is not thereby a private Post.

Some access capabilities depend on application configuration. See Visibility & Access and Users & Permissions for the supported boundaries.

Maintenance without pretending everything happens instantly

Some work belongs to the content request itself. Other work is better handled by a scheduled maintenance run.

VerdinCore includes an orchestrated set of maintenance tasks for responsibilities such as scheduled publication, sitemap generation, media cleanup, cache maintenance, and analytics summaries. The application can record the outcome of these runs so that operations are not an invisible afterthought.

This is not a claim that every task runs continuously in the background. Maintenance depends on being triggered and configured appropriately. A scheduled publication or generated sitemap is only as current as the relevant job execution.

A configurable public page cache is also present for eligible guest requests. It is not enabled by default in the reviewed configuration, and its existence alone is not a performance benchmark.

These are operational choices with editorial consequences: a publishing system should make it possible to maintain the website over time, not merely save new articles.

See Automation & Maintenance and Caching & Performance.

Architecture as a product decision

The most interesting thing about the VerdinCore architecture is not the length of its technology list. It is how much of the publishing process those technologies support together.

An editor can focus on the article. The application handles content rules and relationships. The media pipeline prepares images for different contexts. The theme assembles the public experience. Maintenance tasks take care of recurring responsibilities when they run.

That integration is a deliberate choice, with trade-offs. VerdinCore is a proprietary, server-rendered product, not an open-source framework, a generic headless backend, or a promise that every conceivable capability can be plugged in without development.

Good architecture should be visible in what the product makes easier, not in how often its users have to think about the architecture.

The next pages explore two particularly important parts of that design: Themes & Rendering and Image Processing Pipeline.