Stop Blocking Me - PHPIn this third article of the series, I’ll show you how the database and directories should be set up. I’ll also talk about the how to create, install, and use a content block, which mostly relies on arrays and array functions. I'll cover proper authentication methods for such a project so that multiple sites can run off the same users table in the database, while not barring a username from being used on a site because it is being use on another, all the while keeping the authentication accurate and secure from break-ins. (For part 2, see here.)
print this article SEARCH DEV SHED |
Now it’s about time to talk about the block system. Don’t worry if the concept escapes you; it’s taken me a lot of time and trial and error to get this all working right. Since I’m such a nice guy, I’m going to save you the trouble and tell you all about how it works so you don’t have to pull your hair out. The block system can be very confusing if you don’t pay close attention to what it does. Working with the block system can cause a lot of headaches. Now, on to the block system. The block system is very intricate, so take your time when working with it or it can get very out of hand. At the beginning of our class, define all the variables that are going to be used in the class. Since PHP5 had been in beta 1 stage, it allows you to declare your variables at the beginning of a class with public or private. We want to define all ours as public so they can be used elsewhere in the site engine. Here are all the variables we’ll be using: public $bcount; As you can see, we’ll use nine variables through out the blocks plug-in. $bcount is a variable that will hold the number of blocks that have actually been loaded. $columns is the variable that we’re going to use to hold an array of each column that’s in our template. $rows is basically the same as $columns, but instead of holding an array of columns, it’s going to hold an array of the rows in each column, as we use the column. $cur_block will hold the data for the block that’s currently being parsed, in our script. $cur_tags is the array that will hold all the block information that will replace the tags in our block template, with the actual block information. $blocks_list is the most important -- it’s an array that holds all the information about our blocks, information such as the block’s titles, content, what column to load in, and what order it is in the column. Now run our SQL query to select all the blocks that will be shown on the current page. Start by making our function. Name it blocks() so that when the blocks class is called it will automatically run the function. function blocks(){ Now declare all the variables that we’ll use as global. That way we’ll be able to use all the data from the other classes in this function. We’re also going to give our $bcount variable the value of 0 because we don’t have any blocks loaded just yet. $this->bcount=0; Now that we’re started on the function, we want to start a loop to make part of our query; this particular loop is going to count the number of groups the user belongs to from the $user->user[‘gids’] variable that I'll go over in a minute, then it’s going to get the value of each group ID. Then it will generate the part of our query that makes it so that only blocks authorized for users authentication level are selected. Just a personal tip here -- when you make a script that generates a query or part of a query, it’s usually a good idea to echo the query to the browser to make sure it’s generating exactly what you want. $i=0; Now it’s time for the meat of the blocks plug-in, the main SQL query. This query is fine tuned to select only the block information from the blocks that are supposed to be shown on the requested page, that meet a few prerequisites. For the blocks to be selected, the blocks must have a plug-in that’s been initialized; they must have a module that’s been initialized; they must have a site ID that’s the same as the ID of the site that’s requesting them; they must be within the authentication levels as the user requesting them; and they must be set to show up on the current page, or all pages. Another thing about the query is that we use the $b_grp, that contains our user group part of our query, in the query, as you can see in the following query. $blocks=$sql->_query("SELECT After the query returns the results in the $blocks variable, get the information from it with the _fetch_object() function that we made in the SQL class; this enables us to call the results from the query as an object. Then we’ll rebuild it into another array that will be a little more user friendly to us later on in the project. The reason the new array is easier to use is because we set the array keys to the coordinates of the block; that way the engine knows that the block in the array that’s set as $blocks_list[1][2] (read as blocks list column 1 row 2) as the 2nd block down in the 1st column.
For example, if I were to replace the variables in the following code with their values, for the 1st block in the 2nd column, the result would look like this:
The reason we use the actual words “column1”, “column2”, and “column3” instead of just using the column numbers is because those will also be used by the template plug-in to replace tags with the blocks in the correct column. After we build the $blocks_list array, we’ll go ahead and call the function parse_blocks() which actually puts the blocks in loading order, then “packs” them (as I’d say) and sends them over to the template plug-in that we’ll be discussing in the new article. $this->parse_blocks(); The parse_blocks function is an important part of the blocks plug-in, if not the most important. What it does is it looks at the list of blocks that we just put together in the blocks() function, and it puts them in order by column, then by row. After that it calls the block’s template data from the template plug-in, parses it all into an array that contains strings of data that can be outputted to the browser, named $cur_column. Each array key of $cur_column is named as the column name that the data will be put into. After the array is built we send all the data to the template plug-in where it gets used and then sent to the browser. This function is actually a fairly simple process. First we name the function, and set up our global variables. function parse_blocks(){ Then we check to make sure the $blocks_list array have been built without errors if(is_array($this->blocks_list)){ If the array looks like it’s all right, we then get the keys from the array that contains all the column names that is produced by the template plug-in, and set them to the values of another array called $columns. We then start a for each loop that will select each element from the $columns array, that will then make yet another array based on the keys from the specified column element of the $blocks_list array. We then start another for each loop that will process the data each block in the $blocks_list array. $this->columns=array_keys($template->columns); The easiest way to work with the current block at this level is to set it as the value of another easier to work with variable, we’ll call it $cur_block, $this->cur_block = $this->blocks_list[$column][$row]; After that’s all taken care of, we’ll go ahead and get "down and dirty" with our block data. First, set up a temporary array of all the data for the current block; at the moment the only data we’re worried about is the block title, the block content, and the block ID. $this->cur_tags=array('block_title'=>$this->cur_block['block_title'],'block_ID'=>$this->cur_block['block_ID']); To get the file that contains the block’s content, we’ll have to include it and set it to a variable. That will contain the data after it’s been included. However, it’s a little tricky to do that because if you just include it, all the data from the include will show up at the top of the page instead of in the block. To fix this we turn to output buffering. Traditionally output buffering will stop all data output to the browser until it’s told to stop buffering, at which time it will send all the data that it stopped to the browser. In this case we'll still tell it to stop buffering, but instead of having it send the data to the browse, we’re going to tell it to get the contents of the buffer, set it as the value of a variable then flush (also known as empty) the current buffer. This way we get all the contents of our include without it sending the data directly to the browser. After we have the content of our block, we’ll add that to the $cur_tags array. ob_start(); Don’t worry it’s winding down to the end of the blocks plug-in. now we have all our block data right where we want it. So what we’re going to do with it is pass all the info to the replace() function that we have set up in our templates plug-in which will fill in all the tags in our block template with the data in the $cur_tags array. Then it will assign it to the $cur_column variable, using the column name as the array key. Then after all the loops are finished we’ll send all the data to the function that builds the columns and outputs it all to the browser in the, in the templates plug-in. $this->cur_column[$column].=$template->replace($this->cur_tags,$template->loaded->block); }
blog comments powered by Disqus |
|
|
|
|
|
|
|
