[wp-trac] [WordPress Trac] #15800: Adding tabs to the "Edit Site"-pages in Network Admin

[WordPress Trac]

#15800: Adding tabs to the "Edit Site"-pages in Network Admin
-------------------------------------+-------------------------------------
 Reporter:  PuffyThePirateBoy        |       Owner:
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Future Release
Component:  Networks and Sites       |     Version:  3.1
 Severity:  minor                    |  Resolution:
 Keywords:  has-patch dev-feedback   |     Focuses:  accessibility,
  early                              |  administration, multisite
-------------------------------------+-------------------------------------
Changes (by johnjamesjacoby):

 * keywords:  has-patch dev-feedback => has-patch dev-feedback early


Comment:

 15800.2.patch does the following:

 * Refreshes patch for WordPress 4.6-early
 * Adds a `cap` to each tab, so they can be conditionally checked and/or
 skipped
 * Modifies each of the 4 files referenced in core tabs to include their
 new capabilities: (`manage_site_info`, `manage_site_themes`,
 `manage_site_users`, `manage_site_settings`)
 * Adds more sane filters on tabs and arguments vs. HTML output
 * Removes the `nav-tab-small` classification, because big is beautiful and
 this is the last remaining/only place in core that uses these tiny tabs
 * Moves the wrapper HTML into `before` and `after` arguments that can be
 filtered, should someone want to get fancy with this interface on their
 own without modifying core HTML
 * Adds some output buffering to encapsulate the final output of all of
 this processing and calculation

 A few talking points after chatting with @jeremyfelt:

 * What if we want to abandon these tabs later? Personally, I don't think
 we should, because these tabs make for a convenient and useful interface
 for power users in a trusted position. I can see making this fancy like
 the Appearance bar, but removing them seems drastic.
 * How do we want to really truly allow these tabs to be filtered? I can
 imagine a bunch of ways, but I used Mercator as an example of adding
 domain mapping here. Right now, it has to use JavaScript to inject it's
 tab at the end, which isn't very great. I believe tabs alone could be
 filtered, and that someone might want to totally override this interface
 to suit their power-user needs, so I've included 2 filters for both of
 those purposes.
 * Did we get the ARIA tags right? I think there's much more we can do
 here, but what's in the patch seems like the bare minimum and follows what
 WordPress is already trying to do.
 * Is the output buffer absolutely necessary? No, but I like the idea of
 batching this output and rendering it all at once. Why do this? In the
 unlikely event of OOM errors, no tabs render vs partial or incomplete
 tabs. It also prevents jumpiness on slow connections while tabs are looped
 through and echo'ed. I have a tendency to do this with most loops that
 shouldn't communicate to the user if an interruption occurs, so I included
 that philosophy here. WordPress core also does this in several places
 already, though I consider it an unwritten rule.
 * I have a somewhat selfishly urgent need to see this happen in 4.6-early,
 so whatever I can do to get yay/nay from interested parties and a sign-off
 from Jeremy, I will keep an eye on this and shepherd as needed.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/15800#comment:25>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform