In the previous article in this series I introduced the first reason for why I chose to use WordPress as the engine for three CMS-like sites that I designed recently. I wrote about the theming/template system in WordPress – the “looks”. In this article I’m going to talk about the “guts” of WordPress.
Why I chose WordPress
2. The Guts
When I refer to guts, I mean the following things that are “inside” the WordPress engine:
i. File Structure
From the perspective of a newbie developer, the WordPress file structure greatly aids in comprehending where things are and what files need to be edited/looked at in the development process. The fact that directory trees and file names are descriptive of their function cuts down on a lot of the guesswork into where things are located.
Here’s the layout of the directory tree structure:
/wordpress (root): You’ll find all the main configuration and base level files such as config.php (database settings), wp-blog-header.php (calls necessary includes and header information), and various feed related files among others. I’m not going to go into detail about each of the files but I’ll just mention that for the most part, the files in the root wordpress directory are what WordPress accesses when initializing.
/wordpress/wp-admin: In this directory are located all the core files that run the administration interface of wordpress. Files are named appropriately according to what their purpose is. For example, guess what the “edit-category-form.php” file is for? Or how about, “inline-uploading.php”?
/wordpress/wp-content: For most self-hosted WordPress users, the wp-content folder will be the one you’ll access the most. Within this folder is found all the user modifiable/plugginable content.
There is the
/wp-content/themes/ folder which is where all the themes/template related files are found. Each theme is found in it’s own named folder. There is also the
/wp-content/plugins/ folder which is where all the various WordPress plugins are put.
A brief word about naming convention with themes since this is another area that I really appreciate about WordPress when it comes to design/development. The files for themes all have a naming convention that just makes sense and again aids in understanding the purpose of the code found within. Here’s a brief list of the some of the various file options found in WordPress themes. (Important note: Not every theme has every file as some theme authors choose to keep their file arrangement compact and thus include various theme structure elements in a smaller number of files – which is possible with WordPress)
- index.php – This is the layout for the initial page when WordPress is loaded. Alternatively (but not necessary with WordPress 2.1) home.php can be used for the first page. WordPress 2.1 however allows you to set what you want to be the first page loaded up via the administration options page.
- single.php – The file that contains the layout for single post pages.
- 404.php – Contains the layout for what is displayed on error 404 pages (when someone is trying to access a page that doesn’t exist).
- archives.php – Usually contains the layout for archives pages
- category.php – Contains the layout for category archive pages
- sidebar.php – Contains the layout for the sidebar section of a page.
- header.php -Contains the layout for the header section of a page (the top that usually contains the Blog Title/logo and the main navigation menu)
- footer.php – Contains the layout for the footer section of a page (footers widely vary between themes but at the minimum usually contain the copyright info for the blog, powered by WordPress text etc.)
- functions.php – Contain any theme specific functions. If your theme is widget enabled you’ll see this file as the code to enable widgets for the theme is found therein. Some theme authors also use the function.php file to add theme specific functions to the blog (without using the plugin functionality of WordPress).
- page.php – Contains the layout for static pages on your WordPress blog.
So you can see from this list that the naming convention with WordPress themes also helps in understanding where various elements of the site design can be found. There is much more regarding this but since the WordPress Codex has great help files I’ll direct you there instead.
Also found within the
/wp-content folder is the
/plugins/ folder. This is the central location for where all the various plugins you can download and install for your WordPress powered site. This makes it easy for keeping track of what plugins you have installed and also knowing where to install the plugins you download.
Yes, the File Structure of WordPress is one component of her “guts” that help in developing CMS based sites.
ii. Coding Practice
Something else that is found in the WordPress core that might not be really obvious at first is the actual coding practice that is followed. Not only have WordPress developers followed good coding practices in the files they’ve written but they also encourage it for those adding to WordPress via themes/plugins.
When I talk about coding practice, I’m talking about adherence to x-html/.css/php standards – and certain structural elements in writing code so it’s easy to read and parses correctly. This, along with standards for inline documentation, make it easier to track various code elements and what it affects. When you read through WordPress core code not only is the structure fairly easy to follow (for someone who understands php of course 😉 ) but because functions are named for what they do it greatly helps in locating things you want to edit/understand. Clean code makes for less headaches!
When I was designing my sites and needed to understand how something worked in WordPress, not only did the file structure make it easy to find out what file the particular function might be in but the coding practice made it easier to find the snippet of code in that file.
iii. Template Tags
Probably one of the most important aspect of WordPress guts that stood out for me were the usage of what the WordPress community knows as template tags. Put simply, template tags are php functions that are used in your theme templates to perform specific tasks. There are a variety of different functions built into WordPress that make customizing themes and designing a CMS based site less time-intensive than most CMS-based scripts that are out there. Add to that the fact that Template Tags are fairly well-documented and this makes them even more powerful.
iv. Category System
One of the strengths of WordPress in my opinion is the way content can be organized via the built-in category system. Using this and various conditional template tags, the possibilities for making a dynamic CMS becomes much simpler. For instance, on my church website that I designed, I greatly utilized the category system to “split-out” various sections of content that the site would serve up. I have an “upcoming-events” category for events, a “Pastor’s Perspective” category for all my pastoral blog entries, an “announcements” category for various news and announcements made on the church site, and many more other categories. Then using the conditional template tags I can place content from a specific category in the design the way I want it. Whenever I want to add content to a particular section of the site I just have to add the post to the correct category.
Another bonus with WordPress is not only are there categories but you can also further classify posts by subcategory creating more possibilities for dynamic design.
One important component of WordPress that is key to it’s use as a CMS is the ability to create static pages from the administration interface along with dynamic posts. If this component were not available then it is likely I might not have used WP in designing my sites. Put simply, there are instances when you will be presenting content that rarely changes (hence, “static”) and thus you want an easy way to add this content and edit it if and when needed. If WordPress didn’t have this feature the only way to add static content would be to develop specific theme template files that have the static content encoded via html.
An added feature that was also appealing to me was the fact that I could create certain “page templates” in my theme that could be selected in the “write page” panel. This makes it possible for me to create different page layouts for different topics/subjects.
vi. Admin Interface
I could probably write a whole article on just the administration interface of WordPress but I’ll just include a short list of what was important to me in reviewing using WordPress as a CMS (everyone loves lists don’t they?)
- Simple Layout – A novice user won’t have to read through a thick readme file to understand how to get around. That was important to me because for two of the sites I designed (gohpc.net and vigliottiwoodworking.com) I would not be the only one maintaining them and I wanted things to be as easy as possible for people who would be doing that.
- Quick Load Time – The interface is not graphic intensive which makes things load fast for those on slower ISP connections. This was an important consideration for one of my site designs as the person maintaining that site is on dial-up (shudder)
- WYSIWYG write/edit window – Although I’m not a big fan of the Tiny-MCE window that is included with WordPress for my own use – it does come in handy for those who are not familiar with html code. Once again an important consideration for me when designing for end-users who would be maintaining the sites. A plus for me is that I don’t have to use the “Visual-Rich Editor” (as WP developers have named it!) if I don’t wish to. WP 2.1 makes this even easier by giving the ability to switch between visual and non-visual (code) right on the same page.
- Built in Roles Management – basically this means that I can give other people access to add things to a website without giving them full access to other administration functions.
- Easy Plugin/Theme Management – The activation/deactivation of plugins and themes is ridiculously easy in WordPress.
The final “guts” component of WordPress that was important to me is something that few novice web developers think of but has nevertheless become one of the more important priorities in web-design. One of the dangers of dynamic websites that invite interactive contributions from visitors is the accessibility to malicious hackers. Insecure sites become targets for activities that can be as “benign” as the changing of your sites homepage to as harmful as the complete erasure of your database. Either way, when an unauthorized individual invades your website it’s never pretty.
Although, I’ve been fortunate to not experience being hacked, I realize that it’s only a matter of time before it happens if steps aren’t taken to ensure good security measures are in place.
I’ve written all that to write this, WordPress is one of the most secure publishing engines available. I’ve heard of very few WordPress based sites that have been hacked and even the ones that have been were due to the owners not ensuring that the latest WordPress updates have been applied.
In reviewing the WordPress development over the years I noticed that a great deal of attention is given to the security of the code and as such whenever there are updates released there are usually security patches included as a result of the diligent testing and reporting of the WordPress developer and user community.
No platform can ever be 100% secure from malicious hackers – but WordPress comes pretty close. That’s important.
That’s all I’m going to highlight about the guts of WordPress in this article. While there is much more that can be written, I wanted to try and limit what I wrote to what actually contributed to my decision to use WordPress as a CMS.
Next up, I’m going to talk about the beautiful appendages of WordPress – plugins. In the next article (or two) I’m going to highlight how the plugin architecture of WordPress makes it easy for developers/designers to expand on the core functions and then I’ll list some of the plugins I used in the sites I designed.