WordPress.org

Make WordPress Core

Updates from Jeremy Felt Toggle Comment Threads | Keyboard Shortcuts

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

    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 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( ”,
      array(
      ‘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
      ‘super-admin’,
      ‘administrator’,
      ‘editor’,
      ‘author’,
      ),
      ‘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
      array(
      ‘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 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:00 pm on February 16, 2015 Permalink |  

    Multisite Office Hours – Rescheduled to 21:00 UTC on Tuesdays. 

    During a discussion last week, we realized there was an opportunity to involve more people in the weekly multisite office hours by adjusting the time a bit. Starting tomorrow, weekly multisite office hours will be at 21:00 UTC Tuesday in #core-multisite. We’ll also follow that with a weekly multisite bug scrub at 22:00 UTC Tuesday.

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

    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 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:   

    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 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.

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

    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

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