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.
Wishlist:
* 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.
*Rennick
wp-login.php was also mentioned along with wp-signup.php & wp-activate.php
Yeah, but it’s not really a multisite thing.
That’s an interesting statement. Do you mean there are too many use cases to come up with ‘common’ APIs? Because there are too many difference use cases for WordPress, but we can provide people with easier tools to meet those cases. The two primary use cases (free and controlled) is a good start, but maybe we need to reach out and get a better list?
Speaking from support? Please don’t do this. The hurdle of people having to do that actually weeds out folks who shouldn’t be using Multisite. It’s certainly easier now, but that extra step isn’t a bad thing. What’s the reasoning behind changing that?
I guess I didn’t phrase it properly. Yes, there might be common use cases that would make sense to have in Core, but we just don’t know about them, so some kind of survey would be good.
There was a question: why is it so hard to set up Multisite? I tend to agree that enabling WP_ALLOW_MULTISITE by default should be accompanied by more profound improvements. Here’s a memorable quote from JJJ during that talk:
Yes, thank you JJJ
that was what I was worried about too.
If we can make it easier … Okay, I say that and I totally feel that Multisite, the basics, is easy, but it goes back to what you said about too many use cases. The ones for Single WP are well worn paths, for the most part, and when someone comes up with the wild and wooly, they accept that they need to make their own trail. Multisite is all new paths. I have a blog post in draft, about why it’s so damn hard to find the right plugin for Multisite :/
After 3.5 goes live, a think a survey to sort out what people want in Multisite, coupled with looking at the multisite plugins that are highly used, should be in order.
(I wanted to come to this talk, but it was opposite another one I wanted to go to, so Multisite lost, since I knew I could just pester Ron later
)