Dan & Jennifer
Forum Replies Created
-
***** It works now!!! ****
Turns out to have been some type of caching issue, because after making all the db changes as expected it did NOT work, but a few hours later it magically did.@andrea agreed – though a broken config (read: user error / typo lol) can still cause that type of server error.
Your tip was very helpful btw – I was concerned that Multisite may be hard-coding the filesystem path in a config file somewhere, and you assuring me it does not definitely helped. 🙂@ipstenu thanks, great point, though in this case I literally only moved domain1.com to domain2.com, same directory structure.
So, it works…. we’ve been running our production site on WP3 Multisite since the last migration Saturday morning (2 days now), and it’s been working flawlessly with the 3 previously separate wordpress installs as sub-sites.
The main website – Ask Dan & Jennifer
– 1st sub-site – Ask Dan & Jennifer – Love & Sex Reviews
– 2nd sub-site – Ask Dan & Jennifer – Best Sex PlacesBefore the migration-to-production I did some further testing and narrowed this down (and was able to duplicate the error scenario on the 2nd test move btw) – will update the ticket with more details for future queries.
Thanks guys for the quick answers!
DanHey Andrea! LOL yeah, followed the “moving multisite” instructions on that page, though they are quite brief. regardless it implies it’s the same process as singlesite, just more involved, and that it was. 🙂
over last cpl of years I’ve moved wordpress (single site) many times manually – just by changing the domain/url/paths in the database with phpmyadmin, worked flawlessly.
You need to do a search 7 replace on the entire database.
Agreed, forgot to mention that above. so yesterday I figured out how to do that easily on the server… exported the whole db to a text file and searched it for the unique string that the domain and URL share (what i’ve been replacing).
here’s how i did it
`mysqldump –opt –default-character-set=utf8 –skip-extended-insert –user my_user –password my_db -r exp-utf8-2011-06-03.sql –log-error=log-mysqldump.txt
grep -i “/my-path-here/” ./exp-mydb-utf8-2011-06-03.sql > find.txt`I know this works because I did find 2 places i had missed it (wp_2_options i think – some plugin setting) – and fixed that, but no go, still broken, same error.
My question – could that directory path be hard coded in any text file in the whole multisite install? i’ve gone thru wp-config.ph and .htaccess and it’s clean, but could it be anywhere else?
that is what it’s looking like for me… because it’s not in the database anymore, so that means it has to be in a file. but i dont have a way to search files as easily as i can search the db… plus it gets ALL the error_log files which contain plenty of this error with that exact string, argh.
also completely uninstalled w3totalcache and removed all cache files – just in case, so that’s not it.
Thanks!
DanHi Arne!
Do you have an estimate on when the multisite-updated XML Sitemaps plugin version will be ready?
We’ve been holding off migrating our several WordPress sites into a single Multisite one until then. 🙂
Thanks!
DanOh, I remember why we didn’t go with this one “sitemap feed” – saw this note on the plugin page: “The feed contains the front page and all posts and pages but excludes category, tag and other dynamic archive pages.”
some of our tag and category pages are some of our highest ranked site pages…
LOL been using Arne’s plugin for 3 years, it’s worked great, and the update’s almost here… I’m patient. sort of. 😉
Dan
@andrea hmmm, I’m confused then… Referring to this plugin:
Google XML Sitemaps – on the page it says it’s not “yet” multisite ready.And I’ve been following this WordPress support thread for the plugin by the author (Arne) as he’s alpha testing the new version which does have it.
Now i know there’s Multisite port of his previous release which someone has released (this one i think) but not confident to try that one, it’s not by the same author.
by the “alpha testing” support thread though I’d expect the final release of the XML Sitemaps plugin with Multisite support within a week or two at most.
Am I missing something?
Thanks!!
Dan@ipstenu LOL yeah, I’ll be saying that too in about a year. 😉
Frankly getting it “wrangled” (which is quite the understatement for the past few weeks) wasn’t too much of a priority, but it came to a head with the Multisite upgrade issue.
Have an awesome day!
DanGuys – very happy to say we finally resolved the charset / encoding issue for our WordPress installs. We’ve documented the step by step process for anyone else having this charset issue:
Hope that helps!
And thanks everyone for your help in troubleshooting the Multisite issue!
Now as soon as Arne’s Google (XML) Sitemaps Generator plugin comes out with Multisite support (hopefully any day now), we’ll officially be on Mulsitie for all our websites. 🙂
Have an awesome day!
Dan@speedtriple that’s really great to hear. 🙂
(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@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!
DanForum: Networking WordPress
In reply to: Amazon S3Hmmm, I know CDNTools supposedly does this, but dono whether it works with Multisite… you might check with the author. * scratch that, just saw that S3 is “coming soon” – now it’s ust CloudFiles (Rackspace)
http://ww.wp.xz.cn/extend/plugins/cdn-tools/We also run W3TotalCache and it MAY auto sync media, though I’m not sure if it does. http://ww.wp.xz.cn/extend/plugins/w3-total-cache/
we have all our static content running on Rackspace Cloudfiles and are very happy with it; it’s also less expensive than Amazon. but it’s not set up to auto-sync as we don’t have the need for user-shared images, etc, for us it’s just the site images that don’t really change much.
Have an awesome day!
DanHi 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@andrea – found the bug!!!!!!!!!!!!!! (not the solution per-se, but the bug causing the headache).
breakdown: remember when I said http://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!
DanOK 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 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