Smart WYSIWYG Blocks of Content is now 3.1 compatible

Today was a big day for the WordPress community. WordPress 3.1 was released, introducing a bunch of exciting new features. Like most people, I updated some of my WordPress installations right away. One of my clients installations was running my Smart WYSIWYG Smart Blocks of Content plugin and when I updated that installation to 3.1, I instantly noticed that there was something wrong.

All of the Smart Blocks where no longer available and WordPress trimmed the post_type of the Custom Post Type to a lowercase version without spaces. Once I started the plugin, I choose to use ‘Smart Block’ as a post_type, which seemed to be a great idea back then. But with the change to a lowercase version in the WordPress queries, all of the Smart Blocks where no longer query-able, so pretty useless.

Hero of the day is Andrew Nacin, who pointed me to some code in his Log Deprecated Notices plugin, which I could use to fix this problem. Few minutes ago, I fixed the plugin, all new Smart Blocks will be using ‘smartblock’ as post_type and all the old Smart Blocks will be converted to new onces, the minute you update the plugin to version 0.4.1.

UPDATE: Thanks to Brian’s comment, I managed to fix another bug in this plugin. It is fixed in version 0.4.2 which is now the latest version available.

Don’t we all love Comic Sans?

It was Andrew Nacin’s tweet that got me thinking. Why isn’t there a plugin that gives us all the Comic Sans awesomeness that we can find, right in our beloved WordPress administration panel? That’s where my Comic Sans FTW plugin kicks in. Enjoy!

Don’t we all love this soft edged and curly font? It really adds value to all the work the Core UI team put into the looks of the WordPress administration panel. Thanks for all the feedback and exciting new features that you all mentioned in the past hours! 😉

My take on the Post Formats criticism

WordPress 3.1 will give us Post Formats. There is a lot of arguing on if themes and plugins should be able to add their own Post Formats. It is quite clear that the Post Formats serve a totally different need than everyone is thinking. In case you need to create your own Post Format, you should use a Custom Taxonomy instead of a Post Format. All of you still complaining about standardized Post Formats, should read Andrew Nacin’s excellent post On standardized Post Formats.

More information on the difference between Post Formats, Custom Taxonomies and Custom Post Types is to be found on Otto Wood’s blog: Post types and formats and taxonomies, oh my! and on Mark Jaquith’s blog: Post Formats vs. Custom Post Types.

I love the WordPress community

It’s been a while since my last post on this blog. The last two months have been filled with work, work and even more work. But that’s a good thing! My days are almost completely filled with WordPress development and I’m pretty confident that even the last few hours of the week that aren’t filled with WordPress yet, will be too soon.

Since WordCamp Netherlands (where I spoke about plugin development), I’ve noticed that the WordPress community is a community which I love to be part of. In the past years I’ve been working in many open source communities. But once I got into WordPress, the other communities look like just another computer club.

Being part of the WordPress community is different. I notice that I’m really looking forward to a new release – breathtaking moments every time the active tickets counter in Trac hits 0, feel proud of our community once the new release is there. It almost feels like a family, scattered all over the globe.

The more effort, time and dedication I invest in my WordPress work, the more I get back from the community. People are genuinely interested in what everyone is working on. And it all comes down to improving our favorite open source project.

Speaking at WordCamp Netherlands 2010

Last weekend was the first WordCamp I was speaking at. WordCamp Netherlands was a huge success with many great, international speakers. I had the pleasure to meet Adii Pienaar, Andrew Nacin, John O’Nolan, Fredrick Townes, Isaac KeyetMarco Galasso and many more.

From the moment Fredrick Townes opened with a great keynote, until host Erno Hannink closed the day, it was an adventure that I will not forget. Continue reading Speaking at WordCamp Netherlands 2010

Add WYSIWYG Smart Blocks via shortcodes

Minutes ago, I’ve uploaded version 0.3 of my Smart WYSIWYG Blocks Of Content plugin. Besides adding a Smart Block in a sidebar widget, you can now add them in any post or page you want – exactly where you want it.

Example of how to use the shortcode:

[sourcecode][smartblock id=12345][/sourcecode]

Where it says 12345 you add the id of the published Smart Block, ofcourse.

Using this shortcode, you can create Smart Blocks for texts that need to be shown on multiple posts or pages. When that text needs to be changed, you change it in a single Smart Block, and all posts and pages containing that Smart Block will change with it.

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()) {
include("admin_plugin.php");
}[/sourcecode]

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()) {
include("single_plugin.php");
}
}[/sourcecode]

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.