404 and 500 error on log in for wordpress network 3.0.4 after upgrade from wpmu 2.9.2

I upgraded from wpmu 2.9.2 to wp 3.0.4 Network. After upgrading I can not log in to sites, I get 404 and 500 errors after logging. Note, that my wpmu sites were working (as sub-domains) before upgrading.

I tried to do an automatic upgrade and it did not work. So I did a manual upgrade.

Below is the process I followed to upgrade:

1.Deactivated plugins

2.Downloaded the wp 3.0.4 file from wordpress.org/download

3.Deleted the wp-admin and wp-includes folders in my installs root

4.Uploaded the new wp-admin and wp-includes folders from wp 3.0.4

5.Overwrote only the duplicated files in the wp-content folder from the wp 3.0.4. Left the other files in wp-content alone.

6.Uploaded the loose upgrade (3.0.4) files to the root dir.

7. Following the directions on: http://codex.wordpress.org/Create_A_Network

Quote from that page:

“NOTE: If you are currently running a version of WordPress MU, you do not need to complete these steps. your network is already enabled. Once you upgrade to the 3.x branch, you will be prompted to update your .htaccess rules for MultiSite.”

I assumed I could ignore the steps to set up a Network since I was upgrading from WPMU 2.9.2, following these directions.

8.So I did NOT:

Open up wp-config.php and add this line above where it says /* That’s all, stop editing! Happy blogging. */:

define(‘WP_ALLOW_MULTISITE’, true);

9.And I do not see: Network under Tools in my Super Admin. So I do not have the option of selection sub-domain over sub-directory, or setting the server address, network title or email address. I assume these are carried over from WPMU 2.9.2 However, in my Super Admin I do see Sites, Users, etc…same as in WPMU 2.9.2.

10.I find that blogs.dir directory is already created under /wp-content/ with 0755 permissions.

11.I delete blogs.php from /wp-content/.

12.And I update my htaccess to reflect that blogs.php has been moved to wp-includes/ms-files.php by finding:

RewriteRule ^(.*/)?files/(.*) wp-content/blogs.php?file=$2 [L] and change it to this: RewriteRule ^(.*/)?files/(.*) wp-includes/ms-files.php?file=$2 [L]

13.I add the Nonce salt in my WP install to the wp-config.php twice.

14.Then I logged in as SuperAdmin again and upgraded through Tools and Updated through Super Admin.

NOTE

My wp-config.php does not include 2 lines shown on https://premium.wpmudev.org/wpmu-and-buddypress-installation/creating-a-network-by-enabling-wordpress-multisite/

Instead of:

define( ‘MULTISITE’, true );

I have:

define( ‘DB_Collate’, ”:wink:;

And instead of

define( ‘SUBDOMAIN_INSTALL’, true );

I have:

define( ‘VHOST’, ‘yes’:wink:;

The rest is the same (see below):

$base = ‘/’;

define( ‘DOMAIN_CURRENT_SITE’, ‘sitename.com’ );

define( ‘PATH_CURRENT-SITE’, ‘/’ );

define( ‘SITE_ID_CURRENT_SITE’, 1 );

define( ‘BLOG_ID_CURRENT_SITE’, 1);


Before (in WPMU 2.9.2) I got around my webhost not having wildcard dns enabled by using an external dns provider and by setting up subdomains in cPanel. My external DNS provider has three A records set up:

website.com.

*

www

In my webhost cPanel I have subdomains set up:

ie. subdomain.website.com

The above setup used to work well. Now when I try to log into a subdomain blog site I get 404 and 500 errors. Below is the error log from my webhost (duplicates deleted and x’s added to identifiers):

[Sun Jan 23 15:00:37 2011] [warn] RewriteCond: NoCase option for non-regex pattern ‘-f’ is not supported and will be ignored.

[Sun Jan 23 15:00:42 2011] [error] [client 67.xxx.xxx.xx] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use ‘LimitInternalRecursion’ to increase the limit if necessary. Use ‘LogLevel debug’ to get a backtrace.

[Sun Jan 23 15:00:50 2011] [error] [client 202.xxx.xx.xxx] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use ‘LimitInternalRecursion’ to increase the limit if necessary. Use ‘LogLevel debug’ to get a backtrace.


My current htacccess file is:

RewriteEngine On

RewriteBase /

#uploaded files

RewriteRule ^(.*/)?files/$ index.php [L]

RewriteCond %{REQUEST_URI} !.*wp-content/plugins.*

RewriteRule ^(.*/)?files/(.*) wp-includes/ms-files.php?file=$2 [L]

# add a trailing slash to /wp-admin

RewriteCond %{REQUEST_URI} ^.*/wp-admin$

RewriteRule ^(.+)$ $1/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]

RewriteCond %{REQUEST_FILENAME} -d

RewriteRule . – [L]

RewriteRule ^([_0-…(deleted because I did not know if this was an identifier)

RewriteRule ^([_0-…(deleted because I did not know if this was an identifier)

RewriteRule . index.php [L]

<IfModule mod_security.c>

<Files async-upload.php>

SecFilterEngine Off

SecFilterScanPOST Off

</Files>

</IfModule>


I appreciate any help.

  • Mason
    • DEV MAN’s Sidekick

    Hiya wpmu@dm1n,

    That’s no fun at all. The upgrade to 3.0+ from WPMU is a scary process, but I haven’t encountered this kind of error. It looks like you followed all the instructions correctly. Are you seeing anything in our php error logs?

    I’ll ask a couple of the developers to comment as well, but I can’t see any reason for this. Is it only the admin area that is blocked? Got a link?

    Thanks!

  • Ulrich
    • The Crimson Coder

    Try adding the following lines to the file wp-config.php:

    define( 'MULTISITE', true );
    define( 'SUBDOMAIN_INSTALL', true );

    Remove:

    define( 'VHOST', 'yes');

    And replace all the lines in the file .htaccess by:

    # BEGIN WordPress
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index.php$ - [L]

    # uploaded files
    RewriteRule ^files/(.+) wp-includes/ms-files.php?file=$1 [L]

    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^ - [L]
    RewriteRule . index.php [L]
    # END WordPress

    <IfModule mod_security.c>

    <Files async-upload.php>

    SecFilterEngine Off

    SecFilterScanPOST Off

    </Files>

    </IfModule>

  • wpmu@dm1n
    • Design Lord, Child of Thor

    Thanks for the suggestions. However, I’m still having some problems.

    I did what you said:

    Adding the following lines to the file wp-config.php:

    define( ‘MULTISITE’, true );

    define( ‘SUBDOMAIN_INSTALL’, true );

    Removed:

    define( ‘VHOST’, ‘yes’:wink:;

    And replaced all the lines in the file .htaccess by what you typed above.

    1.Log-in of sub-domain site seemed to happen; but the page still shows an Error 404. This time the 404 page is formated with the blog css template.

    2.When I tried to log in as Super-Admin I got an “Error establishing a database connection” error. So I returned the .htaccess file to the original. And then I got a message saying there was no wp-config.php file. Somehow it just disappeared. Weird.

    3.I uploaded a saved wp-config.php. But I am not sure how the Nonce Salt is generated. So I am not sure if the saved wp-config.php is the version with (what I assume is) the Nonce Salt request or the generated Nonce Salt from the request. In any case…

    4.After logging in as SuperAdmin I get a notice that:

    “One or more database tables are unavailable. The databases may need to be repaired”. The word “repaired” is a link. When I click it I am taken to a page that says:

    “To allow use of this page to automatically repair database problems, please add the following line to your wp-config.php file. Once this line is added to your config, reload this page.

    define(‘WP_ALLOW_REPAIR’, true);”

    5.I did NOT do this. Instead I deleted the lines you told me to add to the wp-config.php file one at a time and then refreshed my SuperAdmin page. The line:

    define( ‘SUBDOMAIN_INSTALL’, true );

    has no effect that I can tell.

    When the following line is deleted, I have no problem getting to SuperAdmin:

    define( ‘MULTISITE’, true );

    When the above line (Multisite) is in the wp-config.php I get the “One or more database tables are unavailable. The databases may need to be repaired” message. Apparently, this line:

    define( ‘MULTISITE’, true );

    causes at least the database problem.

    6.Does it matter where in the wp-config.php file I add the lines you suggested?

    7.Do you suggest that I keep the:

    define( ‘MULTISITE’, true );

    and “repair” the databases or try something else?

    8.Do you suggest I return the .htaccess to your suggestion?

    9.Below are the php error logs recorded by my webhost. I changed my database name (DB_Name) to DBName for privacy.

    Php Error Log:

    /home2/DBName/public_html/error_log:

    [21-Jan-2011 18:17:12] PHP Warning: require(/home2/DBName/public_html/wp-includes/compat.php) [function.require]: failed to open stream: No such file or directory in /home2/DBName/public_html/wp-settings.php on line 264

    [21-Jan-2011 18:17:13] PHP Warning: require(/home2/DBName/public_html/wp-includes/compat.php) [function.require]: failed to open stream: No such file or directory in /home2/DBName/public_html/wp-settings.php on line 264

    [21-Jan-2011 18:57:53] PHP Warning: require(/home2/DBName/public_html/wp-includes/compat.php) [function.require]: failed to open stream: No such file or directory in /home2/DBName/public_html/wp-settings.php on line 264

    [21-Jan-2011 19:33:39] PHP Warning: require(/home2/DBName/public_html/wp-includes/compat.php) [function.require]: failed to open stream: No such file or directory in /home2/DBName/public_html/wp-settings.php on line 264

    [25-Jan-2011 17:18:04] WordPress database error Table ‘DBName_wpmu.wp_options’ doesn’t exist for query SELECT * FROM wp_options WHERE option_name = ‘blogname’ made by require, require_once, do_action, call_user_func_array, redirect_mu_dashboard, get_dashboard_blog, get_blog_details, get_blog_option

    [25-Jan-2011 17:18:08] WordPress database error Table ‘DBName_wpmu.wp_options’ doesn’t exist for query SELECT * FROM wp_options WHERE option_name = ‘siteurl’ made by require, require_once, do_action, call_user_func_array, redirect_mu_dashboard, get_dashboard_blog, get_blog_details, get_blog_option

    [25-Jan-2011 17:18:08] WordPress database error Table ‘DBName_wpmu.wp_options’ doesn’t exist for query SELECT * FROM wp_options WHERE option_name = ‘post_count’ made by require, require_once, do_action, call_user_func_array, redirect_mu_dashboard, get_dashboard_blog, get_blog_details, get_blog_option

    [25-Jan-2011 17:19:07] WordPress database error Table ‘DBName_wpmu.wp_options’ doesn’t exist for query SELECT * FROM wp_options WHERE option_name = ‘blogname’ made by require, require_once, do_action, call_user_func_array, redirect_mu_dashboard, get_dashboard_blog, get_blog_details, get_blog_option

    [25-Jan-2011 17:19:07] WordPress database error Table ‘DBName_wpmu.wp_options’ doesn’t exist for query SELECT * FROM wp_options WHERE option_name = ‘siteurl’ made by require, require_once, do_action, call_user_func_array, redirect_mu_dashboard, get_dashboard_blog, get_blog_details, get_blog_option

    [25-Jan-2011 17:19:07] WordPress database error Table ‘DBName_wpmu.wp_options’ doesn’t exist for query SELECT * FROM wp_options WHERE option_name = ‘post_count’ made by require, require_once, do_action, call_user_func_array, redirect_mu_dashboard, get_dashboard_blog, get_blog_details, get_blog_option

    [25-Jan-2011 17:20:39] WordPress database error Table ‘DBName_wpmu.wp_options’ doesn’t exist for query SELECT * FROM wp_options WHERE option_name = ‘blogname’ made by require, require_once, do_action, call_user_func_array, redirect_mu_dashboard, get_dashboard_blog, get_blog_details, get_blog_option

    [25-Jan-2011 17:20:39] WordPress database error Table ‘DBName_wpmu.wp_options’ doesn’t exist for query SELECT * FROM wp_options WHERE option_name = ‘siteurl’ made by require, require_once, do_action, call_user_func_array, redirect_mu_dashboard, get_dashboard_blog, get_blog_details, get_blog_option

    [25-Jan-2011 17:20:39] WordPress database error Table ‘DBName_wpmu.wp_options’ doesn’t exist for query SELECT * FROM wp_options WHERE option_name = ‘post_count’ made by require, require_once, do_action, call_user_func_array, redirect_mu_dashboard, get_dashboard_blog, get_blog_details, get_blog_option

    [25-Jan-2011 17:20:48] WordPress database error Table ‘DBName_wpmu.wp_options’ doesn’t exist for query SELECT * FROM wp_options WHERE option_name = ‘blogname’ made by require, require_once, do_action, call_user_func_array, redirect_mu_dashboard, get_dashboard_blog, get_blog_details, get_blog_option

    [25-Jan-2011 17:20:48] WordPress database error Table ‘DBName_wpmu.wp_options’ doesn’t exist for query SELECT * FROM wp_options WHERE option_name = ‘siteurl’ made by require, require_once, do_action, call_user_func_array, redirect_mu_dashboard, get_dashboard_blog, get_blog_details, get_blog_option

    [25-Jan-2011 17:20:48] WordPress database error Table ‘DBName_wpmu.wp_options’ doesn’t exist for query SELECT * FROM wp_options WHERE option_name = ‘post_count’ made by require, require_once, do_action, call_user_func_array, redirect_mu_dashboard, get_dashboard_blog, get_blog_details, get_blog_option

    [25-Jan-2011 17:21:50] WordPress database error Table ‘DBName_wpmu.wp_options’ doesn’t exist for query SELECT * FROM wp_options WHERE option_name = ‘blogname’ made by require, require_once, do_action, call_user_func_array, redirect_mu_dashboard, get_dashboard_blog, get_blog_details, get_blog_option

    [25-Jan-2011 17:21:50] WordPress database error Table ‘DBName_wpmu.wp_options’ doesn’t exist for query SELECT * FROM wp_options WHERE option_name = ‘siteurl’ made by require, require_once, do_action, call_user_func_array, redirect_mu_dashboard, get_dashboard_blog, get_blog_details, get_blog_option

    [25-Jan-2011 17:21:50] WordPress database error Table ‘DBName_wpmu.wp_options’ doesn’t exist for query SELECT * FROM wp_options WHERE option_name = ‘post_count’ made by require, require_once, do_action, call_user_func_array, redirect_mu_dashboard, get_dashboard_blog, get_blog_details, get_blog_option

    Thank you

  • wpmu@dm1n
    • Design Lord, Child of Thor

    Here is the list of tables from my wordpress database from phpMyAdmin:

    wp_1_commentmeta

    wp_1_comments

    wp_1_links

    wp_1_options

    wp_1_postmeta

    wp_1_terms

    wp_1_term_relationships

    wp_1_taxonomy

    wp_3_commentmeta

    wp_3_comments

    wp_3_links

    wp_3_options

    wp_3_postmeta

    wp_3_terms

    wp_3_term_relationships

    wp_3_taxonomy

    wp_4_commentmeta

    wp_4_comments

    wp_4_links

    wp_4_options

    wp_4_postmeta

    wp_4_terms

    wp_4_term_relationships

    wp_4_taxonomy

    wp_5_commentmeta

    wp_5_comments

    wp_5_links

    wp_5_options

    wp_5_postmeta

    wp_5_terms

    wp_5_term_relationships

    wp_5_taxonomy

    wp_blogs

    wp_blog_versions

    wp_registration_log

    wp_sighups

    wp_site

    wp_sitecategories

    wp_sitemeta

    wp_support_faq

    wp_support_faq_cats

    wp_support_tickets

    wp_support_ticket_cats

    wp_support_ticket_messages

    wp_usermeta

    wp_users

  • drmike
    • DEV MAN’s Mascot

    require(/home2/DBName/public_html/wp-includes/compat.php

    Can you confirm that that file exists and if it’s there, that it’s readable by the webserver? It seems to be a common issue with wordpress with a botched upgrade.

    You can grab it from here if you just need the file. There’s a download link at the bottom of that page.

    edit: I noticed that others have had this problem but the line number is 246. You didn;t transpose those numbers by any chance, did you? Line 264 (Link higher in the code so one can see the whole bit) is actually calling the theme’s functions.php file. 246 is calling a locale file which may be the compat.php file. (I have no clue really what’s going on in that bit.)

  • wpmu@dm1n
    • Design Lord, Child of Thor

    Did some comparing in the Root Directory. There are 6 files that seem questionable.

    Two files that are among the wpmu 2.9.2 install files but not the wp 3.0.4 files:

    Root Directory:

    1.index-install.php

    2.wpmu-settings.php

    There are 4 files that are not among either the 2.9.2 or the 3.0.4 install files:

    Root Directory:

    3.default.html (empty)

    4.htaccess.dist

    5.pay-to-blog-paypal.php

    6.php.ini

  • wpmu@dm1n
    • Design Lord, Child of Thor

    Still stumped.

    I deleted:

    index-install.php

    wpmu-settings.php

    Logging in to subdomains still gets me a 404 error.

    If the line: ‘define( ‘MULTISITE’, true );’ is in wp-config.php then I can not even get to the base blog site, I get an error: Error establishing a database connection. This happens with or without the changes Ulrich suggested be made to the .htaccess file.

    If I remove ‘define( ‘MULTISITE’, true );’ from the wp-config.php file I can log in as Super Admin; however, the subdomains still give me a 404 error.

    The Php error log is below, I replaced what I think are my user and database names with generic terms “UserName” and “DBName”, respectively.

    :

    /home2/UserName/public_html/wp-admin/error_log:

    [27-Jan-2011 08:34:39] PHP Warning: require_once(/home2/UserName/public_html/wp-settings.php) [function.require-once]: failed to open stream: No such file or directory in /home2/UserName/public_html/wp-config.php on line 119

    [27-Jan-2011 08:34:39] PHP Fatal error: require_once() [function.require]: Failed opening required ‘/home2/UserName/public_html/wp-settings.php’ (include_path=’.:disappointed:usr/lib64/php:disappointed:usr/lib/php’:wink: in /home2/UserName/public_html/wp-config.php on line 119

    [27-Jan-2011 08:35:16] PHP Warning: require_once(/home2/UserName/public_html/wp-settings.php) [function.require-once]: failed to open stream: No such file or directory in /home2/UserName/public_html/wp-config.php on line 119

    [27-Jan-2011 08:35:17] PHP Fatal error: require_once() [function.require]: Failed opening required ‘/home2/UserName/public_html/wp-settings.php’ (include_path=’.:disappointed:usr/lib64/php:disappointed:usr/lib/php’:wink: in /home2/UserName/public_html/wp-config.php on line 119

    [27-Jan-2011 17:07:56] WordPress database error Table ‘DBName.wp_options’ doesn’t exist for query SELECT * FROM wp_options WHERE option_name = ‘blogname’ made by require, require_once, do_action, call_user_func_array, redirect_mu_dashboard, get_dashboard_blog, get_blog_details, get_blog_option

    [27-Jan-2011 17:07:56] WordPress database error Table ‘DBName.wp_options’ doesn’t exist for query SELECT * FROM wp_options WHERE option_name = ‘siteurl’ made by require, require_once, do_action, call_user_func_array, redirect_mu_dashboard, get_dashboard_blog, get_blog_details, get_blog_option

    [27-Jan-2011 17:07:56] WordPress database error Table ‘DBName.wp_options’ doesn’t exist for query SELECT * FROM wp_options WHERE option_name = ‘post_count’ made by require, require_once, do_action, call_user_func_array, redirect_mu_dashboard, get_dashboard_blog, get_blog_details, get_blog_option

    [27-Jan-2011 17:09:54] WordPress database error Table ‘DBName.wp_options’ doesn’t exist for query SELECT * FROM wp_options WHERE option_name = ‘blogname’ made by require, require_once, do_action, call_user_func_array, redirect_mu_dashboard, get_dashboard_blog, get_blog_details, get_blog_option

    [27-Jan-2011 17:09:54] WordPress database error Table ‘DBName.wp_options’ doesn’t exist for query SELECT * FROM wp_options WHERE option_name = ‘siteurl’ made by require, require_once, do_action, call_user_func_array, redirect_mu_dashboard, get_dashboard_blog, get_blog_details, get_blog_option

    [27-Jan-2011 17:09:54] WordPress database error Table ‘DBName.wp_options’ doesn’t exist for query SELECT * FROM wp_options WHERE option_name = ‘post_count’ made by require, require_once, do_action, call_user_func_array, redirect_mu_dashboard, get_dashboard_blog, get_blog_details, get_blog_option

    _____________________________________________________

    Line 119 of my wp-config.php is:

    require_once(ABSPATH . ‘wp-settings.php’:wink:;

    Both wp-config.php and wp-settings.php are in my root dir with 644 permissions.

    __________________________________________________________

    I looked up my database tables in PhpMyAdmin and there is no wp_options table. There are:

    wp_1_options

    wp_3_options

    wp_4_options

    wp_5_options

    ___________________________________________________________

  • wpmu@dm1n
    • Design Lord, Child of Thor

    How do I go about repairing the database? After deleting from the root dir:

    index-install.php

    wpmu-settings.php

    I can no longer get to the SuperAdmin log-in which used to offer me the “repair” option. Now all I get is the error:

    Error establishing a database connection

    Should I repair all the tables in the database from PhpMyAdmin “with selected” drop down. Or should I try to get back to the WordPress screen that offered to repair the database? Is the process the same?

  • wpmu@dm1n
    • Design Lord, Child of Thor

    Decided to use this method to repair the database https://premium.wpmudev.org/blog/wordpress-maintenance-101-how-to-optimize-and-repair-database-tables/

    So I backed up my database and put the line:

    define(‘WP_ALLOW_REPAIR’, TRUE);

    at the bottom on my wp-config.php file before “That’s all…”

    But since I can not even get to the base site without getting the error

    Error establishing a database connection

    I have to first delete the line ‘define( ‘MULTISITE’, true );’ from the wp-config.php. Now I can get back to the base site. I am able to log in to the SuperAdmin area as usual. But, there is no indication that the database has been repaired. I update the site and the network again. Still no indication of a database repair.

    So, I put the line ‘define( ‘MULTISITE’, true );’ back in the wp-config.php file. I reload my SuperAdmin and I get the error:

    “One or more database tables are unavailable. The databases may need to be repaired”. The word “repaired” is a link.

    I click the “repaired” link and I am taken to a page that list the repair process, summarized as follows(again I changed my database name to DBName):

    Some database problems could not be repaired. Please copy-and-paste the following list of errors to the WordPress support forums to get additional assistance.

    wp_posts: Table ‘DBName.wp_posts’ doesn’t exist

    wp_comments: Table ‘DBName.wp_comments’ doesn’t exist

    wp_links: Table ‘DBName.wp_links’ doesn’t exist

    wp_options: Table ‘DBName.wp_options’ doesn’t exist

    wp_postmeta: Table ‘DBName.wp_postmeta’ doesn’t exist

    wp_terms: Table ‘DBName.wp_terms’ doesn’t exist

    wp_term_taxonomy: Table ‘DBName.wp_term_taxonomy’ doesn’t exist

    wp_term_relationships: Table ‘DBName.wp_term_relationships’ doesn’t exist

    wp_commentmeta: Table ‘DBName.wp_commentmeta’ doesn’t exist

    ____________________________________________________________

    For some reason, the line ‘define( ‘MULTISITE’, true );’ being in the wp-config.php file causes problems with being able to get to my site. Without it I am able to get to my site and SuperAdmin; but, the subdomains don’t work.

    If “wp_1_options should have been renamed wp_options during the upgrade”, I assume the same is true for the tables listed above. For example, wp_1_posts should have been renamed wp_posts during the upgrade.

    At this point do I try to manually rename the tables in PhpMyAdmin?

  • drmike
    • DEV MAN’s Mascot

    There are 6 files that seem questionable.

    7 actually. The wp-settings.php file you have in there is a 2.9.2 version. I have a feeling though that you have a lot more than 7 files mixed between versions.

    Not talking about going ahead and deleting files. You have incorrect files. Like holding a book about the Red Sox and discovering it’s filled with pro Yankee material.

    I;m thinking when you upgraded the files in step 6 up there in your first post, those files didn;t get replaced.

  • wpmu@dm1n
    • Design Lord, Child of Thor

    Clarification before going forward…may or may not change things:

    Before I posted that after making the changes below I was getting a different 404 error:

    ______________________________________________________________

    Posted on 25th January 2011 (2 days ago) #

    Thanks for the suggestions. However, I’m still having some problems.

    I did what you said:

    Adding the following lines to the file wp-config.php:

    define( ‘MULTISITE’, true );

    define( ‘SUBDOMAIN_INSTALL’, true );

    Removed:

    define( ‘VHOST’, ‘yes’:wink:;

    And replaced all the lines in the file .htaccess by what you typed above.

    1.Log-in of sub-domain site seemed to happen; but the page still shows an Error 404. This time the 404 page is formated with the blog css template.

    __________________________________________________________________

    Sometimes a picture is worth more than words:

    I will try to upload an image of the Subdomain admin and about pages (these are what happens when the line ‘define( ‘MULTISITE’, true );’ is deleted from wp-config.php:

    Does this clarify or change anything?

  • wpmu@dm1n
    • Design Lord, Child of Thor

    Ulrich asked

    Posted on 28th January 2011 (3 days ago) #

    Did you try running ‘/wp-admin/ms-upgrade-network.php’?

    If this is “run” by going to SuperAdmin> Update> Update Network, then yes. I have updated through the Dashboard in SuperAdmin also. If ‘/wp-admin/ms-upgrade-network.php’ is not run through the above ways, then No.

    Are the images I uploaded showing. Are they helpful?

    What would cause a wordpress style html 404 error page to come up instead of the subdomain Admin page when subdomains are logged in? At appears that log in happens. The about page is there, from which log-out is possible. The problem seems to be in getting the subdomain Admin pages to show.

  • wpmu@dm1n
    • Design Lord, Child of Thor

    drmike said

    Posted on 28th January 2011 (3 days ago) #

    There are 6 files that seem questionable.

    7 actually. The wp-settings.php file you have in there is a 2.9.2 version. I have a feeling though that you have a lot more than 7 files mixed between versions.

    Not talking about going ahead and deleting files. You have incorrect files. Like holding a book about the Red Sox and discovering it’s filled with pro Yankee material.

    I;m thinking when you upgraded the files in step 6 up there in your first post, those files didn;t get replaced.

    Did some comparing in the Root Directory. There are 6 files that seem questionable.

    Two files that are among the wpmu 2.9.2 install files but not the wp 3.0.4 files:

    Root Directory:

    These files have been Deleted

    1.index-install.php

    2.wpmu-settings.php

    There are 4 files that are not among either the 2.9.2 or the 3.0.4 install files:

    Root Directory:

    Should these files be deleted as well?

    3.default.html (empty)

    4.htaccess.dist

    5.pay-to-blog-paypal.php

    6.php.ini

    Beyond the above, what are you suggesting?

    Note:

    1. That the wp-admin and wp-include folders were deleted and replaced with versions from 3.0.4 long ago during upgrade.

    2. The loose files in the root directory (not listed above) show “modified dates” consistent with being updated during upgrade.

  • wpmu@dm1n
    • Design Lord, Child of Thor

    I know they mean the same thing; but, should I have both (will it hurt to have both)?:

    define( ‘SUBDOMAIN_INSTALL’, true );

    and

    define( ‘VHOST’, ‘yes’:wink:;

    What is the correct setting for this and could this be why the subdomain admin page shows a 404 error?:

    define( ‘NOBLOGREDIRECT’, ” );

  • Mason
    • DEV MAN’s Sidekick

    Hiya wpmu@adm1n,

    The noblogredirect define is for when someone tries to access a site that doesn’t currently exist. This define will automatically redirect them to a page of your choosing (like a signup page or your main site).

    It isn’t mandatory, but also shouldn’t be causing you a problem here. I’ll ask the devs to take another look at this with ya though. Frustrating to have it continuing after this long, I know.

    Thanks!

  • wpmu@dm1n
    • Design Lord, Child of Thor

    Thank you,

    I wonder if the images I uploaded can be seen? If so, do they help at all in narrowing down the problem?

    From what I can tell from the advice given above and from how the problem presents:

    Something is blocking the subdomains’ Site Admin pages from showing

    Or,

    Something is substituting the “404 error Not Found” for the subdomains’ Site Admin pages

    Or

    The Site Admin file is missing or not replaced with the 3.0.4 version.

    Or,

    The connection between the subdomain Site Admin and the login is broken

    Or

    Tables are missing (although, since deleting the line ‘define( ‘MULTISITE’, true )’ I have had no indication of missing tables).

    ________________________________________________________

    I wonder, without the line ‘define( ‘MULTISITE’, true );’, what (in the wp-config.php) indicates that this install is a MultiSite/Network?

  • wpmu@dm1n
    • Design Lord, Child of Thor

    I appreciate your willingness to troubleshoot the problem directly. However, giving out my account passwords/direct access is against the terms of service I agreed to with my host. Additionally, if only one person is making changes in the install, issues that develop are easier to track. I also perfer to keep the problems with and vulnerabilies of my install, anonymous. However, I will gladly fetch images of anything you need to see (editing out personal identifiers). I hope this does not put you off and prevent you from helping further, because I certainly need all the help I can get. Thank you.

  • wpmu@dm1n
    • Design Lord, Child of Thor

    As usual it was something uber simple. Before upgrading to MS 3.0.4 from wpmu 2.9.2, I forgot to change the name of the plug-ins folder:

    /public_html/wp-content/mu-plugins to something like mu-pluginsCommentedOut.

    This would have prevented any of the plugins from running until I had properly ironed out the upgrade. Then, I could have upgraded/tested one plugin at a time to catch any problems that might have popped up. Which, is what I am doing now. So far, no problem.

    The problem was being caused by the 2.9.2 version of pay-to-blog plugin.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.