UPDATE. WordPress 3.0 was released today, Thursday 17 June 2010. Get it here or upgrade automatically!

The first release candidate of WordPress 3.0 came out on 28 May 2010. The second followed a week after that, and the final release is expected sometime after 14 June 2010.

WordPress 3.0 is a large release. The codebase underwent more changes than in any previous version (about 2700 sets of changes at this moment), and more people than ever before (above 200) contributed changes directly. However, for the most part the changes are not immediately obvious.

Much of what changed is under the surface: A lot of rewriting for the merge with WordPres MU, good features for developers, things to make WP a better tool internally, and many bug fixes. Then, there are several new user features, but some of them are not visible either unless you select to use them or unless your theme explicitly supports them.

COMPATIBILITY NOTE

Backwards compatibility is good. If op111.net is any indication, of the 25 plugins it uses 24 have been working flawlessly with WordPress 3.0. One (HeadSpace2) caused a small issue recently, because of a JavaScript conflict.

See also “Known Issues”, right below.

Known issues

• Upgrading to 3.0 may need more than 32MB of memory (because the package is larger now). If you cannot upgrade because of insufficient memory, try adding in your wp-config.php this: define('WP_MEMORY_LIMIT', '256M');
• Plugins that replace the WordPress database class, and probably also plugins that extend it, need to be updated. This is because of substantial changes that were required for the merge with WordPress MU.
• Conversion from single-site to multi-site can become problematic if subdirectories—rather than subdomains—are used.
• See also the Issues, Problems and Resolutions thread at the official WordPress forum.

Highlights

WordPress MU merge

WordPress MU is a variation of WordPress designed for running multiple sites and weblogs on a single installation. As an application it is not as widely known as WordPress, but there are probably more people using it daily to publish on the web than there are using WordPress. Its users include educational institutions, research centres and publishing companies all over the world, and also services like WordPress.com (which must be the largest user of WordPress MU and for which MU was initially developed).

WordPress 3.0 brings together WordPress and WordPress MU. All MU functionality was merged into WordPress, and MU will now be discontinued. Its current version, 2.9.2, will be the last.

The merge and transition were designed to be invisible to users: Users of WordPress MU 2.9.2 will simply see a notice to update to WordPress 3.0, while users of single-site WordPress won’t see anything related to multi-site functionality unless they define a specific constant in wp-config.php.

Terminology changes

One difference users of single-site WordPress will notice is in terminology. All instances of “blog” in the administration interface were replaced with “site”, to standardize terminology between single-site and multi-site.

The new meanings, which I hope I’m getting right, are as follows:

• example.com in a single-site installation is now a site (which can of course be a blog).
• example.com in a multi-site installation is a network of sites and also the main site of the network (and can of course be a blog).
• demetris.example.com or example.com/demetris in a multi-site installation is one of the sites that make up the network.

Trying WordPress MS

If you want to try the multi-site mode, there are two things you should know:

• Setting up multi-site is not as easy as the rest of WordPress.
• You should keep copies of wp-config.php and .htaccess, in case you change your mind later and want to return to the single-site mode.

Setting up WordPress for multi-site use will probably become easier in the future. In this release, however, the aim was different: To merge the two code bases as well as possible, and to make the transition seamless—even invisible—for all, both WordPress users and WordPress MU users. This aim was achieved.

DOCUMENTATION. codex.wordpress.org/Create_a_Network

Update centre

The new update centre displays in one place everything for which there is an update, and lets you update everything—WordPress itself, plugins, and themes—from the same place. It also lets you update themes in bulk, which was not possible before. Notifications of available updates appear in a little bubble next to the menu item from which the updater is accessed: Dashboard › Updates.

The update centre is my favourite new user feature in WordPress 3.0. It makes maintenance easier and it helps keep your website up to date and secure, all from a simple interface that does not betray the complexity of the underlying mechanism. (A bulk updater that works well across all the different environments and setups in which WordPress runs is not a simple matter!)

Custom post types improved and simplified

Custom post types were already possible in WordPress but the functionality was basic. In WordPress 3.0 they come with many improvements and they can have their own UI too!

What are custom post types? Think of the WordPress Posts and Pages that you already know. They are both post types, same in many ways and different in some—mainly in that Pages are arranged hierarchically, while Posts are arranged chronologically—and they exist by default in WordPress. A custom post type is a post type that does not exist by default and that you create.

And why make a custom post type?

Say, for example, that you enjoy publishing recipes but it always nagged you that in WordPress your recipes had to be either Posts or Pages. Now you can create your own post type, “Recipes”, to write about your recipes, and you can add to it exactly the set of features you want: It can have its own UI, e.g. “Edit Recipe” instead of “Edit Post”, and “Add New Recipe” instead of “Add New Post”, it can have or not have features like Excerpts, Featured Images, Comments, etc., and it can also be associated with custom taxonomies.

Custom taxonomies

Like custom post types, custom taxonomies already existed but they are now improved. One of the improvements is that they can be combined with custom post types. So, continuing the above example, if you don’t like using Tags for your Recipes, you can make a new flat taxonomy, say “Ingredients”, and associate it with the post type “Recipes”.

Not excited by all that? Don’t worry! You probably don’t need so much custom. Not everyone does. In fact, I would say that most WordPress sites can be organized perfectly well with what we already had: Posts, Pages, Categories and Tags.

Yet, custom post types and taxonomies open up new possibilities, and it would be interesting to see what applications entertaining minds find for them, especially as the functionality is refined and improved in the future.

FURTHER READING

• WordPress 3.0 and Custom Post Types is a level-headed explanation and assessment by Otto.

PLUGINS FOR CUSTOM POST TYPES AND TAXONOMIES

• Custom Post Type UI makes it easy to create new post types and taxonomies.
• Post Type Switcher lets you switch posts from one type to another.

New theme

WordPress 3.0 has a new default theme named Twenty Ten (after the year in which it is introduced).

Twenty Ten is a simple theme with a clean and modern design and a number of interesting features, my favourite among which is the array of four widget areas above the footer. In addition, and as is always the case with the default WordPress theme, it implements all the new features of this release; most notably, custom background and header (see below) and custom menus (see below).

One thing I particularly like in Twenty Ten is the collection of header images it comes with.

One thing I do not like is its typography, which I find noisy. (Too many combinations—unnecessarily many for such a clean design—of font family, font size, font style, font weight, and font colour). That is easily fixed, however, even with a very basic child theme: Unlike the previous default theme, Kubrick, Twenty Ten supports child themes well.

MORE. The story of the Twenty Ten header images by Matt Mullenweg

Twenty Ten is the only theme bundled with WordPress 3.0, since both Classic and Default (Kubrick) were removed. Both are now at WordPress Extend:

• Classic
• Default (Kubrick)

NOTE. When upgrading to 3.0 from an earlier version, Classic and Default are not removed or affected in any way!

Custom menus

The most anticipated of the many “custom” things in this release is probably the new menu creator. It lets you create navigation menus exactly how you want them, and then assign them to predefined menu locations of your theme.

One thing to note about the custom menus is that they must be supported explicitly by your theme. But you can use them even if your theme does not support them yet: The new Custom Menu widget lets you add any of you custom menus to any of your theme’s sidebars.

Another thing to note is that the custom menus are not always a viable alternative to the methods by which menus were built up to now. Why? Because they are not dynamic. For example, you cannot make an item whose subitems are all existing and future categories; or add a page to the menu and specify that all its current and future subpages be added as subitems.

I imagine theme authors will find ways to deal with that, probably by offering a choice between the two menu systems.

ACCESSIBILITY NOTE. The menu creator is fully functional without JavaScript too.

DEV

• Documenation on wp_nav_menu() at the WordPress Codex
• Goodbye, headaches. Hello, menus! By Justin Tadlock

Custom header and custom background

Two new APIs were introduced that make it easy for theme authors to offer options for custom header images and custom backgrounds. If your theme supports this, you will see the menu items under Appearance. We already saw the Custom Header screen in one of the Twenty Ten screenshots. Here is the Custom Background screen:

The tiled image in the screenshot is from ava7 patterns.

DEV. Twenty Ten’s functions.php is a good starting point to see how all this works.

More new things

Selectable username and password during installation

Now the installation process lets you choose username and password for the administrator account. That is, you no longer have to use “admin” or the password generated by WordPress. (Of course, you can still use these if you prefer.)

TIP. In earlier versions the admin account can be renamed with a plugin like Admin Renamer Extended.

Shortlinks

WordPress 3.0 comes with a new function that themes can use to display a shortlink for the current URL. By default, shortlinks are generated for Posts only (not for Pages or for anything else) and are of the form http://example.com/?p=123. So, for example, the default shortlink for the page you are viewing is:

http://op111.net/?p=76

op111.net uses the shortest possible permalink structure—/%post_id%—, so in this case the default shortlink happens to be longer than the long link, :-D but you get the idea.

Plugins can easily change the default form to anything they like.

DEV. Shortlink functions and their filters are all in link-template.php. Look at the inline documentation of:

• the_shortlink()
• wp_get_shortlink()
• wp_shortlink_header()
• wp_shortlink_wp_head()

Better security by default

WordPress 2.6 introduced security keys, which help add a bit more security to an installation. WordPress 3.0 adds security keys by default when setting up the configuration file of a new installation:

You can change these keys at any time, or add them if you don’t have them, by making new ones yourself or by visiting the Secret Keys Generator at WordPress.org:

https://api.wordpress.org/secret-key/1.1/salt/

(Just copy the whole lot and paste it in your config.php.)

Even more

• r12523. Check PHP, MySQL versions in update response and notify if reqs are not met. See #11562.
• r12815. Make login form shake when incorrect info is entered.
• r13012. Twenty Ten theme initial import. See #9015.
• r13026. Update keys and salts with random values from api.wordpress.org. See #12159.
• r13034. Introduce DISALLOW_FILE_EDIT for enabling/disabling theme/plugin editor. See #11306.
• r13041. r13574. Custom background support. Background color selection. See #12186.
• r13084. Add setting for no. of comments to Recent Comments dashboard widget. See #11891.
• r13134. Selectable username/password in installation. See #10396.
• r13168. r13767. r14237. “Search Engines Blocked” mini-alert when Privacy is on. See #12211.
• r13233. Show must-use plugins and drop-ins in Plugins screen. See #11861.
• r13257. r14248. Introduce custom menus. New menu UI. See #11817. See #12713.
• r13272. Enable threaded comments by default. See #11992.
• r13276. Add support for non-tag taxonomies to Tag Cloud widget. See #11612.
• r13403. Header image selector. See #12343.
• r13424. Reject numeric page slugs (they don’t work) and force suffix. See #11917.
• r13470. When deleting plugins, check for uninstall routines and warn of data deletion. See #11850.
• r13516. Better readme.html. See #10835. See it while it’s fresh: http://op111.net/readme.html
• r13529. Move Upload folder settings to Settings › Media. See #11687.
• r13541. Display MIME type when file has no extension. See #9924.
• r13573. Add options to Tools › Export. See #10317.
• r13587. r13634. Show Network menu only if WP_ALLOW_MULTISITE is true. See #11644. See #11816.
• r13588. Move Tools › Upgrade to Dashboard › Updates. See #12517.
• r13602. r13686. New UI for bulk plugin/theme upgrades. See #11232. See #12528.
• r13636. Don’t paginate comments by default in Settings › Discussion. See #12562.
• r13744. Remove defunct link update checker from core. See #12437.
• r13745. Remove empty Options › Misc. Redirect plugin options to Options › General. See #12437.
• r13750. Change “Blog” to “Site” in Settings screens. (And in any other place in later revisions.)
• r13824. r13842. r15127. Lighter header/footer for gray color scheme. New logo for header.
  See #12586.
• r13833. Remove “Turbo” link from admin header. See #11301.
• r13879. Remove Classic and Default themes. See #10654.
• r13898. Add link to Updating WordPress (Codex article). See #11280.
• r13900. Add Password Mismatch feedback to Password Strength Meter. See #12576.
• r13932. Fix out-of-order comments when nesting depth is reduced. See #8841. Displays child comments on same level as parent when max_depth is reached.
• r13942. Better default excerpt. Remove multiple white spaces and split safely on UTF-8 strings. See #10376.
• r13963. Link to new Child Themes Codex article from the Updater. See #12787.
• r13981. Remove Gears from UI. See #11301.
• r14010. Update stats provided to api.wordpress.org. See #12672.
• r14088. Introduce DISALLOW_FILE_MOD for disabling all operations that modify core, theme, or plugin files. See #13000.
• r14280. Keep “Remember me” checked when user password is incorrect. See #13165.
• r14324. Change “WordPress Development Blog” to “WordPress Blog” in dashboard widget.
  • r15027. Use “WordPress Blog” (instead of “Development Blog”) in initial blogroll. See #14324.
• r14487. Improve cross-DST future post publishing behaviour to try and publish at correct time if we have PHP5 timezone support available to help. See #9285.
• r14491. Bump memory_limit for admins in wp-admin. Should help in imports, upgrades, uploads, etc.
• r14764. Move importers to WordPress Extend. See #13307.
• r14836. Contextual Help for Dashboard (and for all admin screens in subsequent revisions). See #13467.
• r15032. Check capabilities properly when processing bulk edited posts. Hide checkbox on Page edit screen for users without capabilities. (Also in 2.9.x.)

Highlights for developers

The part below this point is for developers, those who like getting their hands dirty, and, of course, the curious.

Multi-site things are mostly omitted here, for two reasons: First, while all are new to WordPress, most existed already in WordPress MU. Second, I know almost nothing about the multi-site functionality.

Compatibility

Backwards compatibility in version 3.0 is in general very good. Areas that may need attention are highlighted in a number of compatibility posts at the WordPress Development Updates blog:

wpdevel.wordpress.com/tag/30compat

WP_DEBUG and deprecated functions

WP_DEBUG was improved. It now informs of the version as of which a function is deprecated, and it also informs about deprecated arguments. Its definition is included for the first time by default in wp-config.php (set to false, of course), along with the recommendation to enable it when developing.

Why enable WP_DEBUG? Three reasons:

1. It helps make code better and future-proof
2. It helps make code faster: Code without errors is faster than code with errors
3. It helps fellow developers (who won’t have to sift through messages generated by our code when they enable WP_DEBUG to debug their code)

Andrew Nacin has more: Deprecated functions and WP_DEBUG

*_option() and *_transient() functions now expect unslashed data

See the explanation by Ryan Boren, and the relevant ticket:

• Explanation by Ryan Boren at wpdevel.wordpress.com
• #12416: *_option(), *_transient() and *_meta() functions should all expect unslashed data

comment_form()

I believe this new template function will become a favourite of all WordPress developers, theme authors and plugin authors. Just use:

comment_form();

… and you get a comment form that is complete, fully filterable and fully actionable.

DOCUMENTATION. codex.wordpress.org/Template_Tags/comment_form

get_template_part()

get_template part() is a new template function that helps avoid repetitive code in themes and makes it easier to modify themes via child themes. Again, usage is simple:

get_template_part('nav');

This will bring nav.php in, in the same way that get_header() brings in header.php and get_footer() brings in footer.php.

Of course, the above was already possible with PHP constructs like include and require. What get_template_part() adds to that is granularity and awareness of child themes.

First, it can take a second parameter. E.g.:

get_template_part('nav', 'main');

Here it will first look for nav-main.php and include it if it exists. Otherwise it will include nav.php.

Second, if the active theme is a child theme, get_template_part() looks in the child’s directory first. So, for example, you can add a nav.php template to your child theme, and it will be used instead of the nav.php of the parent.

DOCUMENTATION. codex.wordpress.org/Function_Reference/get_template_part

Hyperminimal themes deprecated

These are themes that rely on the default theme for any of header.php, footer.php, sidebar.php, comments.php, comments-popup.php. This method is now deprecated and may stop working in the future:

Themes and WordPress 3.0: Some important changes by westi (Peter Westwood)

Improved inline documentation

Over the last versions inline documentation has become more or less a requirement for any function, class and file added to WordPress. In addition, supplying documentation where it’s missing, and improving existing documentation, is an ongoing project. So, inline documentation gets better and more useful with every new release. A small example of this ongoing effort:

r12761: phpDoc for the metadata API

The official web interface of the inline documentation was also improved: phpdoc.wordpress.org/trunk

More for developers

Work on this part is in progress.

3rd-party libraries

• r12491. JSON lib updated. Use encodeUnsafe in our JSON wrapper. See #11537 for trunk.
• r12521. phpass 0.2. See #10727.
• r12522. SWFobject JS 2.2. See #11109.
• r12557. Prototype.js 1.6.1. Scriptaculous.js 1.8.3. See #11041.
• r12822. MagpieRSS deprecated. Use SimplePie (class-simplepie.php). See #11982.
• r13201. r15243. jQuery UI 1.7.3. See #11595. See #13868.
• r13310. jQuery 1.4.2. See #12305.
• r14052. Snoopy deprecated. Use WP_Http (http.php, class-http.php). See #12882.
• r14718. autocomplete.js, CodePress removed. See #13283. See #13307.
• r14728. interface.js removed. See #13442.

New constants

• r13034. DISALLOW_FILE_EDIT. Banishes theme/plugin editor. (By removing the edit_files, edit_plugins and edit_themes capabilities from all roles.) See #11306.
• r13737. r14485. WP_DEFAULT_THEME. See #12846.
• r13587. r13634. WP_ALLOW_MULTISITE. To display Tools › Network menu. See #11644. See #11816.
• r14088. DISALLOW_FILE_MOD. Disables all operations that modify core/theme/plugin files. See #13000.
• r14244. DISALLOW_UNFILTERED_HTML.
• r15225. ALLOW_SUBDIRECTORY_INSTALL. See #13844. (For conversion to multi-site.)

New action and filter hooks

• r12790. wp_die_handler(). AKA “customizable death”. Filter for wp_die(). See #11892.
• r13037. r14603. posts_search(). Filter. Lets plugins contextually add/remove/modify search section of database query. See #10667.
• r13073. activate_wp_head(). Action in wp-activate.php. See #12166.
• r13156. r13214. after_setup_theme(). Action. Runs after parent/child themes are included. See #12231.
• r13231. get_avatar_comment_types(). Filter for get_avatar(), to allow avatars for custom comment types. See #11880.
• r13252. template_include(). Filter to modify template path before it is included. See #11242. See #12739.
• r13305. show_advanced_plugins(). Filter to hide mu-plugins/drop-ins tabs in Plugins screen. See #11861.
• r13330. plugin_locale(), theme_locale(). Filters for load_*_textdomain() functions. See #9686.
• r13523. tables_to_repair(). Filter. See #11707.
• r13430. pre_insert_term(). Filter for wp_insert_term(). See #10943.
• r13434. comment_duplicate_trigger(). Action. Runs when duplicate comment is detected. See #12188.
• r13549. pre_post_link(). Filter for get_permalink() before token replacement occurs. See #12240.
• r13478. paginate_links(). Filter for links in paginate_links(). See #10826.
• r13479. wp_link_pages_args(). Filter for wp_link_pages(). See #12158.
• r13481. wp_loaded(). Action. Runs once WP init has finished. See #12400.
• r13525. widgets_admin_page(). Action at top of widgets.php. See #12190.
• r13629. before_signup_form(), after_signup_form(). Actions. See #12199.
• r13867. right_now_content_table_end(), right_now_discussion_table_end(). Actions. See #12202.
• r13891. robots_txt(). Filter for robots.txt output. See #11918.
• r14067. comment_id_fields(). Filter for get_comment_id_fields() See #12893.
• r14382. Actions for the Widgets API. See #12546.
  • register_sidebar()
  • wp_register_sidebar_widget()
  • wp_unregister_sidebar_widget()
  • dynamic_sidebar()
  • the_widget()
• r14814. post_updated(). Action. Runs when a post is updated. See #12473.
• r14996. capital_P_dangit(). Default filter for the_content(), the_title(), comment_text(). (An addition that will have to be removed or modified, because it causes problems.)

New functions

• r12487. is_comment_feed(). See #10827.
• r12598. home_url(). Returns home option in appropriate protocol, HTTP or HTTPS. See #9008.
• r12609. is_multisite(). See #11644.
• r12611. is_super_admin(). See #11644.
• r12659. get_intermediate_image_sizes(). See #10263. For when adding/deleting attachments.
• r12696. wp_login_form(). Emits complete login form for use in templates. See #11172. CODEX.
• r12714. is_main_site(). See #11644.
• r12719. register_post_status(). See #9674.
• r12796. WP_User::for_blog(), current_user_can_for_blog(). See #11781. To avoid calls to WP_User::_init_caps().
• r12810. comment_form(). Emits complete comment form for use in templates. See #10910.
• r12917. get_the_date(). See #11264. Defaults to date_format option. CODEX.
• r12923. r13023. get_post_permalink(). See #9674. See #12172. Returns permalink for post of custom type.
• r12946. r14417. get_available_languages(). See #11774. See #13023.
• r13004. is_textdomain_loaded(). See #10527.
• r13082. add_plugins_page(). Adds submenu to Plugins page. See #11377.
• r13146. r13816. r14047. get_template_part(). For themes to bring in template parts. See #12371. See #12248. See #12941.
• r13177. add_settings_error(). In the Settings API, to register messages for users. See #11474.
• r13229. wpdb::tables(). To fetch table names on global/blog scope. See #11614. See #12083.
• r13330. unload_textdomain(). See #9686.
• r13358. wp_kses_named_entities(). Whitelists valid named entity references. See #12284.
• r13403. r13928. register_theme_headers(), unregister_theme_headers(). See #12343.
• r13409. r13806. send_nosniff_header(). Turns off content sniffing in supporting browsers. See #10671. See #12683.
• r13413. r13526. r14639. r14641. Functions for returning various values to filters:
  • __return_false()
  • __return_true()
  • __return_zero()
  • __return_empty_array()
• r13438. add_permastruct(), flush_rewrite_rules(). Wrappers for the WP_Rewrite methods. See #10912.
• r13441. add_editor_style(). Registers stylesheet for visual editor. See #11512.
• r13454. wpdb::replace(). For replacing queries. See #10864.
• r13483. get_search_link(). See #10552. Has permastruct support. E.g.: http://example.com/search/foo
• r13557. the_feed_link(). See #11794.
• r13576. cache_users(). See #11914.
• r13608. get_taxonomies(). See #12516.
• r13635. r13683. wp_get_shortlink(), the_shortlink(), wp_shortlink_wp_head(), wp_shortlink_header(). See #10640.
• r13658. disabled(). Form helper, companion for selected() and checked(). See #12581.
• r13718. sanitize_key(). Sanitizes string keys.
• r13756. apply_filters_ref_array(). See #9886. Like apply_filters(), but args passed are in array.
• r13819. get_index_template(). So that child themes can override a parent’s index.php. See #12635.
• r13877. remove_theme_support().
• r14028. get_the_author_link(). See #12892.
• r14053. is_post_type_hierarchical(). See #12950.
• r14067. get_comment_id_fields(). Getter for comment_id_fields(). See #12893.
• r14360. is_rtl(). See #13206. Defined when locale is loaded, cannot be used too early.
• r14409. is_child_theme(). See #12998.
• r14607. wp_reset_postdata(). Restores post global to current post in main query after looping through a separate query. See #12320.
• r14647. _ex(). Combines _e() and _x(): Translate with context, then echo. See #13395.
• r14649. wp_check_filetype_and_ext(). To handle MIME/ext image comparisons/corrections for upload/sideload. See #11946.
• r14711. get_term_feed_link(). Returns feed link for taxomomy term. See #13058.
• r14760. WP_Importer class. See #13034. phpDoc.
• r14950. comments_link_feed(). Echoes link to comments of current post properly escaped for XML. See #13555.
• r15174. get_current_user_id(). See #13785.
• r15193. register_nav_menu(), register_nav_menus(). For themes to register one or more menus. See #13825.
• r15203. menu_page_url(). For plugin authors, to get URLs of pages they have added. See #13829.
• r15220. r14158. post_type_exists(). Checks if post type is registered. See #13747. See #12588.

Improved and modified functions

• r12514. the_modified_date(). New before/after/echo args. See #11255.
• r12518. get_comments(). More orderby and select options. See #10668.
• r12558. WP_Dependencies. New null arg to disable script/CSS version query strings. See #11315. Useful, e.g., when scripts are loaded from an external CDN.
• r12658. get_terms(). Now include and exclude args can be arrays. See #11076.
• r12667. wpdb class. Compatibility with WP, MU & MS. See #11644. wp-db.php changelog.
• r12719. register_post_type(). See #9674. CODEX
• r13048. get_search_form(), wp_loginout(), wp_register(), get_calendar(). New echo arg. See #11842.
• r13350. post_class(). New .type-{post_type} class. See #11609.
• r13417. add_theme_support(). New custom-background, custom-header, nav-menus params. See #11817.
• r13467. single_(post|cat|tag|month)_title(). Filters standardized on strip_tags() and wptexturize(). See #10900.
• r13483. get_search_feed_link(), get_search_comments_feed_link(). Updated to use get_search_link() (new, with permastruct support). See #10552.
• r13486. is_tax(). New term parameter. See #11904.
• r13673. *_option(), *_transient(). Now consistently expect unslashed data. See #12416.
• r13695. get_pages(). Now supports custom hierarchical post types. See #12600.
• r13773. add_endpoint(). Now accepts custom Endpoint Mask. See #12605.
• r13854. wp_list_categories(). Now aware of custom taxonomies. See #11838.
• r13952. wp_unique_filename(). Now methods too can be a callback. See #12824.
• r13978. get_search_query(). Now escapes by default, like the_search_query(). See #12780.
• r13982. wpautop(). New block-level HTML5 elements. See #12335.
• r13995. wp_delete_comment(). New force_delete arg. See #12766. See #11470.
• r14095. wptexturize(). Improved for single quotes. See #4539. (Abbreviated years followed by punctuation or markup.)
• r14131. wp_list_bookmarks(). Now orberby accepts comma-delimited list of fields. See #12421.
• r14133. get_posts(), get_pages(). Now include/exclude args can be arrays. See #11076.
• r14766. stripslashes_deep(). Attempt to make object-safe. See #12860.
• r14887. is_singular(). Now understands custom post-types. Usage: is_singular('book') or is_singular(array('newspapers', 'books')). See #12588.
• r15002. r15003. wp_constrain_dimensions(). Tweaks for better fits and consistency. See #13556.
• r15107. wp_list_categories(). Now filter accepts args. See #13682.
• r15188. get_page(). Now alias of get_post(). See #13753.

Deprecated functions and their replacements

• r12526. Set version when function was deprecated for all deprecated functions. See #7493.
• r12536. Introduce _deprecated_argument() for marking args as deprecated, so that with WP_DEBUG enabled developers can see they need to review and update their code. See #11386.
• r13185. Add WP_DEBUG define to wp-config-sample.php and suggest plugin/theme developers use it. See #12236.

Following is a not complete list of functions added to the deprecated group in WordPress v3.0:

You don’t need to memorize all that, of course! Simply enable WP_DEBUG, and it will tell you if there is anything you should not be using.

• r12459. _nc(). Use _nx() for specifying contexts. See #11404.
• r12585. Deprecate user levels. See #10805. Use Roles and Capabilities instead.
• r12624. generate_random_password(). Use wp_generate_password(). See #11746.
• r13093. Move deprecated functions to deprecated.php. See #11388.
  • get_the_attachment_link(). Use wp_get_attachment_link().
  • get_attachment_icon_src(). Use wp_get_attachment_image_src().
  • get_attachment_icon(), get_attachment_innerHTML(). Use wp_get_attachment_image().
  • get_link(). Use get_bookmark().
• r13096. Deprecate old L10n and sanitization APIs. See #11388.
  • ngettext(). Use _n().
  • ngettext_noop(). Use _n_noop().
  • translate_with_context(). Use _x().
  • sanitize_url(). Use esc_url_raw().
  • js_escape(). Use esc_js().
  • wp_specialchars(). Use esc_html().
  • attribute_escape(). Use esc_attr().
• r13299. clean_url(). Use esc_url(). See #12309
• r13300. *_usermeta() family. Use new *_user_meta() functions. See #10837.
• r13398. automatic_feed_links(). Use add_theme_support('automatic-feed-links'). See #12364.
  • r13399. Restore back compat in automatic_feed_links() to deregister the extra feeds. See #12364.
• r13464. get_profile(). Use get_the_author_meta(). See #10695. CODEX.
• r13761. get_usernumposts(). Use count_user_posts(). See #12642.
• r13805. (add|remove)_option_update_handler(). Use (un)register_setting(). See #11730.
• r13988. funky_javascript_fix() and callback. See #12520.
• r13991. trackback_rdf(). See #11139.
• r14090. set_current_user(). Use wp_set_current_user().
• r14646. get_bloginfo('text_direction'). Use is_rtl(). See #13206.
• r15168. r15170. get_most_active_blogs(), get_blog_list(). See #13773.
• r15220. Replace misnamed is_*() functions with *_exists() ones. See #13747.
  • is_taxonomy(). Use taxonomy_exists().
  • is_term(). Use term_exists().

Performance, optimization

• r11976. Improve get_page_hierarchy(). See #10853.
• r12464. Improve do_action() performance. Make $wp_actions an associative array. See #10561.
• r12657. Switch to passing arrays instead of query strings to functions. See #6647.
• r13143. Optimize single_(post|tag|cat)_title() to use WP_Query globals if available. Removes extra DB query in single_post_title() in most cases.
• r13205. Bail early for favicon.ico requests so we don’t load WP twice. See #3426. Reduces server load when certain browsers arbitrarily request /favicon.ico and /favicon.ico does not exist.
• r13227. Add INDEX on comment_parent to speed up wp_delete_comment() reparenting queries. See #12289.
• r13576. Improve user listing performance. See #11914.
• r13647. Add no_found_rows arg to WP_Query::get_posts() to allow forcibly defeating SQL_CALC_FOUND_ROWS. Use no_found_rows for the query in get_boundary_post(). See #12557.
• r13653. Cache get_lastpostmodified() results. See #12575.
• r13676. Don’t check for existence of index.php in .htaccess rewrite rules. See #11845.
• r13676. Use wp_cache_set() instead of wp_cache_add() in Recent Posts and Archives widgets. See #11580.
• r14139. Use relative paths when including files, to avoid include_path. See #12594.
• r14665. Don’t update_post_caches() if a persistent object cache is installed. See #12611.

Other

• r12602. Add multi-site settings code. Here starts the MU merge!
• r12641. Allow attaching PHP 5.3 closures to filters and actions. See #10493.
• r12727. Always set default timezone to UTC. Do offsets on top of that to be portable across all environments. See #9588. See #11665. See #11672.
• r12914. Add phpDoc to all add_*_page() functions. Rename arguments to emphasise that people should be using Capabilities, not User Levels, and named hooks, not __FILE__. See #12101.
• r12915. Support specific author templates by ID or user_nicename. See #12064.
• r13032. Look for single-*.php templates. Add single- class to get_body_class(). See #12105.
• r13167. r13452. r15017. Warn of unexpected output when activating plugins. See #12089. See #13585.
• r13427. Use is_ssl() instead of $_SERVER['HTTPS'] == 'on' checks (which don’t work on all hosts). See #11885.
• r13433. Consistently pass unserialized values to hooks in update_site_option(). Change add_option() and add_site_option() to do the same. Plugins using maybe_unserialize() would continue to work as the value would no longer need to be unserialized. See #10788.
• r13484. Support non-BASIC authentication schemes in HTTP API if server supports them. See #4011. See #12200.
• r13499. Display PHP start-up errors and warnings. See #12395.
• r13456. Allow multiple To: recipients in wp_mail(). Improve handling of \r\n in headers and multiple CC/BCC headers. See #10420.
• r14086. Register inherit as post status. Check parent post status when commenting on attachments.
• r14111. Introduce edit_theme_options capability.
• r14276. Introduce template file for front page. Has priority over other templates which apply, falls back to standard template flow for the page/list of posts. See #6801. CODEX.
• r14406. Add HTML5 elements to KSES. See #12835.
• r14412. Add protocols to KSES, make protocol list filterable, start esc_url() with same list. See #10914.
• r15096. Introduce export capability. See #13681.
• r15239. Missile guidance capabilities.

That’s it, folks!

I wish you enjoy WordPress 3.0 (once it’s officially out!) and you publish even better content with it!

Thanks for reading!

/δκ

Changes in this document

2010-06-21

Link to the story of the Twenty Ten headers.

2010-06-19

Link to issues thread at the official forum.

2010-06-17

Additions. “Known issue” of insufficient memory for upgrading.

2010-06-16

2010-06-14

2010-06-13

Additions.

2010-06-12

What you need to return from multi-site to single-site (see comment no. 3 by Ron). Fixed link to Ryan Boren on *_(option|transient)() functions and unslashed data.

2010-06-11

Additions. Typos. WP/MU/MS terminology explanation corrected (see comment no. 1 by Andrew Nacin).

2010-06-10

Additions. Link to Otto on custom post-types.

2010-06-09

Improvements, additions, new links. WP/MU/MS terminology explanation to be corrected. Link to improved webif of inline docs. Link to wpdevel compatibility posts.

RELATED

• Page Lists Plus: Comprehensive control of your WordPress page menu
• Add any link to your WordPress navigation menu with Page Links To
• Progressive enhancement of drop-down menus with the :not CSS selector
• WordPress 2.7: Ten useful new features

Add to del.icio.us

© 2010 op111.net | Permalink

Looking at a ticket on the WordPress bug tracker yesterday, I was reminded of a little thing that can be a problem when you use OS X to generate archives for distribution.

The problem

The built-in archiver of Mac OS X adds metadata directories and files, like __MACOSX and .DS_Store, to the archives it makes. On Mac OS X these directories and files are hidden by default. On other operating systems, however, in addition to being useless, they are also visible, cluttering the view and confusing the users:

Above are two ZIP archives made on OS X and opened in other operating systems, Linux/GNOME and Windows 7. Notice the __MACOSX folders. What are they? What are they there for? Maybe I can ignore them. But if I can ignore them, why are they there in the first place? Please, someone explain this to me because I feel stupid right now!

The solution

If you use OS X and make ZIP archives that you send to other people or distribute publicly, a simple solution to this problem is CleanArchiver, a little free archiver by Anyakichi that, among other things:

has the ability not to include system files peculiar to Mac OS X such as .DS_Store and custom icon file (Icon\r) in your archive. So your archive is always clean on other operating systems.

CleanArchiver is simple to use: Throw it to your Dock and, when you want to package something, drop it on the icon.

It can make archives of other types too, including GZIP and BZIP2, and it also has some more preferences that you can set. It comes with a short help file that explains all its functionality in English and in Japanese. Get CleanArchiver from its homepage:

www.sopht.jp/cleanarchiver

And thank you for reading! —δκ

RELATED

• Fifteen useful shell extensions for Windows
• Five clean, minimalist themes for WordPress
• WordPress 3.0: What’s new
• WordPress: 20 answers

Add to del.icio.us

© 2010 op111.net | Permalink

You probably have noticed the characters—usually arrows—displayed on some navigation menus to indicate the presence of subitems under an item. I find them helpful, and I recently looked to see if it was possible to have them displayed on a CSS drop-down menu by using only CSS (that is, without any JavaScript assistance). In this howto I explain the solution I arrived at:

How to display these useful indicators on a CSS drop-down menu by using the selector :not.

For a simple demo, see the menu of this site, op111.net.

It is a simple solution that works in all browsers except Internet Explorer, where the indicators simply do not appear at all. Hence, it is a progressive enhancement, or, to put it the other way round, it degrades gracefully in old or wayward browsers.

It is also a solution that suggested to me that the :not selector may offer possibilities that are unexplored. If you know of other useful applications of the :not selector, be kind enough to enligthen us with your comment!

Step 1

To each anchor in the menu we add an indicator-character wrapped in a span with an appropriate class:

<span class="more"> &darr;</span>

For this howto I use the downward arrow as indicator, and more as the class name.

So, supposing we have a menu with two top-level items, one of which has a subitem:

<ul>
  <li>
    <a href="http://x.net/p1">Page1</a>
  </li>
  <li>
    <a href="http://x.net/p2">Page2</a>
    <ul>
      <li>
        <a href="http://x.net/p2/s1">Subpage1</a>
      </li>
    </ul>
  </li>
</ul>

... what we aim at is:

<ul>
  <li>
    <a href="http://x.net/p1">Page1<span class="more"> &darr;</span></a>
  </li>
  <li>
    <a href="http://x.net/p2">Page2<span class="more"> &darr;</span></a>
    <ul>
      <li>
        <a href="http://x.net/p2/s1">Subpage1<span class="more"> &darr;</span></a>
      </li>
    </ul>
  </li>
</ul>

The best way to add the indicators will depend, of course, on how the markup is generated. If you use WordPress, look at the Appendix at the end for some examples.

Let’s see the second step now...

Step 2

We make a CSS rule to hide all indicators we added:

li a .more { display: none; }

Why did we do that?

Because the indicators we added in the first step appear in all items, but not all items have subitems. So, in the second step we hid the indicators, and in the third step we will instruct the browser to display indicators only in items with subitems:

Step 3

We make a second CSS rule:

li a:not(:last-child) .more { display: inline; }

Done!

How does this work?

In items with subitems, the a anchor is followed by a ul element (which containts the subitems). So, in items with subitems the anchor is not the last child of its li parent. This is the condition that our :not rule specifies, saying, in human language:

Select .more within any anchor that is not the last child of its parent, and display it inline.

The display:none declaration of the second step is understood by all common browsers. So, all browsers will hide the indicators from display. Then, browsers that understand :not and :last-child will show the indicators where appropriate.

Simple, perfectly valid CSS 3, and, for this reason, future-proof too!

Fine... But!...

I want the helpful indicators in Internet Explorer too!

That’s not possible with CSS alone, because IE (even IE8) knows nothing about CSS3 selectors like :not and :last-child (or :only-child, which would have the same effect here).

So, for Internet Explorer you will have to resort to a mixture of CSS and JavaScript. Either use something like Superfish or write some custom JavaScript. If the site already uses a JS framework, I imagine the code would be pretty simple. In jQuery, for example, all it takes is one line:

jQuery(document).ready(function($) {
    $('a:not(:last-child) .more').show();
});

Then, load the JavaScript snippet conditionally if the user agent is Internet Explorer, so that good browsers don’t have to download unnecessary bytes.

I want different indicators for parents of different levels!

I omitted that from the example on purpose, to keep the markup as simple as possible. It’s easy to do:

1. Add two indicators to each anchor, one for subitems that expand vertically and another for subitems that expand horizontally, and wrap each indicator in its own span along with an appropriate class. E.g.: more-v and more-h.
2. Hide all indicators.
3. For top-level parents display the one indicator by making a selector that applies to top-level parents only. E.g.:
   • #menu > ul > a:not(:last-child) .more-v
4. For lower-level parents display the other indicator by making a selector that targets lower-level parents. E.g.:
   • ul ul a:not(:last-child) .more-h

Links

That’s it for now. Thanks for reading!

Here are a few links to help your work and research on drop-down menu systems:

• CSS browser compatibility table at QuirksMode. See which browsers support advanced CSS3 selectors.
• Dropdown low down — Tyssen Design. Extensive comparative review of drop-down menus.
• Free CSS Drop-Down Menu Framework. Popular, actively maintained, relatively easy to set up, and licensed under the GPLv3.
• Keyboard accessible dropdown menu. Full keyboard-accessibility even without JavaScript!
• Superfish. A jQuery plugin that adds useful enhancements, including indicators, to Suckerfish-type drop-down menus.

Appendix

Here are three bits of code that show how to generate the markup for the indicators in WordPress.

If you are constructing a WordPress theme from scratch, simply use the link_after argument of wp_page_menu(). If the menu is generated by wp_list_pages(), you can pass the exact same argument to it too. Here is an example that uses wp_page_menu():

wp_page_menu(array(
    'depth' => 2,
    'link_after' => '<span class="more"> &darr;</span>',
    'sort_column' => 'menu_order',
    'title_li' => '',
));

wp_page_menu() and wp_list_pages() can also be modified by applying a filter, which is convenient if you do not want to edit template files directly.

For wp_page_menu() the indicator markup is added by applying a filter to wp_page_menu_args():

function my_page_menu($args)
{
    $args['link_after'] = '<span class="more"> &darr;</span>';
    return $args;
}
add_filter('wp_page_menu_args', 'my_page_menu');

For wp_list_pages() your filter will have to do a simple string replacement instead:

function my_list_pages($html)
{
    return str_replace('</a>', '<span class="more"> &darr;</span>' . '</a>', $html);
}
add_filter('wp_list_pages', 'my_list_pages');

RELATED

• Page Lists Plus: Comprehensive control of your WordPress page menu
• Add any link to your WordPress navigation menu with Page Links To
• Five good WordPress plugins you may not know about
• Add meaningful tooltips to your WordPress menu links with Page Menu Editor

Add to del.icio.us

© 2010 op111.net | Permalink

Whether you use WordPress for a weblog or as a more traditional CMS, your pages probably have a page navigation menu somewhere near the top. Sooner or later there comes a time when you need a way to manage this menu better. In fact, if you use WordPress more as a CMS and your main content is pages arranged hierarchically, this time comes right at the beginning.

There are several good plugins that help with that, and op111.net has written about two of them: Page Links To and Page Menu Editor. A few months ago I started using another page-menu plugin, which finally replaced for me both Page Links To and Page Menu Editor, as well as a third plugin, Exclude Pages. It is called Page Lists Plus and this is a small review of it.

Page Lists Plus

Homepage: technokinetics.com/plugins/page-lists-plus
WP.org homepage: wordpress.org/extend/plugins/page-lists-plus
Author homepage: technokinetics.com
Version reviewed: Page Lists Plus v1.1.5
Compatibility: Tested and works fine with WordPress v2.8, v2.9 and v3.0-dev.

Page Lists Plus is a plugin that offers options to customize the output of wp_list_pages(). If that sounded like Greek to you, here is an explanation: wp_list_pages() is the main WordPress function for generating a list of all pages (as opposed to posts) in a site, and it is what WordPress themes use to create page navigation menus. What that means is that Page Lists Plus will work with virtually any WordPress theme that has a page menu.

What exactly can Page Lists Plus do then?

Page Lists Plus global options

Page Lists Plus has about twenty options. They are all presented on one screen, separated in two groups. The first group is the global options, which you set once and forget about:

Add “Home” link is the first option and, I imagine, it must among the most useful to the users of the plugin: If your theme does not have a Home link on the page menu (or an option to add one), all it takes to add it with PLP is one click.

Add class="first_item" and the four options after it make it easy to change the appearance of the page menu via CSS.

The last global option, Remove title attributes from anchors, is what intrigued me most the first time I tried PLP, becaused it indicated interest for an area in which WordPress has not always been perfect (and in which WordPress has significantly improved the last few versions) — accessibility.

As the author of Page Lists Plus explains in his site, what WordPress does with title attributes is wrong and, unless you are manually adding meaningful and informative title attributes to your links, the best thing to do is remove them completely. Selecting Remove title attributes from anchors will do exactly that.

(Even leaving accessibility aside, a title attribute identical to the anchor text is pointless and annoying.)

Page Lists Plus per-page options

Next is the group of page-specific options. They are eight in total and, since not all will be of interest to everyone, the plugin lets you select the ones you want to use:

The options you select will then appear grouped in a box on the Edit screen of your Pages:

As of version 1.1.5, the page-specific options of PLP are eight — one that I dislike, one that I’m indifferent to, and six I like and use:

Add Custom Classes to Individual List Items

Adding custom CSS classes to specific items makes it easy to style them individually via CSS.

Alternative Link Text

To specify, e.g., a short link text for a page that has a long title. If I had a page with the title, say, Greek Cuisine Recipes by Demetris, I could use just Greek Recipes for the page menu.

Alternative Title Attribute

To supply supplementary information that appears when a link is hovered over. (See screenshot example below.)

Include

To specify whether a page appears on page lists and page menus. This option is selected by default for new pages. (In the Global options you can also specify whether children of excluded pages are excluded too.)

Link

To unlink a page. Useful, for example, for empty pages that serve as parents to other pages.

Redirect To

To make a page that appears on page menus and redirects transparently to a different URL. For example, you can make a page that redirects to a category archive, by specifying the URL of the category archive.

In this example from op111.net the link for the Archives page has a TITLE attribute that provides some supplementary information on the target. Graphical browsers commonly display the TITLE attribute when the link is hovered over.

Suggestions & Feature requests

All in all, I’m happy with Page Lists Plus. It’s been a three-in-one plugin for me, and it has been working flawlessly. The following are just a few small points that I think would help make it even better, at least for what I need:

• An additional Save button near the top of the Options screen.
• An option to use page Excerpts as title attributes of links.
• An option to use custom anchor text for the Home link.

Questions & Answers

These are a few questions I had when I started using Page Lists Plus, along with the answers I can offer now:

Is PLP a replacement for Page Links To?

Page Links To is a specialized plugin that does redirections of all kinds. In that sense, Page Lists Plus is not a replacement for Page Links to. However, if all you need is adding links to your page menu, Page Lists Plus will do that for you just fine.

Is PLP a replacement for Page Menu Editor?

For me it has been a complete replacement, as it does everything Page Menu Editor does, and more. Also, PLP is more economical in database queries: While Page Menu Editor makes one query for every page that exists in a site, Page Lists Plus only makes one query per active option that needs information from the database. (Some of its options, like the addition of various CSS classes, do not need database information at all.)

Does PLP work with wp_page_menu()?

It should in theory, as wp_page_menu() is simply a wrapper for wp_list_pages(), and it seems to work in practice too. (At this writing, the page menu of op111.net uses wp_page_menu(), and Page Lists Plus seems to work fine with it.)

Behind Page Lists Plus: Tim Holt

Page Lists Plus is made by Tim Holt, a web developer in England. Tim Holt specializes in WordPress customization, and, as his homepage and Page Lists Plus show, has also a special interest in web accessibility.

Tim replied prompty and informatively to two questions I sent his way before I started writing this review. I want to thank him for his kindness from here too.

Links

All Page Lists Plus links again, for your convenience.

Remember that you can install the plugin directly from your WordPress dashboard too: Go to Plugins › Add New, search for Page Lists Plus and click Install on the first result.

• Page Lists Plus, homepage
• Page Lists Plus, WP.org homepage
• Page Lists Plus, author homepage

Thank you for reading! I wish you a happy 2010!

/δκ

CHANGES

• 2010-01-02. Added Questions & Answers part.

RELATED

• Add meaningful tooltips to your WordPress menu links with Page Menu Editor
• Add any link to your WordPress navigation menu with Page Links To
• Progressive enhancement of drop-down menus with the :not CSS selector
• Tangofy: Better icons for WordPress 2.7 and 2.8

Add to del.icio.us

© 2009 op111.net | Permalink

After six months in preparation, the first beta version of WordPress 2.8 was released on 16 May 2009. Following WordPress 2.7, which focused mainly on the UI, WordPress 2.8 brings changes that are more evenly distributed across all areas. There are big improvements in the user interface, but there is a much larger amount of not immediately obvious improvements in two main areas:

• Extensibility
• Optimization/Performance

Also, many bug fixes and enhancements, big and small: This version saw more tickets opened and, most importantly, closed than any other version of WordPress before. The closed tickets are almost 800 at this moment. — All in all, WordPress 2.8 is a better tool than WordPress 2.7.

A NOTE ON COMPATIBILITY

In general, backward compatibility seems good. With two exceptions (one theme that broke itself and another that broke WordPress) all themes I’ve tried work well. Same with plugins: A few have problems but most work well. If it is any indication, of the plugins used in op111.net only one explicitly supports WP 2.8 at this moment; yet, all work without problems. (op111.net has been running on development snapshots of v. 2.8 since March.)

On to what’s new, in alphabetical order…

Accessibility improvements

WordPress 2.8 brings several improvements, big and small, to accessibility. A lot of work went into two areas in particular:

1. Adding labels and alternative text to input elements that did not have them.
2. Making the functionality of the new Widgets UI (more on that later) fully available without JavaScript.

Authentication: more pluggable

The authentication mechanism is now improved, so that authentication methods like OpenID and authorization methods like OAuth can cooperate easier with it (without replacing it and then having to deal with other issues). Read more:

• Authentication in WordPress 2.8 — Will Norris
• #8938 (Use new filter for extending WordPress authentication) – WordPress Trac

Improvements in this area also pave the way for OAuth support in the core (which will probably come in ver. 2.9).

Columnification and pagination in Screen Options

Screen Options has two new options, depending on the type of screen:

1. Number of columns
2. Number of items per page

Items per page is the one I’ve found more useful, but I can imagine columnification would be very useful too in some situations, e.g. on a netbook with an 800×480 display.

CSS: new dynamic classes with body_class()

Dynamic CSS classes were first brought to WordPress by the innovative Sandbox of Scott Wallick and Andy Skelton, offering a simple way to modify to any extend the appearance of a WordPress site by CSS alone. They offer possibilities that would otherwise require JavaScript or PHP.

WordPress 2.7 added dynamic CSS classes for the post div(ision). Version 2.8 adds dynamic classes for the body element too. Both implementations were based on Sandbox.

For theme authors. To add this to a theme, simply open the body element like so:

<body <?php if (function_exists('body_class')) { body_class(); } ?>>

More on the body_class() function:

• WordPress 2.8 and the body_class() function — Nathan Rice

Feed links for everything

WordPress 2.8 automatically adds feed links specific to the page viewed. For example, when you view the archive of the category Cooking, it adds a feed link for that category. When you view the archive for author Cyrus, it adds a feed link for that author, etc.:

For theme authors. The two main feed links—all posts and all comments—are not added automatically. To let WP add them too, put the automatic_feed_links() function (defined in general-template.php) in your functions.php.

Note. Extra Feed Links, a plugin by scribu, adds the same functionality to earlier WP versions.

JavaScript at the bottom

JavaScript files properly registered via the appropriate script API can now be placed at the bottom of the page. In most cases this is preferable, because JavaScript blocks parallel downloads (browsers need to evaluate it before proceeding) and can delay the time by which a page is usable and also the time by which the rendering is complete. So, unless a JavaScript file needs to be at the top, it can be moved to the bottom for better performance.

For plugin/theme authors. This is done with a new optional argument in the wp_enqueue_script() function. The argument defaults to “false” (not in the footer). To put a script in the footer, set it to “true”. E.g.:

wp_enqueue_script('script_handle', 'script/url/file.js', '', '', true);

More:

• Script loader updates « WordPress Development Updates
• Loading JavaScript In Footer In WordPress 2.8 « Lester Chan’s WordPress Plugins

LiveJournal Importer: Redone and improved

Importing a LiveJournal blog into a WordPress 2.8 blog is easier and more complete thanks to the rewritten LiveJournal Importer, which uses the LiveJournal API. Read more:

• The All-New LiveJournal Importer for WordPress « Dented Reality

Minification and concatenation of CSS and JS…

… or, faster admin pages.

Most CSS and JavaScript files in the administration area are now concatenated (chained together into one file) and, depending on the server setup, compressed too. Javascript files are also minified. Using minification, concatenation and compression improves performance in two ways:

1. The total size of files to get is reduced.
2. The browser requests fewer files from the server.

This kind of optimization could prove even more beneficial to the frontend (the public part of a website). Of course, things can become more complex there, but the current impementation could serve as a testing ground for applying something similar to the frontend at a later time.

What is minification? Minification is the practice of removing from a file bits useful to humans but unneeded for machine execution, like comments, spaces, line breaks and indentation. On the web it is used mainly for CSS and JS files, to reduce the amount of bytes sent from the server to the browser.

Plugin Installer

The plugin browser/installer was first introduced in the previous version, six months ago. I’m including it here for two reasons:

1. It seems it’s not very well known yet…
2. It’s been improved in v. 2.8. In the meantime, the search mechanism of wordpress.org was improved too, and now the whole system works much better.

Here is how to install a plugin in the new way:

Plugins management

The plugins manager was retouched, and is still being worked on at this writing. It now offers views/filters by plugin state, which I’ve found to be very convenient:

Pretty permalinks for IIS 7

IIS 7, the current version of the Microsoft web server, recently got an official rewrite module and can now do URL rewriting like Apache does. WordPress 2.8 detects if the server is IIS 7 with the rewrite module and offers the option to use fully pretty permalinks with IIS 7 too — not just the semi-pretty ones with index.php in the middle. Read more:

• IIS 7 URL Rewrite Module support in WordPress 2.8 : Ruslan’s Blog : The Official Microsoft IIS Site

Proxy support

Easy proxy support (without editing core files) had been missing from WordPress and was a frequent request. Now it is part of the WordPress HTTP API. You enable it by defining a few constants in wp-config.php.

The documentation for this, along with an example, can for now be found in the file wp-includes/http.php (look for the WP_HTTP_Proxy class).

Quotation marks locale-aware

WordPress has a smart typography filter that, among other things, replaces ASCII quotes—"like these"—with proper quotation marks “like these”. Before v. 2.8 this filter only knew about quotation marks as used in American English.

Now translators can specify the appropriate quotation marks for a language, and, if you use a localized version, they will be used instead. For example, «αβγδ» for Greek, „abcd“ for German, and so on and so forth.

Relational navigation links

A relational link in an HTML document points to another document and states its relation with the current document. Examples of such links that are used for navigation are “prev” (previous in a series) and “index” (index for current). Browsers can use them to offer an interface for navigation, much like they do when they show an icon/menu in the URL address bar for the feed links in a document.

WordPress 2.8 generates four types of relational navigation links: home, index, prev, next. If your browser supports such links (not many do, at least natively), you’ll be seeing them more often as WordPress sites upgrade to v. 2.8:

An interesting possibility of relational links is that browsers can also use them as hints to prefetch (predownload) a page, cache it, and then serve it from the cache, for better speed. Firefox—the only browser that does link prefetching currently—does this with relational links of the type next. (I have not been able to verify if it works in WordPress sites.)

Smilies: Now faster!

Version 2.8 cuts in half the time needed to convert text smilies to image smilies! :-o The faster code is also availabe as a plugin for WordPress 2.7: Faster Smilies

(Of course, you can always turn graphical smilies off in Settings › Writing › Formatting, and WordPress will be even faster!)

Theme Installer

Installing themes in v. 2.8 is as quick and easy as installing plugins is in v. 2.7:

Theme/Plugin Editor with highlighting and lookup

I was never fond of this feature of WP: I don’t see any need for it and I also think that it encourages bad habits. But others like it. They’ll be happy to know that the theme/plugin editor is now improved, with syntax highlighting and function lookup:

Note. In Chrome and Safari you’ll see the plain old text area without fancy colours. These two browsers (that share the same rendering engine) are not supported at the moment.

Timezone selection and DST

Settings › General had been displaying for a long time this apologetic message:

Unfortunately, you have to manually update this for Daylight Savings Time. Lame, we know, but will be fixed in the future.

Well, the future is here! :-D Now you only need to enter your location:

Note. Automatic DST adjustment uses functions that were introduced in version 5.1.0 of PHP. So, you won’t see it if your server has an older version. (The minimum requirement to use WordPress remains PHP 4.3.)

• Automatic Timezone is the plugin on which this enchancement was based. It adds the same functionality to WordPress 2.5, 2.6 and 2.7.

Widgets API: new and multiple-instance

Another part rewritten in v. 2.8 is the Widgets API. Writing widgets is now simpler and, importantly, widgets based on the new API are multiple-instance by default, like the Text/HTML widget in previous versions. (Writing multiple-instance widgets was already possible but convoluted.) Read more in this announcement by Ryan Boren:

• New Widgets API - wp-hackers | Google Groups

As a bonus, the new function the_widget() lets you display the output of a widget anywhere in a template.

Widgets management UI: Redone, much improved

This took a lot of work and is, in my estimation, the most important improvement in the user interface of WordPress 2.8.

The new Widgets manager:

1. Does everything by simple drag ’n’ drop (and is fully functional without JavaScript too).
2. Has better memory/storage: You can deactivate a widget without losing its configuration, and widgets that are deactivated automatically retain their configurations too.

Also, thanks to the new Widgets API, widgets can now have multiple instances. You can add a widget as many times as you wish.

See the screenshots:

That was it!

If you think I left out some important feature, please leave a comment to say so. If you want to try test versions of WordPress 2.8 as they come out, watch the official blog: wordpress.org/development — Usual warnings apply, of course: This is not a final product! Do not install on a live website unless you are prepared to spend time investigating and reporting bugs!

Note. The menu icons on the screenshots are not the default ones. If you like them, you can have them too!

Thanks for reading!

/δκ

Changes

• 2009-06-18. Added function_exists condition to body_class example.
• 2009-06-11. Locale-aware quotation marks by wptexturize.
• 2009-06-02. Link to X. Borderie on 10.000 tickets and 2.8 dev stats. Link to Automatic Timezone.
• 2009-06-01. Link to N. Rice on the body_class() function.

RELATED

• WordPress 2.7: Ten useful new features
• WordPress 3.0: What’s new
• Progressive enhancement of drop-down menus with the :not CSS selector
• Page Lists Plus: Comprehensive control of your WordPress page menu

Add to del.icio.us

© 2009 op111.net | Permalink