Multisite Office Hours Recap (December 13, 2016)

Multisitemultisite 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 office hours are held every Tuesday at 17:00 UTC in #core-multisite. The next will be Tuesday 17:00 UTC.

The weekly agenda was to discuss long-term goals for multisite and prioritize tickets to work on related to one of the three new focuses, particularly the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/..

Today’s chat log

Attendees: @iamfriendly, @mista-flo, @johnjamesjacoby, @loreleiaurora, @johnbillion, @jeremyfelt, @flixos90

Chat Summary:

  • @jeremyfelt, @flixos90, @johnjamesjacoby, and @johnbillion sat down for a chat at WCUS to discuss multisite topics and possible future focuses. @jeremyfelt shared his notes from that session. Items of particular interest in today’s chat were:
    • Identify statistics for multisite usage, size of multisites: Possibly sending more general multisite-related metrics during coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. updates could be helpful and should be further discussed. In addition to whether multisite is enabled and the count of sites (on the main networknetwork (versus site, blog)) it could be helpful for future decisions to know how many sites there are in total, how many networks exist and whether user / site registration is open or not.
    • Implementation of network user roles: A ticketticket Created for both bug reports and feature development on the bug tracker. is in place at #39174. @flixos90 requested feedback: Everyone interested is asked to read through the ticket description and provide an elaborate response with how they think network roles should work. Then a discussion based on these approaches can start.
    • Network administrators should be able to enable themes on the site level: It is currently not very convenient for a network administrator to switch back to the network adminadmin (and super admin) to enable a theme when currently working within the site admin.
    • Disable plugins per site in the network admin: Sometimes not all plugins should be visible on all networks or all sites, which is currently not possible. However, even for a disabled theme a network administrator should still be able to “silently” activate it on a site. Plugins would need to be enabled by default, so it would be the opposite way of how themes are currently handled. This also ensures there are no concerns with backward-compatibility. UIUI User interface-wise an improved flow should be investigated instead of simply pursuing a similar approach to how enabling themes works: Having all the functionality inside the Network > Plugins screen would be helpful, with row and bulk actions for “Network Disable” as well as “Disable for Site…” with the latter having some kind of popover with an autocomplete field for sites. A related ticket to take into account for the implementation is #38652 which @johnbillion opened to introduce singular capabilities for managing plugins.
    • Whichever flow is agreed on for disabling plugins per site or network, once this functionality is implemented, it will probably makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). sense to “back-port” the behavior to improve the existing theme and maybe even user handling in a multisite.
  • At this point, the highest priority is multisite support for the REST API.
    • The users endpoint should be improved, particularly the implementation of DELETE for a user on a multisite as well as removing a user from a site or setting their capabilities per site via PUT (see #39000 and #38962 for related tickets).
    • A sites endpoint should be added.
    • A networks endpoint is not as important and should for now only live in a standalone pluginPlugin 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 if there is interest to implement it.
  • A general question raised was how No-JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. fallbacks for REST API functionality in the admin should be handled. Should JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. become a requirement to use such new functionality or should the REST API only be used to improve existing PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20-only features? These questions should be discussed in a broader scope than just multisite since they affect all of WP Admin.
  • Possible usage for a REST API sites endpoint:
    • Replacing “My Sites” in the toolbar with a menu that doesn’t load until needed and pulls all sites from the APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways..
    • The possible autocomplete field for disabling plugins for a specific site (see above) could pull sites from the API.
  • @mista-flo brought up #13743 and asked for feedback. Everyone in the chat agreed that the ability to set a default theme for a network would be a valuable enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. over the existing constant. For the approach, introducing a new row action “Set default theme” the Network > Themes list table was suggested, alongside an indicator “Default Theme” in that same table. This is an enhancement that can be worked on beside the other important REST API features.
  • A Google document was opened a while ago to gather input for a future multisite roadmap, as a follow-up to 2013’s post. @jeremyfelt highlighted that this document should continue to move forward in order to hopefully be able to publish an actual roadmap in early January.

#4-8, #multisite, #network-sites