This is correct, and unfortunately neither are compatible without a core hack. The root of the problem is due to the pervasive use of absolute urls in wordpress. So at the moment only path-based installations are compatible and only if the core patch is applied (and I haven’t updated the patch to work for 3.3 so you’d have to investigate the new version on your own.) And honestly after working with the MU system for wordpress for the past year I don’t recommend it at all from a usability or architecture perspective. It’s just a giant hack on top of the wordpress base install.
By any chance were you able to come up with the mu ‘hack’?
Because I don’t have a better solution than to use mu, I’m kinda stuck having to use it.
I just read through the trac ticket and you make such a perfect argument that I am shocked that it is not being seriously considered. Here’s to hoping that maybe in a near distant future the core team will give it more consideration as the benefits are huge.
Unfortunately I don’t have a one size fits all solution. It really depends on the number of users and whether each user needs access to mutltiple sites. Given the existing pain in managing users under the current MU install I’d wager it would be easier to just create separate installations of a single install and try to automate the upgrade process across each installation. Granted this means N databases, N apache configs, N admin accounts etc but if you can knock out a few shell scripts and your users don’t need cross-site access then you’d be better off in my opinion. Unfortunately the wordpress core team is committed to keeping this application an install in one place and manage in one place only package so I doubt they’ll be open to retrofitting the mu architecture in any significant way.
And the root problem of absolute urls will prevent any sane architecture and the core team has officially rejected such a design. It’s sad to say but this is one of those cases where investing heavily into an application framework like codeigniter or joomla will yield better results (at a higher price of course.)
I’m sad to hear that it’s been officially rejected. Appreciate the heads up and information. Supppose I will keep muddling along.
I’m going to mark this as resolved since there isn’t much I can do about it. If in the future I ever get the time to hack around the MU problem I’ll be sure to update you. But alas we’ll just have to keep muddling along 😐
Sounds good. I just wish they would get rid of the absolute urls in the source. I doubt I’ll ever understand why they are there in the first place, but oh well…
From at least one core developer they are there for three reasons: 1. you “need” a unique identifier to search on when migrating a wordpress install to a new domain or to a subdomain, so the full domain name is the best identifier to search on (I don’t think he realized the power of url rewrites in combination with root relative urls.) 2. Absolute urls are context independent, so if your content is printed in a book it will still make sense, whereas root relative urls are not relative to the book (even though on export programmatically adding the domain to root relative urls is part of the internet spec.) And 3 – there was some sort of reasoning that content should only ever exist in one location, so absolute urls do not cause problems. He further clarified that you should never under any circumstance put production content into a staging database, so if you put content in a staging database and you expect it to work in production you are doing it wrong. Again, he probably never worked in a continuous integration shop where content has to go to a staging / blessing server first, and then migrate without human intervention to production after QA approval.
The rest of the excuses were either a lack of knowledge regarding best practices, technical feasibility, or insanely unrealistic expectations, like in the event you need to host content on two different sides of a DMZ for a government contract, you should tell the 4 star general he’s an idiot for using a DMZ because it’s likely configured incorrectly anyway… which was apparently a true story experience of Otto the Tech Ninja.
In the end there are no valid reasons for using absolute urls for local content and yet there *are* reasons that 97 of the top 100 alexa sites use root relative urls, including wordpress.org and wordpress.com. Two of the sites that don’t are wordpress installs, and the final one was a russian server that looked like it hosted content produced in the late 90’s.
Don’t feel bad that you don’t understand it either. The one truth I could extract from a core dev is that changing the infrastructure at this point with 65+ million installations would be a risky change that they are not going to prioritize over other features. I far more realistic explanation than “it doesn’t work” or “you’re doing it wrong.”
Ha.. your last paragraph is probably the most accurate statement of all.
While most of the time it’s appreciated, sometimes I think WordPress takes backwards compatibility way to serious, even to their own detriment at times. Even the table structure doesn’t make sense at times, and yet any changes are like voodoo around here.
The longer they wait, the harder it is going to become, where I fear that someday, they will go so far down the rabbit trail, that they can’t change.
Thanks for the detailed explanation. Who knows, maybe someday someone will find this and just plain decide it’s time for a change.
