Easy WYSIWYG widgets with Smart Blocks

Finally, it’s release-day! My Smart WYSIWYG Blocks Of Content plugin for WordPress is live in the WordPress plugin directory.

With this plugin you can create WYSIWYG widgets with the default set of tools available in WordPress. Every user will love this. When I started developing, I couldn’t believe that there was no other plugin that did just this. In it’s core, the plugin is very simple. But it’s use is very efficient.

In the next releases, I will add features that will enable you to add Smart Blocks all over your WordPress installation. For example; add them to a post or page via shortcode. For now, this is all the information I’m going to post on this plugin. Please post any comments regarding it’s functionality, bugs and other reports in the WordPress support forum of this plugin. Have fun with the plugin!

Back on the WordPress track

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.

So stay tuned, follow me via @coenjacobs on Twitter or subscribe to my RSS-feed!

WordPress 3.0 compatibility of my plugins

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!

Using conditional file loading in WordPress plugins

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:

[sourcecode language=”php”]if(is_admin()) {

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:

[sourcecode language=”php”]add_action("wp", "load_plugin");
function load_plugin() {
if(is_single()) {

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.

Easily customize your WordPress comments looks

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;

[sourcecode language=”php”]<ul>
<?php wp_list_comments(); ?>

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;

[sourcecode language=”php”]<ul>
<?php wp_list_comments(‘callback=mytheme_comment’); ?>

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;

[sourcecode language=”php”]function mytheme_comment($comment, $args, $depth) {
$GLOBALS[‘comment’] = $comment; ?>
<li <?php comment_class(); ?> id="li-comment-<?php comment_ID() ?>">
<div id="comment-<?php comment_ID(); ?>">
<?php echo get_avatar($comment,$size=’48’,$default='<path_to_url>’ ); ?>
<?php printf(__(‘<cite>%s</cite> <span>says:</span>’), get_comment_author_link()) ?>
<?php if ($comment->comment_approved == ‘0’) : ?>
<em><?php _e(‘Your comment is awaiting moderation.’) ?></em>
<br />
<?php endif; ?>
<div><a href="<?php echo htmlspecialchars( get_comment_link( $comment->comment_ID ) ) ?>"><?php printf(__(‘%1$s at %2$s’), get_comment_date(), get_comment_time()) ?></a><?php edit_comment_link(__(‘(Edit)’),’  ‘,”) ?></div>
<?php comment_text() ?>
<?php comment_reply_link(array_merge( $args, array(‘depth’ => $depth, ‘max_depth’ => $args[‘max_depth’]))) ?>

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.

Get page ancestors the easy way in WordPress

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

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.

[sourcecode language=”php”]$ancestors = get_post_ancestors($post);[/sourcecode]

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.

[sourcecode language=”php”]if(in_array(17, $ancestors)) {[/sourcecode]

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.

So why should we write a new function?