In the past tutorials, I have shown you how to create a flat file system content management system (CMS) using Go, Node.js, and Ruby.
In this tutorial, I am going to take the same design model and build a server using PHP. Since PHP isn’t a server by itself, but is usually paired with the Apache web server, I will show you how to set up the Apache web server inside a Vagrant virtual system.
Setup and Loading the Libraries
To start off, you need to have PHP installed on your system. Go to the PHP website and download the version for your system. Most Linux distributions and all Mac OS X systems have PHP already installed.
Next, install Composer, a package manager for PHP similar to npm for Node.js. To install Composer, type the following in a terminal:
With Composer installed, installing the libraries for the server is next. First, create a directory for the project with the files from Building a CMS: Structure and Styling or extract the download for this tutorial. Once set up, go to that directory and type:
These lines install the four libraries that make up the server: Slim Router is the routing library to process the incoming server requests, Parsedown translates Markdown to HTML, Handlebars is the templating library, and the Jade Library is a short-hand form of HTML that I use to make the index pages for posts.
Creating the index.php
In the top of the project directory, create the file index.php. The Apache server expects the main page for the site to have this name. In this file, place the following code:
The require statement allows PHP know how to load the different libraries installed with Composer. Then you tell PHP to use the LightnCandy and Jade libraries.
Next, you set up the Slim router by creating an instance of the Slim app object and setting the error handler. With the error handler set, you never get debugging information when an error happens. Therefore, while developing, you need to unset the error handler. But for production, comment out the last line with unset.
The next section of code is the creating of the $parts hash table for storing the pieces of information used in the templates. The program then adds everything in the site’s parts directory to the hash table. That way, you can create reusable pieces to add to any page.
The SetBasicHeader() function sets the return header for all of the pages. This sets the cache control functions and the name of the server. If you need more header information, this is where you would set it.
The $shcodes hash table contains all the shortcode functions for processing items in a web page. The functions that I wrote here are simple, but they can be more complex if needed. This gives a way of embedding more dynamic code into your web pages.
The processShortCodes() function will find, execute, and insert the results of a shortcode. This function finds all shortcodes in a page by calling itself recursively on the enclosed contents and the rest of the page.
A shortcode has the following syntax:
The name is the name of the shortcode, arg is the arguments passed to the shortcode, and contents are the part of the page the shortcode encloses. The -[ and ]- act just like the < and > in HTML.
The next section contains the helper functions for adding helpers to the Handlebars template engine. The helper functions are save, date, and cdate. The save function takes a name and some text. Anywhere the name given is in a macro, the text given will replace it. The date function takes the current date and formats it according to the formatting string given. The cdate function takes a date and a formatting string. It will put the given date to the given format.
The next function is ProcessPage(). This function takes the layout for the page and the contents of the page. It will combine them using the LightnCandy Handlebars template engine. The resulting page is then searched for shortcodes. The resulting page after that is run through LightnCandy again. The browser receives the output from LightnCandy.
The page() function determines the page to send to the user. The function receives the page address from the router and calls ProcessPage() to create the page.
The posts() function works just like the page() function for post contents. The router passes the post type, blog, and page address values from the route. This function then uses ProcessPage() to create the page to return.
The figurePage() function gets the correct page content based on the name given. The function will look for a file with the .html extension. If there is one, it reads it in and sends it to the calling routine.
Next, the function looks for a .md extension. If there is one, it reads it, converts the Markdown to HTML, and returns it to the calling routine. Next, the function sees if there is one with the .amber extension. If there is one, it reads it, converts the Jade syntax to HTML, and returns it to the calling function.
This route function maps the main or home page for the web site. This will fire for all requests to the domain name with or without a ’/’.
This route definition maps to the specific request: /favicon.ico. This gives the favicon for the web site. It returns the image “/images/favicon.ico” in the site directory.
This route gets the compiled style sheet and returns it to the requester. The compiled style sheet is always “/css/final/final.css”.
This route always returns the compiled JavaScript file found at “/js/final/final.js”.
This route processes all requests for images. The {image} tells the router code to give the image name to the function. The call to the $request->getAttribute() function retrieves the value.
This route gets all the video requests and sends them to the browser.
This route returns a list of blog entries and their summaries. The {blog} variable will be the blog name for which to list entries.
This route gets an individual blog entry. {blog} is the name of the blog, and {post} is the blog entry to get.
The news router requests work just like the blog router requests.
This is the generic page route. All requests that do not match any of the previous requests will trigger this request.
This last bit of code starts the server. This function will do all the processing for the request. Upon returning, the PHP interpreter will end and close the connect to the user’s browser.
This PHP server works completely differently from the other servers in this series. This routine starts and ends for each request, while the other servers keep processing requests. Therefore, this PHP server takes longer to process requests due to loading and unloading of the routines.
Getting the Server Up
Now to set up the server. One of the easiest ways to get an Apache and PHP stack is to use Vagrant. To install on a Mac, use Homebrew with this command:
If you have a Windows or Linux system, use the installers from the Vagrant website. The website also has a standalone installer for the Mac, but by installing with Homebrew, you can get automatic updates by running:
Once installed, create a file named Vagrant in the project directory. In this file, place the following code:
This is Vagrant’s configuration file. It tells Vagrant what virtual machine box to build upon, the script to run to set up the box for your server, what ports in the virtual machine to map to ports on your main computer, and the folder to sync to the /vagrant folder in the virtual machine. You need to set the full path to the directory on your computer instead of /full/path/to/code/directory.
Next, create the file bootstrap.sh and add this script to it:
This script will load in the Apache web server and configure it. With Apache configured, it then installs PHP version 5, sets up the root directory for the server, and launches the Apache service. All of this will configure the virtual machine as needed for this project and have the root directory of the server getting files from your project’s directory. Any edits you make in your project directory are instantly available to the server.
In the project directory, create a file named .htaccess and place this code:
This tells the Apache server how to handle requests for this site and for automatic caching of requests. The index.php file gets every request to the server.
Running the Server
To start the server, run the following command in the project directory:
This will download the virtual machine if it hasn’t already on your system, run the provisioning script, and launch the server. To view the site, open your browser to http://localhost:8080.
The browser should show the above page. The server is now online and ready for your additions.
If the web site isn’t viewable, you should check the permissions for all the files in the site. OS X often has them set to own readable only. You need to make them world readable with the following command in the project directory:
That will ensure that the Apache server in the virtual machine is able to read the files.
To stop the server, run the following command in the project directory:
To learn more about using Vagrant, please read the Vagrant Documentation. You can also check out the many Vagrant tutorials here on Envato Tuts+. I used the tool Hobo for creating my Vagrant files. It is a great tool for configuring, running, and managing Vagrant systems on OS X.
Conclusion
Now that you know how to build a simple yet powerful web server using the PHP language, it’s time for you to experiment. Create new pages, posts, embeddable parts, and shortcodes. This simple platform is far faster than using WordPress, and it is totally in your control.
Unlike the other web servers in this series, this PHP-based CMS can run on any shared hosting account. I am using it for my ministry’s website on DreamHost. I haven’t optimized the pictures any, but it still does fairly well. Tell me about your server in the comments below.