Make WordPress Core

Opened 5 years ago

Last modified 3 years ago

#47085 new enhancement

Site Health appear on individual sites in Multisite

Reported by: iandunn's profile iandunn Owned by:
Milestone: Future Release Priority: low
Severity: minor Version: 5.2
Component: Site Health Keywords: has-patch needs-dev-note
Focuses: administration, multisite Cc:

Description

The tests are all related to the server or the network of sites, rather than individual sites. Individual site admins are unlikely to be able to perform most of the recommended actions.

Would it make more sense to place the page in the Network Admin area, rather than on individual sites?

Attachments (2)

47085.diff (4.8 KB) - added by donmhico 5 years ago.
47085.2.diff (6.6 KB) - added by donmhico 5 years ago.

Download all attachments as: .zip

Change History (31)

#1 @iandunn
5 years ago

  • Priority changed from normal to low
  • Severity changed from normal to minor

Er, it uses the install_plugins capability, so regular admins wouldn't see it anyway. It still probably makes more sense to place it in the Network Admin, but there aren't a lot of tangible downsides.

#2 @Clorith
5 years ago

  • Milestone changed from Awaiting Review to 5.3

Agreed that multisite hasn't been given enough attention this time around. I'm thinking that we'll improve on this for 5.3, and introduce a view in network admin with all the heavy data, and a more generic version for end users, as many features are useful to regular site maintainers as well, especially as plugins and themes can extend them.

For now, as you mentioned, the capabilities limits it to network admins any way, so I'm happy not making any adjustments here for 5.2

This ticket was mentioned in Slack in #core by iandunn. View the logs.


5 years ago

#4 @SergeyBiryukov
5 years ago

  • Component changed from General to Administration

#5 @desrosj
5 years ago

  • Component changed from Administration to Site Health

Moving Site Health tickets into their lovely new home, the Site Health component.

@donmhico
5 years ago

#6 @donmhico
5 years ago

  • Keywords has-patch added

The attached patch 47085.diff, adds the Site Health wp-admin/menu.php if not in MS. So individual sites in MS won't be able to see it.

Then it adds the Site Health menu in wp-admin/network/menu.php. It's a parent item since there's no "Tools" parent menu in Network admin.

I also changed the "Status" and "Info" tabs to use network_admin_url() instead of admin_url() since the former will just fallback to the later if not in MS.

Let me know your thoughts regarding the patch.

#7 @iandunn
5 years ago

Thanks! I would probably add a Tools parent menu in the Network admin, for consistency, and then put Site Health under that. There may be future situations where we'd have a similar need for that (e.g., privacy tools).

I don't have time to do a deep dive, but at a quick glance the rest of the patch LGTM :)

@donmhico
5 years ago

#8 @donmhico
5 years ago

Thanks for the feedback @iandunn. I've attached a new patch, 47085.2.diff, that creates a new Tools parent menu in Network admin. But since for now, Site Health is the only child for the Network > Tools and I don't have any idea what content network/tools.php will have, I just directly use site-health.php on the Tools menu declaration, instead of creating a tools.php.

Also, I placed the Network > Tools above Network > Settings to make it consistent with how the menu in single WP is arranged.

Lastly, I used $menu[24] for the Network > Tools. I know that the menu uses increments of 5. However, I'm not sure if modifying Network > Settings from $menu[25] to $menu[30] so we can use $menu[25] for the Network Tools menu won't break anything.

#9 @iandunn
5 years ago

Those sound reasonable to me, thanks!

#10 @garrett-eclipse
5 years ago

I like the thought @iandunn about adding privacy tools here as well so spawned #47940.

As to what should live on the Tools root page @donmhico I added a relation to this ticket from #46745 so when tool cards get introduced they can be introduced for this new Network Admin > Tools page you're introducing.

#11 @Clorith
5 years ago

  • Keywords has-patch removed

I like the approach of implementing a network admin level entry for the tool, but I don't agree with removing it from sites in the network, the debug information will likely be needed in support scenarios for example, individual settings on a site may impact functionality, stuff like that.

I'm thinking there needs to be a few checks on what data is shown to the site admins, versus what network admins see in these scenarios though. See for example how the installation size is omitted on a network setup, or checking for core updates won't be of much use to site admins, since only network admins would have that power normally.

The fact it wasn't available to site users in the first place was, unfortunately, an oversight on my part, so I would love it if we rectified this here.

#12 @donmhico
5 years ago

Thanks @garrett-eclipse. I'll take a look on those tickets.

@Clorith - Thank you for your input. What you said make sense. If it's possible, I need the list of data that should be shown to Network Admin vs Site Admin so we can proceed with this approach.

Version 0, edited 5 years ago by donmhico (next)

#13 @Clorith
5 years ago

  • Milestone changed from 5.3 to Future Release

As we're moving into the 5.3 beta period, I'm moving this ticket out of the 5.3 milestone, as there's unfortunately not been any changes to it since the last input.

Time permitting, I think multisite would be a good focus for the Site Health Check in the next version, as the current version has focused a lot on improving the user interface and developer side of things.

#14 @Clorith
4 years ago

  • Milestone changed from Future Release to 5.5

#15 @Clorith
4 years ago

I milestoned this for 5.5, the intent is to improve network install behavior with that release :)

#16 @SergeyBiryukov
4 years ago

In 47300:

Site Health: Prevent the Site Health Status dashboard widget from loading on network admin screen for now.

Props Clorith, pbiron.
See #47606, #47085.

This ticket was mentioned in Slack in #core-site-health by afragen. View the logs.


4 years ago

#18 @afragen
4 years ago

  • Keywords has-patch added

This ticket was mentioned in Slack in #core-site-health by afragen. View the logs.


4 years ago

This ticket was mentioned in Slack in #core-site-health by afragen. View the logs.


4 years ago

#21 @afragen
4 years ago

As discussed in #core-site-health meeting today, we should create a listing of the checks that would be specific to the network admin.

This ticket was mentioned in Slack in #core-site-health by afragen. View the logs.


4 years ago

#23 @Clorith
4 years ago

  • Keywords site-health has-patch removed
  • Milestone changed from 5.5 to 5.6

I don't think we can realistically create a list of checks as mentioned in comment:21 before the 5.5 beta, I'd like to put this on the 5.6 list though, as it's gotten pushed twice, and it would be nice to get this resolved properly.

But perhaps getting a quick workgroup together to look at this list before the official 5.6 kick-off happens is an idea, that way we'll be ahead of the curve for 5.6, does this sound like a good plan forward to you, @iandunn ?

#24 @iandunn
4 years ago

Yeah, that sounds good.

This ticket was mentioned in PR #559 on WordPress/wordpress-develop by Clorith.


3 years ago
#25

  • Keywords has-patch added

Trac ticket: https://core.trac.wordpress.org/ticket/47085

This PR creates a new Tools section for the network admin, so that Site Health checks can be separated between single site and multisite setups.

It also introduces the concept of individual capabilities to check singular health checks and debug roles.

This new set of capability checks will allow single sites in a network-scenario to only show actionable items for them (for example, updating plugins, themes or WordPress falls to the network admin, a single site can not do anything here).

This will likely need a bit of input as I am uncertain of the best practices for how to achieve the end goal, separating items so they are available only to those who can (or should) have access to them.

#26 @Clorith
3 years ago

So I did an initial pass with PR#559 above, would love some more eyes on that, as multisite at this level is a whole new world to me, and it also does some interactions with meta capabilities which are also rather new to me (pinging @peterwilsoncc here as he helped me with the initial details around that).

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


3 years ago

#28 @davidbaumwald
3 years ago

  • Keywords needs-dev-note added

These new filters will need a small call-out on the Misc Dev Note, for whichever cycle they end up landing in.

#29 @Clorith
3 years ago

  • Milestone changed from 5.6 to Future Release

Punting this as I've not had the time over the weekend to go through everything proper, we'll likely be able to land this for 5.7, but punting to future release until it's clear.

Note: See TracTickets for help on using tickets.