Troubleshooting WordPress MU 2.8
From TroubleshootingWiki
| Official Page |
| Project Documentation |
| Download |
|
Contents |
[edit] Why worry about upgrades
Once you have your site set up and working, it can be tempting to leave things as they are, although the reasoning "why fix it if it isn't broken" does not always apply to web applications. Just because you cannot see something obviously wrong with the way your site is working does not mean there is not a security hole that you cannot see, which could be exploited by an attacker.
In general, it is worth upgrading whenever a new stable version of a script is released. If the new version is mostly full of cosmetic changes and new features, you can wait a while before upgrading to ensure that any teething issues with the new version are ironed out. However, if the new release contains security patches, you should seriously consider applying it as soon as possible.
The best place to get updates on new releases is the WordPress MU web site (http://mu.wordpress.org) and the web sites of the plugins that you are using. For convenience, WordPress MU will inform you of the release of any new versions when you log in to the admin panel. If you check the plugins page of your admin panel, you will often see messages about out-of-date plugins in there as well.
If you aren't sure whether to apply an update, read the release notes. Usually there will be a readme.txt and a changelog.txt with any major release. If security updates are mentioned, it is worth applying the patch as soon as you are able to. The WordPress MU forums are also a good source of information. You can find those at http://mu.wordpress.org/forums/.
You can keep up to date with security issues by reading the Bugtraq mailing list, which can be found at http://www.securityfocus.com/. This web site contains an up to date list of vulnerabilities and exploits for the most popular scripts and web applications. Usually, security experts will inform the software vendor before submitting their findings to Bugtraq, giving the vendor time to release a patch. If a patch does not get released in a timely fashion, you may find that the notification on Bugtraq will give you the information you need to fix the bug yourself either by making some minor changes to the code of the application or by disabling a certain plugin or feature until a patch is released to prevent your site from being vulnerable to attack.
[edit] Performing a safe upgrade
WordPress MU will usually display a message in the admin panel informing you when an upgrade is available and offering you the chance to upgrade immediately. This feature is very convenient and can save you a lot of time when it works. However, it does not work well on all web server setups and, when it goes wrong, it can cause a lot of problems.
Before you perform any kind of upgrade, you should make a backup. If you already have a backup strategy in place, then you probably already have an up to date backup of your web site's files, as things such as plugins and theme files don't change all that often. Still, your database will need to be backed up.
Before you perform the upgrade, you should put your web site into maintenance mode (which you can do using the Maintenance Mode plugin available at http://wordpress.org/extend/plugins/maintenance-mode/) so that your users don't add any posts or comments while the upgrade is taking place. Once the site is in maintenance mode, you can back up the database either by using a WordPress MU plugin, phpMyAdmin, the cPanel backup tool, or your favorite database management tool.
[edit] Performing a database backup via the command line
If you have SSH access to your server, then performing a database backup via the command line is probably the fastest and easiest way. The syntax for performing a backup using mysqldump is as follows:
Mysqldump add-drop-table h localhost u username p databasename | gzip c > backup_wpmu.sql.gzip
[edit] Performing a database backup via phpMyAdmin
Performing a backup via phpMyAdmin is a good alternative if you do not have shell access. Performing a database backup via phpMyAdmin is fast and convenient for smaller databases. However, it does not always work for very large databases, as the backup process may time out if it takes too long, depending on how your server is set up.
To perform a backup via phpMyAdmin, log in to the tool on your server, select the database you want to back up, and click Export.
You can leave all of the settings at default, but it is a good idea to click the ADD DROP TABLE option, and select some form of compression for the backup. Select save as file and choose a compression type. When you click Go, you should be presented with a box asking you where to save the file.
Store the backup somewhere safe. If anything goes wrong, you will need to import the backup later to get the site working again!
It's worth checking the integrity of any file backups you have, especially if you have made extensive changes to any of the files.
[edit] Performing the upgrade
1. Make sure that the site is in maintenance mode before you start this process. Ideally, you should have put the site into maintenance mode before taking a backup earlier in this tutorial.
2. Go to your Site Admin panel. You should see a link at the top of the screen alerting you to the fact that there is a new version available. Click this link and enter your FTP details when they are requested. Once you've completed the upgrade, check your plugins page. If you see any plugins that are out of date, upgrade them using the upgrade automatically link.
|
Problems with the upgrade? If the upgrade fails for any reason, check the developer's site (usually linked in the plugin's description) and download a copy of the plugin so that you can try installing it manually. |
What just happened?
You have just upgraded your WordPress MU installation. In most cases, the upgrade goes smoothly. That being said, make sure you test all aspects of your site after you have finished updating everything. This is especially important if you are upgrading WordPress MU, BuddyPress, or bbPress. Sometimes the developers change or remove functions, which plugin developers may have relied upon in the past. Usually, developers are given a lot of warning about these changes, but sometimes they don't update their code before the new version comes out. So, you may find that some of your plugins behave unusually after an update.
Don't let fear of plugin problems put you off upgrading, especially if the new version includes security updates. Keeping your user's data safe should be your first priority.
[edit] Troubleshooting when upgrades go wrong
If your upgrade does not work as you had hoped, then there are a few things that you can check. First, look at your .htaccess file. Sometimes, WordPress MU does not correctly update this when changes are made. Usually, an error in your .htacces file will either lead to a 404 Page Not Found error, or a 500 Internal Server Error. If you suspect that your .htaccess file is the source of your problems, take a backup of it, and then rename htaccess.dist to .htaccess. In the .htaccess file, you can see a line that says this: RewriteBase BASE/
Edit the file so that the line simply reads like this: RewriteBase /
The htaccess.dist file is distributed with the WordPress MU install and has all the default settings. If your .htaccess file is broken, then restoring this file will fix it. As our WordPress MU site has been installed to the root of our domain, we removed BASE so that the rewrite rules would point to the right URL.
Solving database connection issues
If you see an error like the one shown in the next screenshot, then this most likely means that there is a problem with your wpmu-config.php file.
If you get this error, the first thing you should check is the contents of your wpmu-config.php file. Make sure that the username and password provided are correct. Also, check that the server's hostname is correct. In most cases, it should say "localhost", but some web hosts such as GoDaddy do use remote MySQL servers. If those details are all correct, check that you can connect to the database using phpMyAdmin.
If you can't connect using phpMyAdmin, then it is likely that there is something wrong with MySQL on your server. If you're running a VPS, restart the MySQL. Depending on the OS of the server in question, we have two probable syntaxes. The first syntax is this: service mysqld restart
The second possible syntax is as follows:'/etc/init.d/mysqld restart
If you aren't using a VPS or dedicated server, contact your web host to ask if they are aware of a problem on your server.
Diagnosing unusual error messages
If you see an error message instead of the blog, or in place of some of the content on the site, don't panic! Read the error message and take a look at the file that the error message belongs to.
For example, if the error message says:
Parse error: parse error in /var/www/slayers/wp-content/plugins/featured-posts.php on line 45
Load up that file, and scroll down to line 45. The chances are, the error will be right there or on one of the surrounding lines. Look for missing semicolons, unclosed brackets, and missing quotation marks.
Another error you may encounter involves "undefined functions". For example, see the following error:
Fatal error: Call to undefined function get_blog_posts() in /var/www/slayers/wp-content/plugins/featured-posts.php on line 27
This error means PHP doesn't know anything about a function called get_blog_posts. This is because the function in wpmu-functions.php is actually called get_blog_post. In this case, the error was created when I was making some changes to the plugin. I was tidying up the code and I turned the function name into a plural by mistake. However, you could see this error appear if a function gets renamed or merged into another function as WordPress MU evolves.
Error Message: Headers already sent...
One common error message that can be difficult to track down is "Headers already sent". This error message means that the server has sent headers to the browser before WordPress MU was finished preparing them usually because of something simple such as some white space in the wrong place. If you have edited any files recently, make sure that there is no white space before the opening <?php tag or the closing ?> tag. If you have just updated a plugin or updated WordPress MU itself, check the files that have been changed. Even a single space or line break in the wrong place can cause this error.
[edit] Troubleshooting common problems
Sometimes problems can crop up that are seemingly unrelated to any changes you have made recently to your site. Tracking down problems of this kind can be difficult, unless you approach the issue in a systematic manner.
If you have not changed anything on the site yourself, the most likely causes of unusual behavior from your web site are file permissions and caching.
In this section, I will give some examples of issues that my clients have encountered with their web sites:
- Users unable to add photographs to posts:
If your users are complaining that they are unable to add photographs to their posts (but the uploads seem to be completing successfully), then the first thing you should check is file permissions. On some servers, new files and folders are created with 644 permissions; ensure that the files are being uploaded to a folder with 755 permissions.
- Slow loading admin panels:
After you have performed an upgrade, if you find that your site's admin panels are running slowly (especially the ones not connected to the main blog), then you should first try disabling any unnecessary plugins. Also, access each admin panel individually and confirm that the upgrade script was executed correctly on all of them.
- I can't see any posts!:
If you can't see any posts, or searches return no results when they should have returned some, then you may have a problem with your browser's cache. Your cache might have stored a blank result. You can fix this problem by clearing your browser's cache and cookies.
- Registration emails aren't going out:
If your users aren't getting their registration emails or password reminders, then you should check the SMTP configuration of the mail server. If you don't have an SMTP server set up, install sendmail (or ask your host to do it for you).
[edit] Restoring a backup
If you decide to restore a backup, you can do this either via the command line or via phpMyAdmin. For very large backups, using the command line is a good idea; however, if you don't have command-line access, phpMyAdmin is a good option.
1. Go to your site's phpMyAdmin page.
2. Select the database on the lefthand side. For SlayerCafe, the database is called SlayerBlogs.
3. Go to the Import tab.
4. Select your database backup, and click Go.
|
What to do if your upload times out: If the upload times out, you can use the Partial import feature and tell the importer to skip the lines that were executed during the first attempt. |
What just happened?
You have just restored a database backup. Hopefully, you will never need to do this on your live web site! However, you may need to do this if an upgrade goes wrong or if your server crashes for some reason. If you ever need to move web hosts, perhaps because your site has become so popular that you have outgrown your original host, you could use this method to move the database to your new host.
For example, if you decided that you wanted to move your site to a different domain, you could set up the other domain, upload the database, and then use a simple SQL query to replace all instances of the old domain with the new one (for example, all instances of slayercafe.com with slayerbistro.com).
[edit] Protecting your site from hackers
When you put your site up on a server that is connected to the Internet, it instantly becomes a target for attackers. A popular web site is more likely to be the victim of a focused attack, but even a small web site is at risk from mass exploitation attempts where attackers scan every host they can find in the hopes of coming across something vulnerable.
Patch regularly and use good passwords
The best way to keep your site safe is to stay up to date with security updates and keep your server's settings as secure as possible. Limit the number of people you give admin access to and enforce secure password policies.
For example, don't use the same password for your blog account, FTP account, and the MySQL database for the blog network. Also, make sure each password contains a mix of letters and numbers (and a mix of upper and lowercase characters, if possible). The longer the password, the better.
Limit what your users can do
If you allow your users to upload files, limit the kinds of files they can upload to ones that are not likely to contain anything malicious.
If you are going to allow your users to customize their layouts, either limit this to simple CSS changes or moderate all theme changes by having someone look over the user's code submission before allowing it to go live. Allowing users to edit the theme files (or worse, the plugin files!) at will is very risky. There's nothing to stop the user from running malicious code on your server and possibly causing serious damage to your database.
Avoiding social engineering
Once you have locked down your server, the easiest avenue of attack is through your users and your staff. Social engineering is a favorite technique of hackers. Even technically brilliant hackers who know lots of ways to break in to computer systems sometimes try social engineering first. After all, why risk exposing a vulnerability that has so far gone unnoticed (thereby making the systems administrator patch it), when you can get into the system just by asking a poorly trained staff member for their password?
A common technique for social engineering attacks on web sites is to pose as a moderator or staff member. You may have seen phishing emails coming from systems-administrator@myemailprovider.com. Hopefully you haven't handed over your passwords, but there are lots of computer novices who would believe that an email coming from an official sounding address is the real thing.
You can protect your users by preventing people from signing up with official sounding names. The option to do this is found under Site Admin | Options in the Site Admin panel.
On SlayerCafe, we have banned the following usernames: Watcher, slayer, vampireslayer, root, admin, administrator, register, blog, activate, support, techsupport, tech-support, members, watcherscouncil, email, council.
The list is not exhaustive and includes many usernames that sound authoritative only to vampire slayers. You should change this list for your site, adding in any names that may fool your customers (for example, an ISP may want to block names such as "billing" or "email-support").
If you are using a premium subscriptions feature on your blog network, then you should test it extensively to make sure that only those people who should have access to certain pages are able to view them. In the past, some member site add-ons have had a lot of holes or backdoors (although most of these have now been fixed). If you have a "printer friendly" plugin, make sure that users can't access premium content by using a "printer friendly" version of a link. Make sure that users whose memberships have expired really do lose access to pages that they should no longer be able to view; test your pages logged in, logged out, with JavaScript turned off, and so on. If everything behaves as you would expect, then you can be confident that your membership site stands up well to at least a cursory test. You should still keep an eye on your logs for brute force attempts and, if the software supports it, you should set up your member site script to lock out any user who fails to enter their password correctly a certain number of times in a row.
[edit] Getting help online
If you believe that you have encountered a bug in WordPress MU or in any of its plugins, then it is a good idea to report your findings to the developer so that they can fix the problem for you and any other users of the script or plugin.
For WordPress MU, you can find support at http://mu.wordpress.org. You can also read in-depth information about WordPress MU at http://codex.wordpress.org.
Most plugin developers will provide their contact details (either a web site address or an email address) in the plugin's readme file. So, if you have an issue with a specific plugin, check that file for details. Some developers maintain a presence on the WordPress MU, BuddyPress, and bbPress forums, while others prefer support requests and bug reports be sent via email or as a comment on their blogs. There are some premium plugins on wpmudev.com and, if you have an issue with those, you should use the support features offered on that web site.
Before you raise a bug report, it is a good idea to search the WordPress MU forums (or the forums at buddypress.org if it's a BuddyPress issue) to see if others have already encountered the same bug. Often, you will find that several other people have already posted about the issue and hopefully a workaround has been found.
If you cannot find any posts relevant to your problem, then you can make a post yourself.
posting to request support
The people who offer support for open source web applications do so on a voluntary basis. They are not paid staff and are taking time out of their day to help you with your problems. The support forums get a huge number of posts each day, and it's easy for a post to get lost in the noise or ignored if it is too vague or difficult to read.
To maximize your chances of getting the help you need, you should be polite, offer as much information as you can, and indicate any measures you have already taken to try to solve the problem. You should also try to post in the most appropriate section of the forum.
For example, consider this request:
HELP!!!! BLOG WONT LOAD!
This request will probably be ignored or at least not treated with priority over more descriptive subject lines.
Consider the post subject:
'''500 Internal Server Error''' after Upgrade to WP-MU 2.8
This is much more descriptive and will likely get a faster response.
Inside the post, you could say something like the following:
I upgraded from WP-MU 2.7.1 to WP-MU 2.8, and I am now getting a 500 Internal Server Error when trying to visit user profiles. The front page loads fine, as do blog posts. It's only user profiles that have issues. My MU install uses subdomains.
I have checked my .htaccess file, and all seems fine. The contents are as follows:
<paste.htaccess file here>
I searched about this issue and found others with similar problems who were running bbPress and BuddyPress. I followed the instructions for reinstalling those, but that didn't help. Any suggestions would be much appreciated.
A post such as the one above gives those who are in a position to help you the information they need, and it indicates that you have tried to solve the problem yourself but found that the posted solutions did not help you. This avoids people suggesting things that you have already tried.
When making such a post, it is a good idea to remove any information that is specific to your server. Pasting a .htaccess file is fine, but if you are asked to post the contents of your config file, you should replace the database username and password details with "MYUSERNAMEGOESHERE" and "MYPASSWORDGOESHERE" in the forum post, rather than giving your username and password details out to the thousands of readers of the forum.
Sometimes you will get a response to your query within a few minutes. Other times, it could take a day or so. It depends on how busy the forums are and how complicated your problem is. If you do not get a response to your post within a day or so, it can be tempting to "bump" it that is, to make it appear at the top of the list of recent posts by posting a reply yourself. Before you do this, read the sticky posts in the forum to check the rules. In general, bumping too frequently is frowned upon.
If you are going to email a developer, it is doubly important to provide as much information as possible and to be polite. Developers of popular plugins will get a lot of email about it and, while they would love to be able to help everyone, they most likely have a job, family commitments, and hobbies taking up a lot of their time. If a developer doesn't answer you instantly, don't assume they are being rude. It s much more likely that they simply haven't had a chance to read their plugin-related email yet.
[edit] Additional References
- For instructions on Customizing site using WordPress MU 2.8, click here
- For instructions on Installing WordPress MU, click here
- For instructions on Developing WordPress Themes, click here
- For instructions on Configuring WordPress Themes, click here
- For instructions on Troubleshooting WordPress Installation, click here
- For instructions on Developing WordPress 2.7 Themes, click here
- For instructions on Set Up for Word Press 2.7, click here
- For instructions on Theming Wordpress, click here
- For instructions on WordPress, click here
[edit] Source
The source of this content is Chapter 12: Troubleshooting WordPress MU 2.8 of WordPress MU 2.8: Beginner's Guide by Lesley A. Harrison (Packt Publishing, 2009).
