Opened 5 years ago
Last modified 4 years ago
#47085 new enhancement
Site Health appear on individual sites in Multisite
Reported by: | 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)
Change History (31)
#2
@
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
#5
@
5 years ago
- Component changed from Administration to Site Health
Moving Site Health tickets into their lovely new home, the Site Health component.
#6
@
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
@
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 :)
#8
@
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.
#10
@
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
@
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
@
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.
I'll add dev-feedback
in this ticket to get more attention and possibly reach a consensus of how to resolve this.
#13
@
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.
#15
@
5 years ago
I milestoned this for 5.5, the intent is to improve network install behavior with that release :)
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
This ticket was mentioned in Slack in #core-site-health by afragen. View the logs.
4 years ago
#21
@
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
@
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 ?
This ticket was mentioned in PR #559 on WordPress/wordpress-develop by Clorith.
4 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
@
4 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).
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.