Choosing WordPress: “She’s got guts”

This entry is part 4 of 4 in the series Wordpress as a CMS

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-includes: For the most part this directory contains files that are called/included when various other WordPress .php files are executed behind the scenes – hence the name of the directory is wp-includes! Also, within this directory is found a sub-directory for all the javascript files/libraries included with the WordPress install. Again file names are very suggestive of their purpose. Examples like, “category-template.php”, “comment-template.php”, and “template-functions-post.php” all are indicative of this. A little bit later in this article I’ll mention the wonderful world of template-tags in WordPress but just a quick mention that the files that make the template-tag magic happen are located in the wp-includes directory.

/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.

v. Paging
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.

Again, the WordPress Codex has excellent documentation on everything to do with using Pages.

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.

vii. Security
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.

Choosing WordPress: “ooo doesn’t she LOOK fine?”

This entry is part 3 of 4 in the series Wordpress as a CMS

In the previous article in this series I gave a summary of some of the core differences between a CMS (content management system) and a blogging engine. I talked about some of the cases where one system is more preferable over the other when designing websites. In the conclusion to the article I mentioned that in light of what I had just written, it would have made more sense for me to go with a CMS for the website designs of Hanover Pentecostal Church, UnashamedSermons.com, and VigliottiWoodworking. Yet, as can be observed from the title of the series I obviously used WordPress instead. This article will focus on the first reason for why I made that choice.

But before I get to that I’ll give a quick rundown of some of the requirements that needed to be considered for each site.

UnashamedSermons.com
UnashamedSermons.com UnashamedSermons.com is where I host all the various sermons I have (and still am!) written and preached while pastoring at my church. There were predominately two purposes for me creating UnashamedSermons. One, I wanted a place where I could archive all my messages and access it for personal reference. Two, I wanted to make available to as many people possible these messages in the hopes more people would be impacted.

Some of the requirements needed for this site:

  • Custom theme to deal with a specific structure I wanted for the front page
  • A way of cataloging/archiving all the messages I submit

VigliottiWoodworking.com
vigliottiwoodworking.com My brother in law wanted to me to design a website for him that could be used as an online portfolio for his cabinet making business.

His requirements:

  • Simple design with pages he could edit that describe his business. Simple, but still professional looking.
  • Capability to add/remove pages at will (for him)
  • A gallery system that he could use to display pictures of work he had done. And again something he could easily edit
  • Everything had to be fast especially since he is usually working with dial-up internet access (affordable broadband is still no available where he lives) and didn’t want to have to wait through long page load-ups.

Hanover Pentecostal Church Website
hpconline In redesigning the website for my church I wanted to move away from the generic cms look in the previous design I had used (phpNuke based) and give it a more up to date look. The purpose of “HPCOnline” is to:

  • inform visitors of what my church is all about
  • to provide updates/event information for members/guests of the church
  • to make maintenance and adding of features in the future easier to do (and open up the possibility for church volunteers to assist in maintaining the site)
  • to provide a place for me to post a “Pastor’s Blog” as a way of communicating with people associating themselves with HPC (and reaching a wider audience as well).
  • show the latest sermon I’ve preached and provide not only the text of the sermon but also a podcast/downloadable file.
  • In the future, I hope to add an online library system where people can see what resources our church library contains, who has signed it out, and also sign out books themselves. On the backend the librarian can use this to maintain the church library (printing out reports of overdue books etc.)

With outlining some of the requirements I was looking to meet (just remember that’s only a summary!) in designing the three websites out of the way – it’s now time to (finally!) get to what won me over to WordPress as the solution.

Why I chose WordPress

1. Looks
When I refer to “looks” I’m referring to the robust theming/templating system that WordPress offers. While I can do graphical design work, it takes me a long time and my skills at coming up with something clean and neat are limited at best. With literally hundreds (thousands yet?) of themes currently available (and more being added daily!) there are a wide variety of not only color/graphical combinations but also site layouts to choose from. Since a large part of site design is developing a layout and graphical interface that makes it look polished to visitors, having this wide variety of themes to choose from saves time in the development process.

Another plus with the theming system WordPress offers is that due to the thought that has gone into the code architecture – the themes are for the most part – version independent. That is, with most themes you won’t have to update them when you upgrade WordPress to the latest version. Again, a plus on the maintenance side of the ledger.

Also, I must not forget to mention that creating/modifying themes is fairly straightforward and there are many excellent resources available that aid in learning how to create your own themes. If you are familiar with .css that goes a long way in the theme creation/modification process.

The first full-fledge design that I used WordPress for was my sermons site (UnashamedSermons.com). I decided I would give a go at creating a theme from scratch and even though it took me a bit longer it helped me to appreciate just how robust the theming system of WordPress is.

When I designed VigliottiWoodworking.com I again went with a custom built theme due to the requirements my brother in law had for loading speed and presentation. I was able to easily strip the theme of any extraneous WordPress functions that were not needed and yet still leave the dynamic capabilities intact for future use.

Then when it came to designing my church site I decided to go with a modification of the fresh theme since I liked the existing layout for it so much! Of course, I heavily modified the structure of various templates/pages etc so that it would fit my uses, but I was able to save alot of time by not having to worry about the graphical design so much.

Of course, looks aren’t the only reason why I went with WordPress – and looks, while important, are definitely not the only defining criteria in determining what should be used as a script for a website.

In the next article I’ll look at the guts of WordPress in all their gruesome glory!

CMS vs. Blog…no you don’t need Pepto Bismol

This entry is part 2 of 4 in the series Wordpress as a CMS

{this is part 2 of the series “WordPress as a CMS”}

WordPress is primarily a blogging tool (or engine as I like to call it!) but I’ve learned in the course of designing three websites that are not primarily blogs that WordPress can also cross over and serve somewhat nicely as a Content Management System (CMS). In the second article of this series I want to talk a little bit about the difference between a CMS and a blog and then in the next article I’ll talk about how this played into my decision to use WordPress for the design of UnashamedSermons.com, VigliottiWoodworking.com, and gohpc.net.

On the surface it may seem that there isn’t much difference between a CMS and a Blog. They both provide some sort of backend interface for administrators to manage the content of the website. They both invite social interactivity via the ability for visitors to leave comments, register as a user, or even become a contributor to the content. Then of course the primary focus of each is the delivery of some sort of content which in later years has involved not only pictures and text but also videos and audio (podcasts and the like). But surface appearances can be deceiving!

I believe that while the differences between the two may not be extreme (and indeed the line is being increasingly blurred between the two with the advent of Web 2.0 and the “social” internet – and as I’ll argue later – great tools made available like WordPress), there are a few things that make a CMS distinct from a blog. Why is this important? Put briefly, in developing websites there are some places where using a CMS works better than using a blog engine and vice versa. Later in this article I’ll explain how this is so.

Here’s some more noticeable differences between a CMS and a Blog (keep in mind that this is not an exhaustive list and I’m not going to go into a great level of detail as that’s not the purpose of this article. Also keep in mind that this is a very generalized list – I fully realize that not only are there differences between CMS platforms and Blogging platforms but there are also differences within and among various CMS platforms as well as in and among Blogging platforms. Again the purpose of this article is not to compare Drupal with phpNuke or WordPress with Typepad.):

  1. Difference of structureThe bones McCoy, the bones…A CMS is usually a system of “blocks” and/or “modules” that are added to the website via the administrative interface. Blocks are usually positionable “content display sections” (for lack of a better term) whereas modules are usually entire sections of a website designated to a specific task. For example in a CMS you might find a “menu-block” which contains a list of hyperlinks to other areas of the site and below it you may have a login-block which allows people to register and/or login as a user to the site. Now the login-block might actually be a part of the “user – registration” module that controls all the various backend stuff for managing the users of the site and what they have access to. An example of a CMS might be Drupal or phpNuke (in my eyes even MySpace may be considered at a CMS of sorts). In most typical content management systems there is a main “core” to the software upon which these various “modules” and “blocks” are added to build the website (and then “skinned” by a theming/templating system). Certain modules and blocks are usually included with the default setup but there are many possibilities for how the software can be used to set up a website.A blog engine on the either hand is usually a core defaulting to a certain layout and may have the ability for adding “plug-ins” or “widgets” which can give additional functionality to the blog but for most users the layout stays roughly the same (in terms of structure of the blog – of course theming systems can change the way a blog looks but generally speaking the components [structure] stays the same). In CMS terms a blog usually has one module (which is the core) and the potential to add optional “blocks” (plugins or widgets). Some examples of blog engines are of course Google’s Blogger, Typepad, and of course, WordPress.
  2. Difference of purposeWhen the mask drops from the ceiling…

    A blog engine usually has one purpose and that is for publishing the various writings, observations, and sometimes pictures of the person owning the blog or other authors he/she has invited to contribute as well. Typically the core and administrative interface is designed with that purpose in mind. A blog is like an “online journal” – although in a real sense, the evolution of the blogosphere has led to certain blogs taking on the credibility of more traditional newspapers or other journalism forms and so the blog has become (is becoming?) a mass news outlet. At its core however, it still remains a way of for the average joe to self-publish what they want to write (and the rest of the world to read…although we only think the whole world actually wants to read it 😉 ).A CMS on the other hand, has a core that is a lot less rigid and provides for all kinds of different uses (including blogging as a component). Because of it’s module/block structure – a website designed around a CMS can just as easily (figuratively speaking!) become a storefront for selling things as it can be a community hub via forums. The purpose of a CMS is managed content delivery period – in whatever form it may come.To put it simply – multiple sites using CMS may have all kinds of different purposes but, for the most part, multiple sites using a blog engine only have one purpose – getting their message out!
  3. Difference of function Martha, the VCR time is flashing again…all I want to do is change the dang channel! When I use the word “function” here I’m not using it as a synonym of purpose but rather as a way of describing the usability of a CMS vs. a Blogging Engine. There are two ways of looking at this – function from the standpoint of the developer and function from the perspective of the user/contributor.From a developer standpoint designing a website that has different purposes (shopping system, blog, news portal) with a CMS is more functional than designing the same site using a blog engine. Further, the argument could even be made that it would make more sense to start up a blog using a CMS rather than a blog engine because it leaves the door open to easily evolve the website to further uses without worrying about the adaptability of the core software.However from a user/contributor perspective the broad functional use of a CMS can sometimes require a greater learning curve to do what you want to do (especially in the case of multi-purpose sites). This is certainly more the case when the developer/designer is not the one who is actualy maintaining the website but instead is passing it off to a user(s) who will most likely be unfamiliar with the way things work. A CMS can create more hoops for a user to publish the content they want to publish. So in the example of using a CMS as a blog – while it may make more sense from a developer standpoint – to a user, having to find the module for the blog and learn how to recognize it from the other modules, access it, write their piece and then publish it can be more difficult than doing the same from a blog engine where the steps are (generally) much more intuitive.With that said, the functional difference between a CMS and a blog engine is probably the one that varies the most between various software solutions. In some cases it may not be a problem at all – I’m basing my observations here primarily on the usability differences I’ve observed between phpNuke and WordPress.

For me, these three differences (structure, purpose, function) are the primary ones I worked through when thinking about the best fit for the sites I was designing (CMS or Blog engine?). Of course, from the title of this series you should’ve guessed by now that the sites I designed were more suited to a CMS than a blog engine. If so, then why did I go with WordPress as the core for their design? In the next article I’m going to answer that question.