Don’t do this. Install WordPress. Hug your family. Get some rest.
If you’re like me—and I know I am—you are not going to take my advice. You probably searched on google how to make a CMS. You’re committed.
CMS’s are a solved problem. But so is checkers. Lets begin.
A.K.A. Content Management System
A Content Management System (or CMS) could be anything from a form that can edit pages on a website to enterprise grade software that is used by large media conglomerates to track all their digital assets. For our purposes, we are going to build a CMS that can allow someone to update the contents on a common website. Foundationally, there is the website that is public and an administrative area (or Admin) that allows certain people to edit the content of the website. These people will need some sort of login to access this area. In this series, I will refer to the public portion as the “Website” and the administrative area as the “Admin”. As you will see, the Website and the Admin will be two separate webapps that share the same data.
Why
Even for very simple websites it makes sense to have the content stored in a database instead of on the file system. New pages, posts, comments, images, videos, etc., can be added simply without copying a file on the server. Creating a password protected section of the website that can update the database is the next logical step. Because of this, there are already many options out there for ways to update your content. There are hosted services, software like WordPress, individual plugins, even frameworks. Most people should never spend their time building their own admin. But again, you are not most people 😉
How
UX is critical to website administration. So often the responsibility of maintaining the content of a website goes to regular folks who are not good with computers. They are not going to sign into your pretty admin and have a object-oriented mental model of the components of the site. They will be task oriented. There’s that thing on that page that needs to … something.
The regular folks will not want to change every possible thing, either. The more customizations you give them, the less likely they are to 1) use the admin, 2) successfully complete their tasks and/or 3) enjoy using the admin. On the other hand, the client (the one that made the decision and/or the one that financed it) will want everything. You need to use your best judgement. Determine what features your client needs, add in only the wants that don’t hinder the needs, and push back on everything else. If your client insists on something that will ruin the UX, you have three choices: 1) find a reason why it will push the project over budget, 2) leave it till the end—maybe a pressing deadline will chop it off, or 3) bury it deep in a submenu.
Every website is different, but try to find the best logical heirarchy for the tools in the admin that are both task oriented and object oriented.
Setup
There are zillions of ways to do this. I can do—and have done—several. Lets do this one with this setup:
- Linux OS
- git
- Apache 2
- MySQL 5
- Ruby 2
- Ruby on Rails 4
- ERB
- SASS
- AngularJS 1.3
- Underscore 1.5
I am not going to go through how to install any of this, only how to build with them. I am building this on Ubuntu 14.04LTS, but that shouldn’t matter. There are many different distros, frameworks, languages, etc. Other articles have been written about them. Google is just a click away.
Rails
Since I am using AngularJS, Rails is just a simple webservice. I am using ERB just to start the app, but AngularJS takes it from there. If your app requires things such as non-JavaScript SEO, then a lot of your work will be duplicated in ERB and Angular. That is something you need to think about. Of course, I have done it.