Make WordPress Core

Opened 14 years ago

Closed 11 years ago

#15738 closed feature request (duplicate)

Automate Security Releases

Reported by: ericmann's profile ericmann Owned by:
Milestone: Priority: normal
Severity: trivial Version:
Component: Upgrade/Install Keywords: needs-patch dev-feedback ux-feedback
Focuses: Cc:


When security releases are published, several less tech-savvy users might neglect to update in fear of breaking their site. In reality, security/maintenance releases don't change the core API and shouldn't break anything*.

We should have an option (disabled by default) that allows these X.X.1-style security updates to happen in the background. This will keep sites updated and secure and (hopefully) prevent the inevitable "I wanted to wait to install 3.0.2 and someone hacked my site while I was waiting" support requests.

The option should be disabled by default, but when users are on the update screen they should see an option to "install security releases automatically."

Major releases should always require an explicit action from the user to update the site as they can break themes and plug-ins and could potentially update database schema.

  • Except in the rare occasion where a developer hacks core.

Change History (6)

#1 @ocean90
14 years ago

  • Keywords dev-feedback ux-feedback added; needs-dev-feedback needs-ui-feedback removed

#2 @dd32
14 years ago

This will not be possible (securely) on all installations, even if the user requested. Hosts which require the usage of FTP are ruled out straight up, as storing the FTP password is a no-no (Incase the system is exploited).

Personally I believe #10787 would be a better way of helping users update faster.

#3 @jane
14 years ago

  • Milestone changed from Awaiting Review to Future Release
  • Type changed from enhancement to feature request

I would love it if we could security updates automatically, but when it's been discussed before the variations in server setup etc has always been the blocker. Moving this to future release, it can be discussed in 3.2 dev cycle. Notification emails (as referenced by dd32) is something all the leads have signed off on, so that's more likely to make it into 3.2.

Also changing type to feature request, as this isn't a tiny little fix to the existing process, but an entirely new one.

#4 @bastosmichael
13 years ago

  • Cc michael@… added

#6 @nacin
11 years ago

  • Milestone Future Release deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #22704, which has more work.

Note: See TracTickets for help on using tickets.