For people that follow me for a while now, this post is not that much of a surprise. I tend to switch from Dutch to English written blogs and back every once in a while. Why switching back to the English language? Simple. It’s hard to position yourself as a Dutch speaking WordPress developer in the English WordPress world without owning your own blog.

So here I am, back on the WordPress track. There is a lot to be done on this website, but I’m getting there. The minimalistic design helps you (and me!) to keep focused on the content, which is – obviously – the most important.

In the next couple of days, I will be updating my WordPress plugins to be compatible with WordPress 3.0. Some of them have a few minor bugs and it’s time to – finally – squash them.

Next on the list: the release of a new plugin. I’ve been struggling with allowing users to work with a WYSIWYG editor in their widgets. There is simply no plugin out there that does just that. Well, my plugin will change that and offer even more features. I’m not giving away the complete idea, but it is going to be quite handy for websites running WordPress as a CMS.

Yes, there are a few errors in my WordPress plugins while running on WordPress 3.0 installations. I’m very much aware of that.

In the next couple of days, all of my plugins will be compatible up to the latest version of WordPress. It’s a shame that they don’t run out of the box, but it’s an even bigger shame that the errors are still there by now!

Most of the plugins seems to show a “You are not authorized…” kind of error, so it should be really easy to fix it. Stay tuned!

Faster loading WordPress installations is our goal, by making our plugins just a little bit smarter. Basic rule is: when we don’t need a file, don’t include it! When you write a plugin for the Dashboard, it is of no use loading the files used by the plugin at your homepage or at a single posts page. For example:

The imaginary plugin that we’re writing here, has some functionality in the WordPress Dashboard. We split up that functionality in a file called plugin_admin.php and we only include it inside the Dashboard. Whenever we are on a page outside of the Dashboard, the file will not be included, which will result in a faster loading page.

Using other WordPress conditions

Besides is_admin(), we have a few common conditions inside WordPress. With is_single() we check if the current page is a single post page and with is_category() we check for a category page. It would be cool if we could use these conditions inside our plugins to determine wether or not a file is needed.

But there is the catch. Conditions like is_single() and is_category() do not work inside a plugin because WordPress loads the plugins way before it knows what kind of page it is at. A great workaround is to hook your script to the wp-hook, so it will be executed right after the posts are loaded, so WordPress knows the type of the page.

A quick example to get you going. In this script, a function is added to the wp-hook, that will include a plugin file, only when we’re at a single post page:

Using a load-function inside the wp-hook, we can use conditions like is_single() just like is_admin() inside a plugin. This way you can start preventing your plugins from loading files that WordPress does not need at certain pages.

You might need to restructure your plugin a bit to make it work this way. But when used effectively, it will make all WordPress installations a lot faster.

As you might know, the function that displays the comments on your WordPress blog (wp_list_comments()) is declared inside the WordPress core. Have you ever wondered how to customize the look of your WordPress comments within your theme and without having to change anything to the core? It is possible and can be done easily.

But many people are changing the core files, because they simply don’t know any other way to change the default layout your comments have. Once they have to update their WordPress core, the changes are lost and need to be applied again!

By default, the call to wp_list_comments() in comments.php looks like this;

Using it this way, it will use the default formatting on the comments. We can provide some arguments to that function, so we can change the looks of our comments. When we look at the arguments we can provide, there is the callback-argument;

callback – (string) The name of a custom function to use to display each comment. Defaults to null. Using this will make your custom function get called to display each comment, bypassing all internal WordPress functionality in this respect. Use to customize comments display for extreme changes to the HTML layout. Not recommended.

It says doing this is not recommended, but it is the way to change the looks of your comments without changing WordPress core files! We can list our function to be executed to display each function like this;

This way, the function theme_display_comments() will be used to display each comment, skipping the normal WordPress routines to do this. Because we skip those routines, we have to take a closer look at our function to make it sure it will display the comments properly. The WordPress codex provides us with the following example, that should get you started on creating custom looks for your comments;

When we put this function in the functions.php-file of our theme, we can customize it (and thus modify the looks of our comments) and save these modifications, so they will be protected from being overwritten by a WordPress core update.

WordPress is used by a lot of people as a real CMS. Although it is actually a blogging tool, it has a bunch of features that enables it to compete with most real CMSs.

A function that comes in hand while building a website with WordPress but isn’t well documented is get_post_ancestors(). With this function you can get the id’s of the pages that are higher in the page-hierarchy than the current page. This can be used to generate breadcrumbs, or for highlighting the current path a user is following in the navigation, like I do in the navigation on this site.

[sourcecode language=”php”]$ancestors = get_post_ancestors($post);
if(in_array(17, $ancestors)) {
// Code that will be parsed when this page has a ancestor with id 17
}[/sourcecode]

By running this function once, you can build a array that contains all ancestors of the current page (or post). After that you can simply check whether or not a page id is in that array and therefor is a ancestor of the current page.

What does this code do?

The example above looks really simple and it actually is. I’ll try to explain it step by step in the following lines so you can use it on your own.

The first line is the actual working of the function get_post_ancestors(). It works with the variable $post that is containing the information about the current page or post. The variable $ancestors will be a array that is filled with the id’s of the pages that are the ancestors of the current page.

Now we are able to check if the id that we are looking for is amongst those id’s and that’s what’s happening in line number three with PHP-function in_array().

This function checks if the first value that is provided (17 in this example), is present in the second value (the array $ancestors). If it is, the code in the if-statement will be processed. You can do inside there whatever you like, from highlighting a navigation item, or creating a breadcrumbs path.

And that’s basically it. There’s more that you can do with this function, but I’ve proven that it’s powerful and it’s very easy to use.

No need for writing your own functions

I’ve seen a lot of people writing their own functions in order to do exactly the same as this function does. But here is no need to do that, since WordPress is perfectly capable of doing this with it’s own functions.