DEV Community

Cover image for I Didn't Set Out to Build an Open Source CMS. I Just Needed One
Wellington Pragidi
Wellington Pragidi

Posted on

I Didn't Set Out to Build an Open Source CMS. I Just Needed One

Initially born out of practical necessity and real headaches, not from a romantic idea of something like “revolutionary free software”. I have been working on it alone for quite some time, creating, updating, and managing websites with the same system. I decided to open-source it because if it works well for me, it may work well for others too.

How the project started

I used to maintain an entertainment website that started on Blogger and later moved to WordPress. As the project grew, I needed to customize themes, create my own plugins, and extend its functionality. Eventually, the WordPress ecosystem started to make the process feel restrictive.

That was when I decided to build a system from scratch, tailored specifically to what I needed.

The problem came later: I decided to run that same system on my agency's website (webship). Suddenly, I had two similar but separate systems running in parallel. The only documentation that existed was my own memory and a few comments in the code. Updating both became a nightmare.

To avoid going crazy maintaining duplicated code, I decided to unify everything into a generic codebase. And it was this need to get things organized that eventually turned OpusCore into an Open Source project on GitHub.

(Note: I still take WordPress jobs when a client specifically asks for it. Let's just say I don't exactly enjoy it.)

I'm not trying to compete with established frameworks or CMSs, but rather to have autonomy. Of course, comparisons with WordPress are inevitable, first because of the problem described above, and then for the obvious reason that it is the most widely used CMS in the world. But this isn't about competing for its space. They are different approaches. WordPress has its enormous ecosystem. OpusCore follows a different path: more freedom to build without crutches and without asking for permission.

Technical decisions

Layered performance: I treat performance like security: you don't get a fast system by applying a single isolated optimization. It requires continuous attention at every layer.

Visible SQL (without excessive abstraction): I don't like the idea of hiding SQL behind huge ORM abstraction layers. In OpusCore, database queries remain visible, simple, and straightforward.

If maintaining code is already work, imagine hiding that code behind unnecessary abstractions.

Simple dependency injection: The system uses a container for instances, taking advantage of what modern frameworks do well. The difference from something like Laravel or Symfony is that here it is a lean class, without dozens of stacked dependencies.

Environment structure: The code does not use namespaces. It is organized and separated into three clear environments: web (public), dashboard (administration panel), and dist (distribution).

The goal is to provide the essentials needed to run a complete website without having to install anything from a few plugins to dozens of third-party plugins for basic features.

Native OpusCore features

Integrated SEO: Automatic generation and updating of meta tags and sitemap.xml, with configurable options directly from the dashboard.

CSS management: Stylesheets can be loaded in <style> or <link> blocks, with minification and conditional loading (when using blocks).

Context Architecture: A publishing block in the dashboard that can be injected into any route through a keyed function in the template.

Security and Users: Login routes are separated from the site's administration, with a user.php file for user profiles.

Optimized Media: Featured images are handled separately by entity, avoiding the creation of multiple unnecessary image sizes that clutter the server's disk.

Optional native features: An asynchronous comment system, conditional script loading, an SVG helper, and integrated sharing buttons.

The main reason I'm sharing this here is that developing and maintaining a system of this size alone for years creates the famous “blind spot”: you get used to your own code and stop seeing its flaws, sometimes even the obvious ones.

OpusCore has room for improvement, and it will. That's one of the reasons I opened the project to the community.

If you're looking for, or interested in, a tool and management system for building your own projects, rather than a tool that tries to build them for you, take a look at OpusCore.

Technical feedback, suggestions, and criticism are welcome and necessary.

GitHub:
https://github.com/wellingtonpragidi/opuscore

Download:
https://opuscore.dev/download

Top comments (0)