The previous two years, I’ve helped put together a WordPress meetup in Amersfoort. While this was fun to do, it didn’t really make sense, because I do not live in (or even really near) Amersfoort. As a result know very little about essential things like venues there. It looks like this year, local WordPress people will take over “their” meetup, and I’ve been thinking about setting up a brand new one in “my” 035 area of The Netherlands.

Ideally, I’d like to do something that’s a little more informal than the Amersfoort ones were, and probably also more frequent. If there’s anyone who’d like to help organize, speak at, or simply attend such a meetup, please let me know in the comments. Oh, and despite the little joke I pulled with the logo, I’m hoping to keep it as low-key and relaxed as possible. Suit and tie entirely optional, perhaps even frowned upon .

One of the biggest, and most useful additions to WordPress in recent years has been the introduction of Custom Post Types. Before CPTs, all the content in your site needed to either be in pages or in blog posts. If your site needed a lot of different types of data, you’d typically use categories (or even tags) to tell them apart. I’ve seen (and probably built) examples where “products” and “news” were post categories, and the site’s front-end would continuously filter out one of the two. In hindsight: madness.

Since the introduction of Custom Post Types, it makes sense to declare separate types for different types of data. When doing so, there’s a crucial argument (passed to the register_post_type function) called “supports”. This argument tells WordPress which post features should be available for the new post type. This allows you to mix and match various features. No need for an excerpt? Require a “featured image”? Need custom fields? No problem. But there’s a catch.

Built-in features only

There’s a fixed list of features you can enable or disable. They correspond to the features present in WordPress’s two built-in types, post and pages. Nothing else. And as far as I know, there’s no (easy, developer-friendly) way to add new features. As nice as CPTs are, I think this seriously limits their potential.

Imagine being able to do something like this to create a CPT for a travel video blog.

'supports' => array( 'title', 'editor', 'author', 'thumbnail', 'subtitle' 'video', 'geo-coords', 'event-time' )

The first four features come standard, but the real fun is in the other (fictitious) ones. Being able to add a video to a post in a manner similar to how featured images work could have many potential advantages over simply adding it into the post’s content. And although there are plugins that’ll let you geo-tag and add timestamps, not all of those support CPTs, and they do not all store data in the same way. They’re all adding data to posts, but they’re all doing it in their own way.

Plugin territory

I’m not saying all these features should be in WordPress’s lean and mean core. Most of the ones I can come up with are arguably plugin territory. But it would be nice to be able to define custom post features once, and then be able to add them to any (custom) post type. WordPress could offer a coherent, standardized way for them to present themselves and store their data. A Widget API of sorts, for the backend.

One might argue that you can do all these things using meta boxes, post meta (or extra database tables) and such, but I feel there’s a certain elegance to opening up “post features” as an API. For one thing, there are plugins that let end users define CPTs without any coding, and this would give them more things to mix and match. And perhaps, something like the functionality of those plugins could eventually make it into core…?

This week, some of the brightest minds in WordPress – and me – are co-working in Sitges, Spain. As I wrote before, I’m part of the first WP On Tour, organized by Karim Osman of Automattic. We’re in a very nice villa and, compared to back home, the weather is excellent here. But more importantly, it’s really nice to be surrounded by fellow WordPress users and devs for a change.

We’ve set up a Flickr group, but at this time there’s very little in there. On Twitter, we’re using the #wpontour hashtag.

WordPress has recently been described as “the dark matter of the web”. It’s absolutely everywhere. The WordPress ecosystem is probably bigger than Facebook. But at the same time, most of the WordPress people I know are “flying solo”. There are a lot of freelancers out there who work with a small team, or none at all.

That’s why things like WordCamps and meetups are important. They offer the WordPress community a way to share experiences, exchange ideas and get inspired. Thinking along those same lines, Dutch Automattic “Happiness Engineer” Karim Osman is organizing a “WordPress Coworking Trip” called “WP On Tour”. Or as Karim puts it:

“The idea is to step out of your daily (office) environment and work at a challenging location somewhere in the world. Like a holiday, but then with WordPress geeks Everybody is welcome: bloggers, designers, programmers, entrepreneurs, etc.”

Sounds like fun, right? So much so in fact that the first trip, which takes place in Spain early next year, is now fully booked. And one of the lucky people who “got in” is me . In January, I’ll be working from a luxurious villa in Sitges for 7 days. The villa only accommodates twelve people, so about 99.999% of the WordPress community won’t fit. Fortunately, there’s a form on Karim’s site in case you’d like to be kept up to date about future tours.

There’s a Twitter list of attendees too.

It’s spring again. Temperatures are on the rise, trees are blossoming and birds are tweeting. Time for another WordPress meetup. Just like last year, Kaj Rietberg and I will be putting together a meetup in Amersfoort. If you’re a WordPress fan and you’re not too far from the geographical center of The Netherlands, please join us on the 10th of May.

This year, Paul van Heel and Amersfoort Creatieve Stad are helping us organize things (see their Dutch language post here).

(image from last year’s meetup, courtesy of Enrise)

We’re still working out the details, but here’s what’s been decided so far.

• The meetup will be on the 10th of May.
• Location will be De Observant in Amersfoort.
• We’ll be kicking off at 19.30, doors will open at 19.00.
• We’re working on a format that’s more interactive than last year.
• They’ll be kicking us out at around 22.00.
• The meetup is aimed at beginners and experts alike.
• Official Twitter hashtag is #wpm033 .
• Please register here.
• Karim Osman of Automattic will be joining us for the latest news straight from the source!

I’ll be posting more info here as it becomes available.

I’ve been promising a new version of WP-Cumulus for a long time. I’ve tried working with more experienced PHP developers, but it’s been hard to find a really good one who’s able to devote time to the project. I still think a plugin like this should be a team effort, but for now I’m going to kick things back into motion again myself.

What’s ready at this point is a much cleaner rewrite of the plugin files, with the display logic in a neat little class that port authors will hopefully be able to reuse. I’ve also got a Flash movie that uses a user-defined system font, as a result is much smaller, and supports unicode tags.

Burning bridges

I’ve decided to bump the required WordPress version to 2.8 or 2.9. There’s so much code in the current version that’s there only to support older versions and adds nothing. Running older WP versions is a bad idea anyway, and I want to use the new widget and option page APIs.

Another thing I consider a bad idea in hindsight is the “compatibility mode”. It way helpful for debugging WP-Cumulus on blogs with poor markup, but I’m going to trust that SWFObject 2.2 does a better job and once again skip all the extra code required.

Lastly, to support unicode, your blog’s visitors will need Flash Player 10.

Security

Now that I have the main two parts (plugin and Flash movie), I need to hook the two up to each other. The basic idea behind how WP-Cumulus works has always been that WordPress supplied the tags through its wp_tag_cloud function. It was easy and convenient to simply pass that function’s output through to the movie using the “flashvars” interface.

However, as some experts have found, the technique of passing URLs through flashvars, while extremely common among Flash programmers, poses a security risk. Versions 1.22 and 1.23 pathed the biggest holes, but there’s still a very eloborate social XSS that could pose a risk to Cumulus users. Another issue is that some themes alter the output of wp_tag_cloud through an API hook. This is fine for the html tag cloud, but for WP-Cumulus it means my Flash movie doesn’t get the data as it expects it.

This means I’ll have to rethink the flow of data, and as a result, the movie’s technical interface is going to be radically different. I’m thinking along the lines of having the movie request its content from a fixed, relative url, and using JSON instead of XML. I know this also affects the authors of ports to other systems, but my primary concern is the WordPress community.

ASAP

There are lots of things that still need to be done. Like i18n, the data interface and better alternate (“no-flash”) content. I’m really committed to getting a completely rewritten version of the plugin out there as soon as possible, but I also want to make sure it’s stable. Think weeks, at least. There’s not a single line of code in the new version that I copied from 1.23, so it’ll need extensive testing.

The great thing about WordPress is that there’s a huge, active and helpful community of users and developers. There have been WordCamps organized all of the world, as well as many smaller meetups. Last week, Kaj Rietberg and I put together just such a meetup in the Dutch city of Amersfoort.

The event was sponsored by open source development company 4WORX and hosted at the neighboring Dara restaurant (recommended!). Kaj and I were happy to welcome around 25 WordPress enthusiasts, a couple of whom had been tricked beforehand into preparing presentations. Kaj has written a more detailed account over at the WordCampNL website (in Dutch) which includes the slides from two speakers.

More images are on Flickr (sets by Kaj and 4WORX).

I’d like to thank 4WORX for helping us out. That was cool.

The templating system in WordPress is very flexible, and there’s rarely something you can’t do or that doesn’t work as you’d expect. A notable exception however is the_date. Its purpose is simple enough. It displays the current post’s date of creation. But on pages with more than one post (such as on many blog home pages), something weird happens. If a number of posts on any given page were created on the same date, the_date will only show that date for the first of those posts.

In the early days of blogging, posts were usually listed by date, much like a regular, paper diary. In the old default theme that comes with WordPress a big date title is used to separate posts into days. That’s what the_date was created to do, and so it makes sense it only displays the same date once. In most modern themes however, people like the date to be among the meta data for each article, so the_date falls short.

the_time

In comes the_time. This template tag, as the name suggests, shows the time at which a post was created. However, it accepts a PHP time format string as an argument, and can be made to display the date. You could simply put a date formatting string in there and be done with it, but I like to keep things flexible, so i wanted to use the date format string set in WordPress’ settings. That way the user controls the output, and it can be adjusted to international preferences.

When I first ran into this I posted my issue on the WordPress forums, and Otto42 came up with a prefect solution. I’ve been using it ever since and thought I’d share it here.

the_time(get_option('date_format'));

What this does is get the user-set date format from WordPress and feed it to the_time. Since that function doesn’t have a ‘once a day’ limitation, you can use this as often as you like in your theme.

I’ve been working on yet another upgrade to my WP-Cumulus plugin. It looks like it’s become a pretty major update with a couple of exciting new features, but as a result it will probably no longer support versions of WordPress prior to 2.5. One of the things I want to introduce is proper shortcode support, and that API was introduced in 2.5.

Does anyone still use 2.3.x? Or even older versions even? I’ve not been able to find any statistics on this, but I assume most people keep their installs up to date, right?

I don’t like ‘re-blogging’. I try and write original stuff and not point to other people’s posts. This video however is essential if you’re serious about SEO and WordPress, and you haven’t seen it already you really should. My fellow countryman Joost de Valk talks about SEO and shares some great tips. The video is after the break.


WordPress SEO & Optimisation Strategies a4uexpo London 2008 from existem on Vimeo.