Update July 23rd, 2011: These instructions still work for the newer 3.2.5 version as well. While this simple modification is useful, I plan to switch the to the 4.0 beta.
Update: Arne has posted an early test version on the WordPress support forums here. At this stage it’s not yet ready for release. If you would like to test that version, you can support Arne’s effort by downloading and reporting any issues to him on that thread.
I’m lazy and have not yet tried the early release version. 🙂
——————————————————–
WordPress 3.0’s Multisite feature is cool and useful. The Google (XML) Sitemaps Generator plugin is also cool and useful. Unfortunately Arne Brachhold’s excellent plugin does not work with multisite blogs.
If you activate the plugin on a multisite enabled WordPress install, you get this error message.
Which is a shame, but it did not take me a long time to find a work around. My setup is using multisite with sub-domains and with the Domain Mapping plugin. These instructions are for the 3.2.4 version of the plugin.
1. Modify the plugin
Edit the file wp-content/plugins/google-sitemap-generator/sitemap.php and comment out lines 53 to 58 to look like this
You can delete these lines, but I prefer to comment them out. All this does is prevent the plugin from detecting the multisite setup and not becoming active.
2. Get your rewrite rules ready
In your blog’s .htaccess file add these lines above your WordPress rules
Now on each of your sites in your WordPress network, activate the Google (XML) Sitemap plugin. Do not Network Activate it.
Now got to your XML-Sitemap options page and for “Location of your sitemap file” select Custom location.
In the custom location change your change the file name sitemap.xml to sitemap-yourblogservername.xml. My server name is blog.dembowski.net so I’m using sitemap-blog.dembowski.net.xml. Save the options.
Look in your WordPress installation’s root and check if you have sitemap.xml or sitemap.xml.gz. If you do then delete them both.
Now at the top of that options page, click on “rebuild the sitemap manually” and confirm that your new sitemap-yourblogservername.xml has been created.
4. Test and confirm that this worked
Now test two things. Start by pointing your browser to http://yourblogservername/sitemap.xml and then http://yourblogservername/sitemap-yourblogservername.xml. If you setup your .htaccess rewrite rules correctly, then both URLs should work.
Load up your WordPress generated robots.txt file via http://yourblogservername/robots.txt and look at the Sitemap line. Mine reads like this
I have that rewrite rule in case the default location for the sitemap is used. When you load the sitemap via the normal location, the rewite rule sends it to the correct location. The second gziped sitemap URL is fine.
There should be no real sitemap.xml or sitemap.xml.gz files in your blog’s root directory. Instead, each sitemap file should have your virtual WordPress network names instead.
5. Rinse and repeat
Repeat this process for each site in your WordPress Network and you can continue to use this sitemap plugin. You will need to activate the plugin in each of your sites and change sitemap.xml to include the site name just as I outline in step 3.
6. The caveat
If this works for you, great! But if it doesn’t, please don’t bug Arne. If and when he makes his plugin multisite compatible, then it will be probably a better solution than this one. I’m not seeing any PHP errors or warning in my log files, but there may be reasons why this is not a good idea.
Also, when you modify your copy of a plugin in the WordPress plugin repository and that plugin is updated you will lose your edits from step 1 when you update the plugin.
In the meanwhile, I can continue to use this excellent plugin.
I have a few blogs and I’ve been maintaining them each one at a time. So when a new version of WordPress is released or plugins get updated, I end up repeating the same process 5 times.
WordPress 3.0 (I’m using 3.0-RC2 as of this writing) supports multisite functionality. One set of software runs multiple sites and I only need to keep on that installation up to date. Setting up the multisite was easy and I just followed the instructions here.
For the WordPress part, I opted for the sub-domain model and with main blog as my existing blog.dembowski.net with all other blogs as *.blog.dembowski.net.
On the DNS and Apache2 portions, I added to my dembowski.net zone a new wildcard entry for *.blog.dembowski.net and added a ServerAlias in my Apache2 vhost for *.blog.dembowski.net to point to blog.dembowski.net.
I then did a WXR export of my existing blogs and imported them into the new setup. My existing blogs are blogname.dembowski.net, not blogname.blogs.dembowski.net. Not a problem. Once I had the data imported, I modified my Apache2 vhosts to point to the new install and followed Otto’s domain mapping tutorial and I’m good to go.
There is some learning for me to do. Not all plugins work in the multisite setup and I’m working out which ones can be Network Activated or need to be activated in each instance. I’ve doped out the vhost issues including SSL, so that’s not a problem. But this is new and somethings will not work as it used to.
WordPress 3.0 beta comes with support for a customized menu system that optionally replaces the wp_page_menu with wp_nav_menu. Drag and drop menu management is a cool and useful feature. It’s like widgets only for navigation purposes.
For my WordPress blog I am using a child theme of Hybrid called WP Full Site and I’ve made some minor changes and additions. Among them I have removed the Home link and added a Subscribe link in my menu.
Modifying my functions.php file like so accomplished the deed:
add_filter('wp_page_menu', 'custom_page_nav');
function custom_page_nav( $menu ) {
// My blog title is already clickable, why have another Home link?
// Remove the Home link from the home page
$zaphome = '<li class="current_page_item"><a title="Home" href="' . get_bloginfo('wpurl') . '/">Home</a></li>';
$menu = str_replace( $zaphome ,'', $menu );
// Remove the Home link from everywhere else
$zaphome = '<li><a title="Home" href="' . get_bloginfo('wpurl') . '/">Home</a></li>';
$menu = str_replace( $zaphome ,'', $menu );
// Now add a RSS subscribe link with CSS id
$links .= '<li id="feed"><a href="' . get_bloginfo('rss2_url') . '" title="Subscribe to the feed">Subscribe</a></li>';
$menu = str_replace( '</ul></div>', $links . '</ul></div>', $menu );
return $menu;
}
And I added these lines to my style.css (I am pretty sure I appropriated it from another of Patrick Daly’s themes but not sure which one):
The upcoming Hybrid 0.8 theme is in beta and has support for the WordPress 3.0 menu system. Activating it changes the CSS styling and replaces wp_page_menu with wp_nav_menu. I wanted to give the menu system a try while keeping my modifications. It was easier than I thought.
First up, fix the CSS. With the wp_page_menu output, the menus are styled with CSS ID of navigation. This gets switched to a CSS class called menu when you use wp_nav_menu.
/* Menus */
.menu {
background: url('library/images/nav-bg.gif') repeat-x;
border-bottom: 1px solid #433B14;
border-top: 1px solid #0F0F0F;
height: 38px;
}
.menu li {
border-left: 1px solid #262001;
border-right: 1px solid #322a03;
}
.menu li ul li {
border-bottom: 1px solid #433B14;
font-style: italic;
font-weight: normal;
text-transform: none;
}
.menu a {
color: #fff;
display: block;
font-size: 14px;
font-weight: bold;
line-height: 14px;
padding: 12px 18px;
text-decoration: none;
}
.menu a:hover {
background: #433B14;
}
.menu li ul li a {
background: url('library/images/nav-bg.gif') repeat-x;
border-bottom: 1px solid #0F0F0F;
}
/* My subscribe button */
.menu ul li#feed {
width: 120px;
float: right;
background: url(images/feed-icon.png) 100px 13px no-repeat;
}
.menu ul li#feed a:hover {
background: #433B14 url(images/feed-icon.png) 100px 13px no-repeat;
}
.menu ul li#feed a {
}
Tedious, but not really a big deal and I just copied the existing CSS in the child theme. I’m not very CSS savvy so there is probably an easier way to re-use the existing section.
To add my Subscribe link all I had to do was add one more filter like so.
add_filter('wp_nav_menu', 'custom_page_nav');
Now I can switch between using the new or old menu system and maintain the look and feel that I want.
I’ve been using WordPress 3.0 beta for about 2 weeks and I’ve only run into one odd behavior.
When I upload or upgrade a plugin, the old plugin gets deactivated and the new plugin version gets downloaded. What is not happening is that the page is not loading up the next steps of re-activating the new version (or just recently downloaded) plugin. I did not catch this and was running without the upgraded plugin for a day or two.
I’m keeping my copies current using SVN and I’m convinced it’s my wonky setup. This server is running NGINX and PHP-FPM. I have the NGINX running as www-data and PHP-FPM running as a separate userid (why? because I can). The NGINX and PHP5 are both installed using non-Ubuntu repos.
I don’t mind this situation and I’ll get it sorted out by running the beta on another box running Apache to get an understanding of what’s going on.
Over on Otto’s blog, he discusses the idea of holding off upgrading to 3.0 when it comes out. Given the hysteria on the support forum whenever a new version comes out, I think that’s an excellent idea. What would be fun is when the 3.0 version is released, and the automatic notification does not get triggered across the globe. Instead the blog gets updated and the notification does not get triggered until 3.1 comes out.
It’s wishful thinking on my part because too many people treat their self-hosted WordPress installation as a service and not as something they are responsible for. I think the majority of WordPress.ORG users are pretty savvy but the minority sure is vocal.
While talking about WordPress, the W3 Total Cache plugin is amazing. I’m playing with it while running the beta and it appears to be speeding up my site without using a disk cache. I have used WP Super Cache but this seems approach the problem from a different angle. Instead of creating HTML static pages, it has the option to use PHP’s opcache. I’m using APC and the speed looks like it’s working. It’s a very cool idea and the implementation looks really polished.
Once WordPress 3.0 is officially released, I’ll run two test blogs on two different boxes and compare the output with and without W3 Total Cache. This way I should be able to get almost scientific results for comparison.
As I usually do, I switched this blog from WordPress 2.9.2 to the current 3.0 beta. I always run the beta versions and I have not yet gotten myself into a hole. It also helps that I have very good backups for the last 30 days.
I re-ran my overnight backup job one more time to make sure I’m up to date and used SVN to perform the switch.
$ cd /my/wordpress/web/directory
$ svn sw http://core.svn.wordpress.org/trunk/
When I went to the login page I had to upgrade my database. And that’s all there was to it. I’ll do a regular “svn up” and keep my install current with the beta.
I have been kicking around the idea of taking the sites I manage and making them one multi-site WordPress 3.0 install but that will be down the road for a while. For now I’ll continue to maintain them separately with the released version (2.9.2 as of right now).
As for the beta, there are not many visual differences (the color scheme is lighter and less “harsh”) and each of my plugins check out. I am hoping that when 3.0 is released, the usual forum drama will not happen. But I also know somewhere someone will upgrade without doing the work of a full backup.
