Participants: Ronnie Burt, James Mowrey, Jake Goldman, Ron Rennick, Frederick Townes, Andrew Nacin, John James Jacoby, Pippin Williamson, Ptah Dunbar, Scott Taylor, Ryan Boren, Cristi Burcă, Peter Chester.
The roadmap so far has looked like this:
3.0 – initial WPMU merge
3.1 – a proper network admin area
3.5 – several enhancements (no more
ms-files.php, being able to install MS in a subdirectory)
There was a big gap between 3.1 and 3.5.
There are two main, competing usecases for Multisite:
- a network of independent sites (like wordpress.com)
- a small number of tightly controlled sites
Since the first case is the original reason why Multisite was created, it covers it pretty well. It doesn’t do so well in the second case. To separate the two use-cases, we could have a “controlled network” flag: when set, automatically enable all themes on all sites etc.
The main problem is that it’s hard to share data between sites in a network. We have
switch_to_blog(), which is faster in 3.5, but still needs caching around it.
The consensus was that there are too many different use cases right now. At this point, the best solution for developers is to build their own APIs; custom global database tables are fine.
- domain mapping in Core
- multi-network support in Core
- enable-disable (not activate) plugins per site, similar to themes
- revisit register_update_hook()
- wp-signup.php and wp-activate.php should become theme templates and/or forms
- admin UI for users that haven’t activated their accounts yet
- settings API that works for network admin
- default WP_ALLOW_MULTISITE to true
Action item: set up team for Multisite component and triage existing multisite tickets.