Join the Discussion on Defining Network Types for WordPress Multisite

photo credit: Doors Open Toronto 2008 – Toronto Archives – (license)

Towards the end of 2013, WordPress lead developer Andrew Nacin outlined a potential roadmap for multisite that would address a number of long-standing questions regarding network setup and organization.

When multisite, formerly known as WPMU, was first introduced, building large blogging networks was the primary use case. Over the years, the uses for multisite have evolved to encompass those who use it to facilitate the management of multiple, and sometimes unrelated, sites. In the future, contributors want to add the option for super admins to select from a list of pre-configured network types when installing a new network.

The discussion in the #core-multisite room on Slack this week centered around identifying and defining different network types. The terms Open/Closed and Trusted/Untrusted were identified as possibilities, but nothing has been set in stone, as both options are ambiguous and confusing.

Jeremy Felt summarized the questions that need to be answered before multisite development 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.

Multisite is used in a wide variety of ways, i.e. networks where super admins control everything, blogging networks where site admins have limited capabilities, private networks with closed registration and a set of trusted admins, and many more. It’s difficult to accurately nail down a small set of pre-configured network types that will be suitable for any new installation.

One interesting idea, proposed by Mike Schinkel, is to allow developers to register a custom network type in order to better fit unique cases:

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.

Even with the option to register custom network types, WordPress core will still need to identify the most common ones to include in its set of pre-configured options. Contributors have been discussing this issue over the span of several months in order to find the best way forward.

If you want to join in the conversation regarding the future of multisite, particularly as it relates to defining network types, make sure to leave your feedback on the recent Make/Core post: Multisite Objective: Defining Network Types. This will be the main topic of next week’s multisite office hours.