Make WordPress Core

Opened 14 years ago

Closed 13 years ago

#11407 closed enhancement (wontfix)

Make WP insist that the user upgrades the site after a certain amount of time

Reported by: denis-de-bernardy's profile Denis-de-Bernardy Owned by: ryan's profile ryan
Milestone: Priority: normal
Severity: normal Version:
Component: Security Keywords:
Focuses: Cc:

Description

Some users ignore upgrades for all sorts of reasons, and end up putting their site at risk.

While I find it perfectly understandable to wait a few weeks when a new major release is around, the behavior is completely nuts when it's a minor release that addresses a security.

Just tossing ideas around, but... would it make sense to make WP gently nag as it does initially. And when it's obvious that the site's owner is ignoring the nag after two weeks, WP places a huge nag on all admin pages: a lengthy page that highlights that the blog's security is being put at risk. It should occupy enough screen place to make the site's admin area hard to use until the site actually gets upgraded.

Change History (20)

#1 @caesarsgrunt
14 years ago

+1

Or even disable the whole admin and just show a notice telling the user to upgrade. It would have to be possible to hide these notices with a constant in wp-config, for those who can't upgrade.

#2 follow-up: @caesarsgrunt
14 years ago

And this shouldn't be shown except for those with permissions allowing them to upgrade; low-permission users should have an undisrupted admin (with the current small notice at the top).

#3 in reply to: ↑ 2 @Denis-de-Bernardy
14 years ago

Replying to caesarsgrunt:

And this shouldn't be shown except for those with permissions allowing them to upgrade; low-permission users should have an undisrupted admin (with the current small notice at the top).

Actually, I tend to disagree here. Unless I'm mistaking, the latest series of security issues all involved non-privileged users who escalated themselves as admin users. So if we go the route of preventing the admin area from working at all (which I'd +1, personally), it should really be entirely, for every user.

#4 follow-up: @filosofo
14 years ago

After so many days, we should send electrical shocks through their keyboards. I think there's an ActiveX method that lets you do that.

#5 in reply to: ↑ 4 @Denis-de-Bernardy
14 years ago

Replying to filosofo:

After so many days, we should send electrical shocks through their keyboards. I think there's an ActiveX method that lets you do that.

Heh, you'd be surprised. I recently ran into a user who had had upgrade nags for over 18 months. She simply ignored them... And I know for a fact that she is not alone among my customers who do this. Some even have multiple error messages on the top of each page (e.g. plugin A requires this, plugin B requires that...) in addition, and a plugin update nag complete with a Mass Upgrade button, and a theme update nag. And they just cope with having to scroll down half a screen in order to post. :-(

#6 follow-up: @miqrogroove
14 years ago

I will give this a point if you agree to also merge the Disable Core Update plugin as a standard setting.

The reality for anyone who uses plugins is that the core upgrades are incompatible until proven otherwise.

#7 in reply to: ↑ 6 @Denis-de-Bernardy
14 years ago

Replying to miqrogroove:

I will give this a point if you agree to also merge the Disable Core Update plugin as a standard setting.

The reality for anyone who uses plugins is that the core upgrades are incompatible until proven otherwise.

I would know, yeah... That WP breaks much about everything with every new release has been my bread winner for almost 5 years now. :-)

Seriously, though, better to have a broken plugin than a hacked site full of viagra links. So big -1 on allowing to disable core update checks, or any update checks for that matter, in core.

#8 follow-up: @miqrogroove
14 years ago

Seriously, though, better to have a broken plugin than a hacked site full of viagra links.

Better to have a working version 2.8 site than a crippled admin panel. I'll see your viagra links and raise you a load of indecipherable cyrillic.

#9 in reply to: ↑ 8 @Denis-de-Bernardy
14 years ago

Replying to miqrogroove:

Better to have a working version 2.8 site than a crippled admin panel.

Oh, but that's another problem entirely. that issue has to do with testing, testing, testing, testing, ... (x100 times more), testing.

I wonder... Say, has anyone been arguing since around 2.8.0 (and 3 years earlier, but nobody remembers) that we should a) keep the bloody ticket list to a manageable level, b) lengthen the release cycle, c) lengthen the test cycle in order to ensure we've proper QA in WP, and d) (more recently) increase the number of core devs so that potential contributors stay around for long enough to get involved instead of fleeing away from lack of traction? Mm... I wonder who that might be...

#10 @miqrogroove
14 years ago

and e) Not punt bugs during beta.

#11 follow-up: @dd32
13 years ago

ok, Given 2.8.x is supposed to be supported until 3.0 is released(I think that was decided upon?), This ticket makes hardly any sense for major releases.

Changing the colour of the update notice depending on how long the update has been out is an option..

#12 in reply to: ↑ 11 @Denis-de-Bernardy
13 years ago

Replying to dd32:

ok, Given 2.8.x is supposed to be supported until 3.0 is released(I think that was decided upon?), This ticket makes hardly any sense for major releases.

This ticket is less about major releases than it is about minor ones that fix security issues.

Changing the colour of the update notice depending on how long the update has been out is an option..

That changes nada. Some users have multiple nags on every admin page, and they still don't upgrade. We should force them to do so for their own sake.

#13 @dd32
13 years ago

That changes nada. Some users have multiple nags on every admin page, and they still don't upgrade. We should force them to do so for their own sake.

Its a much less invasive method, and stresses the importance of it.

Another option could be to extend the "Welcome" screen idea for 3.0 to have an "Upgrade!" screen listing the benefits of upgrading.

Locking a user out of their blog should NOT be an option, It'll get people to upgrade, but it'll rattle a lot of cages. Its not like WordPress is being provided as a service to users, Its their choice to run it, and their choice to uprade. Nagging is all that can be done.

#14 @miqrogroove
13 years ago

It'll get people to upgrade, but it'll rattle a lot of cages.

It's more likely to cause people to avoid the version that has that feature altogether, and/or install the Disable Core Update plugin. Imagine the panic that would grip the blogosphere when alarmists get wind of the software vendor intentionally crippling admin panels.

#15 @westi
13 years ago

I don't think that any software should nag so much that it gets in the way of the user doing there work.

#16 @caesarsgrunt
13 years ago

No; you're probably right.

I propose that after a certain length of time or if there is more than one major revision out since upgrading, whichever comes sooner, the notice should go red, state that there is a major security problem, and link to a page explaining the benefits of upgrading.

#17 @Denis-de-Bernardy
13 years ago

It should also be turned bold, with a larger and noticeable font. And it should link to Matt's september post about sites getting hacked, so that users who don't upgrade feel very insecure about not doing so. :-)

#18 @Denis-de-Bernardy
13 years ago

k, so what's the consensus on this one? shall we just closed as wontfix? shall we make the nag much bolder and visible at all times? only after two or three weeks?

#19 @hakre
13 years ago

I suggest as wontfix. If the user selected to not get a nag again, then it's already the users choice. No need to fix something that is not broken (maybe even close this patch as invalid).

This can be properly solved as plugin material and/or a nice info on the welcome screen (#11651) / a system info screen that offers update info regardless of the nag.

#20 @Denis-de-Bernardy
13 years ago

  • Milestone 3.0 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

lack of traction

Note: See TracTickets for help on using tickets.