A CMS consists of the management area (admin area), and the publicly visible area (front-end).
One very interesting difference between CMS and non-CMS sites is their treatment of a "web page".
In a non-CMS website, when you request a certain URL from the web server, the web server sees if the requested file exists, and if it does, it returns it. Very simple.
This is because there is a very clear definition of what is a web page, and that is tied explicitly to the URL. http://example.com/page1.html and http://example.com/page2.html are two distinct web pages, and they correspond to the files page1.html and page2.html in the websites document root.
In a CMS, the definition might be a bit blurred. Imagine you are in a news section of the site at http://example.com/news, and this shows an overview of all news snippets on the website. This might be defined as a page.
Now let's say you "filter" the news. Let's say there are 60 news items, and only 20 are shown on the /news page. To view the next 20, you might go to /news?page=2.
Is that a different page? In a non-CMS site, certainly it would be, but in a database-backed CMS, the definition of a page can be a little more blurred.
In a CMS, the URLs /news and /news?page=2 may not correspond exactly to two files on the server.
Because a CMS is database-backed, it is not necessary to have a separate physical source file for every page. For example, there is no need to have a /news file at all if the content of that page can be served through the root /index.php file instead.
When we create a new page in the administration area, there is a choice for the engine to either write a physical file that it corresponds to, or simply save it in the database.
A CMS should only be able to write to files that are in the public webspace under the strictest circumstances.
Instead of creating web pages as files, it is better to use a "controller" to read from a database, based on what the URL was. This reduces the need for the CMS to have write-permissions for the publicly visible part of the site, therefore increasing security.
There is a popular programming pattern called MVC (Model-View-Controller), which is very similar in principle to what a CMS of this type does.
In MVC, a "controller" is sent a request. This request is then parsed by the controller, and any required "model" is initialized and run with any provided data. When the model is finished, the returned data is passed through a "view" to render it in some fashion, which is then returned to the requester.
The CMS version of this is: The website is sent a HTTP request. This request is parsed by the CMS engine, and any required plugins are initialized and run with the HTTP parameters. Then the plugins are finished, they return their results to the CMS, which then renders the results using an HTML template, and sends the result of that back to the browser.
And a real-life example: The CMS is asked for /news?page=2. The CMS realizes /news uses the "news" plugin and starts that up, passing it the "page=2" parameter. The plugin grabs the information it needs from the database and sends its result back to the CMS. The CMS then creates HTML by passing it all through the template, and sends that back to the browser.
This, in a nutshell, is exactly how the public side (the front-end) of our CMS will work.
So, to rewrite this as an actual process, here is what a CMS does when it receives a request from a browser:
1. The web server sends the request to the CMS.
2. The CMS breaks the request down into its components—the requested page and any parameters.
3. The page is retrieved from the database or a cache.
4. If the page uses any plugins, then those plugins are run, passing them the page content and the request parameters.
5. The resulting data is then rendered into an HTML page through the template.
6. The browser is then sent the HTML.
This will need to be expanded on in order to develop an actual working demonstration. In the final part of this chapter, we will demonstrate the receiving of a request, retrieval of the page from the database, and sending that page to the browser. This will be expanded further in later chapters when we discuss templates and plugins.
There are a number of ways that administration of the CMS's database can be done:
1. Pages could be edited "in-place". This means that the admin would log into the public side of the site, and be presented with an only slightly different view than the normal reader. This would allow the admin to add or edit pages, all from the front-end.
2. Administration can be done from an entirely separate domain (
admin.example.com, for example), to allow the administration to be isolated from the public site.3. Administration can be done from a directory within the site, protected such that only logged-in users with the right privileges can enter any of the pages.
4. The site can be administrated from a dedicated external program, such as a program running on the desktop of the administrator.
The method most popular CMSs opt for is to administrate the site from a protected directory in the application (option 3 in the previous list).
The choice of which method you use is a personal one. There is no single standard that states you must do it in any particular way. I opt for choice 3 because in my opinion, it has a number of advantages over the others:
1. Upgrading and installing the front-end and admin area are both done as part of one single software upgrade/installation. In options 2 and 4, the admin area is totally separate from the front-end, and upgrades will need to be coordinated.
2. Keeping the admin area separate from the front-end allows you to have a navigation structure or page layout which is not dependent on the front-end template's design. Option 1 suffers if the template is constrained in any way.
3. Because the admin area is within the directory structure of the site itself, it is accessible from anywhere that the website itself is accessible. This means that you can administrate your website from anywhere that you have Internet access.
In this book, we will discuss how a CMS is built with the administration kept in a directory on the site.
For consistency, even though it is possible to write multiple administrative methods, such as administration remotely through an RPC API as well as locally with the directory-based administration area, it makes sense to concentrate on a single method. This allows you to develop new features quicker, as you don’t need to write administrative functions twice or more, and it also removes problems where a change in an API might be corrected in one place but not another.