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.
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.
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.
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.