Support forums, in general, seem to be notorious for hosting lots of posts about problems, with few posts offering solutions to those problems. I see this on a regular basis on many web development support forums… many queries and few answers.

Why the Wordpress Support forums specifically then?

The community behind Wordpress is rich and filled with users of all skill levels, modifying and creating themes and plugins, as well as creating many new and innovative offerings for the community to tinker with. As with the reach of the community, there are many users who post on the support forums with what, to some, may seem like “simple” or “basic” questions (for example; “How do I centre a background image in CSS?”). As mentioned previously, these kinds of queries may seem “simple” to some Wordpress users… however, this query may be really difficult for the poster. Users at different skill levels encounter different issues and post different queries.

Okay, so what does that have to do with me?

Ah ha. Here, ladies and gentlemen, is the crux of this post.

Being in the information and online media industry, I’ve had, on several occasions, a friend or family member who says “you know computers, right?”. I’m certain you’ve experienced this too. The question, followed by your inevitable inward sigh, which is then followed by an equally inward-sigh-worthy question. How about answering the question?

That friend or family member maybe doesn’t know the answer to the question they’re asking you (although, they probably wouldn’t be asking it if they did, but anyway), so why not give them the answer, if you know it? It’s not going to do any harm to anyone and will ultimately potentially benefit the question-ee (is that a word?).

The same goes for support forums. Why not just help the poster out, if you know the answer to a question? In order to keep the Wordpress community as rich and vast as it is, questions at all skill levels with the system should be answered, if a user has the answer. Could you really use the 10 minutes you’ve taken to help a user centre that background image really be put to better use?

To infinity, and beyond!

Right. To end off this post, lets try this. Every other day, pop over to the Wordpress Support forums and browse around. If nothing else, you’ll be keeping up to date with what’s going on in a part of the community… and hey, you may just find the answer to an issue you’ve been tackling in your own code (that happened to me a few weeks ago, actually).

This post applies to any and all support forums, in the greater scheme of things. Be it Wordpress or any other system or community where support is a factor, why not rather play a role in the community and it’s development?

What do y’all say, hmmm?

What’s this “child theme” thing?

For those unfamiliar with the concept, the way I’d explain it is as follows:

A user chooses a Wordpress theme (or theme framework) which they would like to customise. They then create a new theme with only the files required for the customisation. The main change comes in the style.css file where the theme details are specified. The line “Template” is added to the theme details, which then specifies the folder name of the main theme (chosen above). An example block would like like this:

/*

Theme Name: WordPress Default

Theme URI: http://wordpress.org/

Description: The default WordPress theme based on the famous <a href="http://binarybonsai.com/kubrick/">Kubrick</a>.

Version: 1.6

Author: Michael Heilemann

Author URI: http://binarybonsai.com/

Template: parent_theme_folder_name_here

Tags: blue, custom header, fixed width, two columns, widgets

*/

This allows, as I mentioned above, for the user to customise only the areas of the theme where customisation is required, without disturbing the structure of the main theme. Therefore, if the theme developer upgrades their theme, fixes bugs or develops for a newer version of Wordpress, the theme can easily be updated to the latest version.

And, onto the main point of this post…

What about the idea of child plugins for Wordpress?

Would it not be useful for users to be able to customise a particular section of the plugin to suit a specific situation, without modifying the main core of the plugin? This way, the plugin can be developed and maintained on a development path in accordance with Wordpress and the developer, while allowing the end user more freedom to develop the plugin in their own direction.

I find, often, that a plugin has been coded with the right idea in mind for the task at hand, but that it may be rather bulky and contain code that is unnecessary to achieve the main function of the plugin.

OK, sounds cool… but how would you do it?

At this point, I’d keep the approach simple. Following the same method as with child themes seems to me to be the most logical method. That way, users who are familiar with the concept can easily adapt and begin creating right out of the box.

The one requirement I would say, in order to make things a bit easier in the background, would be to keep the file names the same for the modified files. The main issue I can foresee with child plugins would be the multiple declaration of functions. If this issue can be overcome, using some form of bulk “function_exists()” call, the potential for child plugins could have an interesting impact on development for Wordpress. Users could potentially create “addons” for popular plugins, allowing for interesting customisations and to potentially take some of the pressure and workload off of the main plugin developers for that particular plugin.

Closing words.

In closing, I hope this thought sparks off some discussion about the concept. I look forward to hearing everyone’s thoughts on the topic of child plugins.

The “Foursquare everywhere” service allows users to specify their current city via a text box instead of a dropdown selection menu of available cities. When logged in, however, it is displayed as “elsewhere”. Some form of moderated city addition would be really beneficial here, in my opinion. There are definite pro’s and con’s to the choice of retaining exclusivity within Foursquare. It is due to this choice, I believe, that many potential Foursquare users have chosen Gowalla, which has no restriction of exclusivity on their service and allows check-ins at any point as well as point creation, stamps for checking in, pins for accomplishments and various other features similar to those of Foursquare.

Over the last few years, each year or two has seemed to have had a “buzz word”. The last year or so was Twitter, the concept of tweeting and how it all worked and integrated into the average internet user’s daily online life. Before that was the Facebook craze, people finding old friends from their school days and joining groups about going out on the weekend, discussing popular topics of the moment or how much they love kittens. These trends don’t seem to fade away, but rather seem to overlap in a way, retaining their status while the next big one rises to the fore.

I see 2010 as the “year of the check in”. People will use services like Foursquare, Gowalla and any other services that arise from this growing trend, to share their experiences, find new places, meet people who share common interests and, essentially, as another tool in their social networking tool belt. Geo-tagging of images and tweets, Google Maps extensions for Flickr, Tumblr and Wordpress.com exist. This (although having been around for some time now) seems to be the logical next step.

As a developer, the problem and solution are usually quite clean-cut (such is the nature of code, prodominantly). The solution, however clean-cut it may be, isn’t always visible when approaching a coding task. At times like those, I employ a theory:

Whatever you do to figure out the solution, whatever pencil-tapping or repeated contact between your head and desk occurs, the end result will work and be exactly as per the task set out to you.

Knowing this, the task of achieving the goal becomes seemingly less stressful and a bit clearer to tackle. In addition, I find it important to clear one’s head, move away from the problem for a few minutes and give it some thought from a different angle.

That’s my theory, anyways.

Stop. Think. Re-evaluate.

The process

So, what exactly are we doing here? To put things in point form, this is the process:

1. Create custom rewrite rules
2. Add our new variables to the public_query_vars array
3. Flush (and thus, regenerate) all Wordpress rewrite rules
4. Add our functions from steps 1, 2 and 3 into Wordpress via actions and filters

Right, so lets get down to it then.

Create custom rewrite rules

Rewrite rules use a  token which is replaced by the necessary query variable. For example, we create a token called %token% which, using a regular expression, gets replaced by “id=”. This will be shown further below.

Add our new variables to the public_query_vars array

By default, Wordpress has an array of public query variables which can be used within templates and plugins. In order to access our query variables (ie: the “id=” in the above example), the variable needs to be added to the public query vars array.

/**
* add_custom_page_variables()
* Add the custom token as an allowed query variable.
* return array $public_query_vars.
**/

function add_custom_page_variables( $public_query_vars ) {
$public_query_vars[] = 'car';

return $public_query_vars;

} // End add_custom_page_variables()


Flush all Wordpress rewrite rules

By flushing the rules, we are forcing Wordpress to regenerate it’s rules list, including our new rules in the rules set.

/**
* flush_rewrite_rules()
* Flush the rewrite rules, which forces the regeneration with new rules.
* return void.
**/

function flush_rewrite_rules() {

global $wp_rewrite;

} // End flush_rewrite_rules()


Add our functions from steps 1, 2 and 3 into Wordpress via actions and filters

Now that our functions have been created, we need to hook them into the various necessary processes within Wordpress. We do this using a combination of actions and filters.

Our first action runs on initialization. This is where we flush the rewrite rules in Wordpress, causing them to be regenerated.

The regeneration brings us to action number 2. This is where we create our custom rewrite rule, hook it on to the global rewrites array and generate the rules.

Our final line is our filter where we add the new public query variable into the global public_query_vars array. We then later use this array to access the variable in our theme.

add_action( 'init', 'flush_rewrite_rules' );
add_action( 'generate_rewrite_rules', 'create_custom_rewrite_rules' );
add_filter( 'query_vars', 'add_custom_page_variables' );


The scope of rewrite rules

By default, Wordpress rules are applied across all pages. Thus, the tag “%pagename%” is used in place of a specific page slug. To use your rules on only a single page, replace “%pagename%” with a specific page slug. You can either generate this slug dynamically or staticly.

That’s all, folks

And there you have it. A custom rewrite rule in Wordpress. This post is intended as a starting point for using custom rewrite rules in Wordpress. There are virtually infinite possibilities created when using rewrite rules (either one or many) and some really interesting plugins and functionalities can come out of using rewrite rules.

Thanks must also go to Joe Hoyle who’s use of rewrite rules provided the inspiration for this tutorial.

If there’s anything that isn’t clear, please comment below and I’ll do my best to clarify and help.

Before I go… wouldn’t you like the files?

I thought you might. Click below to download the code written above (it’s been written into a class for easy implementation in your projects).

Download the  “Custom URL rewrites in Wordpress — A Getting Started Guide” code example.

“New! Lists. A great way to organize the people you follow and discover new and interesting accounts. (BETA)

Lists are timelines you build yourself, consisting of friends, family, co-workers, sports teams, you name it. You’re part of a small group receiving this feature, so don’t tweet about it yet!”

This looks like it will be quite an interesting feature to work with. It can also allow Twitter users to follow conversations between various groups of people as well as to create an interesting list (for example, South African bands on Twitter) and to share that list with others who may find it of interest (by the way, check out my first Twitter list).

Twitter lists can, in a way, be thought of as similar to groups on other social platforms. They allow users to follow tweets by a group of users with a single click.

I look forward to seeing this feature rolled out fully and to see how it gets used by the Twitter community.

A quick word on conventions

Magento, like many other content management systems, likes to follow conventions. Adopting these conventions when designing your theme, as well as during the theming process, can greatly minimize the amount of code required by your theme. As mentioned on Part 02, Magento has a “fall back” feature where it looks for required files, when not in your theme, within all other themes in the current interface until it finds the file it requires. This essentially allows users to keep a copy of the default theme in the interface in which they are coding their theme (either the “default” or a custom interface) and to only modify the files that require customisation.

An example of the above-mentioned conventions can be seen in the way that boxes are styled within Magento. Boxes are not unlike “widgets” in Wordpress. Each box is assigned a unique class for specific styling to that box, as well as a generic class for global styling.

A CSS block for global Magento box styling looks like this (no attributes currently set for each class):

.box {}
.box .head {}
.box .head h4 {}
.box .content {}

By styling the above tags in a CSS file within your theme, you should be able to style the majority of sidebar blocks within your Magento theme.

Setting up your theme’s stylesheets

As mentioned in Part 02, Magento themes are made up of templates and XML files, as well as a folder to hold all images, CSS files and other assets. For starters, I’d recommend making copies of all CSS files within the default theme and placing them in the same relative location within your custom theme (most likely the “CSS” folder within your theme’s “skin” folder). Once you’ve got the hang of working with these CSS files, or to add your own so your own CSS file conventions can be used, the calls to the CSS files are located in page.xml near the top of the file. Once you get the hang of the conventions used within Magento, adjusting the theme’s CSS becomes a lot easier.

Great, so what other conventions are there?

If you’re working in Firefox, I’d recommend installing the Firebug extension, or something similar. In Safari, use the “inspect Element” command. This will allow you to inspect the code of your Magento installation and to identify conventions within the code. As there are an almost endless amount of template files, when styling your theme I find it best to keep a copy of the default theme within the interface in which I’m coding and to make as many changes as possible via the CSS and images without modifying the template *.phtml files or *.xml files. This way, when your theme is done, you may end up with only several modified *.phtml and *.xml files. Also, if you want to then package your theme as a standalone theme (ie: without requiring the need of the default theme), you can simply copy the unmodified files from the default theme over to yours and voila!

A Very Important Final Note

Well, folks, that’s it for this round of the “Theming For Magento” tutorial collection. In Part 04, we’ll be opening up one or two *.xml and *.phtml files, checking out how they work and looking into ways to create smaller code snippets where possible.

A very important last note: when creating your Magento theme, make a note of all the files you’ve modified along the way. For example, if you only modify the CSS files, make a note of that. It will help greatly later in when identifying unmodified files for copying over from the default theme and can, in general, be a real time-saver.

Yesterday, I jotted down a list of features I’d like to potentially include in this theme… some useful, some for repetitive tasks and some just weird and whacky. My question to you all is, what features would you like to see?

They can be any of the above– minimise repetitive tasks, new and useful or just plain weird and whacky. Lets have it guys. What features would you like to see in a Wordpress theme?

Leave a comment and share your feature request.

The other day, my mom discovered blogs. This got me thinking; how many people discover blogs and blogging for the first time every day?

I had one or two things to sort out with the phone when I got it. I’ll write another post listing those and how I resolved them.

P.S Written on my iPhone.