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.