Nuudelisoppa

Tag: blogging

  • Fixing my plugin's SQL for WordPress 2.3

    I just upgraded WordPress to version 2.3 RC 1 at my test blog, and found out that changes in the taxonomy schema break my Parental Control plugin in a nasty way. Fortunately, it was quite easy to fix.

    I added a test for WordPress’ version and branched the SQL accordingly:

    if (version_compare(get_bloginfo('version'), '2.3-RC1', '<')) {
	$text .= " AND ( '".$jupc_excluded_cat."'  ALL (SELECT category_id FROM $wpdb->post2cat WHERE $wpdb->post2cat.post_id = $wpdb->posts.ID) )";
}
else {
	$text .= " AND ( '".$jupc_excluded_cat."'  ALL (SELECT term_taxonomy_id FROM $wpdb->term_relationships WHERE $wpdb->term_relationships.object_id = $wpdb->posts.ID) )";
}

    The code above reserved for versions 2.3 RC1 and above would probably work with the 2.3 Betas as well, but as I don’t have any interest in testing already obsolete versions, I decided to draw the line to 2.3 RC1, so the code above probably won’t work with 2.3 trunk versions below RC1.

  • Preparing for WordPress 2.3

    WP Dev Blog

  • WordPress 2.2.3 Released

    2.2.3 is a security and bug-fix release for the 2.2 series. Since this is a security release, we suggest you upgrade immediately. Two of the fixes are high priority.

    WP Dev Blog

  • Movable Type 4.0 Released

    Movable Type (via TechCrunch)

  • LiveJournal users fight erotic 'Harry Potter' deletions

    News.com via News.com

  • WordPress 2.2.2 And 2.0.11 Released

    WP Dev Blog

  • Underscores in URLs now word separators for Google

    News.com

  • I want the iframe back: a post preview plugin for WordPress

    Roblog via Wordlog

  • WordPress 2.2.1 Released

    WordPress 2.2.1 is now available Unfortunately, 2.2.1 is not just a bug fix release: some security issues came to light during 2.2.1 development, making 2.2.1 a required upgrade. (The full list of bugs fixed in 2.2.1.)

    WP Dev Blog

  • Wandering through WordPress weirdness

    I’ve been hacking SimpleTagsPlus into not displaying the embedded tags when the content is called via the_content_rss. I wanted it to do so because I’m using the_content_rss in my theme for publishing excerpts (in my other blog), and that makes those embedded SimpleTags look ugly. That’s because they’re not rendered, which in turn is due to the fact that SimpleTagsPlus functions are applied only to the_content and not to the_content_rss.

    I was able to fix this by adding, to the_content_rss, a filter of my own for skipping the tags altogether (i.e. replacing any occurences of [tags]...[/tags] with an empty string). But while doing this I came across some interesting issues…

    First off, there’s this funny little bug #3884 in WordPress’ bug tracker:

    Plugins using the filter the_content_rss are never applied in the RSS2 and Atom feeds, and still not working in the tag of the RDF feed.

    WordPress trac

    While reading about it I came to think that my feeds must have been displaying those ugly [tags]...[/tags] blobs as part of their content. And now, because of #3884, it seems that I can’t fix it in feeds other than the plain RSS one.

    But it turns out to be more complex than that. Instead of full posts, I’ve been providing my feed readers only with summaries for some time now (can’t remember when or why I made the switch), and thanks to that, the embedded tags are not displayed in the feeds.

    Apparently, the question of summaries vs. full posts in feeds is a rather heated one, and I honestly can’t say my choice to provide only the summaries has been a heavily deliberated one. But now, because of the issue I had thought already plagued my feeds, I’m not sure I would even want to make the switch back to full text feeds even if I otherwise did: the full text posts in my feeds would then contain those unrendered embedded tags right at the beginning where I’ve chosen to place them.

    By using a heavier solution to tagging, such as Ultimate Tag Warrior, from the beginning I would have avoided this, since (AFAIK) UTW does not make tags part of the posts themselves like STP does, thus eliminating them from the feeds — just the way I’d want it to be. But back when I was considering the alternatives, UTW seemed somewhat of an overkill. Obviously, I wasn’t thinking far enough ahead or big enough.

    I found a WordPress.org support forum thread discussing the possibility of providing readers with both the summary feed and the full text feed (via Oliver@StevePavlina.com), and I think I’m gonna try and implement the solution suggested there. And then I’m gonna have a serious look at replacing SimpleTagsPlus with Ultimate Tag Warrior. A a bonus, that would allow me to display a nice-looking tag cloud on my archives page, something which apparently can’t be done with SimpleTagsPlus.

    Added 18:57: The one feed that displays full summaries, when the option is selected, is the RSS2 feed, and while tweaking the files I found that it calls the_content and not the_content_rss for producing the content, so it will be properly formatted by SimpleTagsPlus after all, eliminating any problems when switching back to full text feeds. Since I had already figured out how to publish both the summaries and the full text feeds, I just reversed the procedure by making full text posts in feeds the default and publishing an additional summaries-only feed with the hack described in the aforementioned WP forums link.

    Added 20:27: I came across some very bizarre behavior from WordPress after having set up my summaries feeds. The feeds were seemingly ok in the browser, but Google Reader wouldn’t load them and Feed Validator claimed there was a 404 error fetching them — yet it would display their source right after the error! At first I couldn’t even find anything resembling this, and when I did (examples 1, 2, 3, 5) the links had no solutions or the solutions were referred to but the links were dead, or the solution was more than two years old and couldn’t be applied to newer WordPress versions.

    Finally, I found a bug posted on wp-trac, describing a similar-sounding situation with a little hackish but functioning workaround. Apparently, forceably rewriting the headers to report 200 instead of 404 does the trick, like so:

    header("HTTP/1.1 200 OK");
    
header("Status: 200 All rosy") ;

    WordPress trac

    I inserted these lines into my feed-(rss|rss2|atom)-summaries.php files, between the header('Content-type... and $more = 1; lines, and voilà! No more 404 from Feed Validator.