These are the notes from a breakout discussion on 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 at the core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. meetup All local/regional gatherings that are officially a part of the WordPress world but are not WordCamps are organized through https://www.meetup.com/. A meetup is typically a chance for local WordPress users to get together and share new ideas and seek help from one another. Searching for ‘WordPress’ on meetup.com will help you find options in your area. with me, @markjaquith, and @nacin. As with all of these discussion summaries, please remember that they’re just discussions. I’m posting the notes for transparency purposes, not to say that these are the only things discussed or decided. I’m working from notes, and sometimes you don’t get everything down when you’re taking notes (next year I’ll record these things instead).
Who can lead this joint? Since the merge and Donncha moving on to other things, we had Ron for a cycle, Pete for a cycle, then no one. It would be good to have someone act as component owner.
Multisite needs parity with the single site experience. Includes UI User interface, UX User experience, copy/strings, install flexibility (subdomain etc), installation ease (add a site).
First we need to improve the manage/use experience, then fix install stuff and get it into the dashboard to turn on multisite.
We need a useful global dashboard.
We need to have flexibility in where sites and networks live — should be able to live wherever you want on one network (versus site, blog). Subdomains/subdirectories/mapping/whatever you want, mixed subdomain/subdirectory, custom domains, global permalink consumer/router.
Need to fix different workflows: adding users to network, adding users to site, invitations. User signup, creation, assignment, invitation all need new flow
We need parity between plugins and themes. Enable vs activation is confusing, need to improve language, indicators. Need ability to network enable but disable for individual sites. Need to standardize network enable/activate etc for plugins/themes. Network activated plugins don’t show in individual site’s 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 list, which is confusing.
UX Action Items:
UX ACTION ITEM — Include network activated plugins in the plugins menu and give message that it is automatically on for the whole network (if admin (and super admin)/have rights to see plugins screen).
UX ACTION ITEM — Autocomplete usernames or site names for network admin and for superadmin everywhere.
UX ACTION ITEM — Get multisite tag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.)/indicator on plugins in directory, add multisite specific/required indicator.
Under the Hood Action Items:
ACTION ITEM — Get rid of MS-FILES.
ACTION ITEM — Enable install in subdirectory so you can use externals.