On one of the websites I am administrating, posts are assigned two kinds of categories:

• the age of children
• for boys or for girls

In the navigation menu, you need to be able to select menu items corresponding to the following types of criteria:

• Display all posts for boys or all posts for girls
• Display all posts for children in a specific age category
• Display all posts for boys in a specific age category or for girls in a specific age category

The first two requirements are easy. You just need to add the corresponding category archives to the menu. For the last one, there is no way to select a combination of categories in the WordPress menu builder.

So you need to add links to the menu and point to the results of a query for a combination of categories. Fortunately, you do not need to write any code to have such a list of post displayed. This can all be done by providing the appropriate parameters in the URL e.g.:

http://mysite.com/?cat=for-boys,6-12-months

for-boys and 6-12-months are the slugs of the corresponding categories.

If you have pretty URLs, it’d look like this:

http://mysite.com/category/for-boys,6-12-months

This will show you posts belonging to either category. What we actually want are posts belonging to both categories. In order to get this result, you need to replace the comma by a plus sign:

http://mysite.com/?cat=for-boys+6-12-months

If you have pretty URLs, it’d look like this:

http://mysite.com/category/for-boys+6-12-months

Instead of “category” you can use “tag” for post tags or “author” for post authors.

WordPress multisite has been aroung for quite some time now. But since many users still have a single-site installation and it’s not so easy to install WP Multisite using alternative ports (see this post), you will see that first not all plugins behave well in a multisite environment. Second, if you have a problem and google for it you will most likely find solutions working on single site installations but it’s not always to find out whether it will work in a multisite environment and if not, how to modify it to work in such an environment.

That’s the reason why I’ve started writing this post. First, I am a plugin author and need to have my plugins work in a multisite environment. Second, I am considering moving from multiple single sites to a multisite installation myself.

What’s WordPress Multisite?

WordPress Multisite was introduced in WordPress 3.0. It basically allows you to host multiple sites in a single WordPress installation. This means that once your WordPress installation is converted to multisite, it becomes a network of sites, with one central site used to administrate the network and a series of virtual sites building up your network.

The sites in this network are then not completely independent of another. They share some features. But they also have their own data and settings. So it is important to understand what’s shared and what not.

Just before we really start: in the WordPress multi-user solution which was available before Multisite was introduced in WordPress 3.0 the wording was a little bit different. That why I tend to sometimes mix it all. I’ll try to stick to the WP 3.0 wording but can’t promise I’ll always manage to do it.

What used to be called a Blog before WP 3.0 is now a site.
What used to be called a site before WP 3.0 is now a network.

What’s different with WordPress Multisite?

There are a few differences between a multisite based network of sites and a network of individual WordPress installations. Except for the WordPress PHP scripts themselves, a WordPress installation is basically made of some database content and the contents of the wp-content subdirectory.

wp-content

Let’s start with wp-content. It contains your plugins, themes and uploads (in three different directories).

Plugins

The plugins are installed for the whole network. Since you cannot install plugins per sites, there is no difference difference in the directory structure.

Note that this doesn’t mean that when you install a plugin it has to be active on all sites in the network. But it does mean that if a plugin is not installed globally, a site administrator cannot install this plugin just for a single site.

It also means that when a plugin is updated, it’s updated for all sites in the network. This is a good thing since you do not have to update each plugin for each site individually. On the other side, if you know that one site has a problem with the new version of a plugin and another site needs the new version, there is no way to handle this in a WordPress Multisite installation.

But even though the installation files are the same for all sites in the network give a specific plugin, this doesn’t mean that the settings of this plugins have to be the same for all sites. Depending on the plugin, you may want to have a site specific configuration or a network-wide configuration. See this post to learn more about network-wide plugin settings.

Also since the plugin files are available globally, this means that as a plugin developer, you do not need to take care of Multisite installations when enqueuing files (JavaScript or CSS files).

Themes

Themes work the same way as plugins in this case. Themes are installed globally and a user administrating a site in the network can activate these themes for his site. You can also restrict themes for individual sites and make them only available to a subset of the sites.

When working with themes and Multisite, it is important to keep in mind that whenever you update a file of the theme, you’re not modifying the file for one site but for all sites using this theme. So if you use a theme and would like to change a few things e.g. some CSS, instead of modifying the theme itself, you should do one of the following:

• Create child theme to use in the individual sites
• If it is already a child theme, you should create a copy of the theme before modifying it. The drawback is that you will not get automatic updates from wordpress.org anymore since it’s not the original theme anymore
• Use themes which provide you with means to make the adaptations you need in their settings
• If all you want to change are CSS styles, there are also plugins allowing you to load some additional styles

Uploads

The uploads work in a different way. Unlike the plugins and themes, upload can either be available on the network level or for a specific site.

So under the uploads directory, you will find one subfolder per year for the network-level uploads and a “sites” subdirectory. The “sites” subdirectory contains in turn one subdirectory per site. The names of this subdirectory are numbers representing the site ID. And in these sites subdirectories, you will again find a subdirectory per year.

The database

First of all, even in a Multisite installation, all tables, whether central tables or tables for individual sites in the network, are stored in a single MySQL database.

Assuming you chose the prefix “wp_” when installing WordPress, all central tables will be called wp_something and the site specific tables will be called wp_X_something, where X is the site ID.

The central site of your network will contain all tables you’d normally see in a single site WordPress installation. The individual sites in the network will only have a subset of these tables, containing the data which are stored per site:

• wp_X_comments and wp_X_commentmeta contain data related to comments
• wp_X_posts and wp_X_postmeta contain data related to posts
• wp_X_terms, wp_X_term_relationships and wp_X_term_taxonomy contain data related to terms and taxonomies
• wp_X_links contains site specific links
• wp_X_options contains sites specific settings and options

wp_X_options also includes data about plugins and themes available on individual sites.

As said before, the central site also has all these tables. Additionally, it also has a few more database tables:

• wp_blogs contains a list of all sites in the network. It’s still called “blogs” as in the old wording.
• wp_blog_versions contains the db version of each site. I guess you usually don’t care about this table.
• wp_users contains all users in the network
• wp_usermeta contains data related to the users in wp_users
• wp_registration_log contains a list of which users are registered on which site and when they registered
• wp_signups contains a list of users which signed up on you network along with the activation key and when/whether they were activated
• wp_site contains a list of networks and their primary domain. So you could have WordPress installation with multiple networks with each network having multiple sites
• wp_sitemeta contains additional information about the networks

Handling WordPress Multisite in your code

First of all, most WordPress functions you might be using are related to the current site. So when you get e.g. a list of categories using get_categories(), you will see only the categories for this one site. If you need to get e.g. the categories for all sites, it will require some extra work.

There are 5 functions which are relevant for such things:

• get_current_site()
• switch_to_blog()
• restore_current_blog()
• wp_get_sites()

get_current_site

This function returns a site object containing the following public variables:

• id: this is the site ID (number)
• domain: this is the domain name of the current site
• path: this is the URL path of the current site
• site_name: this is the name of the current site

You can also get the ID of the current site using get_current_blog_id().

switch_to_blog

This function takes a site ID as parameter. If the provided site ID doesn’t exist, it will return false.

Once you’re done doing whatever you need to do with this other site, you can get back to the original site using restore_current_blog().

restore_current_blog

You should call restore_current_blog() after every call to switch_to_blog(). The reason is that WordPress keeps track of site switches and if you do not use restore_current_blog, the global variable $GLOBALS[‘_wp_switched_stack’] will be left with some values in there.

An alternative is to clean up $GLOBALS[‘_wp_switched_stack’] yourself:

$GLOBALS['_wp_switched_stack'] = array();
$GLOBALS['switched'] = false;

wp_get_sites

This function returns an array with the list of all sites in the network. You can use this function to get a list of all sites and iterate through them (and switching from one blog to the next one using switch_to_blog()).

Iterating through sites

In order to iterate through sites e.g. in order to get all categories for all sites, you can do the following:

// store the original current site
$original_site = get_original_site();

// get all sites
$sites = wp_get_sites();

// loop through the sites
foreach ( $sites as $site ) {

	// switch to this one site
	switch_to_blog( $site['blog_id'] );

	// do something here

}

// return to the original site
switch_to_blog( $original_site->id );

Note that by doing this, the global variables tracking the site switches will not be reset. So it is recommended to rather do:

// get all sites
$sites = wp_get_sites();

// loop through the sites
foreach ( $sites as $site ) {

	// switch to this one site
	switch_to_blog( $site['blog_id'] );

	// do something here

	// restore the original site
	restore_current_blog();
}

Or something like this:

// store the original current site
$original_site = get_original_site();

// get all sites
$sites = wp_get_sites();

// loop through the sites
foreach ( $sites as $site ) {

	// switch to this one site
	switch_to_blog( $site['blog_id'] );

	// do something here

}

// return to the original site
switch_to_blog( $original_site->id );

// manually reset the global variables tracking site switching
unset ( $GLOBALS['_wp_switched_stack'] );
$GLOBALS['switched'] = false; 

 TO BE CONTINUED…

Since I’m maintaining a few WordPress plugins I wanted to have a local installation where I can also make sure that new versions of the plugins also behave well in a multisite environment (site network). Unfortunately, I cannot use ports 80 and 443 since I need them for some other projects I’m working on (using IIS). So my local apache server runs on ports 8080 (http) and 8443 (https).

The problem is that this is not supported by WordPress. You need to run on ports 80 and/or 443. Otherwise WordPress won’t let you create a site network and you’ll get a message saying:

You cannot install a network of sites with your server address.
You cannot use port numbers such as 8080.

A single site installation of WordPress works fine on port 8080 but for some reason, it isn’t support for WordPres Site Networks… Well, that’s not a reason not to use it 🙂

Since it’s all PHP, you can easily just fix it. Of course, you need to keep in mind that any update of WordPress might remove the changes and you’ll need to do it all again. But since it’s just a test installation, it’s not a problem for me.

So, to find out how to fix it, we first need to find out where this message is displayed. Using grep, you can quickly find that it comes from the function network_step1 in wp-admin\network.php. The relevant piece of code looks like this:

if ( ( false !== $has_ports && ! in_array( $has_ports, array( ':80', ':443' ) ) ) ) {
	echo '<div class="error"><p><strong>' . __( 'ERROR:') . '</strong> ' . __( 'You cannot install a network of sites with your server address.' ) . '</p></div>';
	echo '<p>' . sprintf( __( 'You cannot use port numbers such as <code>%s</code>.' ), $has_ports ) . '</p>';
	echo '<a href="' . esc_url( admin_url() ) . '">' . __( 'Return to Dashboard' ) . '</a>';
	echo '</div>';
	include( ABSPATH . 'wp-admin/admin-footer.php' );
	die();
}

If you use an extra :80 or :443, WordPress will not complain but it will if it is another port number. So in order not to get this error message, you just need to add the ports you need to the list, replacing:

if ( ( false !== $has_ports && ! in_array( $has_ports, array( ':80', ':443' ) ) ) ) {

by:

if ( ( false !== $has_ports && ! in_array( $has_ports, array( ':80', ':443', ':8080', ':8443' ) ) ) ) {

Of course, I assumed there was a reason why only ports 80 and 443 were supported. So I searched in the code for 80 and 443 and found this in wp-includes\ms-settings.php:

if ( substr( $domain, -3 ) == ':80' ) {
	$domain = substr( $domain, 0, -3 );
	$_SERVER['HTTP_HOST'] = substr( $_SERVER['HTTP_HOST'], 0, -3 );
} elseif ( substr( $domain, -4 ) == ':443' ) {
	$domain = substr( $domain, 0, -4 );
	$_SERVER['HTTP_HOST'] = substr( $_SERVER['HTTP_HOST'], 0, -4 );
}

In a previous version of this post I was adding some code for ports 8080 and 8443 but I realized it was actually making things worse. The only purpose of this piece of code is to remove unnecessary port numbers which are not relevant for comparing domain names. But ports 8080 and 8443 are relevant (https://benohead.com:8443 doesn’t point to the same web server as https://benohead.com, but https://benohead.com:443 does).

With the changes above I could create the site network. But when I tried to login, I was redirected to the IIS, to http://localhost/wordpress/wp-login.php instead of http://localhost:8080/wordpress/wp-login.php. Since I couldn’t find anything in code which would explain this, I had a look at the wp_options. And saw that the siteurl option contained http://localhost/wordpress/ instead of http://localhost:8080/wordpress/. So I just updated it in MySQL using the following SQL statement:

UPDATE `my_wordpress_db`.`wp_options` SET `option_value` = 'http://localhost:8080/wordpress/' WHERE `wp_options`.`option_name` = 'siteurl';

And tried again. And this time I got to the right login page ! Remember to replace “my_wordpress_db” by the name of your WordPress database.

I then noticed that there were still some links pointing to http://localhost/wordpress. Finally I saw that the “home” option in wp_options was still pointing to the wrong URL. After fixing it, everything looked fine:

UPDATE `my_wordpress_db`.`wp_options` SET `option_value` = 'http://127.0.0.1:8080/wordpress/' WHERE `wp_options`.`option_name` = 'home';

So now everything was working fine, the admin page, the blog post/pages. But then I realized that when creating a new site, I saw “localhost:8080” in the UI but it was saving localhost8080 instead. So something was removing the colon. And I found the following in the function wpmu_create_blog in wp-includes\ms-functions.php:

$domain = preg_replace( '/\s+/', '', sanitize_user( $domain, true ) );

With the second parameter is true, only alphanumeric characters plus these: _, space, ., -, *, and @ are returned. Of course, one solution would be to add colon to the list but then it would allow usernames to contain colons as well. So I ended up just setting the second parameter to false, or rather commenting it out, since false is the default:

$domain = preg_replace( '/\s+/', '', sanitize_user( $domain/*, true*/ ) );

Now everything seems to be working.

While looking for a solution, I did find a few links explaining how to do it in version prior to WordPress 3.7. But I needed it for WordPress 3.9.1. So I had to find a solution by myself. Of course I have only tested it on WP 3.9.1 and haven’t checked when was last time these pieces of code were changed. So it might work on WP 3.7 and WP 3.8 as well but I cannot guarantee anything.

When activating the Jetpack module called Jetpack Comments, you will see the following banner after activation:

This actually clearly states how to disable it. But for some reason it took me a long time to find it, so I thought I’d write a post about it.

As stated in the banner, you need to go to the Jetpack modules page and click on “Learn More”:

The “Deactivate” option will then be displayed:

The reason I couldn’t find it for a while is that a new area called “Jetpack Comments” is made visible and I was thus only looking at this area. But the “Deactivate” button is shown next to the “Learn More” button:

Just click on this button and Jetpack Comments will be deactivated.

By the way, after activating this module, there were absolutely no change on my site. So that’s the reason I deactivated it again. I just didn’t feel like trying to find out why it didn’t work…

When checking your site with PageSpeed Insights, you might get the following finding:

Remove query strings from static resources

Enabling public caching in the HTTP headers for static resources allows the browser to download resources from a nearby proxy server rather than from a remote origin server.

Suggestions for this page

Resources with a “?” in the URL are not cached by some proxy caching servers. Remove the query string and encode the parameters into the URL.

It will report the finding for CSS or JavaScript files referenced with a specific version number in your site e.g.:

http://spielsachenweb.de/wp-content/plugins/google-analyticator/external-tracking.min.js?ver=6.4.3

In many cases, you will see that the version number is not required as you actually only have one version available at that location and you’d get exactly the same file with or without the version number. But the version specification as a parameter does have a negative impact on caching on proxy servers (especially old Squid proxies). That’s why PageSpeed Insights recommends dropping the version specification from the URL.

If you have written the <script> or <link> tag directly in some template files, you can just delete the part starting from the question mark (?). But most probably it will come from themes or plugins you use.

1. The first step is to check whether you really do need the version number or not. You can do this by copying the URL from the PageSpeed Insights report and open it in a browser. Do it twice, once with the version number and once without. Copy each of them and compare them (e.g. using WinMerge). If you see no difference, then you’re safe removing the version number.

2. Once you’re done with the step above. You have a list of files which can do without the version number and a list of those which cannot. Now you can add a very simple function in functions.php in your current theme (in the theme editor) to remove the parameters for specific URLs:

function remove_style_and_script_version($url) {
	$url_to_fix = array('http://spielsachenweb.de/wp-content/plugins/google-analyticator/external-tracking.min.js?ver=6.4.3',
					    'http://spielsachenweb.de/wp-includes/js/jquery/jquery.js?ver=1.8.3');

	if (in_array($url, $url_to_fix)) {
		//if it is one of the URLs to process, remove everything after the question mark
		$parts = explode('?', $url);
		return $parts[0];
	}
	//otherwise return the URL as is
	return $url;
}
add_filter('script_loader_src', 'remove_style_and_script_version', 20, 1);
add_filter('style_loader_src', 'remove_style_and_script_version', 20, 1);

Note that the two last parameters of the add_filter calls (20, 1) mean that the new function should be called with priority 20 (default is 10) and will thus happen after all other filters on the script or style loader which have a priority of less than 20 (so including the ones using the default priority).

Also note that this trick only works if the scripts and styles are loaded using the WordPress enqueueing mechanism, which is almost always the case.

Now if you want to do it the other way around and strip the part after the question mark for all script and style URLs except for the ones for which you known you’d get the wrong file, you can do the following instead:

function remove_style_and_script_version($url) {
	$url_not_to_fix = array('http://spielsachenweb.de/wp-content/plugins/google-analyticator/external-tracking.min.js?ver=6.4.3',
					    'http://spielsachenweb.de/wp-includes/js/jquery/jquery.js?ver=1.8.3');

	if (in_array($url, $url_to_fix)) {
		//if it is one of the URLs to exclude, return the URL as is
		return $url;
	}
	//otherwise, remove everything after the question mark
	$parts = explode('?', $url);
	return $parts[0];
}
add_filter('script_loader_src', 'remove_style_and_script_version', 20, 1);
add_filter('style_loader_src', 'remove_style_and_script_version', 20, 1);

If you just want to remove everything after the question mark for all script and style URLs:

function remove_style_and_script_version($url) {
	$parts = explode('?', $url);
	return $parts[0];
}
add_filter('script_loader_src', 'remove_style_and_script_version', 20, 1);
add_filter('style_loader_src', 'remove_style_and_script_version', 20, 1);

Note that you might also get parameters added to the URL of scripts and styles when using W3 Total Cache. Please have a look at this post in this case.

There is also an additional special case. If you only want to remove the script or style URLs called with the WordPress version number e.g. because it shows which version you use and if it’s an older one, it might give away some information which can be used by a hacker (although the best solution in this case would be to upgrade to the latest version), you can specifically process only these URLs:

function remove_style_and_script_version($url) {
	global $wp_version;
	return str_replace("?ver=$wp_version", '', $url);
}
add_filter('script_loader_src', 'remove_style_and_script_version', 20, 1);
add_filter('style_loader_src', 'remove_style_and_script_version', 20, 1);

Or you can show a different version:

function remove_style_and_script_version($url) {
	global $wp_version;
	return str_replace("?ver=$wp_version", '?ver=X.XX', $url);
}
add_filter('script_loader_src', 'remove_style_and_script_version', 20, 1);
add_filter('style_loader_src', 'remove_style_and_script_version', 20, 1);

Replace X.XX by the version you want to show.