Prevent Update Checks for a WordPress Plugin

Earlier today, Jason Gegere asked me how to prevent WordPress from checking for updates on a plugin. This may be helpful if you are running a custom version of a plugin from the repository and you don’t want to accidently update the plugin and lose the customizations, or if you are running a private plugin and don’t want WordPress to check for updates from the plugin repository. WordPress doesn’t know if your plugin is in the WordPress plugins repository and it will request the update check on all installed plugins.

WordPress checks for updates using wp_update_plugins() in wp-includes/update.php but there are no hooks in this function which could be used to exclude your plugin from the update check. However, you can hook into http_request_args and remove your plugin from the query arguments passed in the http request. You can add the following code to your plugin to prevent WordPress from checking for updates for your plugin:

add_filter( 'http_request_args', 'dm_prevent_update_check', 10, 2 );
function dm_prevent_update_check( $r, $url ) {
	if ( 0 === strpos( $url, 'http://api.wordpress.org/plugins/update-check/' ) ) {
		$my_plugin = plugin_basename( __FILE__ );
		$plugins = unserialize( $r['body']['plugins'] );
		unset( $plugins->plugins[$my_plugin] );
		unset( $plugins->active[array_search( $my_plugin, $plugins->active )] );
		$r['body']['plugins'] = serialize( $plugins );
	}
	return $r;
}

WordPress 3.0 Release Candidate 3

The third release candidate (RC3) for WordPress 3.0 is now available. This will most likely be the last release candidate before WordPress 3.0 is released at some point next week. So if you are the adventurous kind and would like to contribute to WordPress, then download the release candidate here and provide your feedback.

What’s an RC? An RC comes after beta and before the final launch. It means we think we’ve got everything done: all features finished, all bugs squashed, and all potential issues addressed. But, then, with over 20 million people using WordPress with a wide variety of configurations and hosting setups, it’s entirely possible that we’ve missed something.

Download WordPress 3.0 Release Candidate 3

WordCamp Chicago

I’m speaking at WordCamp Chicago this weekend at the Chicago Mart Plaza. My session is titled Beginners Plugin Development and it will be an introduction to writing a WordPress plugin. WordCamp ChicagoYou can attend my session on Sunday, June 6th at 11:30am 11:15am in the Developers Track.

WordCamp Chicago has an exciting line-up of speakers and I’m looking forward to meeting with Chicagoland WordPress people and reconnecting with some folks I met at WordCamp San Francisco. WordCamps are all about networking, so make it a plan to attend all the parties and hit me up if you see me.

How to Tweak the WordPress Generator Meta Tag

WordPress adds a generator meta tag to the head element of every page that includes the version of WordPress you are using. Many people have debated the need for this and recommend removing it especially if you haven’t been upgrading WordPress regularly. A crawler can easily scan this info and look for sites that are running an older version of WordPress with a known exploit. You can add the following code to your theme’s function.php file or in a plugin.

Tweak the WordPress Generator Meta Tag

The following code will remove the version number from the meta tag:

function devmnd_tweak_generator( $generator ) {
        return str_replace( ' ' . get_bloginfo( 'version' ), '', $generator );
}
add_filter( 'the_generator', 'devmnd_tweak_generator' );

Before: <meta name="generator" content="WordPress 3.0-RC1-15112" />
After: <meta name="generator" content="WordPress" />

You can even add your own custom version number in the generator meta tag:

return str_replace( get_bloginfo( 'version' ), '4.0', $generator );

Remove the WordPress Generator Meta Tag:

if ( function_exists( 'wp_generator' ) ) {
        remove_action( 'wp_head', 'wp_generator' );
}

Enable MultiSite in WordPress 3.0

WordPress 3.0 signals the merge of WordPress and WordPress MU, and allows you to manage a network of sites in WordPress. In this post, I’ll show you how to enable the Network screen and the MultiSite features in WordPress 3.0. You do not need to complete these steps if you are upgrading from WordPress MU. Follow the instructions here to upgrade from WordPress MU. You will need to perform these steps if you are upgrading from a standard pre-3.0 WordPress install and want to use the MultiSite features or on a new WordPress 3.0 install.

Enable Network Menu

Add the following line to wp-config.php:

define( 'WP_ALLOW_MULTISITE', true );

The Network menu under Tools will not show up until you complete this step.

Create a Network
Network Menu in WordPress 3.0

Log in to the WordPress back-end and navigate to the Network screen under Tools. WordPress allows you to choose between sub-domain and sub-directory based installs for your network of sites. You can choose one or the other, but it’s not easy to change later, so you must decide before you proceed.

Sub-domains:

A sub-domain install allows you to have new sites as sub-domains of your WordPress installation. For example, you can have site1.domain.com and site2.domain.com for a WordPress installation at domain.com. You will need to add a wildcard domain alias for your webserver and a wildcard DNS record for your domain. Matt has a detailed explanation about wildcard DNS records and domain alias here.

Sub-directories:

A sub-directory install allows you to have new sites as sub-directories of your WordPress installation. For example, you can have domain.com/site1 and domain.com/site2 for a WordPress installation at domain.com.

Enable Network

Create Media Directory:

Create a blogs.dir directory under wp-content for all uploaded media files for all sites in the network. You must ensure that the new directory has the correct permissions so it is writable by the web-server (apache user).

Update wp-config.php:

Add the following lines to wp-config.php anywhere above /* That’s all, stop editing! Happy blogging. */

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true ); //false for sub-directory install
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'domain.com' ); //replace domain.com with your install
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

Update/Create .htaccess:

Create a file named .htaccess in the root WordPress directory and add the following:

Apache and sub-directory installs:

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# uploaded files
RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule  ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule  ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

Apache and sub-domain installs:

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# uploaded files
RewriteRule ^files/(.+) wp-includes/ms-files.php?file=$1 [L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule . index.php [L]

Replace all WordPress related .htaccess rules with the ones above if the file already exists.

Rewrite Rules for Nginx and sub-directory installs:

  #on server block
  ##necessary if using a multi-site plugin
  server_name_in_redirect off;
  ##necessary if running Nginx behind a reverse-proxy
  port_in_redirect off;

  rewrite ^.*/files/(.*)$ /wp-includes/ms-files.php?file=$1 last;
  if (!-e $request_filename) {
   rewrite ^.+?(/wp-.*) $1 last;
   rewrite ^.+?(/.*\.php)$ $1 last;
   rewrite ^ /index.php last;
  }

Return to the WordPress back-end. You will have to log-in again and now you’ll see a Super Admin menu item. You can manage your network of sites from this menu.