Tomadoh

In my last post we reviewed some of the broader implications of these excellent frameworks. In this installation of my weekly series we will discuss practical application of these frameworks as it relates to caching and user access. I know for some of you this may make your head spin, but believe me it’s important, and you’ll see why.

Caching:

As anyone who has built a website of any note can tell you, caching is a necessity, the more you try to show the user, the longer the page load, the more data that you have to process before the user sees the page, the longer the page load, the more images you have, the longer the page load… you get the idea. Caching basically allows you to serve content to a user that has been saved in a flat file, or similar format. If you aren’t a programmer this is probably as clear as mud, so let me break it down.

When you load a page (we’ll use the home page as an example) in either Drupal or WordPress, the default functionality is to display excerpts of your latest posts in a blog feed style list. What this means on the backend that the user can’t see is that the system must query the database looking for your most recent posts, load the post, load the tags and comments for the post, make sure that the user has “permission” to view the post, check if the post has a excerpt set, theme the post, and then add the post to the page that is being shown to the user… if you load 10 posts on 1 page, the system must go through this entire process 10 times. That doesn’t even include checking to see what your logo is, piecing together the header and main menu from your database settings, determining if the user is logged in and displaying the appropriate links for log in or log out, and then setting up all of the javascript files, css files, images etc etc etc…

>whew< That is a lot of work for the system to handle, fortunately both frameworks have this down to a science and just displaying 10 posts is a very easy thing to do. Unfortunately, (or fortunately in my opinion) the vastness of the web makes unique site design and functionality very important for a successful site. That’s where caching comes in, when you cache a page on your site, what you’re basically doing is saving the page content that was put together after you last updated your site into 1 file that can be loaded very quickly and doesn’t need to be re-processed, speeding your load time up significantly and keeping your users happily able to spend more time looking at your content.

WordPress doesn’t come with this out of the box, but there are many many many plugins available to accomplish this. I’m not going to walk through all of your options ere, but I will point you to this excellent resource that includes benchmarking (speed testing) for each of the most popular plugins available. I will tell you that I use WP Super Cache on all of my sites, it works well and it’s extremely easy to set up and use.

Drupal users have a decided advantage here since caching is something that Drupal’s core can handle out of the box. Mind you not every contributed module properly supports caching, but most of the “good” ones certainly do. If you develop your own modules, make sure you disable caching while you work, otherwise many of your changes may not display properly. On that note let me say that if you have half a clue about how to use PHP, you should always throw a module together on your drupal site just for testing, the documentation for module development is quite extensive.

Obviously there is a lot to caching, and as I said before this isn’t really an optional feature if you have any thoughts of building the next big thing… or even the next kinda big thing.

User Access:

As social networks consume our lives on and offline, more and more people are building websites that allow users to contribute content and interact with other users and their content. This is a powerful marketing structure for all involved, the users have a site they don’t have to maintain or pay for where they can get their content out there for the countless people browsing search engines every day, and the site owners have user contributed content (hopefully) bumping them up in the search engines, which can help power any number of services or products they want to move forward with.

As user content driven sites grow, it often becomes very important to have group admins, moderators for content, comments and forums just to name a few. For a larger company this can be accomplished by simply hiring people to handle their growing needs, for smaller, independent companies and non-profit sites, that isn’t always an option, so trusted users are often chosen to be assigned to these roles. Either way, different levels of access are often very important. For example, just because a user can edit content doesn’t mean they should be able to completely delete it from the system without an administrators approval.

Basically it works like this, when you create or edit a user account you can assign that user to a role, that role in turn grants the user permissions (wordpress calls these “capabilities”) to do any number of things from creating content, commenting on content, editing content, viewing content etc. etc.

WordPress sadly falls short in this area, while roles are available, the permissions assigned to those roles are basically hidden from the user interface, so if you want an “Editor” to be able to edit a post, but not delete it, you have to do it programmatically. There are some plugins that try to address this lack of flexibility, but unfortunately nothing comprehensive and complete is available at this point. (maybe an idea for a new project??).

Drupal wins again here, their user permissions system is as complete as any I’ve ever seen, with a complete UI allowing you to add new roles, add permissions to roles, and set “weights” for the roles, so basically if you have 3 roles, your lightest role (1) will inherit all permissions automatically from heavier roles (2 and 3). Adding permissions still has to be handled programmatically of course because there is no way for you to tell the system what extra access you are trying to add without explicitly describing it in a way that drupal’s backend can understand. But again, for you module developers out there it’s as easy as adding a “hook_perm” function to define what these permissions are.

If you are building a site for your business, or a site that you never plan on expanding enough to need explicit permissions, then you have nothing to worry about with either, if you’re looking to allow users to help you grow your site by contributing content, I strongly suggest that you consider this when making your decision about a framework.