The easiest way to reset your password is with the “Lost your password?” link under your blog’s log in form. This will send a password reset email to the email address in your user profile, so be sure to keep that up to date.

What if the email never arrives, or you’ve lost access to the email address in question? Fortunately, there are plenty of alternative ways to reset your password covered in this Codex article. Most hosting providers offer phpMyAdmin via their control panel, and I have often found the phpMyAdmin method to be the easiest (excluding the “Lost your password?” link, of course).

If you’re having trouble with any of these, the volunteers in the WordPress Support Forums are more than happy to guide you down the right path.

This is unfortunately another one of those common annoyances related to your hosting provider’s server configuration that can take you off guard and lead to plenty of confusion. Fortunately, it’s easy to fix (or work around).

Try changing the permissions of the theme files that you want to edit to 666. If that doesn’t work, just use an FTP or SFTP client and a plain text editor to edit them remotely.

Of course, if neither of those methods are working out for you, please stop by the WordPress Support Forums for further assistance.

First, make sure that your browser has JavaScript enabled. This is usually the most common cause of the issue, and fortunately the easiest to fix.

If your browser does have JavaScript enabled, use an FTP or SFTP client to access your server and a plain text editor to edit your wp-config.php file. Once the file is open, add define('CONCATENATE_SCRIPTS', false); below the define('DB_HOST' line and save the file.

In most cases, one of the two methods will work for you. If you’re still having trouble, stop by the WordPress Support Forums for further assistance.

First, there could have been a momentary glitch, so try re-saving your permalink structure at Settings/Permalinks in your admin panel. If WordPress cannot automatically edit the .htaccess file, it will provide manual instructions after saving.

If that doesn’t work, contact your hosting provider and find out if mod_rewite is installed and active on your server. If it isn’t, refer to this guide for some tips on using permalinks without mod_rewrite, or find yourself a nice Apache-based server with mod_rewrite.

Permalinks are a finicky thing. They’ll either work right away, if you re-save, and if you use a work-around, otherwise they just won’t work at all. If you’re still having trouble, contact the WordPress Support Forums for more assistance.

More than likely, there is an index.html or home.html file in the same directory as the WordPress index.php file. Remove the index.html or home.html file, either via FTP or your hosting provider’s file manager, and all should be fine.

If that didn’t help, your server isn’t configured to recognize index.php as a valid index file, which is thankfully very rare. Access your server via FTP and try adding this to the top of your .htaccess file with a plain text editor:

DirectoryIndex index.php index.html index.htm

Both of these should work to cure your generic home page woes, but if they do not, stop by the WordPress Support Forums for further assistance.

If you’re seeing a blank white screen, consult WordPress and the White Screen of Death. If you’re seeing “Fatal error: Allowed memory size,” consult WordPress and the Fatal Memory Error. If you’re seeing an internal server error or error 500, consult WordPress and the Internal Server Error. And, if you’re seeing a headers already sent warning, consult WordPress and the Headers Already Sent Warning.

As you can probably guess from the articles linked to above, many sudden WordPress problems can be traced back to plugins, themes, or corrupt core files. If your problem is not directly related to one of these cases, it’s time to move through the general troubleshooting steps to find the cause of the problem and maybe even fix it along the way.

If you have access to your admin panel, try deactivating all plugins. If you don’t have access to your admin panel, try manually resetting your plugins. If that resolves the issue, reactivate each one individually until you find the cause.

If your blog showed no signs of improvement after deactivating your plugins, then it’s time to move on to your currently active theme. If you have access to your admin panel, try switching to the Default theme (WordPress 1.5 – 2.9.2) or the Twenty Ten theme (WordPress 3.0 and higher). If you don’t have access to your admin panel, access your server via FTP or SFTP, navigate to /wp-content/themes/ and rename the directory of your currently active theme. This will force the Default theme (WordPress 1.5 – 2.9.2) or the Twenty Ten theme (WordPress 3.0 and higher) to activate and hopefully rule-out a theme-specific issue.

If your blog showed no signs of improvement after deactivating your plugins and switching your theme, try downloading WordPress again and delete then replace your copies of everything except the wp-config.php file and the /wp-content/ directory with fresh copies from the download. This will effectively replace all of your core files without damaging your content and settings. Some uploaders tend to be unreliable when overwriting files, so don’t forget to delete the original files before replacing them.

If the general troubleshooting steps have failed to identify the cause of the problem, the volunteers in the WordPress Support Forums will be more than happy to help you, especially if you list all the steps you have taken so far.

Warning: Cannot modify header information - headers already sent by (output started at /path/blog/wp-config.php:34) in /path/blog/wp-login.php on line 42

Remember the first rule in troubleshooting, don’t panic! First, you need to interpret the error message. Offhand, it would seem as if line 42 of the wp-login.php file was the source of the problem, but that’s a common misconception. In fact, the problem is on line 34 of the wp-config.php file, and line 42 of the wp-login.php file is just the victim.

Now that you know where to look, what do you look for? Believe it or not, this problem is usually caused by nothing more than blank space (either a single blank space or an entire blank line) on the referenced line.

Now that you know where and what to look for, access your server via FTP or SFTP and use a plain text editor to edit the file. Alternatively, if you don’t want to mess with editing the file, replacing it with an original copy may resolve the issue.

What if you don’t see anything wrong with the file, and replacing the file didn’t resolve the issue? There’s always the possibility that a plugin or theme functions file could be causing the space to appear when the file is accessed. Try deactivating all plugins. If that resolves the issue, reactivate each one individually until you find the cause. If that does not resolve the issue, try switching to the Default theme (WordPress 1.5 – 2.9.2) or the Twenty Ten theme (WordPress 3.0 and higher) to rule-out a theme-specific issue. If you cannot access your admin panel, you’ll have to manually reset your plugins and theme, which we covered before in WordPress and the White Screen of Death.

If you still have not been able to resolve the issue, the volunteers in the WordPress Support Forums will be more than happy to help you. Just be sure to fill them in on all the steps you have taken thus far.

Before you ask for support, internal server errors are often caused by plugin or theme function conflicts, so you should start by manually resetting all of your plugins and your theme, which we already covered in WordPress and the White Screen of Death. If that doesn’t resolve the issue, it’s possible that a .htaccess rule could be the source of the problem. To check for this, access your server via FTP or SFTP and rename the .htaccess file. If you can’t find a .htaccess file, make sure that you have set your FTP or SFTP client to view invisible files.

If you weren’t able to resolve the issue by either resetting your plugins and theme or renaming your .htaccess file, it’s time to ask for support, but it would certainly help the supporter if you could offer a more detailed error message. Internal server errors are usually described in more detail in the server error log. If you have access to your server error log, generate the error again, note the date and time, then immediately check your server error log for any errors that occurred during that time period. If you don’t have access to your server error log, ask your hosting provider to look for you.

Once you have all the relevant details, ask either your hosting provider or the WordPress Support Forums for further help. Be sure to describe what you were doing before the error occurred, all the troubleshooting steps that you have taken thus far, and include the quoted error message(s) from your server error log.

You see, your server may be packed with 4 GB of RAM, but that doesn’t mean that all 4 GB have been allocated to PHP on your account. In fact, most decent hosting providers only allocate 32 MB to PHP under each account. Now, most WordPress installations with a good amount of plugins will run fine under 32 MB, but there’s always a chance that one more plugin or one seemingly innocent admin panel task (like exporting or importing posts) may put you over the edge, and you’ll see either a blank screen or the infamous error which starts off something like “Fatal error: Allowed memory size of 33554432 bytes exhausted.”

If you see a blank screen, refer to WordPress and the White Screen of Death before continuing.

Update: Thanks to Big Dave Zatz for reminding me that if you see this error either suddenly (no specific task was done to cause the error) or frequently, try deactivating all plugins to rule-out a plugin-specific issue and try switching themes to rule-out a theme-specific issue.

If you see the infamous fatal memory error, there are three things that you can do before asking your hosting provider for assistance. Which method you use depends entirely on your server configuration. If one method doesn’t work, try the next. Keep in mind that most hosting providers closely monitor memory overrides and don’t take too kindly to frequent use.

1. If you’re using WordPress 2.9.2 or lower, try adding define('WP_MEMORY_LIMIT', '256M'); to your wp-config.php file. If you’re using WordPress 3.0 or higher, WordPress automatically does this for a variety of tasks, so there’s really no reason to try it in this case.

2. If you can edit or override the system php.ini file, increase the memory limit. For example, memory_limit = 256M

3. If you cannot edit or override the system php.ini file, add php_value memory_limit 256M to your .htaccess file.

If neither of these work, it’s time to ask your hosting provider to temporarily increase PHP’s memory allocation on your account. Keep in mind that most decent hosting providers allocate 32 MB to PHP under each account, and most decent hosting providers allow users to temporarily increase the memory allocation. If your hosting provider won’t accommodate you, perhaps it’s time to find a new hosting provider.

As always, if you need further assistance, the volunteers in the WordPress Support Forums will be more than happy to help you.

Andrea Rennick became a user of WordPress MU about three years ago, when it was still in a pre-beta stage. She was just your typical stay at home mom and teacher, and she wanted to create a community where other homeschoolers could have their own blogs all in one location, so they could find and support one another. It took her about a month just to get everything running, and she was spending so much time on the WordPress MU Support Forum finding answers, that she eventually began helping others. Soon after, she launched WPMU Tutorials as a resource for anyone to learn about WordPress MU and now WordPress Multisite.

Now, Andrea is a prominent volunteer moderator on the WordPress Support Forums and is co-authoring the WordPress All-in-One Desk Reference.

We are very fortunate that Andrea has agreed to share with us her solutions to some of the most common WordPress Multisite problems. To avoid any interpretation issues, the rest is entirely in her own words.

“My subdomain sites don’t work, what did I do wrong?”

Subdomain sites are managed on the server through the use of wildcards. This means that the server itself needs to have them set up in Apache, and will send any request for any subdomain, straight through to the WordPress network. Then WordPress will look it up on the database and serve the right content. You also need to have a wildcard subdomain record in your DNS records. It looks like this:
in A * yourdomain.com.

“My subfolder sites don’t work / have no styles / are not in folders on the server. What’s going on?”

Subfolder sites work on the same principle as pretty permalinks do. The URL is rewritten to give the appearance that it is in a folder on the server. So, mod_rewrite has to be working on the server, and actually reading the .htaccess file. It’s the .htaccess file that does the heavy lifting of “making” the subfolder site in this case.

For either kind:
The blogs themselves are virtual. They do not exist on the server. I’ve answered a few threads about the blogs.dir folder that needs to be made on the server when you enable multisite. This folder does not hold the actual blogs. The only use it has is for media uploads from each site. If there is nothing in the folders under the blogs.dir directory, that has no relation to if the site itself shows up or not.

For more information, please see this article.

“There’s a /blog/ in my main blog. Why is it there and how do I remove it?”

Yes, this is done intentionally so any permalink off the main site does not interfere with any site name in a subfolder setup. You will not see this in a subdomain install.

You can remove it by editing the main site details under Super Admin -> Sites and editing the main site.

I actually like to use this to my advantage, and set up a home page for the whole network on the main site, and then use the /blog/ to be the “main” blog on the network.

“Help! my uploaded images don’t work! Also, they are going in one location but my blogs says they are somewhere else, why?”

This is how it is supposed to work. Images are physically located under the blogs.dir folder, in numbered folders from that correlating to each site’s blog-id#. these locations are then rewritten via the .htaccess file and served up to the “new” location. If it’s not working, then either something is missing from the .htaccess file, or the file just isn’t being read by mod_rewrite.

“Do I need a special theme? Why can’t I edit themes? How can I make changes?”

Most any theme for WordPress will work just fine when you are running a network. Super Admins are the only ones who can edit themes, and this is for security reasons. Also, themes are shared. If you set up a network with 10 sites and they all use TwentyTen, only one copy of TwentyTen is in use. This is why each site has its own admin area with their own widgets to manage.

You can give your users an option similar to wordpress.com’s css upgrade through any of these plugins.

As I touched on in the previous question, the main site’s theme is what controls the main page on the network. Getting familiar with the template hierarchy and using a static home page or the home.php template with various plugins to pull network-wide content will give many Super Admins exactly what they are looking for.

“How do I aggregate or gather all the posts from across all the sites onto the main page of my domain?”

You use the best plugin for this, of course. Sitewide Tags.

This needs to go in the mu-plugins folder, and will run all the time. It puts new options on the Super Admin -> Options page, and you can set it to send all new posts to the main site in the network. When new posts are made, they will be copied over to the main blog, and will retain the originating site’s permalink, so there will be no duplicate content. The only thing it will not pull is comments and post thumbnails.

I’d like to thank Andrea Rennick for generously providing her solutions to these common problems both here and on the WordPress Support Forums. If you need any help beyond what was mentioned above, please feel free to ask in the Multisite section of the WordPress Support Forums where Andrea and the rest of the talented support forum volunteers are on-hand to help you at most hours of the day.

Unfortunately, the white screen of death became all too well-known in the WordPress community when a few incompatible plugins began to cause the issue after users upgraded to WordPress 3. Today, most white screens of death are either caused by plugins or themes (theme functions can sometimes interfere with core WordPress functions). If you want to immediately attempt to find the culprit, you can enable debug mode, but even that can produce nothing more than a blank screen, so why not attack the problem head on?

We’ll start with your plugins. If you have access to your admin panel, try deactivating all plugins. If you don’t have access to your admin panel, try manually resetting your plugins. If that resolves the issue, reactivate each one individually until you find the cause.

If your blog showed no signs of improvement after deactivating your plugins, then it’s time to move on to your currently active theme. If you have access to your admin panel, try switching to the Default theme (WordPress 1.5 – 2.9.2) or the Twenty Ten theme (WordPress 3.0 and higher). If you don’t have access to your admin panel, access your server via FTP or SFTP, navigate to /wp-content/themes/ and rename the directory of your currently active theme, which will force the Default theme (WordPress 1.5 – 2.9.2) or the Twenty Ten theme (WordPress 3.0 and higher) to activate. This will hopefully rule-out a theme-specific issue.

Though plugins and themes are the most common cause of the white screen of death, there are a few rare causes as well. If the above troubleshooting steps failed to resolve the issue, please contact the WordPress Support Forums.