Aloia CMS: The road to version 1.0

If you've been reading my blog posts for a longer time, you might remember that I'm working on a CMS, something I never thought I would do. In this post, I will go over my reasons why I'm building my own CMS again because they've changed a little bit since the last time I wrote about it. This post is a little different than my other posts as I usually pick a topic and do a deep-dive. This is more of an announcement and reflection in one in the past few weeks while working on Aloia CMS.

I've published a short announcement on the Aloia CMS website where I explain that the first stable version is not far away. You can read about "The road to version 1.0" on the Aloia CMS website. This post is not about the internal changes of the CMS, because frankly, they're not all worked out yet. Over the past few weeks, I've worked on the project quite a lot because there were things that annoyed me about the internal structure and expandability of the CMS.

Scratch your own itch

Over the past few weeks, I've worked at making the CMS less of a headache for myself. I claim the project is all about developer experience and relieving the headache of dealing with content when working with a CMS. If you never look at the source code, the CMS is quite nice to use, until you want to update the content. Retrieving data is simple and straightforward. This all comes from the fact that the CMS was designed to convert Markdown files to PHP classes and HTML code. That part of the project received a lot of attention because I've been building websites on top of the CMS. The quicker I can create and maintain websites the better. Recently I've been looking at adding features to some of the websites that run on the CMS and came to the conclusion that it's going to cause a lot of headaches.

The included content types (Page, Article, Content block and Meta tags) dictated everything in the CMS and were wired throughout the code. This allowed me to very quickly create websites that dealt with these content types. On the other hand, adding new content types meant I had to add more code to the CMS itself. There was no way to extend the base functionality from the CMS and create your own implementation in your projects. This was never a problem because I didn't need to do that. But now, with the planned features on some of the websites, I need a way to extend the base system and create new content types in the systems that use the CMS. This is where the first stable version comes in: get out of the way and allow the developer to extend the CMS if needed.

Streamlining internal processes

Another reason to go for a major version change is to be able to apply some breaking changes. Currently, you need at least 2 files to be able to display an article (like this one): a config file, and a markdown file with the content. This was initially done because of two reasons: 1. keeping content and metadata separate and 2. I didn't know front matter existed. It wasn't until I started to work with Jekyll for the Aloia CMS website that I found out what front matter was and how powerful it was. This helped me realize that keeping content and metadata separate was a terrible idea. The metadata is about the content and only that content. If you were to see it as a database relationship it's a 1 to 1 relationship. There really isn't a point in keeping it separate. Being able to combine these two into a single file allowed me to create a very extensible system. All content types now have exactly the same structure: front matter and content in a single file. This means I can create a base layer that parses the front matter and keeps it in memory as attributes and keep the content separately.

The included content types are now all extending the base layer, which means adding new content types is as simple as adding a new class to your system and pointing it to a folder. From there you can interact with the content types however you want: retrieving and updating/saving is taken care of for you. The fact that everything extends the base class makes maintenance much simpler: a change in one part will be applied to everything.

An updated version of "Why I'm building my own CMS"

In an earlier post "Why I built my own CMS" I described why I built my own CMS and why I never expected I would do that (again). Most developers, including myself, find building a CMS very tedious because it's a boring task since it's often a lot of copy/paste work. I've now changed my mind a little bit, as most of the copy/paste work is either done or isn't needed for this project. Since my CMS doesn't come with a user interface I don't really have to do a lot of copy/paste. When starting this project, when it wasn't a standalone CMS yet, I never intended to build a full-blown CMS, so I never had that negative mindset when developing the project. Now that all content has the same format, I let the code work for me and not the other way around.

I realized when working on these recent changes and getting ready for the 1.x release, that I'm creating a product that works perfectly for my workflow. Any time I can do something to improve my workflow and get on with my day, I'm enthusiastic about making the change. That's also one of the reasons why I work on Linux 95% of the time: it does what I need it to and doesn't get in my way. The CMS is built to be painless and take away the burden of managing content, so if I can help myself and others achieve that goal I'm happy to do it.

Conclusion

I've been working on making my CMS work for the developer, rather than the other way around. I've made a lot of changes to allow the developer to shape the CMS around his or her workflow and be easy to extend and interact with. My primary goal for the CMS is to make managing content a breeze and to just get out of the way. The content is the most important part of the CMS, not the bells and whistles. If you want feature-rich content management systems, there are plenty of them out there and I'm happy to point you to some of them. Aloia CMS is for you if you want a lean content management system that integrates into your Laravel project, manages your content, can be extended with your own features, and just doesn't bother you.