• 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):