The function can be expanded, for example, with queries on rights of the logged users or various other requirements.

In the first snippet the output on the frontend is always filtered, only your backend is_admin() and your feed is_feed() keeps untouched. The filter is placed in the example at 15 minutes and these are aligned with the setting of WordPress, so that the time zone will be considered. The 15 minutes will be converted into seconds and subtracted from the value.

<code>
function publish_later_on_frontend( $where ) {

	if ( is_admin() || is_preview() || is_feed() )
		return $where;

	$offset =  15; // minutes
	$offset = ( get_option( 'gmt_offset' ) * 3600 ) - ( $offset * 60 ); // gmt offset of WP options minus custom time
	$where .= " AND post_date < '" . gmdate( 'Y-m-d H:i:s', ( time() + $offset ) ) . "'";

	return $where;
}
add_filter( 'posts_where', 'publish_later_on_frontend' );
</code>

Another brief example will allow all users logged, with minimum rights to read current_user_can('read') - so subscribers, to read the contents. All other visitors will get the content presented 10 days later.

<code>
function publish_later_on_frontend( $where ) {

	if ( is_admin() || is_preview() || is_feed() || current_user_can('read') )
		return $where;

	$offset =  10; // days
	$offset = ( get_option( 'gmt_offset' ) * 3600 ) - ( $offset * 24 * 60 * 60 ); // gmt offset of WP options minus custom time
	$where .= " AND post_date < '" . gmdate( 'Y-m-d H:i:s', ( time() + $offset ) ) . "'";

	return $where;
}
add_filter( 'posts_where', 'publish_later_on_frontend' );
</code>

Alternatives with SQL-Statement:

// with INTERVAL
$where .= " AND post_date < NOW() - INTERVAL 5 MINUTE"; // DAY, HOUR

// with strtotime()
$where .= " AND post_date < FROM_UNIXTIME(" . strtotime("-5 day"). ")";

Well - any other ideas? Then let us know in our comment area. I'm happy to see any improvements to the code, especially in the area of calculation with time.

WordPress 2.9 will have the possibility to update all your Plugins, which have an update available, in one step.
That makes maintenance work with customer's and on your own blog more simple and faster. As a little insight, here is a screenshot of the current beta.

Users reporting me, that they are missing files, after they automatically updated to WordPress version 2.8 and there were a problem while updating. I checked out the WordPress Trac and found a brand new record, which confirms this: Trac ticket # 10140

What happened and what are the conditions?

On one hand, the upgrade process has to be so far that the files were downloaded and unpacked. If anything goes wrong after these steps (wrong write permissions, etc.), the upgrade process makes a rollback and usually clears the downloaded files without any problems.

So much for theory. The practice shows, however, in exactly this case, because of a bug, previous existing installation files accidentally get deleted too, so the blog will no longer work!

What to do if already happened?

The best thing to do is to upload the old version completely via FTP. If the files are no longer available, you may download the old version from the archives of WordPress.org.
You should also verify if the wp-config.php needs to be adjusted, because this may also be deleted.

What lesson did we learn?

It’s not just a phrase, when we repeatedly emphasize, before you upgrade:

1. Create a current backup of the database
2. Create a current backup of all files on your web server.

As convenient as an automatic update can be, there is always a risk. If the web server is configured properly and is maintained well, there shouldn’t a problem arise. But the most users do not know or want to know if that’s the case. Therefore, the safest way is still to upload the new version via FTP.
Anyone who knows how everything has to be configured, I mean the pros among you, will surely continue to use the automatic upgrade.

What’s next?

This problem will be fixed, according to WordPress Trac entry, with version 2.8.1, and automatic upgrade will work again without any problems. But we think it is very important that the WordPress-Team let the users know about the problem and not just fix it in version 2.8.1 and be quiet about it. It will avoid a lot frustration!

But please don’t forget about your backups again, when you use 2.8.1 or future versions. It’s better “I have” than “if I would have”.

We still hope that you all continue to enjoy WordPress as we do, and we will continue to do our best to contribute you as quickly as possible with new information.

Alternative: use the plugin Secure WordPress, the plugin has inside the function to active this possibility.

/**
 * remove core-Update-Information
 * @rights: http://codex.wordpress.org/Roles_and_Capabilities
 */
if ( !current_user_can( 'edit_plugins' ) ) {
	// core update
	add_action( 'init', create_function( '$a', "remove_action( 'init', 'wp_version_check' );" ) );
	add_filter( 'pre_option_update_core', create_function( '$a', "return null;" ) );
	// plugin update
	add_action( 'admin_menu', create_function( '$a', "remove_action( 'load-plugins.php', 'wp_update_plugins' );" ) );
	add_action( 'admin_init', create_function( '$a', "remove_action( 'admin_init', 'wp_update_plugins' );" ), 2 );
	add_action( 'init', create_function( '$a', "remove_action( 'init', 'wp_update_plugins' );" ), 2 );
	add_filter( 'pre_option_update_plugins', create_function( '$a', "return null;" ) );
}

It is very popular and an easy process, but I like to upload the newest version via my FTP client. How sure is the use of your FTP login information in your WordPress Admin? If you like to use another way, you can just put a definition of constants in your wp-config.php.

define('FTP_HOST', 'ftp://example.de/');
define('FTP_USER', 'example_username');
define('FTP_PASS', 'example_passwort');
define('FTP_SSL', false); //TRUE for SLL-connection

Otherwise you will have the data after the first use in table options, in field ftp_credentials. If you don't want to use them, you can delete them directly. That's possible either via mySQL-Tool, like phpMyAdmin, or in WordPress, if you open the preferences in table options, just use the admin address of your blog and add options.php (Bsp.: http://example.com/wp-admin/options.php).

You already know the update function for Plugins, which is very convenient. Now the same for your WordPress installation, one click and you are up to date.

Such a powerful and important function comes along with some questions and doubts of course.

WordPress 2.7 Core Update

It's your own decision if you want to trust this function, but it's more secure than the automatic update for Plugins, since the Plugins are provided by different authors without control by the WordPress team. The process of the automatic WordPress update is well thought out, which I will explain, so you can get a better picture of it and it makes your decision easier for you if you want to use it or you still update manually.

• Your installation sends version and localization to http://api.wordpress.org/core/version-check/1.2/ and proofs if there is a newer version available. If there is a newer version, it sends back an address to the new available version. It also sends it in the correct language of your current installation. But right now, there is only the English version.
• If there is a newer version, the files will be downloaded in system-temp.
• Afterwards it creates a folder wp-content/upgrade/core
• Now the file wp-admin/includes/update-core.php will be copied from the new download package into the current installation.
• This new file will be used to start the function update_core().
• The new version will be proved.
• A file will be created in root for the maintain modus (.maintenance file). The file wp-settings.php checks that and avoid any access if this file exists. The visitor will just see a simple HTML page with a short message:
  

  Briefly unavailable for scheduled maintenance. Check back in a minute.

• Because of this maintain modus no one can access any files and now all files are getting copied from the installation package to the current installation.
• All unneeded files are going to be deleted.
• ugrade.php contains the information, that the database can be upgraded now. You have to confirm the database update, so it is only possible after all new files are copied to the current installation.
• wp-content/upgrade/core will be deleted after a successful update.
• The same with .maintenance.
• After that the frontend is available again and all upgrade steps are listed in your admin area. Where you can see where a problem occurred if your upgrade wasn't successful.

WordPress 2.7 Core Update

This function amazed by it's simplicity, click, lean back and relax - done!
It's still in Beta and I'm sure many people will talk about the functionality, but that was a popular desire of the WordPress community. Will see if the endless discussion about the upgrade cycles will end or still continue.

Alternative you can still download the current version and install manually like always . Additional WordPress has to offer an own backup system. This saves the use of other Plugins and an upgrade including a backup is fast and simple. The backup creates a XML-File in WordPress format (WordPress WXR), which you can easily import again. It was greatly appreciated in WP-Hacker forum that you can find this function under tools.