• Widgets API The new widgets API lets you create widgets by extending the WP_Widget class. If making a multi-widget with the old system was like trying to piece together your kid’s bicycle on Christmas Eve, the new API rolls out the bike for you, tires inflated and topped with a bow.
• SimplePie RSS WordPress has been using the MagpieRSS class to parse RSS feeds. Trouble is, Magpie development ground to a halt about four years ago, meaning when contemporary feeds flummoxed Magpie, flustered developers fumed, futilely. In 2.8, WordPress now reads RSS with SimplePie, an active project with a robust API.
• New Escape Functions A new set of functions consistently named and DRY-er now make your strings sparkly clean and cuddly safe.
  • esc_sql(): A wrapper for the $wpdb->escape() method.
  • esc_url(): Clean up an untrustworthy URL for printing.
  • esc_url_raw(): Clean up an untrustworthy URL for storing in the database.
  • esc_js(): Make text suitable for printing as a JavaScript string.
  • esc_html(): Convert characters that have special meaning in HTML (such as > and <) into their equivalent character entities.
  • esc_attr(): Prepare text so that it’s safe to be used in an HTML element attribute.
  • esc_attr__(), esc_attr_e(), and esc_attr_x(): Make a translatable string safe for printing as an HTML element attribute. E.g.,
    
    
    <a href="" title="<?php esc_attr_e('Translate me'); ?>">
     
  • esc_html__() and esc_html_e(): Like the last two, but for escaping HTML characters in general.
• get_the_author_meta() User data is spread out between two database tables and has been accessed—until now—by a number of methods. get_the_author_meta() retrieves user data with one easy-to-remember function.
• the_post Action Hook Called in setup_postdata(), the the_post action hook is one of those things that seems so obvious and so useful that you can’t believe it hasn’t existed until now. At a crucial moment it passes the current global $post variable by reference: during the Loop right after global variables are set but before they’re used in the template.

http://example.com/my-post-permalink/
http://example.com/my-post-permalink/comment-page-1/
http://example.com/my-post-permalink/comment-page-2/

My solution in this short plugin is to have all but the main permalink show an excerpt of the post, with a link back to the permalink page.

Download:
paged-comments-seo.zip
paged-comments-seo.tar.gz

Themes for sites that support “premium” (non-GPL or compatible) themes will not be approved.

Alister Cameron has written a post that’s excellent in describing the issue (Matt Mullenweg, head of WordPress.org and the one who removed the themes, seems to like Cameron’s post too). Here Cameron gets to the heart of the matter:

If your theme was pulled and yet it was GPL licensed, there are only two options. Either it was a mistake (email Matt), or you were linking from it to a site that sold other themes that do contravene the GPL. If the latter is the case then you are in the awkward place of making the argument that Matt was wrong to defend the spirit of the GPL, beyond just the letter of it.

Perhaps unintentionally Cameron highlights the problem with WordPress.org’s actions: the GPL does not really have a spirit. The GPL is a license—a license that makes possible wonderful things, but still just a legal document. When you start trying to defend spirits, you stray from interpretation of a legal document into divination.

What that really means is making judgment calls based on vague or ineffable criteria. WordPress.org can do that because it pays the bills. Legally and perhaps ethically it’s justified in excluding themes that overuse the color blue, if the corporation wants. But in practice, excluding good GPL’d themes because their authors have sites that “support” non-GPL’d stuff will foster ill-will. It will seem just as arbitrary as excluding a too-blue theme because the criteria are just as vague, and that arbitrariness will always seem like capriciousness to those on the receiving end of the stick.

In other words, it’s unclear what constitutes “support.” According to comments on the posts to which I linked above, “support” meant just an ad for a premium theme developer. What about blog posts that promote or otherwise offer aid to premium theme developers—does that taint a site with “support”? No one should have to parse answers to questions like that.

We don’t need more vagueness. One of the main reasons we have more or less precise legal documents and legal systems for their interpretation is that we want to establish confidence in the stability of the system. We won’t invest serious time, money, or other resources when we don’t have confidence about whether our work will be contravened by a subjective judgment call. Subjective judgment calls are fine for our own lives or the businesses that are under our purview. But when it comes to a community, when it means possibly hurting others, there should be greater transparency and specificity regarding the criteria.

So WordPress.org should remove that clause forbidding sites that “support” non-GPL’d stuff, not because as an independent, non-profit organization it doesn’t have the right to do so (it does). WordPress.org should remove that clause because it harms the WordPress community by introducing unnecessary arbitrariness.

Besides, good GPL’d themes—no matter who creates theme—are a benefit to the community. We the community get a free theme, and since we’re adults we’re capable of deciding whether the theme author’s site is one that we think worthy of our attention.

There is a good amount of talent in the WordPress themes business. If the Extend repository becomes hostile to theme authors of quality themes, then the talent will go somewhere else. That hurts non-technical WordPress users, who benefit from a central repository that they know is free from spammy links and back-door code, and home to top-notch themes.

Here’s how to do it just using the WordPress API (instead of direct database queries):

Does that mean I should avoid rewriting dynamic URLs at all?
That’s our recommendation, unless your rewrites are limited to removing unnecessary parameters, or you are very diligent in removing all parameters that could cause problems. If you transform your dynamic URL to make it look static you should be aware that we might not be able to interpret the information correctly in all cases.

A number of bloggers, including Sophia Lucero at WordPress Philippines, draw the conclusion that WordPress permalinks are harmful to PageRank. However, the specific concerns mentioned by Stiller and Szymanski suggest they are not actually criticizing the standard use of WordPress permalinks.

Instead, the authors’ overriding concern seems to be static URLs that “could cause [Google] to crawl the same piece of content needlessly via many different URLs,” and the examples they give are mainly of search queries.

That’s not at all like a WordPress permalink for a blog post. A WordPress post has a one-to-one relationship with its permalink, meaning that only that content will be found at that permalink and that post will not appear at any other permalink. Or at least that’s the way things should be on a WordPress blog: for a while SEO experts have recommended that the complete content for each blog post appear only at an individual post’s permalink. In practice that means making sure that category archives, monthly archives, and the like should show only excerpts of a post, not the complete text. Most modern WordPress themes do this, but some, especially older themes, do not.

The Google article gives a number of bad examples of “dynamic” URLs written as “static” URLs, including this one:
www.example.com/article/bin/answer.foo/en/3/98971298178906/URL
The problem with this, say the authors, is that when crawling that link it is “difficult for us to understand that URL and 98971298178906 have nothing to do with the actual content which is returned via this URL.” (Here “98971298178906″ is a session id). The authors don’t even recommend simplifying the URL to something like www.example.com/article/bin/answer.foo/en/3:

Although we are able to process this URL correctly, we would still discourage you from using this rewrite as it is hard to maintain and needs to be updated as soon as a new parameter is added to the original dynamic URL

Again, the concern seems to be that the bad “permalink” example does not have a one-to-one relationship with the content. “98971298178906″ is particular to the site visitor, not the site’s content, and even “answer.foo/en/3″ could change when that answer is no longer the third one.

So the main lesson a WordPress blogger should take from this is the old lesson of SEO: avoid duplicate content. WordPress permalinks that are one-to-one with their content and have relevant keywords are good for SEO. They combine the benefits of static URLs mentioned by the authors, such as higher click-through rate, without the deficits.

As you can see, WordPress dominates the known blogging platform world. From the numbers below, it looks as though most active WordPress users are keeping updated.

The good news—surprisingly—is that you can still do that in 2.5, as DD32 pointed out on the WordPress hackers mailing list. You can thank wp_check_password(), which checks to see if your stored password is still in md5 form, and if so, it lets you log in and then converts it.

1. Use wp_enqueue_script() to load external libraries and standalone scripts, instead of generating your own script header tags.
2. On admin pages, use the admin_print_scripts-[mypage] action hook to register the code on only your plugin’s page, not every admin page.

Both of those techniques have been available since WordPress 2.1, so plugin authors can be pretty confident that there will be no backwards-compatibility issues in employing them. (Despite the fact that WordPress is maintaining the 2.0.x version line until 2010, my research suggests that the number of users of that branch is insignificant.)

I would add one more tip to Ozh’s: don’t pollute the global JavaScript namespace, especially with the over-used “$”. A number of JavaScript libraries use the dollar sign in different ways, so you can run into problems if, for example, you’re using jQuery but another plugin has loaded Prototype.

Fortunately, jQuery makes it easy to use “$” in a friendly way with other libraries. My favorite is to wrap jQuery-based code in something like the following, which employs $ outside of the global namespace and waits to execute the script until after the DOM has loaded.

jQuery(function($) { /* some code that uses $ */ });

LIEBERMAN CAMPAIGN CRASHED OWN WEBSITE: “The server that hosted the joe2006.com Web site failed because it was overutilized and misconfigured.” That’s like when people send me a link to their underpowered WordPress blog, then it produces a “Database Error” message when too many people try to actually read it. I hate that. (Yeah, this happens elsewhere sometimes, but low-power WordPress blogs seem particularly susceptible.)

Until WordPress version 2.5, a failed database would generate error screens like the one below:

Note the nifty WordPress branding that appears at the top. Thanks to that, countless Diggers, Slashdotters, and the like began to associate WordPress with failure. This is a post hoc fallacy of course: plenty of sites that buckle under the loads brought by Digg are not powered by WordPress, and many WordPress sites that survive a slashdotting are powered by WordPress. But in both of those cases, it’s not obvious; no giant logo greets you to say “WordPress powers this site, which is staying up just fine!”

In my opinion, WordPress version 2.5 solved this problem the right way, by adding a non-branded database error message:

Other people, including both WordPress proponents and opponents, think WordPress lacks something by not allowing all of its users to handle heavy database stress. I’m not so sure.

Flexibility is a large part of what makes WordPress such a great application to write code for. If you let plugins do just about anything imaginable on every page load, there’s a good chance that a small host’s database won’t be able to handle all of that in the face of a slashdotting. And that’s okay. The vast majority of WordPress users won’t ever be slashdotted, and so they don’t need the extra complication, potential server problems, and plugin incompatibilities that built-in caching would produce.

If yours is the type of site that’s going to suffer under the Digg effect, then you can install one of the caching plugins to help you endure, or you can count on superior server resources. Everyone else will be just fine.