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