It's no secret we use Drupal for all our CMS needs at the moment, but what might be a secret is the time it takes to setup a Drupal CMS for a new project. Form scratch, adding the modules, tweaking the chosen theme and maybe 1 or 2 hacks here and there all take time and we have spent months getting all this just right for some projects. Even the smallest project takes a lot of work to get it right. Today, when we install a brand new Drupal setup there are just over 40 Modules we need to install that all need setting up not to mention 2 separate APIs that need setting up.
So, we've decided to look at something new. We are going to create a brand new CMS and the goal is:
"As simple to install as WordPress, with the functionality of a fully upgraded Drupal install, built on the newest of tech."
If you think this might be a tall order, it is! But it's going to be an interesting project.
Project Management
First, things First, the basics. We will use our usual tried and tested project setup:
We have used this for many, many projects and it's simple and works.
Technology
For the tech stack we decided to look at the latest, interesting stack, but we want to allow the most people to be able to install this CMS with the least fuss. This means we want to allow as many types of Database as possible and as many types of hosting as possible. We want to have the Administration side simple, but performant and the tech to scale up and down as needed without any fuss.
With this all in mind, we decided on the following tech stack and architecture:
- JavaScript - No PHP for this project, it'll all be JavaScript
- Node.js - Will scale as needed using the right hosting
- Next.js - Works on the sever and the client side
- Database abstraction - Allows multiple databases depending on a setting
- JSON:API - A standard of API that will allow connections of many types of API consumer.
- API Gates - 3 gates to allow access to the API (session, HMAC or Token gates)
- Roles & Permissions (RBAC) - Admin created roles and tick box permissions for simplicity.
- Email communication - Not on a usual Linux system so not built in and 3rd party needed
- Themes - Ability to install themes to change the client side
- File storage - Allow a user to add images and files through the admin. Not on a usual Linux system so not built in and 3rd party needed
- Simple Browser Setup - No console or file settings.
- Simple Admin - Ability to disable and hide options that are not needed.
- Solid Authentication - Switch on/off registration of multiple types.
- Headless - Switch off the front-end and use the API only for use with separate front end/s
This would give us a solid Admin system that will allow a user or team to update only what they need as they need, but what about the content, how will that work?
Content
This is conceptual at the moment and subject to change.
Content could be simple, were we have a title, body and a date created, then maybe we have an author and allow users to see all this information, like a blog page, but what if the content is not a blog page? What if the app is a website and we want an image or multiple images? What if the app sells cars and the content is a car? Or a house? Or a product? Or any other content a user could think of?
Content Types
This is a CMS, so must allow different types of content and with different types of content comes different fields like cost, number of rooms or subtitle that an Admin user can add to the content type. So now we have content types that a user can create and field types that a user can also create to make up the content.
Format
Each field must have settings for how a user sees it and how the administrator sees it for example, published date, a user will see this as a date, but an Admin will see this as a calendar and a time in the future so they can choose when to publish. Then we might have a field called body text that a user will see as readable text and some images and videos, but the Admin will see this as a long field they can type in with buttons to change the look or add images or videos.
We must cater for this and more, much more. Then we look at how we should show the content. This will be a list of all the fields on a Content type that the Admin can drag up and down and maybe hide or some other visibility settings like groupings or blocks.
Menus
There will need to be a place for menus so we can say this content will automatically go to this menu and a full menu system for creating main menus, sub menus and any other type of menu. We'll need to include a way to add menus to different places on the layout like the footer, header, side menu, menus in menus, etc.
Permissions
Lastly, we need to add the Content types to the permissions so only certain User Roles can see certain content and this will need to be linked to the security and the menu system
So, we'll have Content type, Fields and Field Format plus menus and menu layout and finally content permissions that should take care of all this, then we'll need an import and export so Admins can create their own and share as needed.
Extras
These are the things we must have to make a CMS, but there may be many other 'extras' that we need to add to make this work as a user needs and this is where you come in, what have we missed? Stupid, simple or clever or complex, what is there that a user might need that we don't have here? Add a comment or contact us or add a comment on LinkedIn if you think of something we've missed here.
What to do with it?
Once we have this CMS in a solid state we will start using it for our clients, but what else will we do with this CMS? We could just add a licence and make it open source or add it to a website and package it up to sell it or keep it for ourselves.
Personally, I'd like to open it up and ask for help creating new database repositories and communication repositories and content types and anything else other coders might create. What do you think?
At the moment this is all just ideas, but this is a passion project and we'll rapidly be putting this together and adding more posts as we go.