If you followed the instructions in my post “How do I move WordPress from a subdirectory to the root directory?” and you encountered any issues, please read the following list of frequently encountered issues.
Please comment below if you continue to have problems or write to me via my Contact form if you need personal assistance. If I can help you in less than 15 minutes, then I’m happy to do so for free. If the problem is more involved than that and requires me to login to your site and do the fix for you, then I charge $75/hour. Usually, I can solve these problems in less than 1/2 hour.
Verify the following:
1 – Index.php location and settings
Please check: Which index.php file did you move and where did you move it? The index.php file you moved should start with the following code:
<?php
/**
* Front to the WordPress application. This file doesn't do anything, but loads
* wp-blog-header.php which does and tells WordPress to load the theme.
*
* @package WordPress
*/
/**
* Tells WordPress to load the WordPress theme and output it.
*
* @var bool
*/
define('WP_USE_THEMES', true);
/** Loads the WordPress Environment and Template */
require('./mywp/wp-blog-header.php');
?>
Check the require line in your file. Be sure that the / are in the right place and that the subdirectory name is correct. Most people make a mistake and either don’t edit the require line and put their subdirectory name in it or make a mistake with the syntax and have an extra slash, no slash, an extra period, etc.
Next, where did you put this index.php file? Some people have put it in the root of the hosting account instead of in the domain root — which is the public_html folder on most hosts. If you moved this file outside the public_html folder, that won’t work. Some people’s hosting accounts are really wildly configured, and their host does not have a straight forward path for you to figure out where the heck your domain root is. So, to keep things simple, you would have wanted to move the index.php to the directory just above your subdirectory that contains the WordPress application.
Finally, some people have inadvertently moved the index.php file in their theme’s folder rather than the index.php file in the subdirectory. If you don’t see the require line above in your index.php file, then you moved the wrong file.
2 – WordPress General Settings
The next most common mistake is to not set the General Settings in the WordPress Dashboard correctly. Here is how they should have been set:
If a mistake was made here, then you might not be able to see your site or you won’t be able to login to your site. It is pretty common to have made a mistake with these settings or forgotten to make the change here. To fix this, you will need to login to your phpMyAdmin application via your web hosting control panel. Take note of your database username and password in the wp-config.php file and check the following:
Login to the database and go to the wp_options table and click the browse tab.
The first option is is for siteurl (which is totally inconsistent with the General Settings field label). This should be set to the URL with the subdirectory:
Go to the next page of the table and check the home value. This should be the URL to the main site URL without the subdirectory name:
3 – .htaccess
Some web hosts will have issues with the .htaccess commands once your index.php file is in the public_html file. If this is the case, you should still be able to login to WordPress via the subdirectory, and your home page will display correct BUT your links to the other pages will show a “Page Not Found” error. (Please note: even though you are showing the pages of your site from the main domain url, you will still need to login via the subdirectory url – e.g. http://yoursite.com/mywp/wp-admin – and all of your images on the site will still be located in the http://yoursite.com/mywp/wp-content/uploads.)
So, if you are having troubles with your “pretty permalinks” in other words, the home page of the site displays okay, but your subpages display a File Not Found message, then login to your WordPress dashboard and go to Settings > Permalinks and click Save Changes. This should cause your .htaccess file to be updated correctly. If this does not work, you may need to move the .htaccess to the root directory and manually replace the current WordPress mod rewrite directive with the code below. (Note: you will need to show invisible files via your FTP application or use the web host’s file manager to see this file.)
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
IMPORTANT NOTE: If you are on a Windows hosting account (please check this before commenting below), you will NOT have an .htacccess file. You will need to install a web.config file to use the Microsoft’s Rewrite Module. For more information, please read: http://codex.wordpress.org/Using_Permalinks#Permalinks_without_mod_rewrite. If you are on GoDaddy and have Windows hosting, please read: http://wordpress.org/support/topic/godaddy-iis-and-removing-indexphp-in-url?replies=20#post-1507468
To determine if the permalinks is the issue with why your internal page links are displaying as Page Not Found, try to use the Default permalinks (Permalinks > Settings) and see if you can view all your interior pages fine. If you CAN view all your pages using the Default permalink settings (in other words, the pretty urls are turned off), then the issue is related to the .htaccess file on Linux/Apache hosting or not having a web.config file and rewrite rules enabled on a Windows server.
You may need to check with your web host about how to make this work properly. Some, such as Yahoo web hosting really are not good WordPress hosts, others require that /index.php be part of the permalink structure. So, if the default permalinks work, and you’ve tried creating and editing your .htaccess (Linux) or web.config file (Windows), then call your web host.
4 – PHP Version Called in the .htaccess file
One person who wrote to me had their php version command in their .htaccess file. They had deleted the .htaccess file after moving WordPress, so the PHP directive calling for the correct version of PHP was removed, and their site therefore was running PHP 4, and the latest WordPress will not run in PHP 4. This is something you can check with your web host, and they can give you the line that goes in your .htaccess file to call for the correct version of PHP. It will look something like this:
AddHandler application/x-httpd-php5s .php
5 – Old Site Files Interfering with New Site
Several people installed WordPress in a subdirectory because they had an existing site in the main url. When they followed these instructions to move the index.php file the WordPress subdirectory to the main site directory, they left the old site files in the main directory and therefore, the browser kept trying to open the old index.html file rather than the index.php file. To fix this, simply create a new folder called _OLD in your main directory and drag all of your old site files into this folder. Download this folder and then delete it from the server after you’ve verified that the site is functioning correctly. Do not leave these old files on the server unless you have excluded them from search engines via a robots.txt file.
6 – Redirecting Old URLs
Whether you had an old .html site up or had your current WordPress site in the subdirectory indexed by Google, you’ll want to do redirects on these pages that Google may have indexed.
If you had an old .html site and the WordPress site was “private,” after you’ve completed this process, be sure to change the Privacy settings in the WordPress dashboard, so Google can now index these new WordPress urls. Install the Redirection plugin and create redirects on the old .html URLs to their new WordPress URLs. Install the Google XML Sitemap plugin and generate a new sitemap and submit it to Google Webmaster Tools. This will help prevent any 404 Page Not Found errors. Google will eventually re-index your site with the new URLs, so you shouldn’t have those old URLs come up in search engine searches after a few weeks.
If your current WordPress installation was indexed by Google with the old URLs, eg http://yoursite.com/mywp/about and now it is http://yoursite.com/about, then you will need to do the same as above for those old URLs. If you have a LOT of these old URLs, ie, you had a large, active blog before you followed these instructions, I’m testing out an .htaccess command you can use to rewrite all the URLs. I’ll post it here when I’ve tortured tested it.
7 – Protecting the WordPress Directory from Browsing
Since we removed the index.php file from the WordPress directory, now that directory can be “browsed,” which is not good. To prevent this, add the following line to your .htaccess file:
Options All -Indexes
OR install the Silence is Golden Guard plugin
OR create a new blank index.php file in the WordPress directory which contains the following code:
<?php // Silence is golden. ?>
8 – Internal Hyperlinks
Please note that this process does preserve all the image links in your site. However, you will need to reset any INTERNAL hyperlinks, including any manually entered hyperlinks in the Appearance > Menus.
Some themes have hardcoded the link to the Home page incorrect and you may need to set that correctly in the header.php file of your theme.
A good plugin for finding these broken links is the Broken Link Checker.
I have also used the Search and Replace plugin, but use it with caution, because you don’t want to replace your good image links.
Typically, I will search for <a href=”http://yoursite.com/mywp
and replace with <a href=”http://yoursite.com/mywp
then I’ll do another search to make sure I didn’t break any image links with <a href=”http://yoursite.com/wp-content
and replace with <a href=”http://yoursite.com/mywp/wp-content since the wp-content is and always will be in the mywp (aka the subdirectory).
Follow Me!