WordPress MU

Why are all subdomain blogs given a site id = 1, regardless of which top level domain wordpress mu website it was set up from (using wp-signup.php)

When created, the subdomain blog is showing the URL as hanging off the correct domain, but i have to go in and manually edit that new blog in phpMyAdmin to change the site id to match the top level domains site id. Otherwise you can't log in etc.

I'm running Wordpress MU 1.3.3 on a VPS (cPanel, Apache setting up parked domains etc), MySQL 4.1.22 (standard)

This may be an intentional feature, but I'm not so sure...

So you're running the sub-blogs off multiple domains? Using any plugins or doing it manual?

yes, sub blogs off multiple domains. Everything else works fine and once I've changed the site id, the subdomain blogs then work perfectly.

I take it that this isn't normal behaviour then!

I'm using a variety of plug ins. In the muplugins folder, there's MU Multi Site 0.0.4 (although I installed this after I noticed the problem, as it does seem to mean I don't have to edit the SQL tables directly!), Plugin commander 1.0.2, phpMyAdmin etc.

There's a host of plugins in the main plugins folder, which I haven't activated yet, although from my recollection, this particular issue occured before I even put got hold of most of the plugins in - it was fairly early on in the development of our system.

sorry, i just re-read your question. this happens when going to the website and using wp-signup.php

"there's MU Multi Site 0.0.4 (although I installed this after I noticed the problem, as it does seem to mean I don't have to edit the SQL tables directly!),"

Well, there you go. :) That definately has something to do with it.

If users are ging to your *main* domain and signup up there, then yes - site id #1 would be correct.

they have to go to a domain off that (one of your other "sites") and use the signup page on that one to be properly associated with that domain.

If that's what they are doing, then it's the multi-site plugin causing it. That plugin is.. ugh... needs work. :-/

Well, I've just removed that plugin completely and the problem still persists...

As I say I installed the MU Multi Site plugin "after I noticed the problem". It was to try and find a fix to the site id not being updated correctly in the first place!!!

To confirm, people going to one of our other domains DO appear to have their web address set as a sub-domain of that tld (so the URL is being constructed correctly). It's just the site id that has to be changed by hand.

"As I say I installed the MU Multi Site plugin "after I noticed the problem". It was to try and find a fix to the site id not being updated correctly in the first place!!!"

So what were you doing before that? Manually or your own script?

By using the standard wp-signup.php page (through a web browser) from the appropriate web site.

I'm not sure if this constitutes 'manually' or 'a script' as per your question, but its at least using the default functionality within WPMU.

By before that, I mean before your tried the MSM plugin. You know, for the extra domains?

So just to clarify, to make sure I've got what you mean:
You have mU installed at domain1.com. People sign up for a blog at domain2.com.
Correct?

Yes, before I tried the MSM plugin.

I have mU installed at domain1.com. People sign up for a blog at domain1.com, domain2.com, domain3.com, domain4.com etc etc.

However, regardless of which domain they sign-up via, their blog always get assigned site id = 1. However, their blog URL is correct i.e. blog.domain1.com, blog.domain2.com, blog.domain3.com or whatever site they've signed up from.

Obviously they can never log on until their blog site id matches their blog URL.

Make sense? Well it doesn't, but you get what I mean...!

I don't know if this helps, but this post:
http://mu.wordpress.org/forums/topic.php?id=3275&page&replies=59

talks about exactly my problem (close to the bottom of page 1, the third post from Pumpkinslayer, just afer drmikes response) is clearly stating that site id=1 is actually hard-coded into wpmu-functions.php

As Pumpkinslayer hints, the code has to be fundamentally changed to make the site id dynamic, based on the current
URL used for signup.

It would therefore appear to be an intentional 'feature' of wpmu to set all subdomain blogs (irrespective of tld) to site id=1, although I fail to see why this would be of any benefit to anyone...ever!?!?!

*scratches head*

yeah, I get what you're saying now (have to be sure). Although I dunno why the site id is hardcoded in there. especially as it says elsewhere here on the site that "to MU, a domain is just a domain".

NO WONDER people are having issues with this.

the MSM plugin did (near as I can remember) set the site ID to the right one, when you set up a *new* domain. But like I said, it's a little buggy.

Hmm. I'm gonna hafta think about this for a bit.

Well, yeah if I use the MSM plugin to move a subdomain blog to a new site, it seems to update the site id correctly and everything then works.

Going back to the standard WPMU web interface, if I add a new blog (logged in as Admin, Site Admin > Blogs > Add blog), this also works fine - the sub domain blog gets assigned the correct site id for the domain I'm currently logged in as.

It really does just seem to be through the wp-signup.php page from any site other than the root (WPMU) domain.

I was starting to think I was going mad - kinda of imagining a problem that no one else was experiencing. Trying to find any other posts about this was near impossible.

We'll try and do some php coding to come up with a solution here, but even with my simple grasp of the problem, it seems to suggest that its a fundamental issue that needs to be permanently addressed by a future update, rather than a fix by us that gets potentially overwritten by the next update...

A trac ticket may indeed need to be filed.

Sorry andrea_r, I'm just bumping this message as its a few days on and your last response was unresolved... ;-)

For anyone else experiencing this problem (and I guess there will be many!) I've now filed a trac ticket (http://trac.mu.wordpress.org/ticket/577).

Unfortunately, as of yet no one seems too bothered by this particular problem. My only hope is that it'll be finally noticed and resolved in a future update...

Ho hum!