Building a Site Engine with PHP, Part 5

So you want to use your site engine that you’ve been working on? Okay, now is the time for me to show you how to add plug-ins, modules, blocks, and templates to your database so that they will work with your engine. It’s not that hard to do, and with just a few simple steps, you’ll be running your site off your new stylish site engine in no time.

What do you Need?

The easiest thing to do to install your components into your site engine is to get a GUI for MySQL. The one I use is called MySQL Front, which I’m not sure is available anymore. There’s also another one available from the MySQL website called MySQL command console. This will make it a lot easier to work with MySQL when doing the following things, mostly because there’s a lot to do when installing the components of your site engine when you try to do it through a command line interface.

First, you need to know what things are a must when using a site engine such as this one. Plug-ins aren’t dependant on anything other than themselves. Modules are dependant on plug-ins, therefore you must have a plug-in installed for the module to connect to. Blocks are dependant on both modules and plug-ins. So you must make sure that you have installed the plug-in and the module that the block depends on to load, or else you’ll get some nasty results. 

It’s also a pretty good idea to make a list of all your plug-ins, modules, and blocks so that way you can check them off as you install them because sometimes it gets a little confusing when you are working in the database and you no longer see the names of the files, only numbers relating to the ID of each component. I’ve been known to write it down on paper, along with the ID number of each, as I add them to the database, and yes, I do use a lot of paper. 

{mospagebreak title=Plug it in, Plug it in!}

Once you’ve got a GUI for MySQL (unless you plan on going all out commando with it and using the command line), you can start with your plug-ins. Since everything depends on the plug-ins, I’d say you have to start with the plug-ins, but it is your choice.

In the database there are two tables for the plug-ins — the plugins table and the plugin_status table:

  • The plugins table contains all the information about where the plug-ins are located, their ID’s, what they are named and their loading priority. It also has a few optional fields that contain the author’s name and the plug-in’s version.
  • The plugin_status table only contains two fields, neither of which is optional. The first one is the plugin_ID which corresponds to the plugin_ID in the plugins table, and the plugin_status field. The plug-in_status field is one of two values, “initialized” or “not_initialized”. These values tell the plug-in loader to either load the plug-in or not to load it.

The first thing you need to do when installing a plug-in is name it in the plugin_name field in the database; it can be anything you want it to be. The name of the plug-ins has nothing to do with the functionality of the site engine at all; it’s only for your personal reference. Then put in the name of the directory that the folder for the plug-in can be found in. If you followed the suggested directory structure outlined in article three, you’d put “plugins” in this field named plugin_dir. Then you need to put the name of the plug-in’s folder in the plugin_file field; for simplicity sake we just use the name of the folder that contains the plug-in as the plug-in file. If you remember back to the second article, we did this because it’s better for organizing and loading the plug-ins and we just names the PHP file for the plug-in main.plug.php. After that you have the plugin_priority field, this tells the engine if there’s any plug-ins that need to be loaded before others. The higher the number, the sooner it’s loaded.

For example if you have plugin1 with a priority of 0, plugin2 with a priority of 2, and plugin3 with a priority of 1, they will be loaded in the following order.

plugin2

plugin3

plugin1

As for the plugin_author, you can put in your name, or the name of the person that made the plug-in, or you can be like me and completely leave it blank. You can do the same thing for the plugin_version field.

In the plugin_status table, you have to add a row that contains the plugin_ID that is the same as the plugin_ID in the plugins table, which is auto incremented when you add your new plug-in. Then you have to tell it to either set the plug-in as initialized or not_initialized in the plugin_status field. Keep in mind if you set it to “not_initialized” the engine will not load it.

{mospagebreak title=All your Modules Belong to MySQL}

Modules get loaded into the database just like the plug-ins do. In the database you have two tables — modules and module_status:

  • The modules table contains the same things that the plugins table does (only for the modules instead of the plug-ins) with one slight difference — we’ve dropped the priority field and added a field for plugin_ID.
  • The module_status table is just like the plugin_status table; it contains the mod_ID which corresponds to the mod_ID in the modules table and the mod_status field. The mod_status field is also one of two values, “initialized” or “not_initialized”. Just like the plug-ins, these values tell the module loader to either load the module or not to load it.

When installing modules, start first with the modules table, put the module name in the mod_name field, and then put the directory that holds the modules in the mod_dir field. Once again this is the name of the directory that will hold the modules, beyond the plug-in directory. Then you need to fill in the mod_file with the name of the PHP file that makes up the module. Here’s a small example if you’ve forgotten the third article.

Let’s say you have a module in the following directory,

ROOT/plugins/foo_plugin/modules/bar.mod.php

Then the mod_dir would be “modules” and the mod_file would be “bar”. The reason we want it to be like this instead of the way we did it with the plug-ins is because it makes it easier for us to make multiple modules that use the same plug-in.

After you have the location set up, you’ll need to put in the plugin_ID of the plug-in that the module depends on. For example, if you have a plug-in named foo_plugin with a plugin_ID of 2, and the module bar.mod.php depends on foo_plugin to work. Then you’d put 2 in the plugin_ID field of the modules table for the bar.mod.php module. After that’s all done, you can fill in your optional fields which are mod_author, and mod_version, if you’d like.

Now in the module_status table, once again we need to put in the mod_ID which is an auto incrementing field in the modules table and is generated when we install a new module. Then we need to set the mod_status to either initialized or not_initialized depending on if you want it to load or not.

{mospagebreak title=Improve your Blocking Skills}

Installing the blocks is where that paper that you should have been writing the plug-in and module ID’s down will come in handy. If you didn’t make a list of them, now would be a good time to do so. The blocks and block_location tables are where you’ll spend most of the time installing components because most blocks will share the same plug-in and module. In fact I have one plug-in that runs 27 blocks in my set up.

Blocks Table — Five Fields

The blocks table is where you need to start. This table contains five fields that you need to fill in.

The first is block_title, which contains the title of the block. The block_title can be whatever you want it to be; this is where you’ll put the title that will show up on the top of your blocks (each one is different). You can even put tags in here that will get replaced at runtime.

Then you need to fill in the block_file field, which works just like the module_file field. Just put in the name of the actual PHP file that contains your block data.

Then you have the group_ID field which corresponds with the group_ID in groups table. This enables the engine know if it should load a block depending on who’s logged in.

Following that is the plugin_ID and the mod_ID, which you should fill in with the ID of the plug-in and module that the block is dependant on. This step is really important, because if a plug-in or module fails to load, the block will not load, therefore you won’t get any errors due to the missing information provided by the plug-in or module.

Block_location Table — Four Fields

Now in the block_location table there are four fields to fill in. The block_ID contains the ID for the block in the blocks table that is generated by an auto increment field when you install a new block. The block_col tells the engine what column the block loads in. You simply put the number of the column you want it to load in; for example if you want a block to load in column2, you just put in a 2. After that is block_row which is the number in line that the block loads from top down. If a block is the top block you just put in a 1, if it’s the last in a column with 5 blocks, you’d put in a 5. And finally the blocks page. This field is rather important; it tells the engine what page to load specific block to load on. If you have a block that should show up when a person looks at the page with the URL that looks like this www.yoursite.com/?page=news_details, then you’d want your news details block to load on the news details page and not on the news summary page. For this field just put in the word that would be shown after the page= in the URL.

Not too complicated but it can get confusing after you get in the area of fifty blocks.

{mospagebreak title=Build your very own Theme Park!}

Templates are very easy to set up and install. Basically you only have one table to mess with when installing a template, however you actually have to put information into two tables. You just said “huh!?” Well to begin you have the table that holds all the information about the templates, but then you also have the template_users table which contains all the information about what users are using which template. So you kind of have to set up both.

The templates table is where you’re going to put in information about the template name, the template author, the template’s install date, the template file and the template status. Just like all other components, the template author and the template date are optional. The first field is t_name; this contains the name of the template file. I did it this way so you could have more than one template in the same folder in case you have templates that are slight variations of other templates. Then there is the t_file field, which is more like the plugin_file. Put in the name of the folder that contains the actual template. After that you have the t_status which is where you’d set the default template but put in the word “loaded”. Otherwise you can leave it blank or put in a value other than “loaded”. And by now you should already know what to do with the t_name and the t_date fields. I leave them blank, but I like to know they are there in case I want to use them.

In the template_users table all you have is a field named user_ID that holds the user_ID that corresponds to the user_ID in the users table. After that is the t_ID, which is the ID that is given to a template when you install it into the database, by the auto increment field in the templates table. I have it automatically fill in this information when a user registers so that way you don’t have to do anything with the table at all. That’s all up to you, but personally I wouldn’t like making a full time job out of manually updating the database.

It’s all Over

This is the last part of the last article in this series. If you’ve read all 5 articles, you should now have a good understanding on how to build a site engine. These articles weren’t made to give you a site engine; rather I wrote them to touch on the more confusing parts of building something like what I have. I hope that my articles have helped you to learn some cool new things about how you can work with PHP to make a seemingly self-aware site. And I hope that it’s furthered you in your knowledge of PHP. I’d be happy to lend more information and pointers in the future to those that need a bit of help. I’d also love to see what you can produce while keeping this series of articles in mind. But for now I’ve about said all I think I can say about the theories, ideas, and structure behind a true site engine. Thanks for reading my articles.

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

antalya escort bayan antalya escort bayan Antalya escort diyarbakir escort