WPMU confusion: multiple TLDs are okay, WP Multi Network is not

[rachelwhitton]

Re: WordPress Multisite: Unsupported Use Cases

Priority: Medium

Issue Description:

• Last item in the list of unsupported use cases for WP Multisite on Pantheon is confusing and gives the impression that we do not support connecting multiple top-level domains (TLDs) to a single Multisite application.

  WordPress Multi-Network installations where multiple domains can be added aside from subdomains and subdirectories.

• The following section, titled "Request a WordPress Multisite" talks about the supported alternative for WP Multi Network, which is to request a WP Multisite custom upstream for your workspace, allowing you to create new networks on-demand by selecting the WP Multisite framework during site creation. However, because it's in a separate section, it's not clearly positioned as the supported alternative for the unsupported WP Multi Network use case.

Suggested Resolution

• Revise copy of the last unsupported use case item, do not mention multiple TLDs in this copy since that scenario is not exclusive to this use case and is actually supported. Redefine this use case as "a network of one or more multisites on a single instance, commonly achieved via plugins like WP Multi Network." Provide context for why this usage is not supported.
  • Add a sub-bullet that positions WP Multisite custom upstream as the supported alternative, and provide context for why this alternative is better.
• Revise the section "Request a WordPress Multisite" with more distinction between a single network requirement (I need one WP Multisite) vs a requirement to create new and separate networks self-serve (I need a WP Multisite custom upstream). Right now the copy assumes anyone asking for WP Multisite needs it delivered as a custom upstream

[jazzsequence]

multi-network is different from multisite. Multi-network refers to a single WordPress instance with multiple distinct multisites as part of the network. The description in the doc that describes multi-network as "multiple domains can be added aside from subdomains and subdirectories" is incorrect. Multi-network is unsupported, but it should be described as "a network of one or more multisites on a single instance" or something to that effect.

[rachelwhitton]

@jazzsequence thanks! that's helpful, I updated the suggested resolution in the issue description based on your comment.

Could you provide context for why we don't support the Multi-network use case? And context for why the supported alternative is better (separate network instances managed by a common WPMU custom upstream)?

[jazzsequence]

Multi-network requires a very specific, bespoke server environment setup that we don't really have the capacity to one-off (or support). Multi-network is also broadly more of an edge case used for large networks (like WordPress.com + WordPress.org + the WordPress plugin repository + the WordPress theme repository + WP Make sites + the developer hub, etc, etc, etc). There aren't very many use cases for multi-network that wouldn't be easier to solve with many separate multisites unless you were actively trying to be a webhost (which, if I'm not mistaken, is explicitly spelled out in our ToS).

The only reason you'd maybe want to use a multi-network if you weren't trying to be your own webhost is something that is unlocked/solved for with a common WPMU upstream for all your separate multisites (that is, you want to keep a common codebase for your network of multisites).

[jazzsequence]

@rachelwhitton

Right now the copy assumes anyone asking for WP Multisite needs it delivered as a custom upstream

This is actually technically true, although it is not (necessarily) a custom upstream that the customer maintains (but it could be). See https://getpantheon.atlassian.net/wiki/spaces/ON/pages/2569797666/WP+Multisite+upstream+configuration+Gold for the playbook for setting up multisites. tl:dr; The difference from our side is the Framework value which is not a field that is visible when customers are creating custom upstreams, which is why the request is necessary.

[rachelwhitton]

@jazzsequence Right, but from a users perspective the important distinction is "I want one WPMU network based on the upstream Pantheon maintains" vs "I want a custom upstream that supports WPMU" yeah? It shouldn't matter if the end-user understands that the WPMU framework is achieved behind the scenes by a custom upstream that is maintained by Pantheon in a private employee organization right?