Tag: wordpress cheatsheets

WordPress 3.4 is around the corner. It’s currently beta4 which means a Release Candidate or three will be needed before it drops officially. If you want to test what’s out there now, the way to do that is through SVN. As usual, however, pre-release WordPress is not supported. As usual, however, I have been running trunk throughout the entire development cycle without any problems.

Before I get into the guts of WordPress 3.4, I want to point you to a resource which highlights some of the thinking that is going into the development, now and in the future, of how WordPress is built. Andrew Nacin sent an email to the “hackers” mailing list discussing object-oriented development that informs the thinking of the core developers now that WordPress supports PHP 5.2 and true object-oriented programming.

While it may be over the head of non-developer types, the gist is that now that we (used loosely) can write code smarter, we’re working our way in that direction. Some of the code in WordPress has existed for “generations” of versions and is bulky and inefficient. With new tools at our fingertips, we can begin to approach the idea of refactoring some of this code in better ways. Backwards compatibility is always retained, however, in 99 out of 100 times.WE ARE NOT DRUPAL!

Without further adieu, however, let’s get into what you can expect in the new version of WordPress.

Embed Tweets with oEmbed

Since version 2.9, WordPress has supported a technology called oEmbed that, simply put, has allowed the inclusion of rich media in content in a very simple way. Simply paste a YouTube link on a new line, and WordPress turns it into a properly sized video. No embed code needed. Same for Vimeo, Flickr, Scribd and more. The entire list can be found on the Codex. Now, however, Twitter is supported. Simply place the URL of a tweet on it’s own line and… bam, you have this:

Twitter is an oEmbed provider that is supported out of the box in WordPress 3.4

Query Efficiency Improvements

The common bottleneck for all WordPress users are database queries and data “munging”… that is, what WordPress does with data when it’s returned from the database. The query that brings in all the necessary content necessary to render a page used to look like this:

1

SELECT*FROM wp_posts WHERE...

This has been how the query has worked for years. Really since the beginning of WordPress. And while, in theory that works (and it does, again it has for years), the core reality of this approach is that all the data in the posts table matching the criteria in the WHERE clause is more data than is needed, thus causing potential performance problems.

This approach means the amount of data in memory and floating around WordPress is concise and compact. PHP doesn’t have to work harder to traverse arrays or objects… it is simply a smaller list of data.

But what about the other data? We need the other data! Yes, in fact we do. But since WordPress has an object cache, much of this data is in the object cache. We don’t need to retrieve it from the database.

The second step is to look to the object cache for posts with IDs matching any of the IDs in the first dataset. Anything we can’t find is followed with a second query to get all the information matching the non-matched IDs using MySQL’s IN() function:

1

SELECT*FROM wp_posts WHERE ID IN(10,34,78);

By changing how SQL and object caching is used, WordPress 3.4 finds new efficiencies. In the original ticket, developers were observing 2-3x speed performance improvements. I’ll drink to that.

Theme Customizer

Non-technical WordPress users will love the new Theme Customizer. Otto has a great write-up on this new feature. His video is above. The key takeaway from this new feature is that is possible now to customize a great number of things in a theme from right within WordPress. On the fly. with a live preview.

Change your title, tagline, background color, image and more with a click of a mouse. I can see this being used to create child themes in the future, but for now, it manages settings that are already in WordPress (and accessible in other areas of the WordPress Admin) on the fly. The best way to really appreciate this feature is via Otto’s video above. Related: The best way to leverage this as theme developers is outlined in great detail in his post…

Bundled ‘Touch’ Support

We live in a touchy-feeley world. And by that, I mean mobile. Specifically iOS and Android. In WordPress 3.3, we saw adaptive design come to portions of WordPress. Adaptive design, for the uninitiated, is a technology that elegantly resizes a website to adapt to the the screen it is rendered on. It is a way for developers to create a single experience that works on desktop/laptop browsers as well as mobile interfaces with arbitrary resolutions.

As mobile continues to lead the charge in today’s web, WordPress 3.4 has bundled the jQuery UI Touch Punch library that will give front-end developers more tools to work with in making a website mobile-friendly. Simply include the library via wp_enqueue_script() and now your element has the .draggable() method available. This method enables “drag and drop” support that was previously unavailable and the one major caveat is that it does not support Windows 7/7.5 phones due to limitations in the IE9 browser.

HTML in Captions

Photo by Kyle McCluer and used under Creative Commons. Some Rights Reserved.

I’m trying to rotate between developer tools and user tools in this article, so at this time, I’d like to point out a simple yet important frustration in previous versions of WordPress. When you upload an image and use the media uploader to then insert an image, you have the option of writing a caption. Sadly, it was impossible to include HTML in previous WordPress versions.

Often times, linking the source of a photo is welcome and, possibly depending on the usage restrictions on a photo, required. Before, the only way to do that was to set a link in the media uploader and then the photo would be linked. Now, in WordPress 3.4, you can include basic HTML in your captions as I have done above.

XML-RPC Improvements

XML-RPC. The thing that allows the WordPress apps for Android, BlackBerry and iOS to function. The thing that allows offline editors to function by remotely communicating with WordPress through a public-facing API.

XML-RPC is a venerable technology that is based mainly on the Metaweblog API invented a decade ago. WordPress has supported this iteration of XML-RPC as well as the Movable Type XML-RPC and Blogger XML-RPC APIs for a long, long time. However, WordPress has also extended the Metaweblog API and added it’s own methods along the way.

No more. Instead of band-aiding a solution on top of a limited set of methods intended for blogging only, WordPress 3.4 includes a brand new WordPress XML-RPC API designed to support all the rich features that have evolved since WordPress started focusing on CMS-style features. It incorporates all the methods introduced before as extensions to Metaweblog such as wp.getOptions, wp.getMediaItem, etc and introduces new ones such as wp.getPostTypes and wp.getTaxonomies to name just a few.

It’s important to note that only WordPress products are likely to ship with support for this new API at first, but old capabilities will still exist and function, as backwards compatibility is ensured. As API clients add support for WordPress’ new capabilities, we will see more common usage.

Internationalization (i18n) Improvements

For international WordPress users, WordPress 3.4 continues the tradition of enhancing your experience. As we in the community have stated many times, i18n is incredibly important to WordPress growth and development. In discussing this article with someone inside of the WordPress core community, I am told 2 out of every 3 WordPress users are non-American. Additionally, I am told that 40% of WordPress installations are non-english.

That’s Huge!

The running list of i18n changes in WordPress 3.4 is here. Some notable changes include:

Comma translation. While most languages use a comma as a separater (or delimiter), some do not. This enhancement is useful for languages like Chinese and Arabic that don’t use a comma.

Single-Double quote translation. It’s odd to think, but some languages like Hebrew, actually have distinct meanings for jots that are punctuation marks in an English world.

Default Timezones. It’s possible now to override the timezone WordPress uses in a translation. This, as you can imagine, is important when a language is largely spoken in one region in a single timezone.

Page Template Handling

For theme developers looking to put more organization around their theme file structure, a new change has gone in that has both an obvious, front-facing benefit as well as a background benefit. Now, you can place any page template inside a subdirectory of a theme. So you can now have a /pages/ subdirectory and segregate all of your extraneous one-off or multi-use page templates to that folder (or any folder). WordPress will identify all page templates in the theme root or in a subdirectory of a theme root and make them available for pages to use.

The background benefit of this comes in a new WP_Theme API that is lighter weight, more efficient and handles all the work for you. It’s important to note that most developers will never need to use this API and it is largely considered an “internals” thing.

In relation to the i18n improvements discussed earlier, the headers in these page templates are also now translatable. Simply include a Text Domain: and Domain Path: header in your style.css where the textdomain is the defined textdomain for translations (i.e. twentyeleven) and the Domain Path is the path relative to the stylesheet directory (i.e. the proper place the theme is regardless of if it’s a parent theme or a child theme) where the POT file is (/langs). I don’t want to get too deep into this as Andrew Nacin, the architect of this feature, plans to put out a field guide going into detail. Stay tuned to that.

Custom Header API

For a few versions now, WordPress has supported two functions add_custom_header_image() and add_custom_background(). These two functions have added new menus for designating header and background images to the Appearances menu.

WordPress 3.4 introduces a new API for dealing with custom headers and backgrounds and introduces new flexibility in terms of image sizes, etc. The two functions above have been deprecated (which means they’ll work for awhile but will ultimately go away, so use the new techniques) and replaced with new theme support. If you recall from previous version, we use the add_theme_support() function to, well, add support for a feature in a theme. To integrate the new stuff, include these lines in your theme functions.php:

Both function calls can take a second argument which must be an array of presets, but it’s entirely optional. To omit the second argument renders behavior as we’ve known it for some time. To include it allows theme developers to designate designate parameters for both elements, that can then be customized by the end user.

For custom headers, you may include defaults along these lines (gregariously stolen from the Codex):

Bonus

Did you know?

PHP end of file closing PHP tags are now removed. Those are these – ?> Why is this important? Including the closing tag means that if there is any white space at the end of a file, PHP is likely to break. Omission means that PHP assumes a close tag at the end of the file and whitespace can’t corrupt. Personally I’ve argued for this in the past. The main opponent must have been in a coma when this was slipped through by other core developers.

Distraction Free Writing, first introduced in WordPress 3.2 is now supported by all custom post types.

The theme installer now has infinite scroll which is just kind of pretty aesthetic thing. It also defaults to keyword searches when you’re browsing for a new theme on the WordPress Theme repository.

WordPress 3.2 has been downloaded a killer 12M+ times. WordPress as a whole continues to grow and is touted to be in the approximate 14% of the web zone. That’s ridiculously huge and it astounds me how big the projects footprint has become in the 7 years I’ve been around the community. Well done to all involved!

With that said, WordPress 3.3 is just around the corner and, as usual, it’s chock full of goodies for everyone. I’d say that the notable changes for developers are the most significant. Improved metadata handling, improved SQL tools, improved cache API and deprecation of several venerable functions are all changes that developers should be aware of.

Admin Bar Overhaul

The Admin Bar that was introduced a few versions ago has become a main-stay of my WordPress experience. At first, I felt like it got in the way, but I soon got used to it. In WordPress 3.3, the Admin Bar gets tweaked and enhanced. For Multisite users, you now have access to the Network Admin from a new “My Sites” menu along with all sites that you have access to 1.

As usual, developers can modify the admin bar using the admin_bar_menu action, and hooking a callback that modifies the $wp_admin_bar global. This object is created by the WP_Admin_Bar class that provides an add_menu() and remove_menu() method for manipulation.

HTML5 Admin/Responsive Layout

More Admin-side improvements, like a conversion to HTML5 are a little more understated and less pronounced – unless you’re trying to access it from your iPhone or mobile phone. The conversion to HTML5, while meeting the trends of the day, also have the practical effect of providing an adaptive design which conforms to the device or viewport you are using. There’s nothing too crazy here, but with the web world going in the direction of HTML5, this move lays groundwork for new HTML5 features in the future.

Drag and Drop Media Uploader

One of the biggest new features in WordPress 3.3 (and a long time in coming!) is a new and improved media uploader. This is a feature that is discussed every single release cycle but because there’s only so much room in a major release cycle for major features (and this is a huge rewrite), it has continued to get bumped to a future release – until now.

While the new uploader is not the holy grail and I feel like there’s still a lot of room for improvement, it takes a giant leap forward in making the web interface feel more natural and more like a native application.

What am I talking about? Well, three words: Drag and Drop. With the new media uploaded, it’s as simple as dragging files to the “drop zone” in the native way that your OS allows: On Mac, from the Finder or by dragging the title bar icon in the app you’re using (Photoshop? Preview? Skitch?) into drop zone. On Windows, by pulling your file from Explorer into the Drop Zone.

Plus, related to the last feature, this media uploader prefers HTML5. For the geeky, the failover for HTML5 uploading is first Silverlight, then Flash then the old fashioned “Choose File” HTML dialog.

HTML5 Media Uploader

Welcome Screen and Pointers

If you already are using WordPress, you won’t see the welcome screen unless you setup a new WordPress install 2. The Welcome panel gives an overview of WordPress to new users.

More importantly, there is a new jQuery plugin that adds “Pointers” to WordPress whenever a new core, user facing feature is added. In WordPress 3.3, you’ll see one immediately pertaining to the new Admin Bar. However, Plugin and Theme developers who want to highlight new features can also do so. If you know jQuery, the following code is a good head start in the right direction:

// Define text for the Pointer. Make sure you escape stuff
$widget_text = '<h3>' . esc_js( __( 'Important!') ) . '</h3>';
$widget_text .= '<p>' . esc_js( __( "This is where you would put some text that'll help the user understand WTF is up with your new stuff. Use it wisely and make sure it's short (Users won't read it if it's too long and once they dismiss it, it won't be shown again)" ) ). '</p>';
?>
<script type="text/javascript">
jQuery(document).ready(function(){
jQuery('#your_dom_element').pointer({
content : '<?phpecho$widget_text?>',
position : 'left',
close : function() {}
}).pointer('open');
});
</script><?php}
add_action('admin_head','ab_pointers');

I imagine this will get easier to implement in the future.

Improvements to Distraction Free Writing

Distraction Free Writing, which made its debut in WordPress 3.2, offered bloggers vast improvements to how they wrote content by removing the silly things that, well, distract from the job of writing.

In WordPress 3.3, DFW now integrates the content width and other CSS stylings of post content into the editor. This is all based on the active theme CSS and it attempts to aid the blogger in formatting properly for the theme the content will be displayed in.

Admin Menu Flyouts

A minor enhancement, yet important from a UI perspective – especially for those of you who, like me, constantly have wp-admin menus expanded – are menu flyouts. Very simple little thing, but when a user mouses over a menu, the submenu items under it appear in a “flyout” to the right and disappear when the mouse is no longer over the top level menu. Of course, for touch devices and clicky people, the collapse/expand functionality still exists.

Tumblr Importer

Technically, importers are no longer bundled with WordPress core. They are plugins. However, the removed importers are still listed on the Tools > Import console and can be installed from within WordPress.

An importer that has been in demand for some time, due to the popularity of Tumblr but the more popular nature of WordPress, is a Tumblr importer. Now that is available – also as a one-click plugin – to assist Tumblrs in moving to WordPress.Tumblr Importer

Go forth and enjoy a better blogging experience. And hey, use Press This if you like the Tumble style.

Multisite – Internationalized Domain Name Support

For non-english Multisite installs, it is now possible to designate an international domain name 3 as the site install domain. In Multisite, this means that base installs of WordPress can use IDNs now, which will serve to increase the adoption of these domains in non-English speaking parts of the world.

ワードプレスのイェーイ.jp, FTW!

Multisite – Network Enabled Themes and Theme Updates

Since we’re on the topic of Multisite, WordPress 3.3 brings the Network Activate option that has been available for plugins to themes. The plugin flow and the theme flow is different in WordPress, so this option makes things significantly easier. The plugin workflow only allows Super Admins to install WordPress and gives the Super Admin the ability to turn off the plugin menu for Blog Admins, but if left turned on, any Admin can activate any available plugin for their particular blog. For plugins, Super Admins can designate a plugin as a global plugin by Network activating in the Network Admin.

For Themes, it was an arduous task of making themes available to sub-sites in the past. Now, after installing a theme from the Network Admin, all it takes is a single click on Network Activate to make that theme available to sites in the network.

Deprecating Feeds

Finally, for those of you who rely on your feeds and are stuck in the stone age still, WordPress no longer supports old RSS 0.92 feeds and RDF feeds. For what it’s worth though, the default RSS feed is the still supported RSS 2.0 feed (add /feed to the end of just about any URL in WordPress and that is your RSS 2.0 feed.

Still, I know some of you don’t like to change and may be using the old feeds. There are two things to note:

These now-deprecated feeds will redirect to the proper feed, with 301,

If you use FeedBurner, or similar feed repurposing and syndication service, please make sure you are using the RSS 2.0 feed, not the RSS 0.92 feed. Like I said, a 301 will occur but that is actually additional load on the web server because it generates additional HTTP requests

Wrap Up

Sadly, this was the first WordPress release in some time where I have not contributed any code. There are a lot of reasons for that, none of which are all that important. But the core development team has really done a great job with this release and they should be commended.

You will only see sites that you have a Core Role on (Administrator, Editor, Author, Contributor, Subscriber). Super Admins that are not assigned to a blog, even though they have access to it as a Super Admin, will not have that blog listed ↩

You can manually turn the Welcome panel on in the Dashboard Screen Option ↩

IDNs are domain names that contains non-ASCII characters such as are provided by languages like Arabic, Kanji or Hiragana or language styles like Cyrillic ↩

Gentlemen, start your engines! WordPress 2.9 is just around the corner. Unlike WordPress 2.8, which Mark Jaquith describes as the Snow Leopard of WordPress since most of the basis of the WordPress 2.8 upgrade was complete rewrites and optimization of the infrastructure that ran WordPress instead of providing lots of new features in the same way Apple’s new OS X release is a focus on improved performance instead of features, WordPress 2.9 brings major new “bling” to the table. As a reminder of WordPress 2.8, you can see the writeup that Jonathan Dingman brought us last time around.

By and large, this release is a plugin developers release with lots of new APIs and abstraction. However, there are significant additions for theme designers and users as well. As a result, unlike previous iterations of this article (I do one for every major WordPress release), I’m going to break this down into sections for each kind of feature.

Themes: the_post_thumbnail()

Theme developers have a new piece of functionality that have become extremely popular in themes these days. As blogs have evolved from journal form into entities that can be very magazine-like, the use of thumbnail images has also grown. Typically, this layout is achieved through the use of custom fields that must be manually created and populated. No more!
As of WordPress 2.9, if you use the built in image uploader, then WordPress handle this for you. Theme designers that wish to support this feature can add the template tag the_post_image() to their themes to achieve proper placement as required by the theme layout. The template tag can optionally take a “size”, which is one of the WordPress default sizes: thumbnail, medium, large, etc. If none is provided, it defaults to your preset thumbnail size.

Example:

12345

<div class="entry"><h1>&lt;a href=&quot;"&gt;</a></h1>

</div>

Conveniently, if a theme is enabled for post thumbnails, the only “feature” currently offering this support in WordPress, then a new “meta box” will be displayed on the Write screen allowing you to assign a post image.

Themes: Register Support for WordPress Features

Editorial Note: Since this article was published, the code has changed to refer to post-thumbnails, not post-images. As a result, function names have also change. The code and examples included before reflect this change. Sorry for the confusion and sorry specifically to theme devs who have implemented the_post_image() feature already. Just change it to the_post_thumbnail()

This may seem to be an obscure feature, and typically, it’s pretty simple to figure out what I’m talking about just by looking at the header. In this case, it’s a bit more obscure because it suggests a feature that is introduced in WordPress 2.9 and then only for a very niche purpose. I can see this being built out over time, and plugin authors can supply their own use cases.

The concept is simple. If a feature exists “” in the core, the only use case is for the thumbnails I described earlier and it is called ‘post-thumbnails’ “” then a theme can declare support for the feature using the add_theme_support() function in the theme functions.php. It can only be declared in this file and it requires a feature be assigned a name. As I mentioned, with WordPress 2.9, there is only one feature that is named and that is post-image. Plugin authors can provide their own new functionality using the require_if_theme_supports() function.

We’ve used the function_exists() check on the add_theme_support() function to ensure backwards compatibility with WordPress installations prior to WordPress 2.9. Similarly (and possibly confusingly in this context), before you would have to check for the existence of a plugin by using a function_exists() or class_exists() piece of logic and loading it if the class or function did exist, but now there are on/off switches to get it done.

Users: The Trash Can

On Windows, they call it the Recycle Bin. On Macs, it’s the Trash. In both cases, the feature exists to help people recover from accidental deletions. We have all had those moments where we nuked something we had no intention of nuking. With WordPress, accidental deletions have been permanent. In WordPress 2.9, everything is recoverable now with a new Trash feature. When you delete a post, page, category, comment, or any bit of content, it is moved to the Trash where you can decide whether to pull it back at a later date.

The Trash Can view. From here, content can be restored or deleted permanently.

Trash collection is done every 30 days by default, but it is possible to change this by editing your wp-config.php file. Add the following to your config file to change trash collection to every 7 days. Modify as needed.

1

define('EMPTY_TRASH_DAYS',7);

Users: Image Editing

One of the hot new features in WordPress 2.9 is image editing. Now don’t get me wrong. This isn’t Photoshop. And it only support basic functionality at this time. However, image editing will allow bloggers to crop, scale and rotate images from right within WordPress. From the media library, you can edit images by clicking the Edit link under an image, and then clicking the Edit button on the individual image page. This brings up an interface like what is shown below.

The WordPress 2.9 Image Editing Screen

Users: oEmbed

oEmbed, as described at oEmbed.com, is a specification that allows media providers like Flickr, YouTube and others to provide data for consumer applications like WordPress about media. So by including an Embed (Use the File uploader and choose “From URL” and paste the link to the page that contains the media, not the media file itself) in a post or page, WordPress can retrieve the relevant specs on the media file and formulate a properly formatted embed accordingly.

Qik.com (via oEmbed) “” never heard of this site, but it was listed on oEmbed’s website, so”¦

Revision3 (via oEmbed)

Google Video (via an internal handler)

PollDaddy (via an internal handler)

DailyMotion (via an internal handler)

That said, plugin authors can add new providers if they want by using the oembed_providers filter or override altogether with the WP_oEmbed->providers property.

Plugins: Custom Post Types

One of the strengths of Drupal has been its ability to have multiple types of contents contained in objects that all look alike to PHP. WordPress has supported a variety of content types as well, but it has not been nearly as flexible making WordPress a blog platform with some additional support for pages and attachments. Technically, the only post_types that WordPress has supported have been post, page, revision and attachment. While it has technically been possible to add new post_types (like podcast, mp4, or tutorials – they could be anything, really), it has been a chore and required plugin developers to handle quite a few moving parts in order to make it all work properly.

No longer. Plugin authors now have API to register new post types, opening up the possibility for even more creativity and uses for WordPress.

get_post_type()

The get_post_type() function can only be used in the Loop. It returns the type of post a post is. Keep in mind, I’m using post loosely. All content in WordPress is kept in the posts table thereby inheriting the name “post”, but post is also a kind of content that is associated with blog content (as opposed to page which is a pseudo-static page, attachment which is information about an image or file uploaded with the media uploader, etc).

get_post_types()

The get_post_types() function will return a list of all types of post content. By default, this will be post, page, attachment and revision. Refer to the source code for optional arguments that can be used to control what kind of data is returned.

register_post_type()

As a plugin author, you can use this function to create a new post type. The first argument is the unique handle you want to assign to the post type – let’s call it podcast – and the second argument is an array that contains additional elements. The key one here is an exclude_from_search, which by default is set to true. You actually probably want to set this to false unless you really don’t want this additional content searchable. See below for example usage.

There is currently no user interface for post types. There is a patch in for UI that will likely be included in WordPress 3.0.

Plugins: Comment Meta

There has been a variety of meta tables in WordPress. Meta tables, like usermeta or postmeta, are database tables that contain information about the type of data that is stored in WordPress. It allows plugins and WordPress to assign metadata, such as user roles and capabilities, to pieces of data thus extending that data. Now, there is a comment meta table as well.

Though it is unclear how plugin authors will seek to use this table, the fact that it is available is a major deal as it essentially provides meta tables for every piece of content in WordPress now.

Plugins: Metadata API

With the addition of a comments meta table, it has become effectively redundant to duplicate functions throughout WordPress. You have a get_post_meta() function that does the same thing as a get_usermeta() function except they query data from different tables that also look identical except for the data stored in them.

In WordPress 2.9, there is an entirely new Metadata API that can be used to retrieve data from any of these meta tables.

The add_metadata() function takes a meta type (‘comment’, ‘post’, ‘user’, etc), the ID of the content type, the key and value of the metadata and whether the information should be unique or not (true or false).

1

add_metadata('comment', 12345, 'twitter_id', 'someyoungpunk');

You can also use update_metadata(), delete_metadata(), get_metadata() and update_meta_cache() for further wrangling. Refer to wp-includes/meta.php for full documentation.

Themes/Plugins: Theme System Modification

A lot of messiness has been eliminated in WordPress 2.9 theming. For one, new template opportunities exist. Now, instead of looking for a template file called category-x.php, tag-x.php or page-x.php, where x is the ID of one of those types of content types, it will look for these templates second. The first template that is now looked for is based on the slug. So if you have a category, tag or page called foo, the first template to be sought after would be category-foo.php, tag-foo.php, or page-foo.php. If none of these templates exist, then the ID-based template file is looked for.

Additionally, plugin developers can register new directories for themes to be located with the register_theme_directory() function.

System: Database Repair Script

The database occasionally needs a good spring cleaning. Other times, the database needs a repair. WordPress ships with a new script that will do just this. It is housed at /wp-admin/maint/repair.php but in order to use it, you need to create a new (or modify if it already exists for some reason) constant in wp-config.php.

1

define('WP_ALLOW_REPAIR',true);

System: Minimum Requirements

PHP 5 is not required yet. That’s coming in WordPress 3.0 will be increasingly implemented over time. But MySQL requirements have been boosted from MySQL 4.0 to MySQL 4.1.2.

Bonus coverage

Other interesting things in WordPress 2.9.

JSON compatibility, before only beneficial to PHP 5.2, has been backported for use in WordPress