How to build your own Multilingual PHP MVC CMS from scratch - Part 1 - Introduction

While the MVC architecture has been around for quite a long time, it somehow took longer for PHP than for other languages like C++ to come to embrace it, allowing it to serve as solid ground in a growing number of popular CMS's and Frameworks. But even if nowadays the number of Web developers that can truly claim they have never heard of CMS's like Drupal or OpenCart is becoming increasingly seldom, you, as a programmer, may have often been wondering, as I once have too, just how does the CMS your Project Manager has assigned you on really works, so you could start making the most out of it and stop having to loose half your evenings, week-ends and personal life just to barely keep up with or learn it, let alone the personal stigma that not getting along too well with a custom in-house CMS may at times create in a developer's life.
Since the best way to understand how a device works is by creating one yourself, in this beginning twelve-part series, I will be teaching you how to build a complete and working lightweight Multilingual MVC PHP5 CMS from scratch, that you will be able to use for your own purposes or that will at least leave you with a better insight on how those things really work, get you more pro-efficient. And we will only be using free software tools throughout the whole course of these series.
But during this very first part, and once I have discussed the minimum knowledge required to attend these tutorials, i will be defining what the acronyms CMS and MVC stand for, then I will be reviewing the reasons as to why building your own CMS should only be an exciting, rewarding and beneficial experience. I will also be listing the software you will need and finally, I will expose and explain the basic folder structure around which we will be developing our new project.

Target audience

Although being a senior PHP developer is definitely not mandatory here (especially that after all, we all have to learn things before we can claim we know them), you should at least be confident with the use of classes and of some of the most common practices/algorithms in PHP/Web development, so that, you should not be a total beginner. This however does not mean beginners are not welcome, on the contrary they are, as beginners, always encouraged to read code, especially code they cannot figure out, for their own benefit.
You should have a fair understanding of what Object Oriented Programming means, and ideally of software design patterns, but this is not essential for now, as it will be discussed later in the series. You should also have a strong interest and the time required to build a complete CMS from scratch of course.

So, what does CMS stand for and what is it used for anyway?

For you to properly understand what a CMS is, I will first define what a Framework is and what the difference between the two actually is. In Web development, a Framework, hear a Web Framework or Web Application Framework, is a collection of files and folders (software) arranged according a specific structure or architecture and in such a way as to allow, to a certain degree of abstraction, for the quick/rapid development of Web applications (most commonly Websites) and which aim is basically to reduce the overhead traditionally associated with Web development. In other words, a Web Framework can mostly be seen as some sort of abstract software that would allow someone building a complete full-fledged site ready for production and in the least possible development time. For the sake of this tutorial, this is the definition we are going to stick with for now.

How does a CMS compare to a Web Framework then?

A Content Management System, or Web CMS in this context, simply put, is a Web application (most commonly a Website), that could have been built on top of a Web Framework, or not, but that is designed and optimized to help manage content easily and that ideally provides a certain level of customization capability, as, a CMS like for example Drupal, should be manageable/customizable by a non programmer, eg: the admin of the site can add/edit new articles, change theme etc., without having to know about its underlying structure. So a CMS, in essence, offers an extra layer to what a Framework usually provides, and can be viewed as a ready-made Website/Web application that can be deployed as is. Now for some more advanced customization, programming knowledge may be required.
So, while CakePHP is a Framework (by the definition we have used at the beginning) that could well serve as the basis for developing your own CMS, that is, depending on what your needs as a developer are anyway, it does not, by essence, offer out-of-the-box content-management oriented functionality like Drupal for example does and can only be interacted with by a programmer.
Now, it tends to get complicated when you know Drupal is called either a CMS, a Framework or Web Framework or even Web Application Framework (WAF), when you know that CakePHP is a rapid development Framework(as explained above) but that the company's built-in CMS you may be struggling with all day and that was created out of mostly popular CMS's parts is called a Framework too by everyone in the company you work for.
Frankly, most people's definition of a Framework/CMS nowadays is that it's some software/script that's to some level of abstraction is meant to ease/speed up the process of developing/creating a Web site or Web project, and it's still true in its own right.
Finally, popular CMS provide many functionality you don't necessarily need or use, and that are likely to increase the risk of bugs, vulnerabilities and so forth. While with a more abstract Framework like CakePHP, you do not have to build feature you don't need.

And what about MVC in all that?

MVC, which has been around for some time with languages other than PHP, and which stands for Model View Controller, is a type of software architecture that is designed to clearly separate an application(a Web application here) into three distinct parts: the control, the model and the view. The way we will implement it in our project, basically, the controller receives an input (via the index file) from the mouse or the keyboard for example, addresses the corresponding model in order to get the needed data and/or to process it according to the business logic contained in the given model, which then sends it back to the controller. Then the controller transmits that data to the view, which is responsible for managing visual display on the application, thus, how the site or app looks like. In other words, the controller will act as an interface between the model and the view, allowing for a clear logical separation between those processes, and most evidently for a cleaner PHP code, not being obfuscated by HTML or inline CSS snippets. Now, as the MVC pattern itself however does not define how the data should be passed between entities, it is therefore possible to find Web applications that use this architecture in a different way, having for example the model updating the view.
Regardless of how it is being used, such an architecture represents an evolved way to design an application and differs from the three-tier organization model, somehow very close in essence but where applications are structured around three layers: the client(presentation), the application(logic), and data access(database). That said, MVC is meant to make both the programmers and designers life easier, as, the designer can concentrate on working on the visual aspect of the project, generally through template files, while the programmer takes care of the business logic, eg: PHP code found in models. The controller of a PHP-driven CMS contains PHP but does not hold, or should not hold any element of your business logic.
Now that we have explored the main concepts around which we will be developing our application, a little word again on what we will exactly be building during these twelve-part series. We are going to build a simple lightweight Multilingual CMS that follows the MVC pattern and that will act as finished Website, ready to be deployed and administered by non-programmers. Customizing it for various other small-scale projects should only require little programming knowledge, if any at all. It should be perfect for a small-scale organization.

Fine, but why building your own CMS anyway?

Let's face it, creating your own CMS does require a lot of spare time, BUT

• as a hobbyist, it is a great way to learn about the inner workings of CMS's and to learn about the MVC structure, which is growing enormously in popularity
• as a PHP professional working inside a company, it will help you better cope with the company's custom-built CMS you already work on daily, if you do.
• as a PHP professional working independently and looking to get things further, it will help you create the custom CMS you perhaps have always dreamed of, tailored to almost instantly meet your most recurrent client prerequisites, but best of all, that you will fully know and understand, thus allowing you to cut down on development time dramatically, leaving you more time to focus on other aspects of your activity.
• There are lots of great free popular CMS's on the market, that some developers even specialize in customizing, but for the others, wasting hours looking to solve problems that you can't put your finger on just because you haven't coded it yourself and there is simply too much data to deal with - is never that fun, and gives you one more excellent reason to give it a go and see for yourself how much you could benefit from building your own CMS build from scratch.

Now, before we start getting our hands all greased up, let's review the tools you will need to to be working with:

• Your favorite programming editor.
• PHP 5 (with GD and jpg support enabled) - version 5.4 to 5.6 should be fine.
• Apache HTTPd server 2.4, version 2.2 should be fine too.
• MySQL Community Servers version 5.5 or 5.6 are good choices for our project.
• An image editing program: I will be using the Gimp 2.8, but you could still be using Photoshop or alike if you prefer.
• Optional (although strongly recommended) :
  • A debugger like XDebug and a tracer such as Valgrind.
  • Composer to help you manage our plugins (PHPMailer/TinyMCE) dynamically.

Basic overview of our project's folder structure

So let's take a brief look at what our overall folder structure is going to look like

Our project's general folder structure

• From the image above, you can see the admin section has its own standalone folder.
• Config.php will be our config file for the whole project, and serve for the admin as well. Some settings do rely on the database but most of the configuration will be found in config.php though, including database access parameters.
• The /application folder, as it exists in /admin too, contains our controller and model files. It is the core part of our application, thus the name application. It also contains our base controller, registry, router and template engine, which we will review in the next part of our tutorial, while studying the index.php file.
• The /languages folder will hold the needed translation files, country flags and everything needed to manage encoding as well as Javascript translation strings, all on a per-language basis.
• In /vendors we will simply store the plugin files needed for our project. In fact, composer will store them for us, as we will only have to pull new versions of our plugins from the command line, whenever needed. The plugins we will use are TinyMCE 4 (Wysiwyg editor) and PHPMailer 5.2.6.
• The /public folder will contain our Javascript files.
• In /themes, we will store all the CSS files, template files and site images(site's visual identity) pertaining to each existing theme.
• At root level, we also find the index.php file, which actually is, or should be, the one and only entry point to our application, as all user requests should reach the index first, or be redirected to it, no matter what.
• about.php, provided you launch it manually, will check your server configuration, and more specifically, it will check your Apache/PHP/MySQL versions, as well as your GD library version, and if you happen to have support for JPEG (used for the captcha image in the registration form).
• The /list folder will contain lists like country or language lists and the tools to dynamically manage them.
• The files named composer.json and composer.lock are inherent to Composer. They contain data necessary to manage our plugins. Again, we will only have to use the command line to pull in the updated plugin files whenever available.
• The second multi-level screen capture stops at the beginning of the vendor folder because there only remains the content structure of our plugins, which will will not take interest in.

To help you understand the structure better, here is a multi-level folder representation of the same project, without the files.

Multi-level view 1/2

Multi-level view 2/2

As you can clearly see, the files and folders that are inside the /admin folder repeat almost exactly the same folder structure as we have just reviewed. The admin in itself will be like some sort of modified front-end within the front end.
So far, we have discussed who the minimum knowledge requirements for this tutorial, defined what the acronyms CMS and MVC mean and explained what differentiates a Web CMS from a Web Framework. We have also reviewed the reasons as to why choosing to build your own MVC CMS can be a very exciting and rewarding decision to make for yourself, before enumerating the tools we need to get started, and ultimately engaged in reviewing the core folder structure of our project. In the next chapter, I will be focusing on what I have called earlier the one and only entry point to our application, that is the index.php file, slowly evolving toward the /application folder, which represents the core system of our CMS, containing all the controller/model classes that will empower the MVC structure in our project.

This article first appeared on Thursday the 23rd of October 2014 on RolandC.net.