Add user capability check to WordPress update nag

[krogsgard]

The WordPress update nag has been in effect since the introduction of the WordPress admin update API as far as I can tell. In WordPress 2.3, with #4869, a check was added to differentiate between the language provided to users with manage_options and other logged-in users. In WordPress 3.0, the check was updated to utilize the new update_core permission.

Today, WordPress users should not be assumed to have any form of relationship with the site owner or anyone with update permissions. The nag currently shows for any logged in users, even those with read only permissions.

I don't think I should get update notifications on sites I'm only marginally attached to. Example A:

An example use case is eCommerce. Pretty much anyone making an order will get added as at least a subscriber level, and therefore if they find their way to the WordPress admin (perhaps to edit a profile), they'll get a WordPress update nag.

I'd propose that we limit the nag to users with at least some form of site management permissions.

I'd personally prefer that only editors and above get the nag: perhaps using the permission for publish_pages. Alternatively, we could limit to admins and those with permission to update_core and ditch the secondary language to notify an administrator. At an absolute minimum, I think we should limit it to edit_posts, or the contributor role.

[ryan]

Trustworthy auto-upgrades is how we will get sites to upgrade. Persistent nags don't do it, especially persistent nags to nag a site administrator with whom you have no relationship. Limiting the nag to editors or above sounds good. I might even talk myself into admin or above.

[vancoder]

Check for publish_pages cap before nagging

[MikeHansenMe]

31470.diff​ is coded just slightly different than the previous patch. It also tries to clean up some code sniffer warnings in the general area of the changes.

[johnbillion]

@MikeHansenMe: we try to avoid doing formatting cleanup on lines other than those directly affected by a patch. It greatly increases the cognitive cost of looking over a patch and deciding what is actually having an affect and what is just formatting cleanup.

[johnbillion]

I was going to suggest changing the cap to publish_posts so Authors see the message too, but I agree with Ryan that persistent nags aren't particularly effective. Using publish_pages is fine.

[nacin]

I'm very, very strongly against this. Three anecdotes:

• I don't know how many times I've heard from a friend in journalism or government, "yeah, our site is out of date." And they know it because of this nag. WordPress enters itself into organizations almost never from the top. It enters from the bottom and the middle. The people managing their site need to get their act together and update it. It's WordPress that's empowering these users. It's important for them to still feel empowered.

• I don't know how many times, whether at a meetup (WP or not), or a conference (WP or not), or a coffee shop (Jitterbug or not), I've noticed someone in their WordPress dashboard. This nag stands out, and it's a great way to help them. In fact, they're usually like "oh yeah I'm just scared." And so I push the button with the promise of fixing their site if it breaks. Works like a charm, and now suddenly they're never gonna worry about pushing that button again.

• How many people pay someone to set up a WordPress site, and then are given an editor account? The person who sets up the site keeps the admin account for maintenance reasons. Makes sense; it's common to suggest not giving people tools to shoot themselves in the foot (also security etc). But what's the first indication that the site is no longer being as maintained as it once was? What's going to cause the editor / blogger / business owner to ping their guy or gal and say "hey, can you update my site?" This nag, right here.

(Since it was brought up originally: tongue-in-cheek, if I'm buying something from a site with WooCommerce, and I get dumped on the dashboard and see this nag, which is a bad UX on the site's part by the way, hell yeah I want to know if the site is out of date and potentially insecure.)

I know some of the proposal here is to limit it to certain user roles, but I'm sorry, update your damn site, and then the people who have lower roles won't see this.

[krogsgard]

@nacin I think your anecdotes make sense, though only for update_core, not a lower cap. I still think it's not good for read only users to see this. Often, maintenance teams perform updates on a weekly cycle, for instance. There is no context in the current language as to the severity of the available updates. It's simply a scary message and not a good one imo for most users.

[helen]

I don't see us doing this in 4.2, in any case.

[krogsgard]

I still think this is a good idea, but in current state (a veto from Nacin essentially) I guess for the sake of gardening it can be changed to wontfix.