The first step towards straightening out the new permissions structure is creating and/or changing the existing roles. Steph over at SillyBean has a good article on creating roles in the PHP code, and also mentions Justin Tallock’s Members Plugin, which automates a bunch of the things that she explains. Of course, there’s always the WordPress Documentation, and the reasoning behind the changes are in this WordPress Trac ticket.

If you’re trying to auto-upgrade your plugin and you get a hang at “Unpacking the core update”, then you need to deactivate AND delete the old “WordPress Automatic Upgrade” plugin (most recent version: 1.2.2) before you can successfully use the new upgrade function in WordPress.

So, you upgraded to 2.5 a few days ago, and you’re using the Default theme until you have time to customize another one. And you got rid of the old Statspress plugin because after you started getting over 10,000 pageviews a month, your database got kinda full and rather slow. So for stats, you try the WordPress.com Stats plugin. And you see you’re getting one, maybe two, maybe three hits a day. Whiskey, Tango, Foxtrot?

Turns out that the WordPress.com stats plugin registers pages that call the wp_footer() function. So if you don’t call wp_footer in your code, it’s not going to work. The function that the 2.5 default templates use is get_footer(). If you go into plugins, stats, and edit the only mention of wp_footer to get_footer, you’ll suddenly see hits start appearing. Or, just go to all your pages that you want to collect stats from, and add a call to the wp_footer() function before the get_footer() call.

Note: The wp_footer function either doesn’t get called, or the code won’t be placed in there if you’re logged in to your blog at the moment. It will only display for people who aren’t logged in.

Related:

The basic gist is that I’m trying to use the WordPress 2.5 RSS widget to read in my Google Reader ‘shared items’ feed. Google Reader will publish your shared items in an Atom RSS feed. For a sample, you can see mine here.

The RSS feed is all fine and dandy. It’s valid, it’s namespaced correctly, and it’s got all but one of the required elements. The problem comes when you try to parse it with Magpie. Inside the “entry”, there’s a “title”. There’s also a “source”. The “source” has a “title” attribute as well.

Magpie merges these attributes into one string, which is then retrieved when wp_widget_rss_output pulls $item['title']. In other words, Magpie ignores the tag hierarchy, flattening all the content. Brilliant. This is what we in the business like to call an ‘irresponsible hack’.

There’s two places where this affected me, and I used different hacks to get around each. The first place it affected me was the aforementioned entry title vs. source title. The fix for that one was easy. I simply removed the title attribute from the _CONTENT_CONSTRUCTS array… and suddenly, I got the value I was looking for. The next one wasn’t so easy. The Magpie code parses together all of the link elements, and this is a special case handled in feed_start_element — basically, all of the link tags in each feed entry will be parsed together into one mangled hunk.

Whoever thought this was a good idea should be taken out back and shot. What a stupid hack. Sure, it’s XML! We can’t possibly have a one-to-many relationship! It works for me!

For the link fix, since I always just need the first link element, I added this to my wp_widget_rss_output function in wp-includes/widgets.php:

if($secondhttp = strpos($item['link'],'http',5)) {
$item['link'] = substr($item['link'],0,$secondhttp);
}


It’s a stupid hack to compensate for a stupid hack, but I’m not going to spend an entire weekend mucking around inside of WordPress’s retarded api just to get this RSS feed working.

As a side note, I’m really happy I no longer have to write PHP4 compliant code. More than an hour or two debugging this stuff now and my eyes and ears bleed.

Update: I made a forum post with some cleaner code examples on the wordpress forums.

Related:

Related:

There’s CSS bugs in the admin panel. There’s problems with the editors — code only, becase the visual one doesn’t display. There’s problems with the javascript in the options screens. I had to crack open Firefox just to change the link format.

I know that WordPress doesn’t claim to support Safari, but fer chrissakes — it’s the third of the big3, and makes up about 5% of the traffic to my site. I’m glad that the themes I’m using at least support Safari.

Related: