Building a Site Engine with PHP, Part 1

Content management systems are becoming very popular, but what if you took it a step further than that? That’s exactly what I plan to show you how to do in this series of articles. I’m going to explain how to build a site engine. A site engine is a core code base and database that can run multiple sites that are completely different while all running in unison, using all the same code, yet separate from each other.

A while back, I created a website with object oriented PHP. Then I thought to myself, “Wow, this site works great. It’s got low parse times, and its structure is solid.” At that very point I thought it would be great if I made a centralized code base and database that would run multiple websites. I decided that it would have to have a template system because who wants all their websites to look the same. Also, it would need a plug-in system so that each site had its own type of functionality, after all what would be the point of different sites if they all did the exact same things. Authentication would be also need to be implemented, due to the fact that the administrator would probably want a secure way to administer the sites. Each site would need its own content system, which would prove to be the most confusing part of the entire project, because I wanted it to all work off the same code base and the same database. However, I found a seemingly logical solution that may confuse some people, but I think I can explain it fairly well.

In this first article, I’m mostly going to outline the site engine. I will go over what it does, how it does it, and why it does what it does. In the following articles in the series, I’ll get into the actual technical aspect of all the coding. The articles are as follows:

  • Article1: General Outline and Preparation
  • Article2: Plug-in and Module systems and General Functions
  • Article3: Authentication and Block Systems
  • Article4: Template and Loading Systems
  • Article5: Building a site and Administration samples

{mospagebreak title=First Things First}

The best thing to do first, I say, is to get out some paper and one of those sticks that write stuff…. Oh, yeah, a pencil! Then literally draw out a diagram of your plan on coding. No need for a bunch of words, just horribly sketched boxes and lines, labeled with each elements name. I decided that I would need to first create, in order, the following things for my site engine:

  • Database
  • Main index page
  • Plug-in system
  • Module system (plug-ins for the plug-ins)
  • Content blocks

So, trying to stay advanced, I grabbed my $5 mechanical pencil, and I sketched it out like this:

Pretty isn’t it? Basically, what I have here is my index page calls the database, selects all the plug-ins that are initialized for the specific site, then the plug-ins select all the modules that at initialized for the selected plug-ins. Then the modules select all the content blocks that are initialized for the selected modules with a few more parameters checked, such as authentication level and specific page. Then it’s all returned to the index page to form the website. This diagram is an easier read.

Index >–call plug-ins–> Loaded Plug-ins >–call modules–> Loaded modules >–call block–> Loaded blocks >–return data–> Index displays data

This has shown to be a very solid method of doing a plug-in system, due to the fact that if a plug-in isn’t loaded the content block that depends on that certain plug-in won’t load and cause nasty errors. Now that the plug-ins have been briefly described, I’ll talk about the authentication and block systems.

{mospagebreak title=Better Than your Local Rental Security Officer}

Proper authentication is probably the most important thing in this project. If you have improper authentication, you’ll have improper block loading. It could be your administration block loading to visitors, which I’m sure you wouldn’t like, although the visitors might get a thrill. 

I’ve never really been one to like sessions, but some people swear by them. I’ve always felt cookies have more capability, understanding that you’d probably be safe to say that I use cookies for authentication purposes. That’s why we’ll go over using cookies for the authentication, and why we’ll use them.

The idea behind my method of authentication is the user logs in, and then the authentication plug-in matches the username and password against the database. If the information is correct, the plug-in selects the users ID number, the sites ID number, then with those values it selects the group ID numbers to the groups that the user is a member of. After all the data has been retrieved from the database, it gets stored in a global multidimensional array that’s readily available for use anywhere else in the site engine. After the login process is complete the username is stored in a cookie along with the MD5 encoded password (which was once already md5 encoded in the database, therefore it’s stored in the cookie after being md5 encoded twice.) 

If the user’s username and password aren’t correct, the authentication plug-in will still generate an array containing user information. However the user information generated by the plug-in for a bad login is the same information that’s generated for a visitor, therefore the user is still treated as a visitor, and no cookies are produced. 

The reason we use cookies is so that every time a page is loaded, the user’s login gets validated so that no type of “spoofing” (if you want to call it that) can happen. On each page load the username and password information is pulled from the cookie and sent to the authentication plug-in. Doing this, in theory, means that once the user logs in they’ll never have to login again. Unless they logout, of course, which will empty the cookie of all username and password values.

After the login, since we’d already have the plug-ins and modules loaded, all we have to do is load the content blocks. That’s where the array containing all the user information will come in handy. When we select the blocks, we use a select statement that selects only the blocks that are dependent on the loaded plug-ins and modules, have the same site ID as the user, and have the same group ID’s as the user. At this point you may think, “Wow, that means I’m going to have to make duplicate blocks for each group ID if the block is visible for all groups.” No. Every user has the ability to belong to multiple groups, hence the need for a multidimensional array for the users information.

Each block in the database is set up to have coordinates to direct the site engine as to where to place the block. The coordinate system is really easy to follow, especially since the plug-in that actually handles the loading of the blocks sorts them into a multidimensional array where the array keys correspond to where the block should be placed. Since we’re on the subject, it would be the perfect time to talk about the template and loading systems of the site engine.

{mospagebreak title=The Template Got All GUI}

Even though I’ve loaded all my blocks into a multidimensional array with keys that correspond to the block’s placement, I still need a way for the engine to know what the coordinates made up of the array keys mean. That’s why we need a template system and a loading system. What this system does is it looks at the array of loaded blocks and puts them in place on the template.

The templates are all XML based, to speed up the parse time, and with the new SimpleXML functions of PHP5, it makes it very easy to access the template data. The first thing you’d need to decide how you want the layout to look on the site. I prefer the traditional 3 column layout because it maximizes usable screen space. However it can be set up anyway you’d like, whether it’s 3 columns wide, 1 column wide or even 5 columns wide.

When the multidimensional block array is made it looks something like this:

$blocks[1] – all the blocks in column 1

$blocks[2] – all the blocks in column 2

$blocks[3] – all the blocks in column 3

And so on until the final column. As you can see, the array key determines what column of the layout the blocks will show up in. The rows are just the same as the columns, and each of those arrays are sorted in the order that the blocks with be outputted from top to bottom by specifying the row as the key. Consider the following:

$blocks[1][1] – the top block in the first column

$blocks[2][3] – the third block in the second column

$blocks[3][1] – the top block in the third column

Here’s a small visual mock up of the layout that contains 3 columns 2 blocks in column 1, 2 blocks in column 2, and 1 block in column 3.


It’s pretty simple and logical when you think about it.

The template file also includes the look of the blocks, which also contains tags that will be replaced with the data that the block has such as the title and the block content. The blocks are actually each a separate file that is linked to the database by the file path then called through the plug-ins. The reason for this is because you might have a block that contains no PHP, just some HTML such as a menu block. So we replace the block template content tag with an include of the block file when the block is loaded. The blocks are by far the most confusing part of the entire site engine, but while working on it, you’ll get to know and understand how it works a lot better.

{mospagebreak title=Build It and They Will Come}

Once you get the site engine up and running you are going to want to make a site with it. But wait! You should first build something that no one but you, or other site administrators, will see — the administration site.

Of course you’re not going to want to update two database tables every time you make a new block; that’s why you’ll want to build a simple site that has the entire front end for doing that. When the site engine is all finished, it’s pretty much just some HTML here and there to make your admin site. Then when you’re ready to run another website off the site engine, all you have to do is make the template and block files, upload them to the server and then simply go to your admin site, login, fill out a form to add the site, then fill out the forms to initialize the plug-ins and modules (which can be reused for each site so you don’t have the have duplicate plug-ins and modules), fill out a form to add the blocks and that’s about it — the site’s up running and ready to go.

Now that I’ve hopefully explained what the site engine does, how it does it and why, I think you’ll have a good understanding of what’s to come in the following articles. They’ll go into further detail and explanations on each of the four previously outlining sections. However if you’re kind of lost on the whole subject, I still encourage you to keep a look out for the next four parts to this series, as I’m sure they’ll shed a bit more light on the subject of how to create a site engine.

[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye