We’re having a dev chat about Multisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site in #wordpress-dev tomorrow (May 14, 2014 18:00 UTC). I’d like to split the chat into two main areas:
- Open vs. closed networks
- Everything else
The concept of an open network (versus site, blog) where users can create their own sites was the popular impetus for WordPress MU, but is decidedly not the primary use case for multisite anymore. Most operate closed, trusted networks, where site signups are disabled (and often user signups are disabled as well).
Back in October, Andrew Nacin published a collection of thoughts on potential changes to Multisite, one of which was the idea of open vs. closed networks. I’d like to discuss this concept and whether now is the right time to tackle it. Here are some relevant paragraphs from that post:
When a network is not designed for “open registration”, there are a number of undue burdens that should be lifted for administrators. Uploadable file types are severely restricted, and the amount they can upload is capped. They cannot activate installed plugins, though there is an option for this. They cannot add users to their sites without knowing their email address (ostensibly to prevent spam), and the user must still go through a “confirmation” process. New sites must go through an “activation” process. They cannot create new users.
I don’t think WordPress needs to decide that the multisite feature is only geared for closed networks. Rather, a single option — set on install, and controllable via network settings — can control this entire paradigm very effectively.
Essentially, I am proposing we trust single-site administrators in a closed network to not be spammy, and to be given wide-ranging control of their own sites; but that we do not extend that trust to important areas of security.
So, let’s discuss whether now is the time to introduce the concept of open vs. closed networks, what form it takes, and to which functionality it extends.
- What differences should we see between an open network and a closed network?
- Open user registration
- Open site registration
- Capabilities for regular Administrators (plugins, themes, users)
- Email notifications (amount of, and wording in)
- User listing and user editing UI User interface differences
- Site listing and site editing UI differences
- Network admin (and super admin) dashboard UI differences
- What form should the open vs. closed network option take? A UI option when installing multisite? Changeable after the fact or set in stone like subdir/subdomain option?
- What changes need to be considered for existing multisite installs?
Secondly, let’s discuss all other multisite improvements that we would like to see. Several may well be related to the idea of open vs. closed networks, and that’s ok. Here’s a list to get us started:
Reign in notification emails when adding sites, users
- Improve user searching – #27304
- Improve user management
- Better explanations for what archive/spam/delete does to a site
- Merge in the Hyper Admins plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party
- Merge in the User Management Tools plugin
If anyone has particular issues they’d like addressed (bonus points for existing tickets on Trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.), leave a comment and we’ll see what we can cover.
Two other items worth mentioning are:
- Domain mapping
- SSL Secure Sockets Layer. Provides a secure means of sending data over the internet. Used for authenticated and private actions. improvements
I don’t think we’re yet at the stage where we could consider implementing domain mapping in core Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. It has a prerequisite of removing the subdirectory vs. subdomain paradigm, and we’re not near approaching that (unless someone wants to step up).
Regarding SSL improvements, I’m planning on arranging a separate working group to tackle a whole raft of SSL improvements in core that aren’t just related to multisite. I’ll be publishing a separate post in the next couple of days to get us started.