CMS Themes

In my Joomla vs Drupal vs Wordpress post , I’ve already talked about “themes”. The purpose of this post is to tell you a bit more about what they are, where you find them, how you install them, and last but certainly not least how to personalize them.

What are themes?
Themes define the design of your website, how it looks to you and to your visitors.
We have to admit, You may have such interesting, funny or just great content, when the design of your website stinks, you’re very likely to lose visitors.
Each CMS comes with one or more themes in the default installation. Unfortunately this will most probably be the theme that’s used on the website of that CMS. When you know a bit about CMS, you’ll probably recognize the blue design of Drupal, or the grey and white design of Wordpress out of thousands. And let us be honest, we don’t want our website to look like the Drupal or Wordpress site. So we need another design, another theme.

Where do we find themes
The first resource of themes is the website of your CMS:
Drupal: http://drupal.org/project/Themes
Wordpress: http://wordpress.org/extend/themes/
This should already get you started, I guess.

If you don’t find what you like on the CMS websites, don’t worry yet, there are lots of other websites which provide themes for free or for a small contribution. A few examples:
Free sites:
cmstheme.net: http://www.cmstheme.net
freecmstemplates.com: http://www.freecmstemplates.com/
…

Paysites:
themestock: http://www.themestock.com/
websitetemplates.bz: http://www.websitetemplates.bz/wordpress-themes.html
…

Still haven’t found what you’re looking for? It’s possible that you already had a certain design in mind, which is so unique that it doesn’t exist in a theme yet. There are several options left. If you want to pay for it, there are several companies and web designers who are specialized in the creation of themes. If you want to pay less, you can also purchase software that makes the creation of themes more easy (e.g. premiumwp). I must add here that I never tried such a software packet before, but that it seems to me like you have a lot of limitations (a certain amount of backgrounds, fonts,…). My personal opinion is not to use this kind of software. If you need to have your theme fast, buy it, if you have the time, create it yourself.

How to install Drupal themes
In this part I’ll only handle the installation of themes in Drupal, but the procedure is more or less the same for every other CMS (just keep in mind that in Joomla themes are called “templates”).

First thing to do is download the theme you like. You will normally receive some kind of compact archive (zip, tar.gz,…), which you extract to the “themes” folder of your Drupal installation.

Afterwards go to Administer > Site building > Themes
Find the theme you’ve just installed and check the “enabled” box. If you also want to start using the theme immediately, check the “default” button. After pressing Save, you’ll see your layout change. Now that was easy, wasn’t it?

How to personalize Drupal themes
You’ve downloaded your theme, you’ve installed it successfully, but probably there are still some things that are not 100% like you want them. For example you want a different font, different colors, a different background image, and so on.
Well here’s some good news: themes are fully open source, which means you have access to all of the code, and you’re able and authorized to change it. Of course, depending on what you like to change, this requires some knowledge of CSS, HTML, PHP and/or Javascript.

But let’s not scare you away yet, first we’ll have a look at the file structure of themes, to see how things work.

page.tpl.php
This is the main template , together with style.css it forms the foundations of your theme.
The first thing you notice when you open this file is that it consists of PHP statements with embedded HTML. This is where the “what goes where” takes place.
When you go through this file, you’ll notice the use of a lot of variables ($site_name, $primary_links,…). These are values that come from the Drupal administration. An overview of these standard variables can be found on the Drupal website

style.css
In case you don’t know what a CSS is: it’s Cascaded Style Sheets. Which means that this is where your styling takes place. Here you define your fonts, colors, etc for each single part of your theme

the other .tpl.php files
These files contain the design of different parts of your theme, normally the name already tells you which part it’s about:
block.tpl.php : design of blocks
comment.tpl.php: design of comments
page.tpl.php: design of pages
and so on.
All of these files receive their styles from style.css

logo.png
The logo file. If you want a different logo, just replace this file

the .info file
As of Drupal 6, this file is obligatory. It contains some basic information of your theme.

With only those files, you should be able to create your own theme. Of course there’s more than that. When you browse through the file structure of more sophisticated themes, you’ll notice some more php of inc files (which are called from the tpl.php files), images (background, border,…), fonts, …

HINT: before you start messing up your theme (if you didn’t already), I propose that you first create your own theme as a copy.
This happens as follows:
You create a new subfolder in the sites/all/themes folder (note that this is different from the standard theme folder!) and you call it whatever you want to call your theme. E.g. mytheme.
You copy the content of the folder of the theme that you want to edit into your “mytheme” folder.
You rename the info file to mytheme.info (of course replace “mytheme” by your theme name).
You edit the info file, and wherever you find the name of the original theme, replace it by “mytheme” (normally this is only for “$id” and “name”).
And that’s that. When you go to Administer > Site building > Themes, you should now see your new theme.
It might also be handy to take a backup of your theme folder once and a while.

HINT: If you’re new to Drupal theme development, I propose that you start with the blue marine theme. This is quite a basic one, which only contains the basic files.

Have fun developing!

Drupal vs Wordpress

As you may remember from a previous post Joomla vs Drupal vs Wordpress, I started with very little knowledge of CSM software, I picked the three famous ones, installed them on my web server and I started messing around. After a while I was quite convinced that I wanted to use either Drupal or Wordpress, so farewell Joomla!
It looks a bit like a reality show, doesn’t it?
Now let me welcome you ladies and gentlemen to our big finale, with only two candidates in the running…On my left hand: Drupal and on my right hand: Wordpress!

In the meanwhile, I have been using both CMS, and I tried to perform similar tests, but both succeeded more or less in all tests. One thing that did occur to me is that Wordpress seems to be a bit more user friendly than Drupal. It might be just me, but everything I tried went a little bit faster in Wordpress.
A second thing that I found quite annoying is that the text editor in Drupal stinks. It really does. It’s just a plain text editor which you can compare with MS Notepad. It’s not that I need something very fancy, but some basics are always welcome. When you look at the editor in Wordpress, you’ll find functionalities like lists, hyperlinks, spellchecker, etc.
Now it seems that I’m not the only one who’s annoyed by this, because there are already a lot of Rich Text Editor modules which you can implement in Drupal, for example FCKeditor and WYMeditor. Nick Lewis has written a nice comparison of a couple of these editors:

Basically, this means I’m still nowhere. Both CMS work fine for me, be it with some adjustments where necessary. So I’ll need to take things to a higher level: Have a look what the professionals think about this. Luckily the internet is full of comparisons between different CMS, and especially between Drupal and Wordpress.
The opinion of the professionals is more or less the same everywhere:

“If you want to create a website around a blog, use Wordpress. If you want a ‘real’ website, use Drupal”.

As I see things now, the blog will be the central point of my website, it’ll be updated regularly, and the articles and photo pages will be more static. So I should go for Wordpress. On the other hand, I don’t know what the future will bring, if I want more sophisticated photo galleries, I will get more possibilities in Drupal, same thing for video galleries, and maybe later I want even more stuff like a forum or a web shop. Therefore my final decision will go to Drupal. In the beginning I’ll need to do more than I should have to do with Wordpress, but in the end I hope it’ll be worth the choice.

Ladies and gentlemen, boys and girls! Our winner is … (drum ruffle) … Drupal!

Also nice to know: In the Open Source CMS Awards, Drupal has been overall winner in 2007 and 2008 (the winners of 2009 are selected November 9th), and Wordpress has won the award for “Best Open Source Social Networking Content Management System” in 2007 (This category didn’t exist anymore in 2008).

Content structure: Technical

In my Content structure: Philosophy post, we’ve talked about what content structure is, and why people make such a big deal of it. This week I’d like to tell you how we handle this with CMS.
I’ve already given you an introduction into Structured content and content types in my Joomla vs Drupal vs Wordpress post. These are the components that we’ll need to structure our data.

As an example, I will use the structure of my own website.
First of all, I have the blog, which will be the central component of the website. There will be regular posts and also announcements of what changed on the rest of the website. Next to the blog, there will be a part with articles and a part with photo galleries.

We need to separate the blog from the other parts of the website, as the way of structuring the data will be different. This is something we will do with content types.
For the blog we will use the content type Story in Drupal or Post in Wordpress. For every other part we will use the content type Page (this is the same in Wordpress and Drupal).
The pages will be structured using menus and submenus, the stories/posts will be structured using categories in Wordpress or taxonomy in Drupal

The Pages
Structuring data using menus is not really what CMS is all about. But if they contain data that’s not frequently updated, it’s often the best choice. There will be two main categories: “Articles” and “Photography”. These will be accessed by pressing a button in the main menu (I will chose for a top menu here). For both categories, there will be following subcategories:
Articles
      Travel
      Web Design
      The written word
Photography
      Travel
      People
      Projects
Like I said in the Content structure: Philosophy post, it’s necessary to do some thinking about this. Is this the level on which I want to keep working? Creating new subcategories on an existing level is easy, dividing a subcategory into new subcategories on a deeper level is a lot harder.
As these pages won’t be updated that much, the chance that new subcategories are needed is a lot lower, so I think it’ll be sufficient to stick with this structure. For the blog we will need to be more careful though.

The Blog
As said before, we will use the Story/Page content type for the blog, which is the central component of the website. We will structure the stories/posts using the CMS standards: Categories in Wordpress and Taxonomy in Drupal.
The reason why is because the blog can be seen as one component with lots of new information being published on a regular base. Suppose you have written this great photography post about landscape compositions a couple of months ago, but your readers need to scroll through every post about cameras and aperture settings, chances are that they’ll leave your website before they found your article.
Another thing that needs to be reconsidered is that posts/stories can be linked to different categories. This is a good and a bad thing. The good thing is when writing a post, you don’t have to be thinking all the time about sticking to your subject. The bad thing is that people are likely to link their posts to as much categories as possible.
Let me give you some examples:
1. You’re writing a post about a nice landscape you’ve seen, and you describe why the composition was that perfect and what settings you’ve used on your camera to make that superb picture.
This story can be categorized in photography/technical and photography/composition.

2. You’re writing a travel story about your last trip, and at a certain moment you describe a landscape that seemed to have a perfect composition for a picture and why it seemed like that.
You classify this story under travel/story but not under photography/composition.

In the second example, why don’t we classify the story under photography/composition?
When a visitor requests an overview of all photography posts about composition, your travel story will appear in that list. This is not the information he/she is looking for. The visitor wants tips or information on composition, and is not interested to read how you’ve spent your time in Oegadoega. If you really think that the info about composition that you’re giving in your travel story is that important for photographers, you need to consider to write a separate post for it.

Now let us get back to the techniques. My blog will have four main categories: Travel, Writing, Web development and Photography. These will be the top nodes of the tree structure.
In Drupal:
Go to Administer > Content management > Taxonomy and press the tab Add vocabulary.
We add four new vocabularies for each of our main categories. Check the content type story and check the setting multiple select .
In Wordpress:
Go to Posts > categories and create four new categories.

The next step is to define the different levels in which you will divide your main categories (or vocabularies if you like).
Here’s how I’ll structure my content:

Travel
      Stories

Photography
      Technical
      Cameras & accessories
      Composition
      Pictures
            Travel
            People
            Projects

Writing
      Blogging
      Articles

Web design
      Code
      CMS

Now I know what you’re thinking… first I’m telling you that you need to think this over and over and that you need to have several subcategories of subcategories, but my structure only has three levels, most of the time only two.
And you’re right! This is only a first draft of my structure. At this stage I’ve spent most of my time learning the different CMS that I didn’t really think about the final structure yet. But I promise, when I’ve figured things out, I’ll certainly post them!

Before I show you how to create this structure in Drupal and Wordpress, you need to know that there’s a huge difference between the two. In my humble opinion, I think this is a huge shortcoming of Drupal but I guess the designers had their reasons (probably because taxonomy can be used for every content type in Drupal).
Suppose, you’ve created the category “Writing” in Wordpress with the subcategories “Blogging” and “Articles”. And now you want to write a post about the writing style of a book you’ve read. This doesn’t belong to Blogging or Articles, and as you’re probably not going to write fifty posts about this subject, you can just categorize it under the main category “Writing”.
This is something that’s not possible in Drupal. You can’t categorize a post under a vocabulary, only under a certain term in a vocabulary.
There are two possibilities to solve this issue:
1. For each (sub)category where you expect that there might be post which don’t fit in any subcategory, you can create a new subcategory called “other” or “random” or something like that.
e.g.
Writing
      Blogging
      Articles
      Other
2. You start your vocabulary at a higher level.
e.g.
Blog
      Writing
            Blogging
            Articles
      Photography
      …
Both solutions have their pros and cons. The first solution looks very amateurish to me, it looks like you don’t really know what you’re doing (which might be the case, just don’t tell anyone).
The second solution may resolve in the fact that visitors won’t find your articles as they tend to look on the lowest level possible (so only in Blogging and Articles, but not in Writing).
It’s up to you!

Now how do we create these subcategories?
In Drupal:
Go to Administer > Content management > Taxonomy and press the add terms function next to your vocabulary. Enter the name of the term. For the first level this is sufficient, for any other levels, go to Advanced options and select the parent (higher level) category.
In Wordpress:
Go to Posts > categories, enter the name of the category and select the parent (higher level) category.

And there you go. Your content is now structured.

I’ve mentioned this a lot before (I know), but again, think before you start structuring your content. Otherwise you may find yourself one day in a huge mess, needing a lot of time restructuring it all.
Last days I’ve quite heavily investigated in this issue, and I still haven’t figured out some kind of ideal strategy.
If you have one, please share it with us!

Content structure: Philosophy

What’s the best way to structure your content?
When developing a website, at some point you will need to find an answer to this question. You probably already have some content in mind, written in a notebook or in files on your PC. If it’s on your PC, you might already be one step ahead because there will be already some kind of structure in the form of folders and files. But yet that’s not exactly what we are looking for.

Let us start at the beginning, what is structured content?
When you do a search on Google, the first thing it comes up with is a Wiki. Quite ironical is the fact that this Wiki page seems to be an orphan, which means that no other documents are linked to it. In other words, it’s not structured. But still it has something to say:

Structured content refers to information or content that has been broken down and classified using metadata.

Now we have a new question: What is metadata?
Of course there’s also a Wiki page for metadata which tells us that metadata is "data about other data". Now we’re getting somewhere.
If you’re not familiar with metadata, here’s a Bert and Ernie movie that explains it all:

What we have to do now is have a look at our content and define keywords for it. Unlike Ernie (the smooth bastard), we’ll need to define keywords that point to several of our content items. More important, we also have to think about future content. It’s not unlikely that you don’t yet have an idea of what the future will bring, so instead of defining your future content, you might want to create the possibility to easily add new items to the structure.
As an example, let’s say you are a veterinary medicine, and your specialties are cats and pidgins. So you want to create a website about this, and you create following specifications:
animals
      mammals
      birds

This will work just fine! Everything you write about cats will be classified under mammals, and everything you write about pidgins will be classified under birds. But then one day you start thinking about extending your business, and you start specializing yourself in dogs. Of course you want to write about this on your website. But where do we classify dogs? Also under mammals I guess. It does look strange to put cats and dogs together, doesn’t it?
What you’ll need to do now is split up mammals into cats and dogs, and you’ll have to add the new metadata to everything you’ve already written about cats.
What you should have done from the beginning is structure your data to a further level:
animals
      mammals
            cats
      birds
            pidgins

This way you could easily add an item dogs under mammals, next to cats.
Maybe you should have even gone further and divide cats into Siamese cats, Persian cats and so on. I have no idea which different types of pidgins exist, maybe I should have done some more research before writing this post, but I guess you get my point. It’s worth thinking about possible future content before you start creating your structure.

In a next post, I’ll get more down to earth and describe how we handle this technically, using CMS software.