Noel Tock, who’s at WP On Tour with me, just released a brand new WordPress plugin that lets you accept Stripe payments. Stripe is a new, highly developer-friendly payment solution. They have low rates for processing and a great API. Right now, you can only use Stripe to accept payments if you’re in the US, but if you are, you can accept money from all over the world.

WP-Stripe keeps track of recent payments (without storing the more sensitive bits), and has a widget that shows recent incoming transactions, with gravatars. If you’re running a charity, this can be a great way to thank your sponsors. Donors who’d prefer to remain anonymous can of course opt-out of this.

The donation form is inserted into any post or page on your blog using a simple shortcode. Here’s how it looks (screenshot, not an actual donations form).

Noel needs people to test the plugin, and fortunately, there’s a test setting in the API that lets you make payments without them actually getting processed. This is fully supported in version 1.0 of the plugin, and from what I’ve seen it works perfectly. Recommended.

Because WP-Cumulus is open source software, the source files are available online. I didn’t package them with the regular plugin download, but you can download the Flash files from wordpress.org and my blog. Included in those downloads is a file called “tagcloud.xml”, which is mainly used to test the Flash movie locally, within Flash’s IDE. Unfortunately, that file sometimes ends up online. And, in most cases, it shouldn’t.

This is not the cloud you’re looking for…

To properly (or rather: easily) develop and test the Flash movie that’s the heart of WP-Cumulus, it needs content. Without a set of tags, there’s nothing to see. So I created a file called “tagcloud.xml”. It’s loaded into the movie only if no tags are supplied through the regular route (flashvars). The tagcloud.xml bundled with the source code download is an older, outdated “dump” of my blog’s tags. That’s okay for testing, as long as its contents don’t get indexed by search engines.

Until recently, Google wasn’t very good at looking into swf (Flash) files, but it appears that this has changed. From what I can tell, Google now processes the actionscript inside, at least well enough to detect calls to external files. Unfortunately, Google’s bot isn’t quite smart enough to realize this particular file is only loaded as a fallback mechanism. And as a result, it tries to index the tag cloud xml file. This results in three possible scenarios.

Option 1: No tagcloud.xml file: 404 errors

If you’re running the stock WordPress implementation of WP-Cumulus, there should be no tagcloud.xml on your server. It’s not in the standard plugin distribution. Yet, Google will try to access it because it is potentially called from the Flash movie, resulting in a 404 “not found” error.

If you’re using something like Google’s Webmaster Tools to keep track of 404′s, you might have seen this error pop up. Rest assured, it’s not a missing file. The flash movie won’t actually call it. Since the plugin provides the tag cloud through flashvars, there’s no need to fall back to the static file.

Option 2: You’re using tagcloud.xml to provide the tags

If your website is “homebrew”, you may be using the tagcloud.xml to actually provide the Flash movie with its data. In this case, there’s nothing wrong with it getting indexed. At least not from a technological standpoint, SEO experts may disagree.

Option 3: A tagcloud.xml exists in error, and is getting indexed

If you’re using one of WP-Cumulus’s many ports to other platforms, you may have a tagcloud.xml in place. Chances are it’s not actually used, and it still has “my” data in it. In this case you really should remove the file from your web server. My website’s statistic indicate that a lot of websites have this scenario in place, and it’s causing a lot of unintended links from those sites to mine.

So, please check if your site has a tagcloud.xml, and whether it’s used. If not, please remove the file. If you’re the author of a port, please see if the file is needed in your distribution, and remove it if not. Thanks!

(image by Gurato)

A few days ago, @bakkel tweeted about WP Time Machine. This WordPress backup solution turned out to be exactly what I’d been looking for. It gathers all the relevant bits (like your blog’s database, uploaded images, etc) and uploads them to Dropbox, Amazon’s S3 or FTP. It even adds a file with comprehensive restore instructions. I’ve argued before that backups need to be absolutely painless, and with this plugin they are.

Dropbox

I’d recommend setting the plugin to use Dropbox. Their free subscription only offers 2 GB of space, but as long as you’re not creating daily backups in seperate folders, that should be plenty. And you probably don’t need seperate folders because Dropbox keeps a 30-day file revision history. My site’s backup files take up around 70 MB of my 2 GB, and I’m able to restore previous versions, up to a month old, through Dropbox’s interface.

A somewhat eccentric options page

Setting up the plugin is very easy, but the options page is a little awkward. For some options, it show a clickable link that toggles the setting to whatever it isn’t currently. There’s no indication of the option’s current state, except that it’s not what the link says. In my opinion, this is poor usability, and I’d really love for the author to change the options page to simply use radio buttons or checkboxes.

Setting up recurring backups

This is the hardest part. The plugin has an option to create a new backup every time a new post is published, but in most cases this is not ideal. The alternative is to set up a cron job on your server. Most hosts allow you to do this, but it can be a little tricky to get up and running. The plugin’s website has a guide on how to set up a cron job, but I think this should probably be made easier.

That being said, WP Time Machine is the best free solution I’m aware of for backing up your WordPress install. It does more that the typical database-only backup plugins, and storing backup files off-site adds extra security. Recommended.

When I first started using WPMU, the now-integrated multisite version of WordPress, I found it strange that there were no built-in tools to aggregate content onto the main blog. It seemed to me that that was something plenty of people would want to do. Sure, there were plugins and hacks, but none of them were as polished as I’d like them to be.

Fortunately, things have changed. WordPress 3.0 now has multisite capabilities built right into it, and Bjorn Wijers, a friend of mine and one of Holland’s top WordPress developers, has created a really cool plugin to handle content aggregation. Called bbAggregate, this plugin doesn’t just collect posts from blogs to be displayed on the home page, it allows you to display aggregated content on any of your network’s blogs. And to do this it introduces the concept of streams.

Streams

Once installed, bbAggregate will allow you to create and manage so-called “streams” of content. If there are multiple bloggers in your network who write about cats, you could set up a stream called “cats”. Post authors would ten be able to add posts they write to the “cats” stream. At the same time, they can choose to show the “cats” stream on their blog. If others blog about dogs, setting up a “dogs” and a “pets” stream makes sense. It may help to think of streams as a type of category, but there’s a little more to it than that.

Control

Unlike with (site-wide) categories, bbAggregate offers fine-grained control over what is shown in a stream. You can exclude blogs, limit the number of posts per blog and set up pagination. There’s no per-post control over what is in the stream (other than by editing that post, if you have the right privileges), but the plugin makes it very easy to exclude blogs that don’t play nice.

Room for improvement

This is a brand new plugin. Considering how complex the underlying code must be, the currently released version is very mature. However, there are a few things I think could be improved. The main one is that in order to display a stream, some theme editing is required. This is a well-documented and easy process, but I’d love to see a more seamless integration in future versions. I’m pretty sure this can be done, and it would greatly improve the project’s change of being widely adopted.

If you’re looking for a flexible way to cross-aggregate posts on your multisite WordPress install, I’d highly recommended checking out bbAggregate.

Recently, I came across discussions on Twitter, and a blog post about ‘hidden links’ in my WP-Cumulus WordPress plugin. Quite frankly, I’m a little embarrassed by this, and I’d like to explain how the situation came to be, and what I plan to change in upcoming versions.

History

When I did the first couple of versions of WP-Cumulus, it was not hosted on wordpress.org. All there was in terms of user support was the comments section of a blog post on this blog. To help people troubleshoot flash plugin trouble, I linked to that post in the alternative or “no flash” content. This content is shown only to user without (the right version of) Flash. It is very common among Flash developers to link ‘home’ this way. I was aware this would also be shown to search engines, but at the time there were only a couple of users. My reasoning back then was that providing a helpful message was important enough to warrant putting the link there.

Whoa, millions of incoming links…

Then, Cumulus started catching on. I moved it to wordpress.org, where it made the top 10 most popular plugins a few times. People were starting to port the plugin to other platforms, and I started getting tons of support requests. Some days, just answering these would take hours. I was overwhelmed. Around the same time, I started noticing an increase of traffic on my blog. At first I thought it was because people were googling for the plugin, but it soon became apparent that there was more going on.

As an unexpected side-effect of the ‘no flash’ link, my blog now had thousands of incoming links, causing it to rank well in Google. Because I sometimes write about things like hosting, advertisers were starting to show interest, and I have to admit I jumped at the opportunity. As time went by, it became increasingly ‘difficult’ to remove the links. Here I was, making a little extra money because of a link I forgot to remove somewhere along the way. But even so, I no longer feel comfortable with the current situation, and have been planning to remedy it for a while.

Future versions

As you may have read on this blog, I’ve been trying to get more people involved in the project. It needs a better programmer than I am to keep it up to date. Unfortunately, this has not proven very easy. As a result, WP-Cumulus 2.0 has been in development for over a year, and one of the things it aims to fix is this ‘hidden links’ situation. I’ve decided that any link in the alternative content should be optional, and disabled by default. And it should probably point to the wordpress.org page instead of this blog. By default, it makes sense to show the regular (html) tag cloud to users without Flash. Version 2.0 will probably do it that way.

I’ll be working on Cumulus 2.0 this week (with one of the best software developers I know, whoohoo!), and I hope to have a rough version some time this month. It’ll put you in control of what is shown to users, search engines and everthing else. As it should have been all along.

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.

I hate having to do this, but I’m going to be closing the comments on most of the WP-Cumulus related posts on this blog. Because some have several hundred comments, they’ve become impossible to read and I find that the same questions keep getting asked over and over again. I’ve tried to patiently answer all of them, but I’m no longer able to keep up. Blog comments just aren’t a very good support mechanism.

If your question is about WP-Cumulus, the original WordPress plugin, not one of its ports or variations, please post it in the WordPress forums. This allows others to find the answers, and chances are your question has been discussed already. The forums are an invaluable resource, and offer a much better platform for WP-Cumulus support. If you add the “wp-cumulus” tag to your thread, I’ll almost certainly see it.

I’ll also try to update the FAQ more often. It’s a little out of date, but definitely still a good place to start. Oh, and for more info, see my support page.

WP-Cumulus has been ported to quite a few other platforms. I keep bumping into it, often on sites not running WordPress. I’ve given up trying to post about all of these spin-off projects, but this one feels a little special. Gautam Gupta has created a bbPress version. As far as I’m aware this is the first port to another Automattic project (I’m still waiting for a wordpress.com ‘port’, come on Matt ).

So, if you want your forum tags to fly like your blog tags, head over to http://bbpress.org/plugins/topic/bb-cumulus/ for the download.

The one feature I’ve always wanted to add to WP-Cumulus is true unicode support. Flash player 9 made this impossible because it needed to have the font characters embedded into the movie, and unicode fonts are simply too big for that. But with Flash 10, Adobe has introduced new ways of handling text, and those now allow for non-embedded text to be animated quite smoothly. There’s also no longer any need to specify an exact font name, you can simply tell the player to get a sans-serif font. Flash player 10 is on over 93% of computers now, so it starts to make sense to use it to finally add this long-awaited feature to WP-Cumulus.

I’ve created a test movie (above) that uses these new features, and I’m anxious to find out if it works for you, especially if you’re in Asia, Russia or anywhere else with a non-Latin character set.

What are you seeing?

• Are you seeing all 45 tags (approximately), in many languages?
• Are you seeing your (non-Latin) language?
• Any other issues?
• Do you want me to add your language to the test? Post the language name here.

Please leave a comment below and tell me if the movie works as it should. Thanks!

A few weeks ago I rushed out an update to fix a potentially dangerous Cross-Site Scripting (XSS) vulnerability in WP-Cumulus. With the PHP part of the plugin shielded from ‘outside use’, I was hoping no more issues would pop up. Still, I’m glad MustLive alerted me to another issue that uses the Flash movie itself. The exploit worked by calling the SWF file directly, and supplying link with javascript. I’m not quite sure how dangerous this is, but I’ve modified the movie so it only executes regular links.

Please update your copy of WP-Cumulus to 1.23 asap. For most users it should only take two clicks.

The should not affect how WP-Cumulus works on WordPress blogs. But there have been a number of ports and other projects that use the Flash movie. I urge the authors of those projects to examine the new Flash movie, and see if it still works in/with their product. The exploit is not unique to WordPress, and they may need to modify the security check to fit their project.