Support » Networking WordPress » What's the core logic of Multisite ?

  • Hi,

    Ok, first, I’ve read many tutorial that explain the How, but never the what or the why. So here’s what I’ve tried yet… I would appreaciate if you could point me out where I’ve made a bad assumption:

    Right now, I have 2 WP installations:
    – mysite.com/fr/
    – mysite.com/en/

    Ps.: Do not go offtopic by suggestion Translation plugin please, let’s pretend it’s 2 different blog, not translations.

    I wanted to use WP MU to manage both at the same time, like on wordpress.com, when you have multiple blog on a single account.

    So I go in the /fr/ installation, and follow the steps to activate MultiSite. Now I have the SuperAdmin box. So I go in sites, and try to link the /en/ installation.
    First of, the interface seemed weird, I must enter a path, but the following prefix is mandatory:
    mysite.com/fr/ [ input box ]

    So I try “../en/” , but it doesn’t work.
    So I enter “en”, and then when the “mysite.com/fr/en/” site is created, I edit the path in the modify page to put “mysite.com/en/”

    Now I go in the Super Admin / Themes tab, and make sure my child theme and the parent theme are allowed on the network.

    And then I Update the network.

    I connect myself to the admin panel of my /en/ installation, but the child theme is not there at all.

    Can someone explain me the basic logic behind Multisite ?
    – Does it LINK existing workpress installation in a super-admin panel ?
    – Do I need to activate Multisite on ALL installations that I want to manage ?
    – Is it only 1 big installation, called Multisite, that emulate many blog (so I do not have to make multiple installations, as they are dynamicaly created on the fly)
    – Why is there a mandatory prefix ? It’s like if I *HAD* to have a WP installation on the core domain, then the child site have to be on subdomain or subfolder, but couldn’t be in parent or same level.

Viewing 15 replies - 1 through 15 (of 20 total)
  • Andrea Rennick

    (@andrea_r)

    Customer Care at Copyblogger Media and Studiopress

    – Does it LINK existing workpress installation in a super-admin panel ?

    NO, it does not. once you activate the network, you create new sites in the same install. this is exactly how WordPress.COM works.

    – Why is there a mandatory prefix ? It’s like if I *HAD* to have a WP installation on the core domain, then the child site have to be on subdomain or subfolder, but couldn’t be in parent or same level.

    Because not everyone wants the same setup. If you want multiple top-level domains, there’s a plugin for that.

    Ah… I see, thanks 🙂

    Could you point me out the plugin for the multiple top-level domain ?

    Just to be sure, for you, there is no distinction between “top-level domain” and “same level folder” ?

    My case is really:
    – mysite.com/fr/ <!– One site, multisite installed from here
    – mysite.com/en/ <!– another site

    FMaz008: This might help:
    http://ottopress.com/2010/wordpress-3-0-multisite-domain-mapping-tutorial/

    But note that yes, your main install must be at the root. You can’t make “same level folder” installs work on multisite.

    Create the main site at the root, then the subsites in subfolders.

    But I’m on the same domain, no ? (mysite.com)

    I must consider my case as 2 distincts domains ?

    No, you must consider that WordPress can’t make same-level folders because that’s not how webservers work.

    If your main site was example.com/whatever/, then all the sub-sites must be underneath that. It can’t magically go back a directory and create side by side things.

    You mean because it need an .htaccess to parse the URI and determine the route to the correct blog ?

    What if I put & tweak the .htaccess in mysite.com/ ?

    No, it doesn’t use an .htaccess to determine the route or parse the URI. It does that internally.

    If you want to have side by side sites, then the main site must be below them, at the root URL. No way around it.

    Why your saying their’s no way arround ? Technically, it’s possible.
    The idea is to forward all request from / to /fr/.

    Request:
    mysite.com/en/article12

    Parsed by mysite.com/.htaccess

    Then the following rewrite would occur:
    mysite.com/fr/en/
    to
    mysite.com/fr/

    And then the mysite.com/fr/.htaccess file would thread the request again, not even knowing that it has been previously rewrited.

    So the /.htaccess file should handle 2 exceptions cases:
    – The main WP installation ( in this case /fr/ ) as we don’t want the result to be /fr/fr/
    – The files in / , in my case that would be a static negative condition. So, do not rewrite everything that doesn’t match: (\/fr\/(.*)|\/en\/(.*))

    My not a pro with rewrite, but I’m sure that’s possible, and I’ll prove your “No way around it.” statement to be wrong 😉

    Hum, your right, WordPress doesn’t take in consideration the $_SERVER[‘REDIRECT_URL’] variable in his route handling system, so the URL treated by WordPress is the URL in the browser bar, not the real one on the server in case of a redirection.

    I’ve open a enhancement bug request about that with a fix suggestion.

    Andrea Rennick

    (@andrea_r)

    Customer Care at Copyblogger Media and Studiopress

    but I’m sure that’s possible, and I’ll prove your “No way around it.” statement to be wrong

    Considering a good half a dozen core devs, including people behind WordPress.COM say it’s not possible and have spent literally months trying to figure it out….

    feel free to try.

    Also, the only people who have ever come close and says it’s working either:
    – did really convoluted server horking
    – can’t login to the backend of subsites

    Don’t want to be mad about anyone, and I’m not better than anyone. But technically speaking, wordpress is not known for his good code.

    If you search in the whole wordpress code base, they never use the php $_SERVER[‘REDIRECT_URL’] variable. That’s just weird, and that’s why I pointed that out in the ticket I’ve openned.

    Quoting mfyahya from php.net:

    If you use Apache’s redirection features for custom error pages or whatever, the following Apache’s REDIRECT variables are also available in $_SERVER:
    $_SERVER[‘REDIRECT_UNIQUE_ID]’
    $_SERVER[‘REDIRECT_SCRIPT_URL]’
    $_SERVER[‘REDIRECT_SCRIPT_URI]’
    $_SERVER[‘REDIRECT_SITE_ROOT]’
    $_SERVER[‘REDIRECT_SITE_HTMLROOT]’
    $_SERVER[‘REDIRECT_SITE_CGIROOT]’
    $_SERVER[‘REDIRECT_STATUS]’
    $_SERVER[‘REDIRECT_QUERY_STRING]’
    $_SERVER[‘REDIRECT_URL]’

    I’m still investigating and testing stuff, but I’m now able to display the /en/ site correctly, by using my rewriting of /en/ to /fr/en/.

    I’ve done alot of try & error, so it’s not a definitive solution, but it turned out that I’ve been able to solve part of my problem by doing the following mod:

    Near the line 67 of the file ms-settings.php, I’ve remplaced this:
    $blogname = htmlspecialchars( substr( $_SERVER[ 'REQUEST_URI' ], strlen( $path ) ) );

    By this:

    $reqUri = isset($_SERVER['REDIRECT_URL']) ? $_SERVER['REDIRECT_URL'] : $_SERVER[ 'REQUEST_URI' ];
    		$blogname = htmlspecialchars( substr( $reqUri, strlen( $path ) ) );

    This first path will load the good site, but the “article fetching” will not be ok. You’ll have the good site loaded, but it will report the error message “article not found”.

    To solve that part, I have to modify classes.php, WP::parse_request() method, near the line 161, replacing:
    $req_uri = $req_uri_array[0];

    By:
    $req_uri = isset($_SERVER['REDIRECT_URL']) ? $_SERVER['REDIRECT_URL'] : $req_uri_array[0];

    Now I have the front page displayed correctly in the good site. Next problem: all the links are using the /fr/en/ path. So it must be related to some kind of ROOT_PATH_URL constant or something like this.

    I’m still investigating.

    Note: My admin panel is accessible in both /en/wp-admin/ and /fr/en/wp-admin/ , but as all the link redirect to /fr/en/, I’m redirected there as well after the login.

    You know, you’re going to an awful lot of trouble when all you have to do is install WordPress at the root of the site. It’s pointless. Just move WP to the root, then install both fr and en as separate sub-blogs. Done.

    It’s simpler when you do things the right way.

    TLDR: It’s broken, I’m fixing it.
    ——-

    Think out of the box; WordPress is a blog system, and we’re not all using WordPress as a CMS, but often as a part of larger sites.
    I have a site at the root of the domain, I can’t ovewrite it with a wordpress installation. What I could do is to create a /blog/ folder, and then install it inside, but that would be against the SEO planning of my client.

    I might go in alot of trouble, but for me, it only point out that there is a trouble in the system. I’m on the way for fixing a problem. And listening to you, I’m not the first who seem to ask for that feature, so I don’t think that it’s pointless to get involved in the developpement of that compatibility feature.

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    Lead Plugin Wrangler

    I have a site at the root of the domain, I can’t ovewrite it with a wordpress installation.

    You don’t have to overwrite it.

    You could choose to ONLY use WordPress for the index page and have the rest of your site be what it is. Or you could import your site and make THAT run by WordPress.

Viewing 15 replies - 1 through 15 (of 20 total)
  • The topic ‘What's the core logic of Multisite ?’ is closed to new replies.