WordPress 6.4’s PHP Compatibility

In an effort to keep the WordPress community up to date, this post provides an update on the PHP compatibility of the upcoming WordPress 6.4 release scheduled for November 7, 2023. 

Recommended PHP version for WordPress 6.4

It’s recommended to use PHP 8.1 or 8.2 with this upcoming release. Please refer to the Hosting page for more detailed information, including a few known issues

Reach out to your hosting company to explore PHP upgrade options.

Why does compatibility matter?

PHP is a programming language on which the WordPress code is based. This language runs on the server, and it is critical to keep it updated for security and functionality. Various teams within the WordPress open source project work to both test and fix any issues with new PHP versions so you can update with confidence that the WordPress core software is compatible. 

Happy WordPress-ing! 

Thank you to @annezazu @barry @ironprogrammer @hellofromtonya @chanthaboune @costdev @javiercasares for reviewing and contributing to the effort of this post.

Stay Logged in to WordPress

I work from home so can afford to leave tabs open for each of my WordPress sites. That way I can jump on anytime and update or add new content very quickly. The problem I kept running into is that WordPress automatically logs out users after 48 hours. Which means I have to log back in every day even when it’s not necessary. So I needed a way to stay logged in to WordPress indefinitely. Fortunately WordPress is very flexible and easy to customize, and the login duration can be changed via several different methods.

Here are three easy ways to stay logged in to WordPress for a longer period of time.

Three ways to do it..

Check the box

The easiest way to increase the expiration date/time for logins, is to simply check the “Remember Me” checkbox when logging in to WordPress. That will increase the expiration to 14 days, or whenever the browser is closed. After that time, the session cookie expires and you’ll need to log in once again.

This is useful if 14 days is enough time for your workflow.

One downside is that it requires an extra click to check the box. Fine I guess if you’re logging in manually. But if you’re using a password manager or other auto-login app, the extra checkbox step requires action on your part, thus adding friction and slowing things down.

Another downside is that 14 days is not always enough. For my own workflow, I prefer to minimize as many needless steps as possible. So I prefer the next method of extending the login duration, using a slice of custom code..

Add custom code

For more flexibility and less friction, you can add the following code snippet to stay logged in to WordPress for however long is necessary, even indefinitely if it makes sense to do so. This is the preferred technique for my own websites.

Important: Be mindful of any other users who may be logging in on public machines. Only extend the login duration if you know 100% that it’s safe and secure.

Here is the magic code to stay logged in to the WordPress Admin Area. You can add this code via your theme functions file, or add via simple custom plugin. Here is a guide that explains how to do both.

function shapeSpace_stay_logged_in($expires) {
	
	return 172800; // default 48 hours
	
}
add_filter('auth_cookie_expiration', 'shapeSpace_stay_logged_in');

As written, this code hooks into auth_cookie_expiration and filters the expiration duration (in seconds). By default the duration is 48 hours. You can change that to anything that works best.

To stay logged in forever, change the interval to some very large number, like 3153600000 to stay logged in for 100 years ;) To help with converting time to seconds, you can use a free time conversion calculator.

Thanks to Alex Mills (Viper007Bond) for sharing this code at Stack Exchange.

Install a plugin

If you want to extend the login beyond 14 days, but don’t want to go the custom code route, installing a plugin is the way to go. Currently there seems to be only a couple of capable plugins in the WP Plugin Directory:

Let me know if I’ve missed anything! :)


Minimum PHP Version update

WordPress 5.2 is targeted for release at the end of this month, and with it comes an update to the minimum required version of PHP. WordPress will now require a minimum of PHP 5.6.20.

Beginning in WordPress 5.1, users running PHP versions below 5.6 have had a notification in their dashboard that includes information to help them update PHP. Since then, the WordPress stats have shown an increase in users on more recent versions of PHP.


Screenshot of the "PHP Update Required" widget from the WordPress dashboard. Contains information about detecting an insecure version of PHP, how it affects your site, and a link for information on upgrading.
The dashboard widget users see if running an outdated version of PHP

Why You Should Update PHP

If your site is running on an unsupported version of PHP, the WordPress updater will not offer WordPress 5.2 to your site. If you attempt to update WordPress manually, that update will fail. To continue using the latest features of WordPress you must update to a newer version of PHP.

When updating to a new version of PHP, WordPress encourages updating to its recommended version, PHP 7.3. The PHP internals team has done a great job making its most recent version the fastest version of PHP yet. This means that updating will improve the speed of your site, both for you and your visitors.

This performance increase also means fewer servers are needed to host websites. Updating PHP isn’t just good for your site, it also means less energy is needed for the 1-in-3 sites that use WordPress, so it’s good for the planet.

How to Update PHP

If you need help updating to a new version of PHP, detailed documentation is available. This includes sample communication to send to your host for them to assist you. Many hosting companies have published information on how to update PHP that is specific for them.

5.6 now, but soon 7+

This is the first increase in PHP required version for WordPress since 2010, but may not be the only increase in 2019. The WordPress core team will monitor the adoption of the most recent versions of PHP with an eye towards making PHP 7+ the minimum version towards the end of the year.

Update PHP today, so you can update WordPress tomorrow!

On the topic of that pesky widget…

When I go to WordCamps, I get this question a lot: “Why do you have the PHP Code Widget still in the directory?”

There’s a good answer for that, but first let me explain why I made the thing in the first place.

If you examine the history of that plugin, you’ll find that it was submitted almost 10 years ago. Back then, widgets were new. Most people using WordPress had hardcoded sidebars in their themes. Changing the sidebar meant changing the theme. Widgets aimed to replace that with draggable objects. The Widget plugin was still a plugin, and not in core, but headed there.

The PHP Code Widget was created to make it easy and simple and fast to migrate from a hardcoded sidebar to a widget based one. You could take your existing code in the sidebar file, paste it into the widget, and then you had a movable widget that you could easily use.

Obviously, this was not meant for long term usage. The goal was to get widget support rapidly in your theme, with the expectation that as new widgets came out, you could replace your old code with newer, shinier, well supported, widgets.

The reason the plugin is still in the directory is because it still fills a need for some people. If I removed it, then they would fulfill that need in worse ways. It does not take much searching to find snippets of code, with bad advice saying to just pop it into your theme’s functions.php file, and voila, now all your Text Widgets run PHP code. That snippet actually exists. It’s a terrible idea, for obvious reasons.

The PHP Code Widget is less terrible than the alternatives.

But it’s still terrible.

And yes, it bothers me that it is one of the top 150 plugins. Storing PHP code in your database and then running it is just dumb. Don’t do that. Code should live in the right place, and that place is not the database.

So, in an effort to reduce the usage of the PHP Code Widget, here’s one way to stop using it, if you still are.

Getting rid of the PHP Code Widget

Step 1:

Get the PHP Code that you are using from the Widget, copy it into a text editor, save it somewhere for safe keeping.

Step 2:

You’re going to make a new plugin. You can call it whatever you like, but I recommend naming it specific to the site you’re making it for. If I was making a plugin for this site to hold widgets, then I’d call it “Ottopress Widgets” or something to that effect.

How to make a new plugin:

(Note: You can use Pluginception for this instead, if you like. That one I’m not ashamed of, it’s a very handy tool.)

a. Make a directory in /wp-content/plugins named after your plugin, like /wp-content/plugins/ottopress-widgets

b. Make a PHP file in there named the same. Like ottopress-widgets.php.

c. Edit that file, and add this header to the top of it:

<?php
/* Plugin Name: Ottopress Widgets*/

Lovely. We’ve made a new plugin. It doesn’t do anything, yet, but here’s some more code to add to the plugin. This is largely copy-paste, and then you edit it to fit your specific circumstances

Step 3:

add_action( 'widgets_init', 'ottopress_widget_register' );
function ottopress_widget_register() {
	register_widget( 'Ottopress_Widget' );
}
class Ottopress_Widget extends WP_Widget {
	function __construct() {

		$class = 'widget_ottopress';
		$name = 'Ottopress Widget';

		$widget_ops = array('classname' => $class, 'description' => $name);
		$control_ops = array('width' => 400, 'height' => 350);
		parent::__construct('', $name, $widget_ops, $control_ops);
	}

	function widget( $args, $instance ) {
		extract($args);
		echo $before_widget;

		echo '<h2 class="widget-title">Ottopress Widget</h2>';
		echo "<div>Here's my custom stuff.</div>";

		echo $after_widget;
	}
}

I named this widget “Ottopress Widget” by way of example. In the first few lines of code, you’ll want to change these to your own naming scheme. It’s important that names be unique, which is why I recommend naming things using your site’s name. Unlikely for there to be interference that way.

The $class and $name variables you should also change. The class is used in the HTML that the widget produces, so you can refer to it via CSS. The name is simply used for display purposes on the widgets editing screens.

Step 4:

Finally, the meat of the code you want to edit is here. I’ll point it out specifically.

function widget( $args, $instance ) {
	extract($args);
	echo $before_widget;

	echo '<h2 class="widget-title">Ottopress Widget</h2>';
	echo "<div>Here's my custom stuff.</div>";

	echo $after_widget;
}

This is the code that shows the widget on your site itself. Now, this one is just hardcoded to show the normal before and after code (these are set by the theme, so these should always be there), and then it has a little hardcoded bit there where it echo’s out a title and a div that says “Here’s my Custom Stuff”.

If you’re migrating from the PHP code widget, well, here’s where you migrate it to. You can drop your code from the PHP Code widget here and, you know, do whatever you were doing in the widget before, just now in an actual custom widget, in your own custom plugin. No more storing the code in the database. Just activate the plugin and replace the PHP Code widget with this one.

If you need more widgets because you were using it in multiple places, then simply repeat the process. Paste that whole class in there, only give it a different class name and other info, then put in your other code. You can have as many widgets as you like, they just have to all be named differently. Simple.

Note that this widget has no settings screen of any kind. Why would it? You’re controlling the code directly, no need for settings, presumably. If you want to go on and make your widget smarter and more complex and have settings, well, there’s other tutorials for that.

If this reduces the usage of the PHP Code Widget, well, I’ll be a happier person.

How to create a 301 redirect in WordPress

There will be times where you want to redirect visitors to a different part of your website when they visit a particular page or post. Reasons for this can be that you renamed a post and its URL, a page was removed or you want a different page to rank.

Redirects in a nutshell

The name ‘redirect’ pretty much says it all: It sends visitors traveling to a specific page to an alternative one. But what does this 301 mean and how does it differ from a 302 redirect? Both send your users to a different page. The only subtle (yet very important) difference is that a 301 will permanently send visitors and search engines to the new destination. 302 redirects indicate that you only temporarily want visitors to be sent to a different page.

Creating a 301 redirect on the server

One of the most basic methods of adding a 301 redirect, is by editing your .htaccess file on the server. This method is only available on Apache servers. Nginx has their own way of defining redirects in the server configuration and requires extensive knowledge of system administration.

These configurations can get quite unmaintainable over time, especially if you’re an avid blogger or you’re trying to improve the SEO of your posts. On top of that, you would have to log in on your server over FTP, edit the files and re-upload them every time you add a new redirect. That’s why, generally speaking, using this method is not considered the way to go.

Creating a 301 redirect with PHP

As a WordPress developer, you have two options: Either you make a redirect by altering the headers of a file in the code -or- you make use of WordPress’ built-in
wp_redirect function.

An example of plain PHP could be as follows:

<?php
// MyExampleFile.php
header("HTTP/1.1 301 Moved Permanently"); 
header("Location: http://www.my-blog.com/a-new-destination"); 
?>

And this is how you’d do the same, but now by using WordPress’ built-in function:

wp_redirect( get_permalink( http://www.my-blog.com/a-new-destination ), 301 );

If you forget to add the 301, both WordPress and PHP will both assume that it’s a 302 redirect, which isn’t always the case.

This method is a bit easier than editing files on the server, but can also become cumbersome once the amount of redirects increases.

Optimize your site for search & social media and keep it optimized with Yoast SEO Premium »

Yoast SEO for WordPress pluginBuy now » Info

Creating a 301 redirect with Yoast SEO

Our Yoast SEO Premium plugin offers you a helping hand when it comes to creating these redirects. Our built-in Redirect manager assists you whenever you change the URL of a post, page or any of the taxonomies that may result in a possible 404 if you don’t properly redirect visitors.

In addition, we also offer you an interface to edit or remove these redirects at a later point in time. The plugin also tells you when you’re about to create a redirect that will result in a redirect loop. This looping is something you want to avoid at all costs.

Read more: ‘How to properly delete pages from your site’ »

Ayurmama.com

This site offers natural healing techniques and coaching based on traditional ayurvedic medicine.

Urban Legend web was contracted to create the front-end and back-end using a WordPress framework.

For the front-end, a child of the ‘cardinal’ theme was used to provide a basis for the PHP, HTML, CSS, and Javascript used for the theme files, layout, style, and user interaction respectively.

For the backend, theme files were edited in PHP to provide user options for content management and editing.

Davis Ogilvy

For this project I was under contract to a Christchurch agency, PublicaDDM.
My role was working within the WordPress framework to set up the frontend theme, as per supplied files. That involved creating and editing CSS, HTML, and Javascript to meet the project requirement. The layout is responsive. My role also involved setting up the backend content management system, using PHP.

What’s new with the Customizer

Been a while since I wrote something. Let’s talk about some of the new stuff available in the Customizer.

Forget about some of part two

First, back in part two, I had a bit about Surfacing the Customizer. That bit is outdated now, WordPress does this for you in later versions. So, yeah, skip that.

Shiny new thing: Panels

Okay, so Panels aren’t that new. They were added in WordPress 4.0. Basically, they’re sliding containers for sections. Having trouble fitting all your settings on the screen? Group the various sections up into Panels. Panels show up as an item in the main list, and when you click the arrow next to them, the whole list glides off screen to show only those sections.

So, now we have four things: Panels, Sections, Controls, and Settings.

  • Panels group Sections together
  • Sections contain Controls
  • Controls are what the user changes
  • Settings define what the Controls change

Creating a panel is easy:

$wp_customize->add_panel( 'some_panel', array(
	'title' => 'Panel 1',
	'description' => 'This is a description of this panel',
	'priority' => 10,
) );

Adding a section to that panel is just as easy:

$wp_customize->add_section( 'themedemo_panel_settings', array(
	'title' => 'More Stuff',
	'priority' => 10,
	'panel'	=> 'some_panel',
) );

All that’s new is a panel setting to tell the section to go into that panel. Simple.

Active Callbacks

One of the problems with the Customizer was that it displayed settings and showed them changing on the site to your right, but the site being displayed is the actual site. Meaning that you can navigate on it. Sometimes, the controls being shown don’t necessarily apply to the actual site that you’re seeing.

Example: If you have a control to change the color of something in the sidebar, but then are looking at a page which has no sidebar, then you have no visual feedback to tell you what the change looks like.

To fix this, “active callbacks” are used.

The active_callback is simply a new parameter that you can pass into Panels, Sections, or Controls. It can contain the name of a function, and that function will be called when the page changes. The function should return true or false (or equivalent) to indicate whether or not the element of the customizer should be shown for that page.

So, if you have a whole Panel that only make sense when the user is looking at Front Page of the site (and not an individual post), then you can do this:

$wp_customize->add_panel( 'front_page_panel', array(
	'title' => 'Front Page Stuff',
	'description' => 'Stuff that you can change about the Front Page',
	'priority' => 10,
	'active_callback' => 'is_front_page',
) );

And voila, when the user is not looking at the front page, the panel simply disappears.

You can use any of the normal WordPress Template Tags for this, or write your own function if you want to be more specific about it.

If you do need to write your own callback function, note that the function receives the object in question when it’s called. So, if you attach an active_callback to a Panel, your function will get a argument of the WP_Customize_Panel object in question passed to it. Sections get WP_Customize_Section and such. You can use the information in these to decide whether the panel (or whatever) should be shown for that page.

So, how do we use that object? Well, you can use this to make whether certain controls show or not dependent on the values of other settings. All the various items you can use this on have a link back to the main WP_Customize_Manager. That class has a get_setting function, which you can use to determine what to do.

So, let’s make a control that causes other controls to appear, dependent on a setting.

First, let’s make a simple radio selection control:

$wp_customize->add_setting( 'demo_radio_control', array(
	'default'        => 'a',
) );

$wp_customize->add_control( 'demo_radio_control', array(
    'label'      => 'radio_control',
    'section'    => 'themedemo_panel_settings',
    'settings'   => 'demo_radio_control',
    'type'       => 'radio',
    'choices'    => array(
	'a' => 'Choice A',
	'b' => 'Choice B',
	),
) );

Now, we need to make two other controls, one for each choice. You can actually make as many as you like, we’ll keep it simple.

First, the control for choice A. Let’s make it a simple text control.

$wp_customize->add_setting( 'choice_a_text', array(
	'default' => '',
) );

$wp_customize->add_control( 'choice_a_text', array(
    'label'      => 'Choice A: ',
    'section'    => 'themedemo_panel_settings',
    'type'       => 'text',
    'active_callback' => 'choice_a_callback',
) );

We’ll need that callback function to detect if choice A is selected in the radio control, and return true if it is, and false otherwise. Like so:

function choice_a_callback( $control ) {
	if ( $control->manager->get_setting('demo_radio_control')->value() == 'a' ) {
		return true;
	} else {
		return false;
	}
}

You can simplify that if you like, I spelled it out with an if statement so as to be clear as to what is happening.

panel1

Now for choice B, let’s make it display a color control instead:

$wp_customize->add_setting( 'choice_b_color', array(
	'default' => '#123456',
) );

$wp_customize->add_control( new WP_Customize_Color_Control( $wp_customize, 'choice_b_color', array(
	'label'   => 'Choice B',
	'section' => 'themedemo_panel_settings',
	'settings'   => 'choice_b_color',
	'active_callback' => 'choice_b_callback',
) ) );

And its callback:

function choice_b_callback( $control ) {
	if ( $control->manager->get_setting('demo_radio_control')->value() == 'b' ) {
		return true;
	} else {
		return false;
	}
}

panel1-b
Now, note that the callbacks are very similar. Seems like repeated code, doesn’t it? Well, it is, but remember that the $control here is the whole WP_Customize_Control object. We can use the same callback and simply check which control is calling it here instead.

function choice_callback( $control ) {
	$radio_setting = $control->manager->get_setting('demo_radio_control')->value();
	$control_id = $control->id;
	
	if ( $control_id == 'choice_a_text'  && $radio_setting == 'a' ) return true;
	if ( $control_id == 'choice_b_color' && $radio_setting == 'b' ) return true;
	
	return false;
}

So, instead of using two different callbacks, we just point our controls to this callback, which figures out what should show up for which setting. I’m sure you can simplify this further, depending on your particular needs.

One more thing: Customizing the Customizer

Not everybody likes the style of the Customizer. Maybe it clashes with your theme. Maybe you just want to tweak it a bit. Maybe you dislike that gray background color, and a more soothing blue would go better for your theme.

add_action( 'customize_controls_enqueue_scripts', 'themedemo_customizer_style');
function themedemo_customizer_style() {
	wp_add_inline_style( 'customize-controls', '.wp-full-overlay-sidebar { background: #abcdef }');
}

Or maybe you don’t think the Customizer area is wide enough… be careful with this one though, consider mobile users as well.

add_action( 'customize_controls_enqueue_scripts', 'themedemo_customizer_style');
function themedemo_customizer_style() {
	wp_add_inline_style( 'customize-controls', '.wp-full-overlay-sidebar { width: 400px } .wp-full-overlay.expanded { margin-left: 400px } ');
}

You can enqueue whole extra CSS files instead, if you like. Or, if you have special needs for javascript in some of your controls, and there’s libraries necessary to implement them, then you can enqueue those libraries here as well.

 

More Internationalization Fun


So in my last post about Internationalization, I covered some non-obvious things that you should consider when adding translation capabilities to your code.

Today, let’s add to that by covering some non-obvious translation functions. You’re probably not using these, since they don’t get talked about as much. But there’s probably places where you should be using them, so knowing about them is the first step. And knowing is half the battle.

Basic functions, again

Last time I talked about these functions:

  • __()
  • _e()
  • _x()
  • _ex()
  • _n()

Let’s cover the ones I didn’t talk about.

Escaping output

In practice, you tend to use these mostly when outputting things onto the main page or in the admin. But, one thing you also use a lot when outputting text is the standard escaping functions. These are things like esc_html(), which outputs text in a way that makes it “safe” to go onto a webpage, without being interpreted as HTML. If the text comes from user input, then this is a good idea.

Now, if you think about it, then the text you have may be translated in some other file, which you don’t control either. So escaping that text might be a good idea too. If somebody snuck bad code into a translation file, a user might get bad things displayed without being able to easily find it.

So you could write something like echo esc_html(__('text','text-domain')), but that’s a bit wordy. Let’s talk about some shortcuts.

The esc_html__() function is the equivalent of esc_html(__(...)). It does the escaped html and the double-underscore translation all in one go. Similarly, the esc_html_e() function does the same thing, but it echoes the result, just like the _e() function would. And there’s also esc_html_x(), which is the equivalent of combining esc_html() and _x().

Along with those three are the three identical equivalents for attributes: esc_attr__(), esc_attr_e(), and esc_attr_x(). As the name implies, these combine the translation functions with esc_attr(), which is the escape function specifically intended when you’re outputting text into html attributes.

Also note there’s no shortcut for the equivalent of _ex(). It’s just not used that much, or at least not enough to need something special for it. Use an echo esc_html_x() instead.

There are no shortcuts for the other escaping functions as yet, but these can save a few keystrokes and make your code that much more readable.

The Numerical No-op

So we’ve got some shortcuts for escaping with those three functions, but where’s the love for _n()?

One of the problems with _n() is that it tends to require the strings to be in the same place that the PHP variable is. For all the other functions, you could have a big file of strings in an array, and then reference those strings by name or something elsewhere because they don’t require any PHP variables. Nothing about them is computed at the time of the output.

But not so with _n(), that $number to decide which string to use means that the strings have to be right there, they can’t be translated separately and referenced.

This is where _n_noop() comes in. The _n_noop() function basically takes the singular and plural strings for something, along with the text domain, and stores them in an array so that they can be referenced later by a function named translate_nooped_plural().

Perhaps an example is in order. Let’s go back to the tacos:

$string = sprintf( _n('You have %d taco.', 'You have %d tacos.', $number, 'plugin-domain'), $number );

What if we wanted those strings somewhere else? Like in a big file with all of our strings. Here’s a way to separate the strings from the _n() call:

$taco_plural = _n_noop('You have %d taco.', 'You have %d tacos.', 'plugin-domain');
$string = sprintf( translate_nooped_plural( $taco_plural, $number) , $number );

Now, that $taco_plural can be defined anywhere. Note that it contains no references to PHP variables. It’s basically static and unchanging. This allows us to separate it, then reference it elsewhere for the actual translation. The translate_nooped_plural() function performs the same job as _n() does, choosing which string to use based on the $number of tacos. The sprintf then pushes the $number into the chosen string, replacing the %d with the number.

Thus, that lets us extract the translatable strings out and put them anywhere we choose.

Also of note: The _nx_noop() function is a cross between _n_noop() and _x(). It takes a context for the translators as the third argument, and the domain becomes the fourth argument. Useful if you need to explain to the translators the context surrounding the pluralization choice.

Numbers and Dates

The number_format_i18n() function is functionally equivalent to the PHP number_format function. It lets you format numbers with commas at the thousands mark and so forth, except that it also takes localization into account. Not everybody uses commas for thousands and periods for decimals. This function will do the translation appropriately for that aspect.

The date_i18n() function is functionally equivalent to the PHP date function. It will handle all the same string formatting parameters as date() will, but it will cause output to be translated for month names, day-of-week names, and so forth. Of note is that it doesn’t change the format requested. If some places put days before months, for example, it won’t handle that. But it will output the month name in the native language (if the translation pack has the right month name in it). So you may want to run the date formatting string through __() as well, to let translators adjust the date format accordingly.

Wrap up

And that’s pretty much all the rest of the translation functions that I didn’t cover before. I may have forgotten a few useful ones here or there. Feel free to comment about anything I missed, or what you see most often, especially if you’re doing translations yourself.

Are You Ready for WordPress 3.2?

WordPress 3.2 is going to be released very soon, and we want you to be ready! Take note: the minimum requirements are changing.

PHP and MySQL

As of 3.2, you’ll need to be running PHP 5.2.4 and MySQL 5.0. As we mentioned almost a year ago when we announced that this change was coming, the percentage of people running older versions of PHP and MySQL is relatively low. With more than 45 million people using WordPress, though, even a small percentage can mean a lot of people! Don’t caught with your pants dashboard down — make sure you’re running compatible versions of PHP and MySQL before you update tomorrow when WordPress 3.2 is released.

Log in to your hosting account, and check to make sure you have at least  PHP 5.2.4 and MySQL 5.0. Most of the major hosts already default to these or newer versions, but there are some exceptions. Check to see which versions you are running, and if you’re still on an older version, it should be as simple as changing a dropdown menu and clicking Save to get up to date.

If you don’t know how to find this information in your hosting account or you don’t even know how to access your hosting control panel because someone else manages that for you, don’t fret. You can find out if you’re ready for 3.2 with the Health Check plugin. In your dashboard, go to Plugins → Add New and search for “health check” (it should be the first result). Install it, activate it, and it will tell you if you need to update anything.

If you need more help, contact your host’s customer service and use this email template to ask them to help you.

Hi there. I host my domain [example.com] with you, and I run WordPress on my site. The minimum requirements are changing to PHP 5.2.4 and MySQL 5.0, and I would appreciate your help in confirming that my site’s setup meets these requirements. If I’m currently running an older version of PHP or MySQL, could you update it for me, or tell me how to do it? Thanks so much!

If your host replies that they can’t update to these versions, it might be time to look for a new host.

IE6 and Outdated Browsers

With 3.2, we’re also dropping support for Internet Explorer 6, a 10-years-old outdated browser that even Microsoft is ready to leave behind. From now on, if you access your WordPress dashboard from an outdated browser, we’ll let you know. Why? Because as web technology improves, so does WordPress, as we build features to take advantage of these improvements. If you’re using an out-of-date browser, chances are you’re missing out.

If your browser is out of date, you’ll see a friendly orangey-yellow box in your dashboard letting you know you a newer version is available (which you can dismiss, of course). If you’re using IE6, though, the box will be red, and your dashboard will not function properly. If you’re stuck on IE6 because the computer you use is maintained by a business, library, school, or the like, and you are not able to download a newer browser, here’s a sample email you can use to ask your boss/administrator/IT guys to update the browser.

Hi there. The computer I use at [where you use the computer] is equipped with an out-of-date web browser. Internet Explorer 6 was created 10 years ago, before modern web standards, and does not support modern web applications. More and more sites and applications are dropping support for IE6, including the new version of WordPress. Even Microsoft, the makers of IE6, are counting down until IE6 goes the way of the dinosaur (see http://www.ie6countdown.com/ for more information). Can you please install an updated version of IE or any modern browser (see http://browsehappy.com for more information) on the available computers? Thank you very much.

Welcome to the future!