WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Tagged: multisite Toggle Comment Threads | Keyboard Shortcuts

  • John Blackbourn 8:22 pm on May 13, 2014 Permalink
    Tags: , , multisite   

    Agenda for tomorrow’s Multisite chat 

    We’re having a dev chat about Multisite in #wordpress-dev tomorrow (May 14, 2014 18:00 UTC). I’d like to split the chat into two main areas:

    1. Open vs. closed networks
    2. Everything else

    The concept of an open network where users can create their own sites was the popular impetus for WordPress MU, but is decidedly not the primary use case for multisite anymore. Most operate closed, trusted networks, where site signups are disabled (and often user signups are disabled as well).

    Back in October, Andrew Nacin published a collection of thoughts on potential changes to Multisite, one of which was the idea of open vs. closed networks. I’d like to discuss this concept and whether now is the right time to tackle it. Here are some relevant paragraphs from that post:

    When a network is not designed for “open registration”, there are a number of undue burdens that should be lifted for administrators. Uploadable file types are severely restricted, and the amount they can upload is capped. They cannot activate installed plugins, though there is an option for this. They cannot add users to their sites without knowing their email address (ostensibly to prevent spam), and the user must still go through a “confirmation” process. New sites must go through an “activation” process. They cannot create new users.

    I don’t think WordPress needs to decide that the multisite feature is only geared for closed networks. Rather, a single option — set on install, and controllable via network settings — can control this entire paradigm very effectively.

    Essentially, I am proposing we trust single-site administrators in a closed network to not be spammy, and to be given wide-ranging control of their own sites; but that we do not extend that trust to important areas of security.

    So, let’s discuss whether now is the time to introduce the concept of open vs. closed networks, what form it takes, and to which functionality it extends.

    • What differences should we see between an open network and a closed network?
      • Open user registration
      • Open site registration
      • Capabilities for regular Administrators (plugins, themes, users)
      • Email notifications (amount of, and wording in)
      • User listing and user editing UI differences
      • Site listing and site editing UI differences
      • Network admin dashboard UI differences
    • What form should the open vs. closed network option take? A UI option when installing multisite? Changeable after the fact or set in stone like subdir/subdomain option?
    • What changes need to be considered for existing multisite installs?

    Secondly, let’s discuss all other multisite improvements that we would like to see. Several may well be related to the idea of open vs. closed networks, and that’s ok. Here’s a list to get us started:

    • Reign Rein in notification emails when adding sites, users
    • Improve user searching – #27304
    • Improve user management
    • Better explanations for what archive/spam/delete does to a site
    • Merge in the Hyper Admins plugin
    • Merge in the User Management Tools plugin

    If anyone has particular issues they’d like addressed (bonus points for existing tickets on Trac), leave a comment and we’ll see what we can cover.

    Two other items worth mentioning are:

    • Domain mapping
    • SSL improvements

    I don’t think we’re yet at the stage where we could consider implementing domain mapping in core. It has a prerequisite of removing the subdirectory vs. subdomain paradigm, and we’re not near approaching that (unless someone wants to step up).

    Regarding SSL improvements, I’m planning on arranging a separate working group to tackle a whole raft of SSL improvements in core that aren’t just related to multisite. I’ll be publishing a separate post in the next couple of days to get us started.

     
    • Robert Dall 8:47 pm on May 13, 2014 Permalink | Log in to Reply

      I couldn’t agree more on adding the Hyper Admins and the User Management Tools into core. That makes a lot of sense.

      I could also see real benefit to the Domain Mapping and SSL Improvements.

      Here is why:

      I am actually in the middle of a project where I am using a multi-site for company that has 5 different websites that offer 5 different areas of the products and or services offered.

      So while we could use 5 different installs of WordPress were using the power of multisite to keep the admin to a minimum.

      Domain Mapping will be of great use to this and many other types of multisite usage.

      SSL and wildcard SSL is someone confusing to the uninitiated any improvement to WordPress multisite and SSL would be of great benefit.

    • Sallie Goetsch 8:49 pm on May 13, 2014 Permalink | Log in to Reply

      That’s “rein in.”

      However, I’m really glad to see Multisite getting some attention. I’m not qualified to help develop it, but I’ve noticed the lack of developments in the last several WordPress versions. What IS the status of domain mapping? Do you still need a plugin for it or not?

      Are there any plans to institute network-wide widget areas? Right now network-wide menus are possible with a plugin, but there’s no way to add network-wide widget areas at all.

      How about default theme settings that the network admin can control? I’ve got a project coming up where we’re actually leaning toward NOT using Multisite in part because the network admins would have to go in and configure theme options for each sub-site separately (even though they will be the SAME for each site, with the only difference being a different logo image). We could hack the theme up so it doesn’t have any other options, but that’s not really a good alternative, either.

      I realize these things are too much to ask for 4.0, but wanted to at least add them to the wishlist.

      Thanks!
      Sallie

      • John Blackbourn 3:07 pm on May 14, 2014 Permalink | Log in to Reply

        What IS the status of domain mapping? Do you still need a plugin for it or not?

        Yep, there’s no support in core for domain mapping currently.

        Are there any plans to institute network-wide widget areas? How about default theme settings that the network admin can control?

        Network-wide widgets, menus, and settings are an interesting idea and certainly something I’ve seen requested before. The complication comes when those widgets, menus, and settings need to be present on the main site, which may not be desirable. I’ll add it to the agenda!

    • Rouven Hurling 9:27 pm on May 13, 2014 Permalink | Log in to Reply

      i would love to see #15800 fixed, so that network wide plugins can add a tab the site edit where there can display their options (or in my case, data and options for that client and so on)

    • Knut Sparhell 1:29 pm on May 14, 2014 Permalink | Log in to Reply

      As long as the mulitisite setup can only be done from wp-config.php this should also be where to set a WP_IS_TRUSTED_NETWORK constant. You don’t specifically install a multisite, you install WordPress and transform it to mulitsite by editing wp-config.php.

      The spam site option may be removed unless some sites actually have it set already. The way links was deprecated is the way to go.

      Users should be registered through a signup process to avoid sending passwords over email. Single sites could also gain from a better signup process. For trusted networks this should be unified.

      There is a plugin for dealing with user activation keys, removing unused and unnecessary signups. This could be part of core.

      Shared media could also be something for the future, and have in mind.

      The important thing now is where to start, how to simplify things and not doing things that may block further evolution and flixibility.

      • John Blackbourn 3:10 pm on May 14, 2014 Permalink | Log in to Reply

        As long as the mulitisite setup can only be done from wp-config.php this should also be where to set a WP_IS_TRUSTED_NETWORK constant. You don’t specifically install a multisite, you install WordPress and transform it to mulitsite by editing wp-config.php.

        That’s not quite correct. You add the `WP_ALLOW_MULTISITE` constant but then you still need to go through the setup process in the admin area. This is where I imagine the open/closed network option will go.

        I agree with all your other points!

      • Boone Gorges 4:58 pm on May 14, 2014 Permalink | Log in to Reply

        > There is a plugin for dealing with user activation keys, removing unused and unnecessary signups. This could be part of core.

        Agreed that this is a problem. See also the new “Pending Users” feature in BuddyPress (http://wptavern.com/buddypress-2-0-to-add-signups-administration-screen – BP now creates the wp_signups table for non-multisite as well, to centralize signup management) and this plugin: http://wordpress.org/plugins/unconfirmed

    • Paal Joachim Romdahl 4:50 pm on May 19, 2014 Permalink | Log in to Reply

      An idea… brainstorming….
      What about having a Network page similar to a All Pages/All posts screen. Only here we can create connections. Create a new sub site or link with existing site.

      Create a new sub site options:

      • title, description and perhaps URL.
      • Optional check box for Domain.
      • Check boxes for Shared media, share posts, etc.
      • And probably other options.

      Link with existing site.

      • URL of site
      • Username and password.
      • Check boxes for shared media, share post etc.

      and more.

      This would really make it into a Network page that one can connect existing or new site.

  • Scott Taylor 9:59 pm on May 7, 2014 Permalink
    Tags: multisite   

    Multisite: let’s arrange office hours 

    I am envisioning lots of updates to Multisite for 4.0. @johnbillion and @jeremyfelt have been taking the lead. We should meet (at least) weekly to check in, plan work, and track progress. Not too formal, just to keep it in motion.

    Questions:
    When is a good time to meet?
    Who would like to be involved?

    Leave a comment / suggestion.

    There is no master plan. There is a make/core post: http://make.wordpress.org/core/2013/10/06/potential-roadmap-for-multisite/

    Let’s discuss.

     
  • Jeremy Felt 6:31 am on April 16, 2014 Permalink
    Tags: , , multisite   

    Multisite Changes in 3.9 

    Much of the bootstrap code for Multisite in ms-settings.php has been refactored in #27003 with the intent to improve how we handle the detection of domains and paths for sites and networks in core. Several other smaller enhancements and bugs have been completed in this and in other tickets.

    How networks and sites are found

    In the most common multisite scenario, the network finding process is the same. The constants DOMAIN_CURRENT_SITE and PATH_CURRENT_SITE in your wp-config.php define the network to be loaded by WordPress. In the large majority of installations there is only one network.

    The default process for finding the requested site now goes through a new function, get_site_by_path(). See the new functions section below for more details.

    If you use a sunrise file—likely through a domain mapping or multi-network plugin—and the $current_site and $current_blog globals are configured there through a custom network and site detection process, the finding portions of ms-settings.php will continue to be skipped entirely. Nothing changes.

    In some (very) rare scenarios, multiple networks may be configured in WordPress without a sunrise file. It is here where both the site and network finding process has been altered to use new functions rather than the stream of bootstrap code.

    Deprecated Functions

    There are two deprecated functions that may appear in your sunrise or in plugins to watch out for. Both of these were intended for private use by core, but came in handy as helpers to hack around various bits and pieces of the load process.

    wpmu_current_site() is deprecated. It was previously used to find the network and site information for a request. All functionality has been removed from this in favor of replacement functions. In its current form, it returns the $current_site global.

    get_current_site_name() is deprecated. It was previously used to set the site_name property on a given $current_site object. In its current form, it returns the passed $current_site object. This will likely not break anything, but any code relying on retrieving a site name using this function should be modified to use get_current_site() instead.

    New Functions

    Three new functions have been added to ms-load.php in 3.9 development. All of these have the focus of making sites and networks easier to find. These are meant to be public replacements for the previously private and somewhat inaccessible logic that existed in the bootstrap.

    wp_get_network() retrieves an object containing the network’s information from the database when passed a network ID.

    get_site_by_path() retrieves a site object when passed a domain and path. Two new filters are available here.

    get_network_by_path() retrieves a network object when passed a domain and path. Two new filters are available here as well.

    New Filters

    Inside the new site and network finding functions are a few filters that go a long way in providing for a less hacky sunrise.php file in the future. These can be used to shape the multisite bootstrap process without entirely replacing the logic.

    site_by_path_segments_count fires in get_site_by_path() and sets the number of possible path segments a site may have when we’re searching for it.

    pre_get_site_by_path fires in get_site_by_path() and allows you to short-circuit core’s default logic for finding a site.

    network_by_path_segments_count fires in get_network_by_path() and sets the number of possible path segments a network may have when we’re searching for it.

    pre_get_network_by_path fires in get_network_by_path() and allows you to short-circuit core’s default logic for finding a network.

    Ongoing

    It’s exciting to see some of the progress we’re making around multisite. We’d like to see what can be solved or broken with the new filters. More future improvements will be made around this and we want to make sure the base is right.

    Also take a look at the multisite focused tickets closed as fixed for 3.9. There are several other improvements and bug fixes that are worth taking a look at.

    See #25348 for autocompleting users when adding a new site. See #20601 for proper 404 handling of non member author archives. See #24178 for past confusion with a plugin that is activated on the network and locally.

    Thanks all!

     
    • Ryan McCue 6:37 am on April 16, 2014 Permalink | Log in to Reply

      In the most common multisite scenario, the network finding process is the same. The constants DOMAIN_CURRENT_SITE and PATH_CURRENT_SITE in your wp-config.php define the network to be loaded by WordPress. In the large majority of installations there is only one network.

      It’s worth emphasising: these constants refer to your network, not the site; get_site_by_path, however, refers to the site. (This is an artifact of the blog/site naming convention that’s being replaced with site/network.)

    • bvl 11:03 am on April 16, 2014 Permalink | Log in to Reply

      Great news, although I am a little disappointed that https://core.trac.wordpress.org/ticket/19722 still isn’t fixed, maybe in the next release?

    • rclilly 9:08 pm on April 16, 2014 Permalink | Log in to Reply

      Jeremy, Thanks for all work you’ve into improving multisite!

    • David 6:24 pm on April 17, 2014 Permalink | Log in to Reply

      I upgraded my multisite to 3.9 and this issue has occured….http://wordpress.stackexchange.com/questions/141578/3-9-breaks-multisite.
      Seems to be a bug of some sort as others are having the same issues. Looks to be a redirect issue of some sort.

    • lborgman 11:44 am on April 19, 2014 Permalink | Log in to Reply

      Many thanks for all the work with multisite!

      Here is however another issue that people coming here for information might be interested in:

      Solved: WP Multisite Stuck in Redirect Loop After 3.9 Upgrade http://www.webhostinghero.com/wp-multisite-stuck-in-redirect-loop/

      • Ipstenu (Mika Epstein) 3:09 am on April 20, 2014 Permalink | Log in to Reply

        That’s a poor choice of fixes, when a simple .htaccess redirect to force NON www will work fine (I don’t recommend using www on a Multisite as the default in general, and WP actually suggests you not do so at all when you’re installing, so I wouldn’t think that a fix that says to use it is the best call). Not to mention that how-to didn’t change the rest of the DB, which it should for consistency across the board. If you’re not using www in your site, a much easier fix is this:

        	RewriteEngine On
        	RewriteBase /
        	RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
        	RewriteRule ^(.*)$ http://%1/$1 [R=301,L]
        

        Just added that to my site and it’s better. However I made a trac for this, since www should not be treated as a subdomain. It’s special.

        https://core.trac.wordpress.org/ticket/27927

  • Andrew Nacin 4:48 pm on October 6, 2013 Permalink
    Tags: multisite,   

    Potential roadmap for multisite: Subdirectories, subdomains, open registration, and domain mapping 

    Following up on the potential roadmap for terms and taxonomy meta, here is a potential roadmap for multisite. This is based on years of discussions among core developers and other contributors, which has taken place on IRC, tickets, blog posts, comment threads, at WordCamps and contributor days, and at last October’s community summit.

    The Current State of Multisite

    Historically, WordPress MU was the “multi-user” version of WordPress. Any user could register their own subdomain, exactly how WordPress.com worked. Most of multisite remains centered around open registration and signups.

    The difficulties of setting up a wildcard DNS led to the introduction of a subdirectory option for new sites, as a fallback. Indeed, the old constant to toggle the subdirectory/subdomain option specifically referenced virtual hosts (VHOST, defined as ‘yes’ or ‘no’, rather than boolean). Wildcard DNS is still checked on setup whenever someone is creating a network with a subdomain.

    In a subdomain setup, the valid domains are quite limited. Subdomains cannot be nested and can only be common characters, and top-level domains cannot use www or ports. When creating a new site in the network admin, it still asks for an email address, and a user with that email will be created if the user doesn’t already exist.

    The paradigm of subdirectories versus subdomains is very restrictive. Over time, many have sought two related but distinct concepts that would diversify the address space used for sites.

    Domain Mapping and Multiple Networks

    Generally, domain mapping is the concept of having a top-level domain, such as example.org, being a site inside of another network, such as example.com. Otherwise, sites on example.com would simply be subdomains or subdirectories — so, blog.example.com and photos.example.com, or example.com/blog and example.com/photos. Either way, if the goal is for example.org to be a site on the same network, something must give.

    By default, WordPress MU has only one network (MU terminology was ‘site’, with sites being ‘blogs’), and constants are put in place during network creation to even avoid querying the wp_site table. Multiple networks are possible, but typically, only one network is desired. The only things “global” to entire multisite installs (rather than just a single network) are must-use plugins (“mu-plugins”) and users. Sites are assigned to a particular network; network-activated plugins and network-enabled themes are distinct only to that network; and each network has its own settings, network admin, and even super administrators (unless defined globally using $super_admins).

    There is no way to even store a globally accessible option accessible by all networks. switch_to_blog() (MU terminology for a site) does not actually toggle the current network ($current_site, per MU), and thus get_site_option() can only return current network information.

    WordPress stores a decent amount of “global” information as meta against a single network, which duplicates efforts. This includes plugin, theme, and core update checks; and user counts. (Site counts are per network.) Multiple networks still rely on a single installation of WordPress and a single wp-content directory.

    Domain mapping should be our primary focus here. It would probably be best if the demand for better support for multiple networks (like a user interface) is reduced through robust domain mapping support.

    On API and Naming

    At some point, we should be able to introduce a get_network_option() function to replace get_site_option(), which could follow context switches and accept a network argument. A network ID of “0” could be used in wp_sitemeta (network meta) to store truly global cross-network options.

    A larger point on API is that we should not rename API for the sake of renaming API. A lot of functions still use “blog” when they mean sites, or “site” when they mean network, and many remain prefixed with “wpmu”.

    We’ve tried really hard to move toward “network” wherever possible, at the API and UI levels. We long ago stopped introducing “site” things when they mean network as it is just too damn confusing. We haven’t quite made the switch to always going with site over blog at the API level, though we have at the UI level, but that’s just because it is more difficult for “site” to mean two different things, than it is to start using “network”. Either way you, still need to figure out whether a particular reference to “site” means “blog” or “network”, so we might as well use “network” wherever possible and lessen the number of ambiguous “site” instances (especially those that refer to the old MU definition).

    Not renaming these functions is actually key to the evolution of multisite. There are quite a few functions to rename, but doing so without completely replacing their internals and functionality in the process is a huge missed opportunity — it wrongly suggests things have improved while also cutting into our valuable function namespace. Three plus years later, we’re still finding oddities in old MU code, so it makes sense to bide our time and only undergo renames when they let us shed dead weight. The side effect of keeping the barrier to entry high for multisite is not necessarily a bad one — even three years after merge, the product as a whole is still very weak (which is being kind).

    The Path Forward: Supporting Sites at Any URL

    It should be abundantly clear that creating a second network is often overkill and not necessarily desired for many setups. WordPress.org uses them, but it is a mixed bag. Each subdomain is its own network, which are subdirectory setups. It makes a lot of sense for make.wordpress.org to be its own self-contained network, as they share similar characteristics. But other subdomains are typically just a single site.

    But, because of the subdomain/subdirectory paradigm, many use multiple networks to function as domain mapping. The best way to avoid misuse of multiple networks as domain mapping (which, aside from being counter-intuitive, isn’t generally desired) is to introduce proper domain mapping into core. This requires a complete rewrite of ms-settings.php — which takes a URL and figures out which site it should be on.

    Essentially, it should take the entire subdomain and at most one path segment, and query the wp_blogs table to find the associated site. Something like domain = %s AND path IN ('/', '/first-segment/'). From there, the current site can be inferred.

    The reason to search only one path segment is it immediately becomes an issue of caching. We don’t know how many levels are actually supported, which means we don’t know if /2013/02/01/some-blog-post/feed/ is a site, or a post on the main site. Literally any main site URL would thus cause a hit against the blogs table. This is not ideal. Nested sites are of course going to be desired in many situations, and it should be dead-simple for these URLs to be “trapped” via sunrise.php and mapped to a particular site.

    If a network is “small” (less than 10,000 sites per our wp_is_large_network() API), we could potentially query and cache SELECT blog_id, path FROM $wpdb->blogs WHERE domain = %s AND path <> '/' into a single cache key for lookup. Or we could specifically break it down into caching a shortest path, like any paths that start with ‘a’ in one cache key, any paths that start with ‘b’ in another cache key, etc. That way, we can verify that a site exists or not as long as a cache is in place. (The alternative would be to cache individual successes, but then we do a lot of DB queries if we’re unsure whether something is just uncached or isn’t a site — we’d have to cache in the negative too.)

    Domain mapping in core requires two major things. A complete dissolution of the existing subdomain versus subdirectory paradigm, and cross-domain “remote” logins. Remote login requires some juggling to make sure that domain B can make a request over domain A to confirm someone is logged in, and set a cookie if so. Generally this requires that logins occur on an “unmapped” domain (think the main site in a network, typically), but there are numerous ways to set up remote logins. Unfortunately most current implementations in the wild (including on WordPress.com) are fairly messy and can cause redirect loops, race conditions, and other problems. If done poorly, security issues can result. So this must be done with care.

    Dissolving the subdirectory/subdomain paradigm is actually not so bad. We need to stop thinking about a network only consisting of differing subdomains, or only consisting of differing paths. ms-settings.php would need to be rewritten. Site creation and management will need some changes.

    Dealing with URL Conflicts

    Perhaps the greatest change will be addressing the issue of the main site gaining a ‘/blog’ prefix. This is ostensibly to avoid top-level pages on the main site from clashing with sub-sites. With arbitrary domain support (via domain mapping primarily, and secondarily via secondary networks), any site with path ‘/’ can clash with any other site with the same domain but a different path. With multiple path segments (nested sites), any site with path ‘/X/’ can have pages that clash with site ‘/X/Y/’.

    Ultimately, this requires two-way blacklisting. Before a site is created, it must be checked against top-level URLs of the possibly conflicting site. And, before a page is created, it must be checked against sub-sites that already exist. If an ‘/about/’ page already exists on example.com/, an /about/ site cannot be created. But if an example.com/blog/ site already exists, a /blog/ page cannot be created on example.com. This gets complicated quickly, and is a very strong argument for only supporting one path segment in core by default, and allowing plugins to handle these potential conflicts on their own. In most cases, simply ignoring the potential conflicts is going to be sufficient.

    Registration and Open Networks

    Supporting any URL opens up possible problems with registration, even after dealing with unique URLs. The concept of an open network where users can create their own sites was the popular impetus for WordPress MU, but is decidedly not the primary use case for multisite anymore. Most operate closed, trusted networks, where site signups are disabled (and often user signups are disabled as well). In the case of a closed network, the blacklisting is merely to avoid shooting oneself in the foot. In the case of an open registration network, there does still need to be the choice of what, exactly, someone can register for. Even in a world of domain mapping, it should only be expected that “open registration” still only allows for subdomains or subdirectories, just as it does now. So when I am referring to removing that paradigm, I actually mean downsizing it to being a part of open registration only.

    Trusting Users in a Closed Network

    Despite being the narrower use case, the concept of open registration still implicitly dictates a lot of our current situation and “roadmap.” An administrator for a single site is considered wholly untrusted. Because multisite has the concept of a super administrator, there of course some powers that should be reserved for them. I would argue that would include the use of unfiltered HTML, as well as the administration of anything “global” — editing and deleting users; and editing, installing, and updating plugins and themes.

    But, when a network is not designed for “open registration,” there are a number of undue burdens that should be lifted for administrators. Uploadable file types are severely restricted, and the amount they can upload is capped. They cannot activate installed plugins, though there is an option for this. They cannot add users to their sites without knowing their email address (ostensibly to prevent spam), and the user must still go through a “confirmation” process. New sites must go through an “activation” process. They cannot create new users.

    I don’t think WordPress needs to decide that the multisite feature is only geared for closed networks. Rather, a single option — set on install, and controllable via network settings — can control this entire paradigm very effectively. It will then be much easier to consolidate a lot of the signup, activation, and administration funkiness in multisite under this paradigm into an “open network” concept. The “Allow new registrations” setting is roughly analogous, but would largely be superseded by whether a network is open, as well as fine-grained registration controls.

    One use case we should consider is the concept of a closed network and an open network sharing one multi-network multisite installation. For example, wordpress.org may be a closed network, but meetups.wordpress.org may be an open network to enable others to create meetups. And wordcamp.org may also be an “open” network on the same installation, even if individuals can’t create sites. “Open” is thus wider than registration alone.

    Essentially, I am proposing we trust single-site administrators in a closed network to not be spammy, and to be given wide-ranging control of their own sites; but that we do not extend that trust to important areas of security.

    A strong benefit here is that functionality in a closed network starts to more closely resemble a single site rather than the inherent restrictions of an open network. By shifting these paradigms, networks will become easier to manage and more straightforward to use over time. Eventually, closed networks can and should become easier to install — even if multisite never reaches the point where it is the recommended tool for creating a second blog for your cat.

    Moving Forward

    There is not a specific, multiple-release plan for this roadmap. Rather, every step we take should aim to work toward outlined goals. While people may like domain mapping, it doesn’t make sense to bolt it on just yet — a plugin can do that for them perfectly well now. It would be ill-advised to implement it without making WordPress work significantly smoother for other forms of domain and URL management — subdirectory/subdomain installs, domain mapping, and multiple networks. The best approach is one that smartly and carefully balances the needs of users with our long-term objectives.

     
    • Mike Schinkel 7:14 pm on October 6, 2013 Permalink | Log in to Reply

      GREAT overview of the issues related to multisite; bookmarked for much future reference. Thanks for that even though I assume that wasn’t your intention.

      One thing I would add to the list of improve, if it can be done backward-compatibly of course, is to reduce the number of places that duplicate domain/subdirectory information in the database. This currently makes moving a multisite from development -> test -> staging -> production more of a challenge that moving single site can be.

      And yes scripts can be written to automate but it first requires understand what much be written, which is much most complex for Multisite and most people don’t write scripts if they think they are only going to move things infrequently.

    • John James Jacoby 6:48 am on October 8, 2013 Permalink | Log in to Reply

      This is a great write-up, and I agree with it almost completely minus this one point:

      It would probably be best if the demand for better support for multiple networks (like a user interface) is reduced through robust domain mapping support.

      I think the opposite — it would probably be best if the demand for domain mapping is reduced through robust multi-network support.

      I think when a typical site administrator thinks they want domain mapping, what they actually want is a secondary network, with a new domain, new available themes, new network wide plugin control, with the same username and password. The only reason want domain mapping is because it’s the popular answer, not necessarily the correct one.

      We can use WordPress.org, WordCamp.org, BuddyPress.org, and bbPress.org, as great examples, but I think schools with several campuses might be a better one. They’ll all want users with super-admin access to their respective networks, with separate plugins and themes (maybe even separate wp-content directories) but with the same global users.

      Another great example could be a potential WordCamp.org redux. `sf.wordcamp.org` could be a network, `milwaukee.wordcamp.org` could be another, `newyork.wordcamp.org` a third, and the next level subdomains are all sites to their respective networks. Or… we could flip it the other direction and do networks numerically by year (2013.wordcamp.org) and use cities as subdirectories (2013.wordcamp.org/newyork) which allows us to retire complete networks at the end of each calendar year, allows for planning and rethinking the plugins and themes made available each year, etc…

      Conceptually, the architecture of how sites are related to their networks comes down to however themes and plugins will best serve the sites they’re grouped with.

      The only technical reason (I can think of) for literal “domain mapping” to be in core is shared SSL certs and allowing `/wp-admin` URL’s to always point to the unmapped URL. Any other reason(s) why a blog address would need to be mapped, rather than just being set to what it is (like we do now via Network Admin > Edit Site?) Either way, I think we’re in agreement that more useful UI for allowing capable users to set the homeurl/domain to be agnostic to the root domain (not married to any subdomain or subdirectory structure) is ideal, as the current process is less intuitive and more complicated than it needs to be.

      I don’t expect this to be the popular vote, but I’d like for WordPress’s default installation configuration to look something like this:

      • Multisite always, with no additional installation steps like we currently have.
      • Add a column to the global `wp_blogs` table for domain-mapping (though this doesn’t allow multiple domains to be mapped down to 1, or vice-versa.)
      • Subdomain VS Subdirectory decision eliminated completely. (Can we run an automated check to see if wildcard subdomains are supported, and provide user feedback and/or disable the creation of sites with subdomains?)
      • Create a UI for network management, and for moving sites between networks when it’s needed. A global setting/switch would exist to optionally allow users to create new networks the same as they can currently optionally create new sites. Imagine if a prospective WordPress.com VIP could spool up their own network of 30 sites, choose what plugins and themes they want, and assign super-admin capabilities, completely without human intervention. (Devil’s advocate could say if this was a need it, VIP would have built it already; I think that no one knows they want this yet because it currently seems more complicated than it is.
      • The `/users` dashboard could then use a “Networks” page in addition to the existing “Sites” page, along with matching moderation tools for leaving/deleting/delegating responsibilities/etc…

      Cons are:

      • Introducing several new default database tables that may not ever be used
      • Introducing curious users to multisite UI that may not ever actually need it
      • Code bloat from including new network management code in core

      Pros are:

      • Unified WordPress experience (no more single-site/multi-site support)
      • Decreased code complexity overall (not counting backwards compatibility)
      • Plugins can remove multisite abstractions/exclusions and assume all code is always available
      • True multisite/network management in core
      • Avoid misusing domain-mapping for non-mapped-domain configurations
      • Better allow for 1 WordPress instance with global users to power hugely robust networks of sites

      Hopefully this doesn’t stir the pot too much. Not intending to be adversarial, but when we do decide to focus on multi-site again, I believe investing time in multi-network is equally as important.

      • Andrew Nacin 10:29 pm on October 8, 2013 Permalink | Log in to Reply

        I think the opposite — it would probably be best if the demand for domain mapping is reduced through robust multi-network support.

        I think when a typical site administrator thinks they want domain mapping, what they actually want is a secondary network, with a new domain, new available themes, new network wide plugin control, with the same username and password. The only reason want domain mapping is because it’s the popular answer, not necessarily the correct one.

        I agree with most of the points you make, and obviously you have a lot of experience in the area. But, I think multiple networks are far beyond what most use cases dictate. I think there may be some confusion based on the phrasing I was using to describe some concepts.

        Your comment made me realize I need to stop calling it “domain mapping.” This wording stems from the fact that a top-level domain is “mapped” to an existing subdomain or existing subdirectory. (This is at least how it works on WordPress.com and with the popular WPMU Domain Mapping plugin.) I dislike this strongly. I think the dissolution of the subdomain/subdirectory paradigm would mean WordPress core would specifically support arbitrary domains for multisite, versus having one URL for the frontend and a different URL for the backend.

        Again, we’re talking about focusing far more on closed networks, which implies greater control over the domains in use. In an open network context, mapped domains would probably still be preferred that way logins and administration are occurring over a single domain with an SSL certificate. I think this should remain plugin material.

        I didn’t suggest that multiple networks shouldn’t be implemented, only that it should not be a priority. I mean, single networks are still a mess. Also, multiple networks already work pretty well right now, to be honest. It’s everything else that needs a complete rethink and rewrite, which also strikes much more at the very foundation of multisite.

        Ultimately, I want to move away from the thinking that domain mapping is a hack of the subdomain/subdirectory paradigm and that the only way you get arbitrary domains is with multiple networks. We should have true arbitrary domains within a single network, and we should to it well. Then at some point better multiple network support would allow for people to logically group any sites they wanted based on whatever their needs were, based on the needs of shared plugins, super admins, settings, site registration, etc.

        As long as multisite remains based on the open network paradigm, we’re stuck in a land of esoteric restrictions and gotchas. Combined with the general mess that is the multisite codebase (and in some cases UI), this is why the installation process remains deliberately complex. I did write in the post that closed network functionality starts to more closely resemble what people are used to with single sites, which I think is getting to the root of your “multisite always” suggestion.

        • John James Jacoby 10:00 pm on October 9, 2013 Permalink | Log in to Reply

          Your comment made me realize I need to stop calling it “domain mapping.” This wording stems from the fact that a top-level domain is “mapped” to an existing subdomain or existing subdirectory. (This is at least how it works on WordPress.com and with the popular WPMU Domain Mapping plugin.) I dislike this strongly. I think the dissolution of the subdomain/subdirectory paradigm would mean WordPress core would specifically support arbitrary domains for multisite, versus having one URL for the frontend and a different URL for the backend.

          Completely agree with you here, and like that we can start calling it something else asap.

          I didn’t suggest that multiple networks shouldn’t be implemented, only that it should not be a priority. I mean, single networks are still a mess. Also, multiple networks already work pretty well right now, to be honest. It’s everything else that needs a complete rethink and rewrite, which also strikes much more at the very foundation of multisite.

          I think what I’m suggesting (and likely failed to communicate effectively) is we should get single-network handling sorted before we try to implement arbitrary multisite domains. I have a hunch it will need to happen in that order anyhow.

          Again, we’re talking about focusing far more on closed networks, which implies greater control over the domains in use. In an open network context, mapped domains would probably still be preferred that way logins and administration are occurring over a single domain with an SSL certificate. I think this should remain plugin material.

          Agree that closed networks are more common, and agree that true domain mapping is a much more likely scenario in open (WordPress.com style) networks. I could see it being rolled into core’s open-network handling and enabled via a plugin (similar to how multi-network is now.) It would play nicely with our current sub-team arrangement, enabling a team to concentrate on a canonical domain mapping plugin for possible core inclusion later.

      • Andrew Nacin 10:37 pm on October 8, 2013 Permalink | Log in to Reply

        What’s the benefit of multiple networks over multiple installations that share a user table? And even sharing the same plugin and theme directories? Once we add support for arbitrary domains within a single network of sites, multiple networks essentially just makes certain things a little easier to administrate and manage.

        I’m not saying there shouldn’t be or isn’t already a benefit, nor am I trying to play (much of a) devil’s advocate. I honestly want to know what the answer is, because that could help shape how we build out multiple network management in the future. There needs to be some kind of value-add, and I’m not sure we’ve discovered one that suggests we need much beyond what we already have.

        • John James Jacoby 10:15 pm on October 9, 2013 Permalink | Log in to Reply

          What’s the benefit of multiple networks over multiple installations that share a user table? And even sharing the same plugin and theme directories?

          The obvious benefits are:

          • One copy of WordPress in the file system VS one for each “network.”
          • One `wp-content` folder to run one monolithic network of sites>

          That said, this may not be desirable. Similar to WordPress.org, there’s something nice about knowing if BuddyPress.org botches something, it doesn’t necessarily bleed into WordPress.org (even if system resources are shared, code is not.)

          Once we add support for arbitrary domains within a single network of sites, multiple networks essentially just makes certain things a little easier to administrate and manage.

          Correct. BuddyPress.org and bbPress.org are good examples for this. They run almost identical sets of plugins and themes, and they both should be multisite networks that have their own uniquely activated network wide plugins and themes.

          bbPress.org could be completely under the BuddyPress.org network, but I’d like different sets of Super Admins on both networks. There’s an argument to say that if we trust someone in one place, we can trust them in another, and I do agree with that. In this case it’s less about trust and all about ownership and responsibility; limiting access is a good way to distribute that, without talking about implementing network level roles and capabilities (even though I think long-term they will also be necessary.)

    • @ubernaut 4:49 am on October 11, 2013 Permalink | Log in to Reply

      i just want to add that i’d love to see this happen sounds like a great addition to core.

    • Franz Josef Kaiser 10:02 pm on October 11, 2013 Permalink | Log in to Reply

      Wow. That was … a really long write up. Finally understand the users who want a network of networks. Anyway, what I really would like to see is that we finally drop single site. I think we could just bring in a slightly reduced UI but still run a multisite install per default. Just my 2cents.

      • Dylan Barlett 1:19 am on October 15, 2013 Permalink | Log in to Reply

        I agree. Perhaps an intermediate step would be the installer recognizing that wp-config.php and .htaccess have already been written for network mode, and creating tables accordingly. Right now, if wp-config.php and .htaccess are configured when wp-admin/install.php runs, values are pre-filled and the install works properly. If they are written for network mode, the installer fails.

    • Frank Bültge 8:15 am on October 18, 2013 Permalink | Log in to Reply

      Short – Great!
      Currently is it hard to create plugins for single and multisite mode; much easier with a settings API in single and multisite mode. Also the parts to network in network is fine, use often for customer. Also a important part is the UI and the documentation on wordpress.org, maybe good topics for Contributor Days on WCs ;)

    • Austin Passy 12:13 am on October 19, 2013 Permalink | Log in to Reply

      Great read. I complete confidence in the next major version of MS if it’s in your hands. Looking forward to it.

    • chris207 9:49 pm on January 6, 2014 Permalink | Log in to Reply

      Very glad to see this, I will certainly keep my eye on this.

    • Mte90 3:33 pm on January 31, 2014 Permalink | Log in to Reply

      Any news for the 3.9 about this?

  • Mark Jaquith 7:17 pm on February 1, 2012 Permalink
    Tags: multisite,   

    Team Update: Multisite (Wednesday) 

    I worked some more on the patch we had for #19810. The original patch had features that exceeded our original scope (namely: the ability to bulk-add users). I removed that, cleaned up the JS a bit, and we now have a patch that can probably go in and be iterated.

    http://core.trac.wordpress.org/attachment/ticket/19810/19810.5.patch

    Next up is making it work in the add-user-to-blog interface in the Network Admin.

     
    • Pete Mall 7:19 pm on February 1, 2012 Permalink | Log in to Reply

      I’m working on the patch for the add-user-to-blog screen in the Network Admin. Patch should be up on the ticket in the morning.

  • Jen Mylo 12:48 pm on December 23, 2011 Permalink
    Tags: , multisite   

    Core Team Meetup Recap: Multisite 

    These are the notes from a breakout discussion on multisite at the core meetup with me, @markjaquith, and @nacin. As with all of these discussion summaries, please remember that they’re just discussions. I’m posting the notes for transparency purposes, not to say that these are the only things discussed or decided. I’m working from notes, and sometimes you don’t get everything down when you’re taking notes (next year I’ll record these things instead).

    Multisite!

    Who can lead this joint? Since the merge and Donncha moving on to other things, we had Ron for a cycle, Pete for a cycle, then no one. It would be good to have someone act as component owner.

    Multisite needs parity with the single site experience. Includes UI, UX, copy/strings, install flexibility (subdomain etc), installation ease (add a site).

    First we need to improve the manage/use experience, then fix install stuff and get it into the dashboard to turn on multisite.

    We need a useful global dashboard.

    We need to have flexibility in where sites and networks live — should be able to live wherever you want on one network. Subdomains/subdirectories/mapping/whatever you want, mixed subdomain/subdirectory, custom domains, global permalink consumer/router.

    Need to fix different workflows: adding users to network, adding users to site, invitations. User signup, creation, assignment, invitation all need new flow

    We need parity between plugins and themes. Enable vs activation is confusing, need to improve language, indicators. Need ability to network enable but disable for individual sites. Need to standardize network enable/activate etc for plugins/themes. Network activated plugins don’t show in individual site’s plugin list, which is confusing.

    UX Action Items:

    UX ACTION ITEM — Include network activated plugins in the plugins menu and give message that it is automatically on for the whole network (if admin/have rights to see plugins screen).

    UX ACTION ITEM — Autocomplete usernames or site names for network admin and for superadmin everywhere.

    UX ACTION ITEM — Get multisite tag/indicator on plugins in directory, add multisite specific/required indicator.

    Under the Hood Action Items:

    ACTION ITEM — Get rid of MS-FILES.

    ACTION ITEM — Enable install in subdirectory so you can use externals.

     
    • Frank 1:39 pm on December 23, 2011 Permalink | Log in to Reply

      Great; i love solutions with mutlisite and i wait now for an global dashboard; current i use the root blog (1) for this job. Great news
      I wish the team mery christmas and really nice new year. Best regards

    • Lauro Faria 1:45 pm on December 23, 2011 Permalink | Log in to Reply

      Good.
      These are items that interest me.
      An updated website (multisite), to version 3.3, and found some difficulty in managing permissions and what is accessible by users. It may not have found the right plugin. It aims to improve this item?

    • mitcho (Michael 芳貴 Erlewine) 12:25 am on December 28, 2011 Permalink | Log in to Reply

      +1 Happy to help as time allows. I’ve been involved with and rolling out more and more Multisite installs… there’s definitely a lot of space for improvement.

  • Ryan Boren 12:15 am on July 28, 2010 Permalink
    Tags: multisite, network   

    The wordpress.org infrastructure work has reminded me how much I dislike having the Super Admin/Network Admin pages appearing alongside the regular per-blog admin pages. I think the Super Admin menu should go away, away to a separate network admin area. Ticket 14435 is where I’m scratching this itch. The patches there move the network admin pages to wp-admin/network/. It is a completely separate admin area just for network management. It is available only from the main site url. Visiting wp-admin/network from other blogs in the network will redirect to the one true place. If you have multiple networks, they each will have a network admin area.

    While I was in there I added a network plugins.php. Network activations and deactivations happen here and only here. Network activate/deactivate is no longer available from the blog admins.

    Thoughts?

     
    • Jane Wells 12:17 am on July 28, 2010 Permalink | Log in to Reply

      Agreed. We can brush up the UI for these screens in 3.1.

    • Alex M. 12:21 am on July 28, 2010 Permalink | Log in to Reply

      Sounds good to me and will make it less confusing.

    • John Blackbourn 12:22 am on July 28, 2010 Permalink | Log in to Reply

      This bugs me too, and is especially confusing when you’re on the network admin page but everything else is telling you you’re in the admin area for a member blog. +1

    • John Blackbourn 12:25 am on July 28, 2010 Permalink | Log in to Reply

      Off-topic: Why is this post tagged with ‘multisite’ and ‘network’ yet only the ‘multisite’ tag is clickable? (Underneath Ryan’s name at the top.)

      • Ryan Boren 12:29 am on July 28, 2010 Permalink | Log in to Reply

        I think because this is the only post in that tag.

      • Alex M. 12:30 am on July 28, 2010 Permalink | Log in to Reply

        It’s only clickable if there are other posts with that tag. Note the “(3)” following “multisite” — that’s how many posts there are with that tag.

        EDIT: Bah, too slow! :)

    • Lloyd Budd 4:18 pm on July 28, 2010 Permalink | Log in to Reply

      I like this.
      I’m a little hesitant of “It is available only from the main site url.” Super/Network admin being able to be in the context of the current blog is very handy. It saves a lot of extra text entry and clicks having to look up a blog.

      I think there are benefits of making it blatant that one is logged in as a super admin. It’s a good reminder not to be ;-)

      • Ryan Boren 4:50 pm on July 28, 2010 Permalink | Log in to Reply

        There are definitely some work flow advantages to allowing network admin to be in the context of the current blog. Things like being able to “Add user to current blog” from network/users.php would be nice. We need to document some common work flows and see how best to accommodate them.

      • Ryan Boren 4:58 pm on July 28, 2010 Permalink | Log in to Reply

        Other things to consider. Make the Network Admin link sensitive to context. Link to network/themes.php if on themes page. Link to site editor if on other pages. Or, add an action to Favorite Actions for super admins.

      • Ron 5:00 pm on July 28, 2010 Permalink | Log in to Reply

        From a workflow perspective, I agree with Lloyd. I was going to suggest using context variables, but I see Ryan beat me to it :D

        • Ryan Boren 7:56 pm on July 30, 2010 Permalink | Log in to Reply

          I added some code to save the blog ID for the last blog admin area visited. This allows linking back to that blog from the network admin. Just an experiment. I really like having a canonical network admin and this is an attempt to have it both ways. :-)

  • Ryan Boren 1:40 pm on June 2, 2010 Permalink
    Tags: , multisite,   

    Justin has a nice theme developer oriented review of the nav menus.

    Ron talks about upgrading from MU to 3.0.

     
  • Andrew Nacin 7:23 pm on March 9, 2010 Permalink
    Tags: multisite,   

    WP_ENABLE_MULTISITE is now WP_ALLOW_MULTISITE. This is the constant that turns on the Tools > Network menu. I think the new name will prevent confusion with actually enabling multisite itself, versus just allowing network creation to occur.

     
    • Beau 7:32 pm on March 9, 2010 Permalink | Log in to Reply

      And just for context, if you don’t know what Andrew is talking about, this is the constant that you set in your wp-config.php to turn on the menu so that you can configure multi-site functionality, e.g.

      define( 'WP_ALLOW_MULTISITE', true );

    • Banago 8:13 pm on March 9, 2010 Permalink | Log in to Reply

      Well thought move.

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel