PhpOG CMS: Built from the ground up

Update 18JUL26: I have completed deep performance and security audits via AI, along with manual, human, line-by-line audits. I am very happy with the results and excited that my dream is nearly ready for release. Now I am moving on to further module and widget development. After all, what good is a CMS without the content? I would put up a live community demo, but my tiny VPS cannot handle too many database-driven sites, as the cache preloader uses a lot of CPU and RAM relative to my little VPS. I am hoping to expand from 2 cores and 2 GB of RAM to 8 cores and 16 GB of RAM soon. If you want to help, hit that Heart Icon at the bottom-left to donate for a new server upgrade and I will ensure you get a first look and personal tour! After that, the real fun begins. To show off the CMS's versatility, I will be powering all of my personal passion projects with PhpOG CMS. I will let my users be the judge of the project. Stay tuned. After a weekend of rest, I have a lot of mods and widgets that are nearly ready to package up, from email hosting mods to full Yahoo-style community-building mods and, of course, EComm mods.

Update 15JUL26: I decided to speed up the release of the PHPOG CMS Core and Base modules and am currently performing heavy beta testing manually, as well as via Aider+Gemini and ChatGPT, to ensure everything is stable, secure and efficient. I'm not a fan of using AI for development, but it is exceptional for finding issues and bugs. Performance is already spot-on, with 100% scores across the board on Google PageSpeed and other benchmarks. Stay tuned. Great things are coming.

### Back to the article ###

I’ve been working quietly on something much larger than the PhpOG Learning Library, and the time has finally come to say what it is.

PhpOG CMS is now in active development, with core systems already working, new modules being built, and several major modules moving through beta and final testing. The target for the first public stable release is Christmas 2026.

This isn’t a project I thought up last week because I got frustrated with WordPress. I first planned it in 2004, when the web was still young enough that most people believed the major content management systems would simply keep getting better.

I saw a different road ahead.

I Saw the Problem Coming

WordPress, Joomla, and Drupal all played an important part in building the modern web, and I’m not going to pretend they didn’t. I’ve used the familiar systems, studied how they work, and watched them grow over the years. They solved real problems, but as they expanded, they also became heavier, more complicated, and more dependent on third-party code written by people with completely different standards.

What starts as a simple website can quickly turn into a stack of themes, plugins, frameworks, page builders, update notices, subscriptions, compatibility problems, and security concerns. Before long, the owner doesn’t really control the website anymore; the collection of dependencies controls it.

I believed that would happen, and I believed there would eventually be a need for a new system built from the ground up with the common-sense features already included.

Not another framework wrapped around a framework, and not another empty core that needs twenty plugins before it can properly handle SEO, caching, security, forms, users, and normal administration. I wanted one consistent architecture, one development philosophy, and a modular system where every part was built to work with the rest.

That’s what PhpOG CMS is becoming.

Why I Kept It Quiet

I kept this project private because ideas get copied quickly, especially when someone can take the surface of an idea without understanding the years of thought behind it. I didn’t want to announce a broad plan, watch pieces of it appear elsewhere, and then spend my time explaining that I had already been building it.

There have also been people who tried to interfere with my work or prevent certain projects from moving forward. I’m not going to publish names, technical details, infrastructure information, or anything else that could create a security problem. Some things are better handled quietly, and the work matters more than the noise around it.

So I kept building.

The foundation is now far enough along that I can publicly confirm the project, its direction, and the release target without exposing the parts that still need to remain private.

This Isn’t Just a List of Planned Modules

PhpOG CMS is being built as a true modular platform. The core handles the foundation—routing, templates, database access, administration, permissions, security, caching, configuration, and module management—while each major feature remains contained within its own module.

The long-term module library will grow into the hundreds, but this announcement isn’t about a wish list. Core modules are already operational, more are in active development, and several are in beta or final testing right now.

Current development and testing includes:

• A complete blog and publishing module
• Full SEO controls for titles, descriptions, canonical URLs, indexing, Open Graph data, and structured publishing
• Automated search-engine submission through supported APIs
• XML and human-readable sitemap management
• Static-file caching, cache warming, expiration, cleanup, and route exclusions
• Community accounts, profiles, groups, discussions, moderation, and internal group tools
• Customer registration, account management, orders, and protected downloads
• Digital product libraries and website marketplace tools
• Forms, messages, support workflows, and administrative queues
• Subscriptions, billing, licensing, and SaaS management
• Email hosting, mailboxes, aliases, forwarding, and domain email tools
• Knowledge-base, documentation, and customer-support modules
• Developer libraries, code publishing, and educational systems
• Server, domain, DNS, and hosting administration integrations

Some of these systems are still being expanded, while others are already in the final stages of testing. The Christmas 2026 release won’t be an empty shell with promises attached to it; it will be a working platform with a serious collection of usable modules.

Common Sense Shouldn’t Require Extra Plugins

A modern CMS should already understand the basics of running a real website. Clean URLs, canonical tags, metadata, sitemaps, caching, permissions, protected files, responsive layouts, and secure sessions shouldn’t require a scavenger hunt through an extension marketplace.

PhpOG CMS is being designed with those responsibilities built into the foundation, including:

• Search-engine-friendly URLs by default
• Canonical URL and redirect controls
• Page titles, metadata, Open Graph data, and indexing rules
• XML and HTML sitemaps
• Static page caching and automated cache warming
• Browser caching and local asset delivery
• Secure administrative sessions and permission controls
• Module locking, enabling, disabling, and health checks
• Separated administrator, customer, and community systems
• Protected downloads delivered through controlled requests
• Responsive public and administrative templates
• Maintenance, diagnostics, recovery, and scheduled task tools

These aren’t luxury features. They’re part of the normal responsibility of a content management system, and they should be there before a website owner has to install anything else.

Static Caching Without the Bloat

The static-file caching system is already working and being tested through real PhpOG projects. When a public page doesn’t need to be rebuilt for every visitor, the system can generate a static version and serve it without repeatedly running the same database requests, controllers, and templates.

The cache manager can scan public routes, warm important pages, clear expired files, rebuild selected areas, and exclude anything that must stay dynamic. Administrative pages, customer accounts, private community areas, forms, checkouts, and other sensitive routes are kept outside the public static cache.

I designed the cache manager’s administration in the same all-in-one spirit that made the classic WordPress All in One SEO plugin familiar and useful. Related controls are kept together, the purpose of each setting is explained, and the administrator doesn’t have to dig through unrelated screens to understand what the system is doing.

The code itself is original, modern, and written specifically for PhpOG CMS. It doesn’t use WordPress code, it doesn’t depend on a caching framework, and it doesn’t need a third-party package. It’s built with vanilla PHP and designed around the PhpOG architecture.

The goal isn’t to create a wall of settings that looks impressive. The goal is to make the website faster, while keeping the process clear enough that the person running it still understands what’s happening.

Administration That Feels Familiar

The main administration layout follows the practical organization people already understand from systems such as WHM. Related tools are grouped into clear sections, modules have their own administration pages, and each page explains what it controls before presenting the settings.

I’m not interested in making normal tasks confusing just so the interface can look different. Some of the great systems of the past got certain things right, and there’s nothing wrong with learning from what worked while building a cleaner system underneath it.

An administrator should be able to tell what a module does, whether it’s active, which permissions it uses, what routes it creates, what data it controls, and whether it affects caching. The system should explain itself instead of forcing someone to study the source code before they can safely operate it.

Modular Doesn’t Mean Everything Loads

PhpOG CMS is meant to offer a large module library without forcing every website to become large. Installing a blog shouldn’t load community code, and running a community shouldn’t automatically load commerce, email hosting, or SaaS tools.

Customer accounts are separated from administrator accounts. Community permissions are separated from system administration. Public publishing tools are separated from private operations, and protected downloads aren’t placed in a public folder where someone can guess the path.

That separation is part of the performance model, but it’s also part of the security model. A website should only carry the weight and exposure of the features it actually uses.

Built With Vanilla Code

PhpOG CMS is being built with PHP 8, MySQL or MariaDB, Apache, Linux, vanilla JavaScript, HTML, and CSS. It doesn’t require a PHP framework, a frontend framework, jQuery, a page builder, or a pile of outside interface libraries.

That doesn’t mean I’m against modern development. It means I’d rather use the modern capabilities already available in PHP, browsers, and servers instead of automatically placing another dependency between the system and the technology it controls.

Dependencies can save time, but they also transfer control. They can be abandoned, compromised, changed, or turned into paid services after a project has already built around them. PhpOG CMS is being developed so its core behavior remains under its own control.

More Than a Publishing Platform

PhpOG CMS won’t be limited to pages and blog posts. A small publisher may only need content, SEO, forms, and caching, while a community may add users, groups, discussions, moderation, and private tools. A business may add customers, billing, subscriptions, protected downloads, support, and email services, and a software company may add licensing, hosted applications, and SaaS administration.

The core doesn’t have to become bloated simply because the module library is broad. A broad system and a bloated system aren’t the same thing. Bloat happens when every installation is forced to load and maintain features it doesn’t use.

That distinction has been part of the plan since the beginning.

Testing Is Already Underway

The system is being tested through real PhpOG projects and real administrative workflows, not just sample pages built to make screenshots look good. Current testing covers routing, static caching, module isolation, templates, database-backed content, SEO controls, customer separation, protected file delivery, permissions, mobile administration, desktop administration, and realistic installation and configuration work.

Some modules are still early in development, some are fully operational, and others are already in beta or final testing. Between now and Christmas 2026, the work is focused on finishing those systems, strengthening the boundaries between them, and making sure the public release is stable enough to build real projects on.

Some technical and operational details will stay private until the time is right. That isn’t secrecy for attention; it’s common sense while a large project is still being developed and protected.

Christmas 2026

The first public stable release of PhpOG CMS is planned for Christmas 2026.

That release won’t be the end of development. It will be the public beginning of a platform whose original plans go back to 2004, and whose design has been shaped by more than two decades of watching the web grow, improve, repeat old mistakes, and bury simple work under unnecessary layers.

I waited until I had the experience, the tools, and the independent infrastructure to build it the way I believed it should be built.

Now is the time.

PhpOG CMS is no longer just an old plan I kept to myself. It’s being built, it’s being tested, and it’s coming Christmas 2026.