Multisite (sub-directories): Sub-Sites get created but don't work

just because you can add entries to the table does NOT mean the ID can create new tables!

Ding ding! You win! ??

@ipstenu @andrea OK – we’re absolutely on to something here.

The wp_SubSiteID_xxx tables are NOT there, so no wp_4_posts, wp_4_options, no wp_5_posts, wp_5_options, etc…
and in our install with working sub-sites, we DO have all those tables created for the sub-sites.

However… the mysql account DOES have “all privileges” to the database. in fact I just now created a brand new mysql login and assigned all privs to this database, and that’s what login wordpress is using to power the test site now… and it’s working. And i tried to create another sub-site. same problem… those other tables are just not being created…

Any idea what else could be causing that??

thanks!
Dan

If this is a fresh install (with your stuff imported), might wanna ask the webhost what’s up.

(Andrea clues in…. oh THAT dan & jennifer… ?? )

Edit:
on the sites you had working, are these physically on the exact same server as this one? with the same specs for php, mysql, os?

and becasue my scroll finger hurts and I can’t scroll back and check – you DID disable all the plugins including any in the mu-plugins folder?

I think I recall you saying up above you made a fresh install and imported your db in. I’d want to test a fresh install *without* your old db content to see if new blogs are created. This narrows down if it’s the server itself or something in the db.

(Andrea clues in…. oh THAT dan & jennifer… ?? )

LOL ??

If this is a fresh install (with your stuff imported), might wanna ask the webhost what’s up.

Our web host is amazing at keeping our server solid and running, but we maintain all the wordpress stuff ourselves.

on the sites you had working, are these physically on the exact same server as this one? with the same specs for php, mysql, os?

yep, all our sites are on the same VPS which has plenty of resources to spare, just different wordpress installs.

you DID disable all the plugins including any in the mu-plugins folder?

hmm, don’t have an mu-plugins folder on any of our wordpress 301 multiste installs…. so no plugins in there then.

I think I recall you saying up above you made a fresh install and imported your db in. I’d want to test a fresh install *without* your old db content to see if new blogs are created. This narrows down if it’s the server itself or something in the db.

Just to circle back, here’s what’s WORKED GREAT so far:

• just for practice, did a brand new fresh install of WP 301 and converted it to multisite. flawless. then did an import of 4 of our wordpress sites into it just to test: 1 as main blog and 3 as additional sites. again flawless.
• upgraded a less-mission-critical website (www.TodayIsThatDay) from WP291 to WP301. flawless. then enabled multisite on it.

here’s where it got rocky (read: muy mal):

1.) upgraded our main site https://www.AskDanAndJennifer.com from WP291 to WP301. that worked flawlessly.
2.) a week later (after the practice with the other sites) enabled multisite on https://www.AskDanAndJennifer.com – here it got rocky…

• enabling multisite went fine far as i could see, like the others.
• BUT any sub-site i create didn’t work, the links from “Super Admin -> Sites” to “Visit” and “Backend” are empty, just goes back to main wp admin. figured i did something wrong so deleted sub-site, and re-added it and another test one. same thing. disabled multisite, re-enabled it. tried a few other things, no luck.
• reverted AD&J back to “NOT multisite”, did a mysql export of all the data, installed a brand new fresh WP301 on another domain (dan-and-jennifer.com) and got it running, then imported just the data tables (posts, comments, users) from the production database. import worked great, site works fine (when plugins are enabled anyway, lol).
• now enabled multisite on the new “copy” site at https://www.dan-and-jennifer.com … had same problems as on https://www.askdanandjennifer.com – but then it’s the same database, even if the “wordpress install” is totally fresh shiny and clean.
• noticed that creating a new sub-site does NOT create a directory with the ID of the new sub-site in blogs.dir – and even though all our installs are directory based, they all create a directory named with the ID of the sub-site in blogs.dir. except askdanandjennifer.com and the test site dan-and-jennifer.com
• and after further debugging and learning and help here, discovered that creating a new sub-site is NOT creating the wp_SITEID_posts/options/etc. tables in the multisite database even though the database account has full permissions fine… what what could be causing this?? a setting somewhere in some obscure option in the database?

So that’s where we are… our server (VPS) is totally capable of running a multisite well, and it’s doing so with https://www.TodayIsThatDay.com and another test site… just not with our most important website and the copy of that we’re using for testing – argh! ??

Thanks!!
Dan

installed a brand new fresh WP301 on another domain (dan-and-jennifer.com) and got it running,

Before you imported in the db from the d&j site, did you check and see if new sites could be created AND work?

noticed that creating a new sub-site does NOT create a directory with the ID of the new sub-site in blogs.dir – and even though all our installs are directory based, they all create a directory named with the ID of the sub-site in blogs.dir. except askdanandjennifer.com and the test site dan-and-jennifer.com

this is UNRELATED to the problem. ?? those directories are only created after media is uploaded to the sub sites. The blogs/site do not live here.

So, you can temporarily forget that bit as relating to the issue.

– we know it’s not the server os
– we know WP works fine on that server with the network
– we know it’s something specific in the d&j database.

So, if you can take that install on your test domain, do not use your backup data, but just as if it were a fresh install, and create a site. See if it works. If so, we’re on to something.

@andrea it’s gotta be the data, just not sure how and why??

the 1st thing I did before touching our existing sites was, just for practice, a brand new fresh install of WP 301 and converted it to multisite. flawless. created sub-sites with no issue. it’s still up and running great. then did an import of 4 of our wordpress sites into it: 1 as main blog and 3 as additional sites. again flawless.

that install is on a separate domain – again using “subdirectories” – that’s how all of ours area – and still working great. no issues… behaves like it’s supposed to…

Dan

OK just did a new experiment… reverted dan-and-jennifer.com to non-multisite in wp-config.php, and actually dropped all the multisite tables with phpmyadmin: wp_blog, wp_blogs, wp_site, wp_site_meta, wp_registration_log, wp_signups.

then re-enabled multisite in wp-config.php, logged in and from “Network” created the new network, took the data and updated wp-config.php. same as always. so new “network”, logged in again, created a test sub-site.

and same problem. ?? the sub-site doesn’t have its wp_xxx_posts/options/etc. argh.

So what we learned here is the mysql user CAN create tables just fine since it re-created the multisite tables that i dropped

but we still don’t know why the individual sub-site tables aren’t being created. ??

Thoughts??? what could cause that?

@andrea – found the bug!!!!!!!!!!!!!! (not the solution per-se, but the bug causing the headache).

breakdown: remember when I said https://www.AskDanAndJennifer.com has been around since before 2.3… since back when latin1 was the default charset (or rather wordpress didn’t set a default and it was MySQL default, don’t recall). regardless, our content is actually all latin1, so we still have to run with this in the config file:
/** Database Charset to use in creating database tables. */
/* define(‘DB_CHARSET’, ‘utf8’); */
define(‘DB_CHARSET’, ‘latin1’);

Well, get this. I created a brand new installation AGAIN, which worked fine. turned on Multisite, which worked fine. but when I updated wp-config.php to add all the Multisite params, I also remembered I have to change Charset to latin1 or won’t be able to import all our AD&J posts in the next step. so I did that. guess what – created a sub-site and it DIDN’T WORK – same problem!!!

and it hit me.. wait, the charset! so I deleted the broken sub-site, then went back in and changed charset to UTF8 in wp-config.php and created a new sub-site.

Summary: it has to do with charset and creating tables for the sub-sites. if charset isn’t set to utf8, then sub-site tables are not created.

this wasn’t impacting my brand newly created sites because they were already utf8…

So this presents 2 issues…
1.) this looks like some sort of table creating bug in WP301 I think, so will impact anyone still running with Latin 1 charset (that means most anyone who’s been upgrading every time since the pre-2.3 days)

2.) how can we get all our data (posts) converted from latin1 to utf8 once and for all so i can just do a full import/export and move to a clean install.
(from lots of searching, I know there are A LOT of posts on this, many of them conflicting and contradicting one another… i have yet to see a definitive one. spent last week tinkering with all those options and ended up with broken data in the test site in the end).

Thanks!
Dan

DOH! the charset!!! Darn, I remember that one too! Well, NOW…. ?? lol…

1) Yeah, the latin1 shows up becasue WP back in the day just used the default set on the box.. which on most shared hosts with cpanel, was automatically set to latin1.
(for more background for the eventual searchers)

2) Lemme go ask someone smarter than me in this issue and get him to put his input. I know I’ve dealt with it before, and my memory sucks sometimes. ?? But, he’s my buddy so it works out.

What are the defined values for DB_COLLATE & DB_CHARSET in your wp-config.php?

Hi Ron.

assuming you mean DB_COLLATE / DB_CHARSET only for the broken sites with the latin1 charset, where multisite doesn’t actually work:
define(‘DB_CHARSET’, ‘latin1’);
/* define(‘DB_COLLATE’, ”); */
DB_COLLATE was actually not even in that old pre-WP2.3 config file, so it’s in there just for posterity, commented out.

in the perfectly working brand spanking new installs (can create mini sites and they all work great) i have it like it comes default these days:
define(‘DB_CHARSET’, ‘utf8’);
define(‘DB_COLLATE’, ”);

Thanks!
Dan

Try

define('DB_COLLATE','latin1_general_ci');

@ron HA!!!! That fixed it! i’ve just successfully created sub-sites under the latin1 charset installs and they work perfectly. Thanks!

@andrea, @ipstenu, thanks so much for your help.

So to summarize this for someone else having this problem, the moral here is that if your WordPress encoding is latin1 (i.e. if you’ve had the site since the defaults before WP2.3) – then for Multisite to function and create tables for new sub-sites, it requires DB_COLLATE set accordingly, per Ron’s post above:
define(‘DB_COLLATE’,’latin1_general_ci’);
————

@ron, do you know of an actually reliable way to convert our current data (posts,comments,categories, users) from latin1 to utf8? from lots of searching, I know there are A LOT of posts on this, many of them conflicting and contradicting one another… i have yet to see a definitive one. i suspect just standard wordpress export/import would DO it, but it won’t work as it messes up all the category/tag slugs and loses all the user info. Recommendations?

Thanks!
Dan

Woot, awesome.

I remember (I think) that Ron and I did a couple installs with this issue and even have one of our own where we confirmed it’s doing the same thing and needs the same fix.

(You know how you’re Dan & Jennnifer? We’re Ron & Andrea. ?? )

We’re on different shifts so I’ll confab with him in a few hours.

(You know how you’re Dan & Jennnifer? We’re Ron & Andrea. ?? )

Nice. LOL there are certainly few downsides to working with your spouse, but as long as you actually like your partner, it’s a really good thing. ??

Woot, awesome. I remember (I think) that Ron and I did a couple installs with this issue and even have one of our own where we confirmed it’s doing the same thing and needs the same fix.

We’re on different shifts so I’ll confab with him in a few hours.

Awesome, thanks Andrea!
Dan