Make WordPress Core

Tagged: multisite Toggle Comment Threads | Keyboard Shortcuts

  • Jeremy Felt 9:28 pm on May 19, 2015 Permalink |
    Tags: multisite   

    Multisite Office Hours Recap (May 19, 2015) 

    Multisite office hours are held every Tuesday at 20:00 UTC in #core-multisite.

    Overall 4.3 Release Objectives

    Last week’s objectives:

    • Mockups for the Edit Site / Add New Site improvements. [log] @hugobaeta has started working with this and we had a good conversation today to help fill in some of the blanks and give more to chew on. See the summary below of the issue.
    • Have more flows posted to Make Flow for the network admin. [log]
    • Get some decent progress on `WP_Site` and `WP_Network` #31985. [log] – I poked at @johnjamesjacoby‘s patch for `WP_Network()` and reduced it down to the bare essentials. We can start building this up and figuring out what pieces belong in `WP_Network_Query()`. Hoping to start work on `WP_Site()` shortly as well.

    Summing up the Edit Site / Add Site UI/UX issue:

    We’ve always had two configurations for a network in multisite: subdomain or subdirectory.

    Subdirectory is the easiest to handle as the domain will always be the same, inherited from the network. Only the path can change from site to site. Not only is this a UI decision in the Edit Site and Add Site screens, it is how ms-settings.php parses the requested URL when a subdirectory configuration is used.

    In the changes we make to the Edit Site #22383 and Add Site #31240 screens, we’ll still want to account for subdirectory configurations and make it as easy as possible for somebody to choose a path without worrying about scheme or domain.

    Subdomain seems similar, but ends up being very different. At first glance, only the domain can change from site to site, with the path always set to “/”. This is the case in the current Add Site screen. In the current Edit Site screen, you can change the full domain and the path to anything you’d like. Super admins have been able to use this to get around the strict UI requirements for subdomain configuration in Add Site. In ms-settings.php, the code cares less. We search the database for a matching domain and path, which effectively allows for arbitrary domains and paths—a good replacement for domain mapping.

    In the changes we make to the Edit Site and Add Site screens, we should make this as flexible as possible. The name of the configuration “Subdomain” will be weird, but it should be possible to enter any combination. Ideally we can confirm that this combination works before completing a save.

    Thanks to everyone in office hours today! Chime in with any comments, tickets, etc… or join us in #core-multisite. :)

  • Jeremy Felt 11:22 pm on May 12, 2015 Permalink |
    Tags: multisite   

    Multisite Office Hours Recap (May 12, 2015) 

    Multisite office hours are held every Tuesday at 20:00 UTC in #core-multisite.

    4.3 Release Objectives

    Our objectives for 4.3 can be split between UI/UX and back-end core. Here’s what we’re working on along with who is assigned or expressed interest in the past.

    Network Admin UI:

    1. Capture mobile flows and find areas to improve. @sofiarose, @kraftbj, @ubernaut
      • See last week’s office hours recap for a list of flows we’d like to capture
      • @hugobaeta has posted some desktop flow
      • This objective will likely mirror some of what the Admin UI group is doing. We’ll know more about individual opportunities as we dive in deeper.
    2. Combine scheme/domain/path in Add New Site and Edit Site workflows. @hugobaeta
      • When adding a new site, you should be able to just type the site’s new address without worrying about where to put each of the individual parts. https://wordpress.org should split into a scheme of https, domain of wordpress.org, and path of /
      • If an admin email is added that does not belong to an existing user, a user will be created with the site’s name and the user’s email address. There should be an opportunity to provide the user’s username and email in this scenario.
      • Related tickets: #22383, #31240, #14172, #14215
      • @hugobaeta will be working on some mock-ups
    3. Improvement of network upgrade workflow (ajaxify)
      • The current network upgrade process cycles through sites 5 at a time and processes the database upgrades. After each set of 5, the page refreshes and the next 5 are loaded. If one encounters an error, the entire process is stopped to await manual interaction. This should be something handled nicely via ajax.
      • Related tickets: #11869, #18292, #22589, #24922, #26056, #31405
      • @boren has posted a Mac/Chrome network upgrade flow

    Multisite core:

    1. Provide validation for domains, paths, emails. @boonebgorges, @johnbillion, @jeremyfelt
      • The combined scheme/domain/path objective above relies on the validation of domains, paths, and emails. There are several quirky restrictions in multisite that would be nice to clear up. The first step is to establish validation functions so that we can write tests and then change the results as needed.
      • Related tickets: #17397, #18777, #20019, #19724, #21994, #15936, #16126, #17904, #26784
    2. Introduce WP_Site, WP_Network, WP_Site_Query, WP_Network_Query. @johnjamesjacoby, @earnjam, @rmccue, @jeremyfelt

    If you’re interested in your name being attached to one of these objectives, please leave a comment here or a ping in #core-multisite.

    There may be room for more, or reason to swap one of these with something else once we start progressing. Let’s keep the list about this size for now so that we have something consumable. We’ll continue to revisit these objectives weekly throughout the cycle.

  • Jeremy Felt 3:27 pm on May 6, 2015 Permalink |
    Tags: multisite   

    Multisite Office Hours Recap (May 5, 2015) 

    Multisite office hours are held every Tuesday at 20:00UTC in #core-multisite.

    We had a lively conversation today around some of our objectives for the 4.3 cycle. The conversation was mostly focused around creating a visual record for the current network admin UI and then establishing our goals for moving that forward. @hugobaeta, @sofiarose, @ubenaut, and @kraftbj all volunteered to start capturing workflows for devices. There are a lot of good notes in #core-flow and examples of other visual records on make.wordpress.org/flow we can use as a launch point.

    Here’s an initial prioritized list of some common workflows. Please add and/or discuss in the comments. I’m likely missing many things. :)

    • Add a new user to a site when the user does not currently exist as a network user.
    • Add a new user to a site when the user does exist as a network user.
    • Install, enable, and then activate a theme for a single site on the network.
    • Install a theme and enable it for use on a network.
    • Install and then activate a plugin for use on a single site on the network.
    • Install and then network activate a plugin.
    • Setup multisite from scratch in a subdirectory configuration.
    • Setup multisite from scratch in a subdomain configuration.
    • Create a new site on the network.
    • Upgrade WordPress, including the network upgrade.
    • Update a plugin.
    • Update a theme.
    • Edit the domain/path for an existing site on the network.

    We briefly discussed the possible need for validating domains and paths that will arise from #22383 efforts. We need to gather a list of tickets that could benefit.

    And we just touched on how we might start working toward a future site switcher for core. This is something that would be excellent as a feature plugin for a future cycle, so if you’re interested—please speak up. Ideas are fun to pass around at this point.

    Finally, I’m on the hook for ticket gathering before next week’s office hours so that we can start to prioritize a list of UI (and other) improvements. At the same time, we’ll start finding more and more to fix from the viz-rec process and from general admin UI improvements.

    I’ll start that list of tickets in the comments here and then repackage it in a post for next week. Please add any tickets to the comments that you see as useful for network admin UI improvements.

    Thanks to everyone for participating!

    Chat log

  • Jeremy Felt 6:17 am on February 25, 2015 Permalink |
    Tags: multisite   

    Multisite Office Hours Recap (February 24, 2015) 

    Multisite office hours are held every Tuesday at 21:00UTC in #core-multisite and are followed by a casual bug scrub / ticket conversation at 22:00 UTC.

    We had a great conversation in office hours today around network types as a follow-up to some of the discussion generated by the network types thread from last week.

    I think the chat log is the best place to get a full picture of this one as we covered a lot of material and several possible approaches.

    In short:

    • We’re trying to balance “decisions, not options” with a configuration that has many possible permutations. One way to do this would be a list of checkboxes covering each setting during network setup. It seems everyone agrees that it is much more desirable to have a limited interface to make the option easier.
    • While discussion on the network types thread tended to covered the ability to register new types and filter existing types, the conversation today took an interesting turn toward a model where a small number of key options were offered during network setup.
    • The most important options we should start with in building this out are: (a) Allow new users to register – Yes/No, (b) Allow users to create sites – Yes/No.
    • With each of these questions, we narrow down a set of options (see @johnbillion‘s quick list) to define the “network type”.
    • It’s possible a 3rd or 4th question is useful, though we agreed that starting with these two questions would be a route to progress.
    • We can repurpose #30145 away from our loved and then unloved, but always confusing wp_is_trusted_network() to something along the lines of “Introduce better default settings during network creation” (credit @ipstenu).

    I think that grasps the overall intent of today’s conversation. The entire log is a good read. Please leave feedback here and in the network types thread as you have it! :)

  • Jeremy Felt 5:50 am on February 18, 2015 Permalink |
    Tags: multisite   

    Multisite Objective: Defining Network Types 

    We’ve been having a rolling conversation about the concept of different network types for a long while. @nacin covered it as part of the potential roadmap for multisite in 2013 and described two sections—“Registration and Open Networks” and “Trusting Users in a Closed Network”—that describe the overall intent of this conversation pretty well.

    At WCSF this year, we covered the topic a few times during the contributor days, trying to really nail down what “open” and “closed” meant or if “trusted” and “untrusted” were better words. We even committed wp_is_trusted_network() to core for about a month in #30145 as a guess at starting to figure out what it should do. :)

    This repeating conversation has usually started as one of confusion. We have different meanings for open/closed, so we can’t use that. We have different meanings for trusted/untrusted, so we can’t use that.

    How do we figure out what we’re talking about?

    While all of this discussion has been happening, we’ve been exploring the different ways of phrasing things. A use case discussion for network types on GitHub. A breakdown of open/closed network functionality. A categorization of every is_multisite() use in core.

    During our office hours today, we made some great progress.

    We’re going to skip our attempts at binary classification. The future we’re looking at is one in which installing a network is the choice of a pre-configured network type.

    Long winded intro aside—this thread you are reading is a place to have this discussion. We need to work out answers to a few questions so that we can move forward:

    • What network types are there?
    • Which of these should be pre-configured in core?
    • What are possible ways of managing these network types?
    • What kind of experience can we introduce during network installation that makes this simple.

    I’d encourage you to read some of the previous discussions linked above, especially today’s #core-multisite logs, and then refocus the discussion in the comments here. This will be our main topic in next week’s multisite office hours, so brainstorm away! The more input the better.

    • John James Jacoby 1:39 pm on February 18, 2015 Permalink | Log in to Reply

      Thanks for getting this started Jeremy.

      As far as network types go, the original (and current) vision for WordPress multisite was for it to easily enable anyone to create and manage a network of blogs, for blogging. The more modern use case for WordPress multisite is as a utility for managing multiple sites using one installation, sites that may-or-may-not be related to one-another. There are a few assumptions we can make about the differences:

      • Blogging networks likely have open registration & blog creation. Utility networks likely have closed registration & blog creation.
      • Blogging networks assume an untrusted user might “own” a site. Utility networks assume a trusted staffer, employee, or client are using a site on your network.
      • Blogging networks likely limit upload space. Utility networks likely should not be limited.
      • Blogging networks likely will have very few users on each site. Utility networks likely will have several to many. (Both installations could have millions of users in general.)
      • Blogging networks may-or-may-not allow access to control plugins. Utility networks likely have plugins and themes locked down.
      • Blogging networks mean relinquishing site control to your users. Utility networks mean a trusted group is likely in control of each site, and site-administrators provide as-needed access to wp-admin areas.

      You’ll see lots of “likely” and “may-or-may-not” here. This is because most of us have architected installations and designed experiences around some common directions, but have also deviated far and away from any beaten path for anything from intranets and social networks to complete application frameworks using sites only to store and retrieve data.

      As Jeremy eluded to, what to do about multisite has been a years long thought process, and our current conclusion is approximately as follows:

      • Define at least two network “types” – one being the blogging network we currently have.
      • Define future-proof verbiage for related functionality. wp_get_network_type() and such.
      • Maybe provide constant or UI for installing multisite and picking between network types.
      • Maybe provide API for registering network types as a “package” of predetermined network and site settings.

      Another thing to consider, is if what we are talking about is a “network” type or an “installation” type. Because WordPress multisite supports multiple networks (swoon) is one of our goals to allow each network to operate with its own unique restrictions? WordPress.org is kind-of like this now, with several different networks running on global user tables. I *think* the answer to this question is “yes” but I also think it’s a decision worth being more confident about.

      • Jeremy Felt 4:02 am on February 24, 2015 Permalink | Log in to Reply

        Blogging networks mean relinquishing site control to your users. Utility networks mean a trusted group is likely in control of each site, and site-administrators provide as-needed access to wp-admin areas.

        This is an interesting duality of sorts. I agree with this statement, though I’ll also point out that users of a utility network will often have a higher expectation of immediate capability than users of a blogging network. So, relinquishing mediated control of the full site (blogging network) and allowing full control of a mediated site (utility network). Maybe?

        Define at least two network “types” – one being the blogging network we currently have.

        My current thought is that 3 would be a perfect number. :)

        Maybe provide constant or UI for installing multisite and picking between network types.

        Tools -> Network Setup -> “Select Network Type”, done.

        Another thing to consider, is if what we are talking about is a “network” type or an “installation” type.

        I think network type is the way forward. At least in my multi-network use case, I have a handful of different types I could define at the moment.

    • John James Jacoby 1:56 pm on February 18, 2015 Permalink | Log in to Reply

      Functionally, this could start off using some global array of keys and values used to filter pre_option_ and pre_site_ calls the way bbPress currently allows.

      This gives us the opportunity to write some code as a plugin first, touch options directly, and create some predefined groups of them to later turn into “network types.” This exercise should help us determine what type of interface would be most useful for the type of user who will most likely be interacting with it.

      • Jeremy Felt 4:05 am on February 24, 2015 Permalink | Log in to Reply

        Your mention of wp_get_network_type() above brought me to thinking about a series of network_supports() checks throughout core that checked the current network type for its support of a concept.

        I like the idea of hooking in early with a plugin to test the concepts out.

    • Ipstenu (Mika Epstein) 4:23 pm on February 18, 2015 Permalink | Log in to Reply

      What network types are there?

      Today we have a loosely connected set of blogs that share a common potential user base, common possible plugins and themes.

      The ones I see people wanting the most (excluding the ‘shared media/posts’ which I think is out of scope, and yes that includes a multi-network-store site) would be as follows.

      • ‘Traditional’ Network – One super admin, each site admin has all the access they have today. They can run any plugin that’s installed and any theme that’s active. This is what we have today.
      • Blog Network – Same as traditional, starts with allowing new users AND users to create blogs. Sites would be unrelated. This is the WPCOM option :)
      • Sole Admin Network – One person running multiple different sites. Generally they have to log in as the super-admin all the time to get things done. Functionally this may be the same as traditional, but all registration etc would be locked down.
      • Company/School Network – Each site has it’s own admin, but the admin has limited rights. They cannot mess with plugins that may not be network activated (think plugins acting like themes do – network activated or available on a per-site basis).
      • Private ‘Family’ Network – Less restrictive than the company site, you make a network for your group of people and you maintain it, but you have closed registrations and limit things.
    • Mike Schinkel 4:24 pm on February 18, 2015 Permalink | Log in to Reply

      Following up on what Ipstenu said on Guithub, it seems that all these presumed “Network Types” are simply a collection of potential (programmer level) configuration options (so as not to violate the “Decisions, not Options” principle.) If we looked at all potential types, envisioned and not yet envisioned, we would come up with a finite list of (new?) configuration options.

      It would seem the first step then would be to identify and document all these potential configuration options at an atomic level. From there we could then “map” Network Types to their associated configuration settings.

      Even better, Network Types could then be registered just like how Post Types, Post Statuses and Taxonomies are registered which would make missing out on an important use-case in core much less problematic.

      With this proposed approach everyone both pro and con network types can get their cake and get to eat it too.

      • Gabriel Mays 9:37 pm on February 18, 2015 Permalink | Log in to Reply

        I agree. We could spend a lot of time thinking about different permutations that could exist, we’re better off just making it flexible.

        Each network type is just a collection of options with their corresponding values that make that network type unique. So as new popular use cases arise it’d be fairly simple to add new ones or let people add their own (i.e. import network type via XML).

      • Fabien Quatravaux 8:37 am on February 19, 2015 Permalink | Log in to Reply

        That’s a really great idea ! Let’s put power into the right hands (the developer ones).

      • MartyThornley 4:38 pm on February 20, 2015 Permalink | Log in to Reply

        You beat me to it! +100 for this. Core could define a few then plugins could create new types or option sets. I think of it as comparable to user roles and capabilities. There are network types which are like roles and options which are basically defining what that type is capable of.

      • Jeremy Felt 4:12 am on February 24, 2015 Permalink | Log in to Reply

        I think the concept of “registering” network types rather than defining all of the possible permutations is appropriate. We can decide on 2 or 3 very specific configurations that meet the “blogging network” vs “utility network” vs …. and then provide an easy way to filter that list of network types—through register_network_type() or something similar.

    • Mike Schinkel 4:25 pm on February 18, 2015 Permalink | Log in to Reply

      Another Network Type that I’ve seen is what I’d call the “Shared Server” network type. This is a network of completely unrelated sites, often developed by completely different people, but hosted on a single multisite because of a misguided opinion that this makes sense.

      I do not advocate this use-case and have even actively fought against it, but it seems there are business consulting firms recommending to IT shops at at least one Fortune 100 company the use of Multisite as a way to have one server host multiple WP sites in part so they can then bill out for IT services to each department that needs a site (in this particular case all sites were intranet sites.)

      I have also seen numerous people in forums, on mailing lists and at meetups advocating the use of a single Multisite for hosting all their unrelated clients sites. And I can only assume it is because they don’t understand the pros and cons of multisite. Ugh.

      So I would either like to see this made easier (i.e. by being able to export and elsewhere import a single site’s data and being able to have plugin that are limited to one site) or better yet, make changes in core that somehow make this use-case impossible in future versions and thus force new installations to use multiple single sites and an admin console instead of one multisite.

      • Jeremy Felt 4:18 am on February 24, 2015 Permalink | Log in to Reply

        While I agree generally that this is a misguided use of multisite, there may still be validity in helping to define boundaries for these types of networks. I don’t think it’s a network type that we should account for by default, but it could be cool to see someone create a plugin that helps to nail down problem areas.

        able to have plugin that are limited to one site

        This does need to happen. A+++++ I would like to see #14569 in 2015. :)

    • Mike Schinkel 4:29 pm on February 18, 2015 Permalink | Log in to Reply

      Regarding the “Social Network” type proposed by JJJ on GitHub, if we ignore that Multisite is a requirement for BuddyPress then nothing about a social network actually requires Multisite (other than potentially allowing them their own blog.) Thus it would be great is there is anything added that is not Multisite-specific to support the Social Network use-case would also be applied to Single site.

    • Paal Joachim Romdahl 4:39 pm on February 18, 2015 Permalink | Log in to Reply

      It seems we need a starter wizard that covers the most basic options when the user activates a new multisite. Options that also later can be adjusted.

    • Gabriel Mays 4:54 pm on February 18, 2015 Permalink | Log in to Reply

      For the starter wizard, here’s an idea of what it might look like along with the network settings (originally posted in slack): http://imgur.com/PCnU4rZ

      Idea with tabs is that it’s easy to add more settings in the future, i.e. a domain mapping tab, etc.

      Where the network types are just “bundles” of individual options. But I def think user reg settings and site reg settings should be separated, they’re combined now which is a bit confusing/limiting.

    • Gabriel Mays 4:57 pm on February 18, 2015 Permalink | Log in to Reply

      Regarding network types, I guess it comes down to how different are the network types from each other? I think we should only add a new network type if they are different enough that we believe it’d be complicated for a user to select the options pertaining to that particular type. If we don’t filter then in some way we’ll end up with too many.

      Additionally, just like the admin color schemes plugin there’s nothing preventing people from creating their own network types and letting others use them.

      • Ipstenu (Mika Epstein) 8:44 pm on February 18, 2015 Permalink | Log in to Reply

        In my head, the ‘types’ would pre-fill certain options. So for the wizard you’d pick what you want from the pre-defined ones, or click on ‘customize’ and be a wizard yourself. Or an elf.

        • Gabriel Mays 9:29 pm on February 18, 2015 Permalink | Log in to Reply

          I agree, but why would the “customize” option have to be on the wizard? If the user dismisses the wizard couldn’t we just assume they want to roll their own?

          And the “network type choice isn’t final, it’s just a set of options, which they can change anytime or “reset” to see the wizard (ahem, elf) again. And whether or not they choose a network type I think we expect them to customize at least something, whether it’s the network title, upload quota, welcome message, etc.

          As I understand it, all “customize” means is that at some point they decide to change a setting instead of using the install or network type defaults, which I believe is inevitable. The goal of the network types wizard is just to get them 80% of the way without researching what every option does, right?

          To make it more intuitive we could just call it “Multisite Quick Start” or something since they’re just bundles of recommended settings.

          • Ipstenu (Mika Epstein) 9:39 pm on February 18, 2015 Permalink | Log in to Reply

            Customize clicks you out of the wizard.

            As much as I hate to say it, I worry because of the NUX headaches with the Welcome Panel. Do you know how many people leave it alone? We need to make sure it’s ‘used’ or dismissed, and making an alternate to pick-a-setting may help.

        • Jeremy Felt 4:30 am on February 24, 2015 Permalink | Log in to Reply

          I’m wary of having a customizer wizard of sorts. I can see several plugins springing up to allow other network types to be registered, but it would be nice to avoid managing a lot of options.

    • Frank 9:38 pm on February 18, 2015 Permalink | Log in to Reply

      I see much benefits of the network types for different scenarios on real world examples, there I develop, create for customers. My idea is, that we not get a network type solution with settings ui and confining possibilities.
      I think a small solution like post types, taxonomies to register a custom network type is much easier to create and useful for a lot of scenarios.
      I think is not helpful for the default multisite to have much more settings, ui elements. Network types is sure a helpful type for custom solutions, in the first way for developers. I would see this feature in the core, but not visible on default and usable via the register network type functionality, like post type – no options, decisions.

      • Jeremy Felt 4:31 am on February 24, 2015 Permalink | Log in to Reply

        Completely agree! I think we can decide on a few defined network types and provide ways for plugins to register new types.

    • rosyteddy 2:21 am on February 19, 2015 Permalink | Log in to Reply

      “‘Traditional’ Network – One super admin, each site admin has all the access they have today. They can run any plugin that’s installed and any theme that’s active. This is what we have today.”

      This is so true and it holds good. And is so much needed and so much used.
      However, we need one more : one network plugin or network feature that lets any wordpress site using wordpress downloadable from wordpress.org do the following :
      1) login to wordpress site 1 with wordpress site 2 credentials, provided the sites have mutually enabled this plugin to be ON. (Drupal used to have this type of plugin)
      2) we can follow or befriend anyone on wordpress site1 even if I am a member of wordpress2
      for example:
      friends of userA@worpresssite1 : userA@worpresssite2, userA@worpresssite3, userA@worpresssite4…
      You get the idea
      3) userA@worpresssite1 can comment on a blogpost by userA@worpresssite2 on his site as userA@worpresssite1
      http://gnu.io/social/ diaspora and others already let you do this, same thing can be done if you have logged in using wordpress.com login and other sites also use wordpress.com login
      Just extend that from wordpress.com login to any wordpress site login
      4) Same about “likes”
      For example: This blog post has been liked by userA@worpresssite1, userA@worpresssite2

      Note: userA@worpresssite1 and userA@worpresssite2 are completely different users – the similarity in name is just coincedental :)

      If this can be done it will be a potentially useful and popular network, even larger than FB but only if implemented right now without the years of delay that Buddypress has done.

    • Fabien Quatravaux 9:23 am on February 19, 2015 Permalink | Log in to Reply

      I agree with @bueltge and @gmays : what I like the most in WordPress is that the admin UI is very simple (not so many options, all options are easily understandable), and real power is hidden for non-developers. For example, there is not UI to create new Post Types, taxonomies, or shortcodes, but that’s what make WordPress so flexible.

      We could write an infinite list of different network types and still missing some cases. So let’s just list the discrete options that should be available. Later, we could chose 3 or 4 network types to be present in core to ease the installation of popular network types.

      Here is my list of options :
      1. Allow new users to register (already available)
      2. Moderate new user registration requests
      3. Allow approved user to create a new site (already available)
      4. Moderate new site creation (with the option to automatically allow site creation for some user, the same way comments are moderated)
      5. Allow site admins to manage their site users (already available)
      6. Each theme can be provided to each site independently (already available)
      7. Each plugin can be provided to each site independently
      8. Site access restriction : public OR only to logged-in users OR only to site admin OR completely offline OR in construction (today only public OR completely offline options exist, and they are managed by super-admin not by the site admin)
      9. Add some filters to customize the `wp-admin/network/site-info.php` page : adding some site options, adding or removing tabs, …
      10. Allow access to admin area for each role (typical use case : subscribers will be able to log-in but won’t have access to admin area)

      And here is what the API could look like:

      register_network_type( ”,
      ‘allow_new_users’ => ‘always’, // always, moderate or never
      ‘allow_new_sites’ => ‘always’, // always, moderate or never
      ‘admins_can_manage_users’ => true,
      ‘wp_admin_access’ => array( // list of roles
      ‘admin_menu’ => array( // list of default available menus
      ‘themes’ => array(‘twentyfifteen’), // list of default available themes
      ‘plugins’ => array(‘akismet’), // list of default available plugins
      ‘sites_options’ => array( // list of options available in the sites admin UI
      ‘label’ => ‘A site option’,
      ‘type’ => ‘checkbox’,
      ‘default’ => ‘checked’,
      // this part could be similar to the settings API ?

    • faospark 10:18 am on February 19, 2015 Permalink | Log in to Reply

      “What network types are there? ”

      -Maybe we should start from what we have.
      In the network settings page, particularly the registration settings. right from there we can start to see of what is an example of Open Network and a Closed Network.
      the first two options in the registrations settings (i.e. disabled registrations and user accounts may be signed up ) essentially constitutes an example of a Closed Network while the two succeeding ones constitutes (i.e. users may sign up new sites, sites & user accounts can be Sign uped.)an Open Network.

      For the purpose of discussion i will refer to the default blog on multisite as the parent network and subdomains or sub directories as child sites or sibling sites.

      Closed Network Examples: Organizational Type/ Collaborative Type and Task Oriented Type
      In a Closed Network. what essentially fundamental to it is that everything that is happening is intrinsically from the Parent Network and the identity of the child sites is almost always attached to the Parent Network or its Sibling sites. In real world example the best way for you to visualize this is how an Organization with Chapters work. the chapters almost always has to collaborate with the parent org. will call this example as Organizational Type of Network or Collaborative Type.
      Furthermore. Child sites of Closed network can also Task oriented. where in by which a child site performs a very specific task. Examples are customer support on a sub domain,general forums on sub-domain. user account management on a subdomain. I would call this example as Task Oriented Type of Network
      The key thing about Closed Networks is that the creation of child sites is influenced by factors intrinsic to the parent network and the maturation of child sites does not necessitate of it being mapped on own domain.

      Open Network: Open Showcase and Moderated Showcase
      in comparison Closed Networks, in an Open Network, the creation of child sites is more influenced by an external factor. The main function of the parent network is a showcase site of its children sites.
      its only a matter whether it would moderated or free brawl. in an open Network, The maturation of child sites is very likely and child sites is almost independent content wise from its parent network and sibling sites.

      Summary :
      2 main network types : 1)Open 2)Closed
      Closed Network Examples: Organizational Type/ Collaborative Type and Task Oriented Type
      Open Network: Open Showcase and Moderated Showcase

      “Which of these should be pre-configured in core?”
      -I think we already have based from what i said above , but it would be a lot better if we make multisite installs by default a closed network type;

    • joesell89 10:27 am on February 19, 2015 Permalink | Log in to Reply

      First off, I am not a developer, but I do use multisite. I thought it may be useful to just contribute how I use multisite. Just to add to the mix :-)

      We use multisite to link websites and blogs within our company. We have a membership site a blog and an internal team website. Blog creation is closed but registration is open.

      In the future we would love it if when someone was given a role on one site and had it everywhere else on the network.

      Having a multisite network makes sense because it is easier to setup and configure a new or temporary site and many of the plugins and themes we use are shared anyway.

      Hope this point of view is helpful.

    • ivanblagdan 11:07 am on February 24, 2015 Permalink | Log in to Reply

      Im a developer on a few long term corporate multisite projects, and I’d just like to add my two cents here, even if it might be a little off track and late.
      To start off, I’d state that in my experience, multisite installations easily spiral out of control in terms of complexity. They require more effort and consideration, than in non-multisite, to corral client requests into something that doesn’t end up a mess to be maintained down the road. I’m talking about growing, long term site networks rather than a network of private blogs.

      Most of these have their blogs created by network admins, and in some cases allow user registration on specific sites for various capabilities (commenting, or uploading files, RVSPs etc.).
      Some of these networks are groups of site localizations that share 99% of configuration.

      I think that the use case for preset network options is rather weak and that a certain level of technical ability is to be expected from the person setting up/running the network. I’d rather see this get more flexible, but from the ground up on a API level.

      A few weak spots I encounter:

      • Media asset management, sharing and editorial permissions among specific sites.
      • General user and permission management
      • Configuration management of various sites.
      • Content/data exchange between sites

      All of these are certainly possible, and to a degree mitigated by a few great plugins, but in all honestly it always feels like hacking around something, not actually extending it.
      I feel much of the discussion here should trickle down to API requirements and modularization of these underlying mechanisms and allow flexibility to grow from there, in form of either replacing them by third parties completely or by plugin extensions.

      I also feel that looking at the code, this duality of WordPress in terms of blog/multisite is really apparent and disruptive to the overall architecture, and it would be made worse by introducing another fork in this code path with things like wp_get_network_type().

  • Jeremy Felt 11:40 pm on February 17, 2015 Permalink |
    Tags: multisite   

    Multisite Office Hours Recap (February 17, 2015) 

    Multisite office hours are held every Tuesday at 21:00UTC in #core-multisite and are followed by a casual bug scrub / ticket conversation at 22:00 UTC.

    We covered two agenda items today:

    1. There was some group interest in hearing from wp.com folks about custom solutions in place for multisite. @tellyworth, @pento, @boren, and @johnbillion were around to provide some insight.
    2. How to start the open/closed (trusted/untrusted) (magic/science) network conversation. Defining definitions and first steps.

    Notes on Core hacks in use at WP.com

    Logs for wp.com discussion.

    1. wp.com allows you to set a different language for the admin area and your site, not available in core due to performance reasons.
      • Use case: allow “users who may want their admin in one language and various sites on the network in various languages“.
      • wpcom_switch_to_locale() exists
      • Used for HTML emails as well, send emails in proper locale based on user defined settings.
    2. An async jobs system is used in a few places to run slow tasks, similar to cron. This would be great to see as a “show your work” plugin (i.e. HyberDB).
    3. Handling of cross domain cookies, full SSL. How is that handled?
      • Load wp.com JS in the header, which checks for an auth cookie on wp.com and on the custom domain.
      • If there’s no custom domain cookie, do some magic redirects to auth and write the cookie.
      • General musings over issues with x-domain, x-protocol.
      • Possible lessons to be learned from work on Customizer with domain mapping, mixed SSL, CORS.
    4. Custom network admin pages. Sign-ups, moving users and blogs around, changing usernames.

    In general from @tellyworth“My plan with most is to try to get additional filter/action hooks in core. So if I list the candidates for that, maybe we can identify the custom plugin features we have that are of general interest and could be released open source.

    General takeaways on the wp.com convo:

    • A @tellyworth post on hacks that could go into core via actions/filters/plugins/etc would be excellent.
    • Some sort of example showing off async jobs would be really cool. Similar to HyperDB as a “this is how you do it”.
    • We should look at wp.com cautiously when exploring cross-anything login, but also think outside of the box.
    • Keep exploring what’s possible with multi-language. Performance considerations, etc..

     Open/Closed Networks

    Logs for open/closed networks.

    We quickly solved the first unsolvable question for open/closed networks in multisite: Is it worth trying to user better terms than “open” and “closed” when talking about open/closed networks?

    • Yes. Open/Closed is too confusing, Trusted/Untrusted is too confusing. We need a better way of referring to this conceptually.

    The second unsolvable question took a bit longer, but was also solved: How do we describe this in a sentence?

    • @jjj paraphrased a good discussion – “multisite is now a utility for managing multiple sites using one installation, where as the original vision was to enable blogging networks“.
    • @johnbillion – “So, to that end, how can we best provide that utility in a simple way?”
    • General conclusion: A future in which installing a network is the choice of a pre-configured network type.

    After this we covered what network types might look like in core and how that could be facilitated through config or UI or… It seems there is general support for selecting the type of network to install during the standard setup process.

    Next steps. Sit on the granular bits of today’s conversation for the week and open a discussion thread on Make/Core for brainstorming network types and needs as a follow up to the previous GitHub issue. A granular discussion of network types will be the main topic next week.

    Be on the lookout for another post today to start the network types discussion. Thanks to everyone for a lively meeting today!

  • Jeremy Felt 6:48 pm on February 11, 2015 Permalink |
    Tags: multisite   

    Multisite Office Hours Recap (February 10, 2015) 

    We covered a handful of things in yesterday’s meeting. Multisite office hours are held every Tuesday at 20:00UTC in #core-multisite.

    Work continues to clarify our primary objectives and the order in which they should be approached. Here’s the current list:

    1. Solidify mixed domain/path support. This involves UX and related work in #22383 first. We need help testing what is supported, providing clear docs, and making sure things are working in general.
    2. Define open/closed networks and the words used to describe them. We’ve had some good discussion on this in the past. We need to find the right place to continue this discussion—likely a P2 thread of its own.
    3. Identify areas where featured plugins can be used to rapidly build out features over multiple releases.

    Areas discussed:

    • The future of activating multisite and the steps involved. Some things could be done to simplify the process overall, but we want to make sure its ready for the the accidental enabler.
    • #30202 – storage space used is calculated incorrectly on the main site. @earnjam is working on building out the patch some more to support an array of excluded directories and unit tests. It’s possible work here could help with #26135.
    • Hunt through old tickets in the multisite focus to look for staleness. There are always some good charms from the past.
    • It seems like we can close #16990 as invalid, a custom db-error.php is supported in multisite. We should take care of #30002 though.

    We’re expanding multisite office hours to include a bug scrub in #core-multisite immediately after the meeting. Mark 20:00 UTC on your calendars for office hours and 21:00 UTC for bug scrub and join us in #core-multisite.

    Tickets mentioned: #22383, #31217, #31148, #22251, #30202, #26135, #16990, #30002

  • Jeremy Felt 6:03 pm on February 3, 2015 Permalink |
    Tags: multisite   

    Multisite objectives discussion thread for 4.2 (and 2015) 

    I haven’t written up notes from the last two multisite office hours, so this is a compilation of sorts. We’ve started to hone in on a few objectives for the next few releases. Let’s use this post as a thread for discussion on these objectives.

    1. Arbitrary domain/path support for some networks should work, but there is no UI/UX in the network admin to support it. Testing various configurations should be a priority so that we can determine a possible interface through #22383.
      • Possible concerns involve dealing with URL conflicts and cross site/domain cookie handling.
      • WordPress MU Domain Mapping handles remote login, we should take a good look at this and get more examples.
      • URLs can get confusing, so care should be taken with `home_url()`, `site_url()`, `admin_url()`, `network_admin_url()`, etc…
    2. Nail some things down around open and closed networks so that we can find a path forward.
    3. Multisite focused feature plugins for 4.3, 4.4, and beyond. Quite a bit of work can be done quickly in a featured plugin to build out on an idea. Trying to attempt the same thing with some multisite internals can be a tough task. It would be cool to build out a few things as feature plugins and then work on implementing them.
      • Two commonly mentioned plugins are Network Privacy and the ability to enable plugins per site on a network.
      • I’ll post a list of plugins that were mentioned in on this thread, please continue to discuss here.

    Previous meetings covered by these notes – https://wordpress.slack.com/archives/core-multisite/p1421784125000115 and https://wordpress.slack.com/archives/core-multisite/p1422388887000007

    This weeks office hours are today in #core-multisite at 20:00 UTC, stop on by!

  • Jeremy Felt 4:59 am on January 14, 2015 Permalink
    Tags: multisite   

    Today’s Multisite Office Hours 

    We’re continuing multisite office hours in the new year on Tuesdays at 20:00 UTC in the #core-multisite room. This is a wrap-up of today’s discussion with some goals we have in mind.

    Major takeaways today:

    • Rapid iteration on new and existing ideas can sometimes be done best as a featured plugin. It would be nice to find some areas of multisite that could be addressed this way and start working for a release in 4.3 or 4.4. It is likely too late to include any new feature plugins in the 4.2 cycle and that’s ok.
    • A good sit is needed with @nacin’s multisite roadmap from late 2013. We should revisit this, see what progress has been made, and compare with the world today. As @sam mentioned, it would be nice to see an updated version that references the previous version.
    • Some workflow study is in order. We talked a bit about the painful workflows for multisite management in closed and open networks. Taking a good look at the pain points in current flows for new users, sites, plugins, themes, etc… would be good to get a grasp on priority. Looking at how WordPress.org is organized could provide a good model for a closed network.
    • With of the above combined (and more!), some actual prioritized goals for multisite would be nice. Bug fixes can continue to be addressed as they come in, but without established long term goals we’re “floating aimlessly” (props @earnjam) each cycle with our wish lists. :)

    So. The next week is for thinking, commenting, and collaborating. If anything above sounds interesting or inspires you a bunch, please leave a comment so we can start organizing around things.

    Also – we now have a #core-multisite channel in Slack, so hop in there any time with ideas or questions.

    Thanks all for the lively discussion today!

    Tickets that came up – #30486, #20846, #14569, #18301, #20774, #27606, #30202, #29411

    For the long version, office hours started in #core and then moved to #core-multisite if you’re looking for logs.

    • emarukyan 6:50 am on January 14, 2015 Permalink | Log in to Reply

      Hi, I’m the one who has created many websites on WordPress, for media agencies.
      There are couple of things I would like to see in WP Network.

      1. Option in WP Network setup – shared library or separate library (as it is right now)
      2. adding arbitrary domain on a network, not just sub domains of a single domain.

      Because none of the current plug-ins can be used for heavy load multilingual websites, I use WP Network to solve languages problem. So that’s why sometimes I need shared library across all networks, to have same featured image on the post for different languages.

      Thank you.

      • Ipstenu (Mika Epstein) 2:19 pm on January 14, 2015 Permalink | Log in to Reply

        Adding arbitrary domains is certainly on the radar, though plugins can do that already.

        Multilingual is likely not to be something solved in Multisite at this time.

    • Sam 12:30 am on January 15, 2015 Permalink | Log in to Reply

      Who were you trying to notify and email with the @sam tag mate? I am “@sam“, and it’s not me…

      (If it is someone else who goes by just @sam in some area of WordPress, would you mind directing me to them? Maybe I can ask them to stop constantly trying to reset their password with my user name too.. Haha.)

    • Ihor Vorotnov 9:55 pm on January 21, 2015 Permalink | Log in to Reply

      With all the respect to all of the core team, multilingual is feature that has to be solved asap. There are dozens of ideas and concepts, I personally wrote about this several times. That’s a core feature. It has to be in core. Multilingual plugin developers are ready to do all the job, they are just limited by the core limitations itself.

      • Ipstenu (Mika Epstein) 11:10 pm on January 21, 2015 Permalink | Log in to Reply

        MultiLingual and multiSITE are not the same thing. I’m not arguing that we shouldn’t have a core solution, but I don’t think that solution should be Multisite.

  • Jeremy Felt 4:33 am on November 21, 2014 Permalink
    Tags: multisite   

    Multisite Office Hours (Redux) 

    Several months ago, @wonderboymusic proposed office hours for Multisite. The response was great, but we kind of laxed on making it happen after the first one or two.

    After talking with a few people at WCSF last month, I’d like to fire this up again. As Scott mentioned before, there is no master plan, though there is a roadmap.

    We do have some interesting things that should be on the front of our minds:

    • What does a trusted network look like? #30145 introduced the concept and we need to figure out where to take it.
    • What kind of improvements could/should be made with a “feature as a plugin”? This may help to jump start some ideas, even if they aren’t merged into core immediately.
    • What steps should we take toward multi network? #29415 comes to mind immediately for a likely inclusion in 4.2. #30294 is another example.
    • Unit tests. I’d like to continue doing things like #30080 to really expand how we’re testing multisite.

    Let’s do our first office hours at 20:00 UTC this coming Tuesday (November 25). We can decide then if it’s appropriate.

    /cc’ing some that are likely interested – @ethitter, @johnjamesjacoby, @johnbillion, @ipstenu, @earnjam – but this is by no means a complete list.

    Please stop by in #core on Tuesday and comment away on this post with other things you have your eyes on.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar