WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#31470 closed enhancement (wontfix)

Add user capability check to WordPress update nag

Reported by: krogsgard Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.1
Component: Role/Capability Keywords: has-patch
Focuses: administration Cc:

Description

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:

https://cldup.com/Uxjh2hLmKi.png

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.

Attachments (3)

31470.patch (2.4 KB) - added by vancoder 6 years ago.
Check for publish_pages cap before nagging
31470.diff (2.8 KB) - added by MikeHansenMe 6 years ago.
31470.2.patch (1.8 KB) - added by ocean90 6 years ago.

Download all attachments as: .zip

Change History (16)

This ticket was mentioned in Slack in #core-flow by krogsgard. View the logs.


6 years ago

#2 @ryan
6 years ago

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.

#3 @DrewAPicture
6 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 4.2

@vancoder
6 years ago

Check for publish_pages cap before nagging

#4 @vancoder
6 years ago

  • Keywords has-patch added; needs-patch removed

@MikeHansenMe
6 years ago

#5 @MikeHansenMe
6 years ago

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.

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


6 years ago

#7 @johnbillion
6 years ago

@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.

#8 @johnbillion
6 years ago

  • Keywords commit added

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.

Last edited 6 years ago by johnbillion (previous) (diff)

@ocean90
6 years ago

#9 @nacin
6 years ago

  • Keywords commit removed

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.

#10 @krogsgard
6 years ago

@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.

#11 @helen
6 years ago

  • Milestone changed from 4.2 to Awaiting Review

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

#12 @krogsgard
5 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

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.

#13 @ocean90
5 years ago

  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.