Email administrators that an update is available for core|plugins|themes

[dd32]

Inspired by the recent 'email notifications for updates' plugins discussion on wp-hackers/other forums, I'd like to propose the functionality actually be included in core.

I'm thinking of a daily email (Or perhaps, even when WordPress does the update checks) that says along the lines of:

WordPress would like to notify you that you have 3 updates available:
WordPress 2.9.1
Plugin: Super Plugin 4
Theme: My Theme

Only email when the updates havn't changed since last email.

Core potential? Or leave it for plugin material?

[JohnMyr]

I`m not sure whats planned/discussed when it comes to canonical plugins, but I feel that this functionality should be supported, but as a core distributed canonical plugin with auto activation.

Distributing it will help in making the ignorant upgrade, which will help WP community by making WP less attractive to target for blackhat hackers. There should be an option to remove it though, so a canonical distributed plugin with auto activating is the best solution imo.

Plugin`s admin notification and email should also have an url to an extensive codex article covering all upgrade related issues.

[dd32]

Plugin`s admin notification and email should also have an url to an extensive codex article covering all upgrade related issues.

Unless its currently available in the Admin interface, I dont see a need to include mention of it in this ticket. If you'd like more info related to upgrade issues to be added to various sections, Please open a new ticket.

Disabling the emails should be supported regardless.

[JohnMyr]

Please disregard my inappropriate comment about the function as addressed by dd32.

[Alphawolf]

+1

[dd32]

Whilst a plugin (actually, several) exist for this purpose, Given its come up on wp-hackers twice in the last ~month, and generally has been taken as a positive move for the majority of users, I'll write up a patch for this for 3.0(Given 2.9's feature freeze).

[westi]

We discussed this in the Oct 22nd dev chat and the consensus reached was:

• Leave the notification by email for a single blog to a plugin.
• Revitalise the announcements list and use it for every release.
• Improve the copy in the default post to point to the announcements list and remind people to keep updated.

Therefore closing as WONTFIX.

[demetris]

Replying to westi:

We discussed this in the Oct 22nd dev chat and the consensus reached was:

• Leave the notification by email for a single blog to a plugin.
• Revitalise the announcements list and use it for every release.
• Improve the copy in the default post to point to the announcements list and remind people to keep updated.

Therefore closing as WONTFIX.

For the 3rd item in westi’s list, see: ​http://core.trac.wordpress.org/ticket/11008

[jane]

This has come up a number of times since this ticket was closed, so re-opening to discuss given current situation.

I think this would be popular as an option (on by default) in Settings, especially as more and more users skip the dashboard and post directly from the front end. This will become even more commonplace with 3.1, after @jorbin makes QuickPress a template tag and any theme can have a front-end posting form.

Re above suggestion that it be a canonical plugin: Core/canonical plugins have not panned out as originally expected due to lack of momentum/time from contributors, and even if we were ready to go with the pilot core plugins, they wouldn't be bundled.

I believe Matt would like to see this in core, and I know I would for the reason I stated above. Anyone want to weigh in?

[jane]

To specify: I'm actually not promoting a daily email, but one tied to the core update schedule. I could see a v2 enhancement or a plugin providing user with the ability to set how frequently a check/notification cycle should run.

[dd32]

i'm still a +1 on this, and would gladly write a patch if its where everyone wants to go.

The way i see it, On every update check that runs

• if the set of available updates returns a NEW item for update (since the last check) send an email to the administrator's listed email address
• That email should contain something similar to:

  You have 1 new update ready to install on "dd32's super site!"
   * Plugin XYZ - Some Plugin Author
      Addresses a XSS security issue.
  
  You have 3 other updates previously emailed
   * WordPress 3.2.5 is Available
      Security Update to address xxxxxxxx
   * Theme TwentyEleven v0.5 is Available
   * Plugin ABC - Author
      Correctly implemented uninstall capability instead of rolling my own.
  
  WordPress Admin: http://...../
  

• Emails about Updates would only be offered once, if the user doesn't update a plugin, they won't receive nagging emails, only a mention of it when the NEXT update is available.
• Question: Should inactive plugins/themes cause an update notification email however?

This is a prime functionality which an option would be best for, It could even fit right along side the privacy option in the installer for pre-setting.

Filters would also be included to change the destination email from the "owner" to something else as well as what conditions should spark an email, which would open the way for a plugin which controlled how often/if nagging emails can be sent/what updates trigger notifications, etc.

[demetris]

Replying to jane:

This has come up a number of times since this ticket was closed, so re-opening to discuss given current situation.

I think this would be popular as an option (on by default) in Settings, especially as more and more users skip the dashboard and post directly from the front end. This will become even more commonplace with 3.1, after @jorbin makes QuickPress a template tag and any theme can have a front-end posting form.

Re above suggestion that it be a canonical plugin: Core/canonical plugins have not panned out as originally expected due to lack of momentum/time from contributors, and even if we were ready to go with the pilot core plugins, they wouldn't be bundled.

I believe Matt would like to see this in core, and I know I would for the reason I stated above. Anyone want to weigh in?

I think we are getting too far ahead of ourselves.

You cannot suggest to add a feature NOW based on what users MAY do when theme developers MAY START discovering a feature that was just checked in and that MAY or may not be well implemented and that users MAY or may not like.

Even if the scenario goes exactly as you imagine, and more and more people start checking the backend less and less, we could simply have the update notifications appear in the new admin bar too. (Not only we could, but I believe we should: this information is too important to omit from there.)

Also, importantly, this imagined scenario does nothing to address the concerns of all the people who have said that emailing admins by default is not a good option.

[scribu]

Marked #14444 as duplicate.

[scribu]

I agree with demetris. This will be less necessary in 3.1, since we will have the admin bar that will display update notifications.

[nacin]

While the admin bar is an excellent point with regards to front end editing, it doesn't help in a situation where A) the administrator is not the content producer, or B) where a site, such as one that functions primarily as a CMS, goes a long time between updates.

[Mrmist]

Unfortunately the situation where the administrator is a content provider is not catered for here, though.
Providing a filter is not really a suitable solution, because that then implies a need for plugin bloat just to send this email to the correct contact(s).
Fix the way to identify technical as apposed to content admins, then look at stuff like this.

[MattyRob]

Please also read through the now closed 14444 ticket.

There are many reasons for not implementing this without an option to turn off at the very least. At best leaving this for a future release would be wise.

• Admins who are content posters will check for updates regularly
  
• Admins who set up sites for authors and then leave will not welcome lots of emails from all the sites they have enabled
  
• This already exists in a plugin which has been downloaded less than 4,000 times - not that popular then
  
• It seems the proposed method above will email me daily until I update, major annoyance if I choose to wait a month to ensure a new release is stable enough for my main sites or if a plugin change breaks my theme[[BR]]

I think the reasons against this proposal outweigh the reasons for it. I welcome any debate.

[dd32]

There are many reasons for not implementing this without an option to turn off at the very least.

I don't think anyone is wanting to force this on users, Much like comment notification emails at present, you can turn them off if you wish.

• Admins who set up sites for authors and then leave will not welcome lots of emails from all the sites they have enabled

Then they shouldn't be leaving their email in the blogs they setup, Set it up with your own email, then set it to the clients.

• This already exists in a plugin which has been downloaded less than 4,000 times - not that popular then

Unfortunately not everyone will install a plugin for something they don't see as absolutely essential, I'd be willing to wager a bet that the majority of users who were given the extra functionality, would actually use it.

• It seems the proposed method above will email me daily until I update

I'll personally make sure that's not done. Anything that spams or nags will get the boot, Anything more than a single email notifying ONCE about an update is not in the interests of users.

#14444

I count less than half a dozen contributors, all on similar lines of attack (I dont want emails, Let me turn it off!, No longer control sites, don't want to be spammed, Don't want to be told sites that are working have updates available, don't want more work! etc). I can see where ALL of those points of view come into hand, But they're all very specific users of WordPress, Put it to the WordPress Support Forums or wp-hackers and you'll get a very different subset of users.

However, To rebut it, Here's my list of people who would appreciate it:

• Users who upgrade when they're aware an update is available - Not everyone logs in every day of the week, some do not get a chance to login weekly.. It all varies
• Users who do not use an Administrative login for every day tasks - Face it, Everyone *should* do this, but not many do.
• Users who use non-backend methods of posting, This is not just Front-end posting, but those who use 3rd party applications such as XML-RPC clients or the ipad client, etc.
• Users who manage their jobs from their email - They can file the email as a job to get to when they've got the time
• Users who do not search for a plugin to achieve every small bit of functionality which makes their life easier - Think of a function in WordPress you use and find a golden tool, that 99% of people out there don't even know exists.. There's plenty of us with those, Update emails are one of them, Not many people have downloaded the existing plugin, how many people have attempted looking for it?
• Those who control multiple WordPress Installations where they dont login often - This has said to be a reason why people -wouldn't- want to recieve notifications, But i feel it fits in both categories. Some systems administrators/web developers/content providers/whatever like to keep on top of their security status. In the event that a security release is made to a plugin they're using, or a security release of WordPress is made, you can be sure that anyone with any competence WILL want to update it. Leaving it open to attack is the sign of sheer stupidity. I can understand the "If it's not broke, don't fix it" and I come across this enough, But many live to regret it with security related patches.

It's late, so i'm not going to list anymore. I would be highly surprised if it turned out that less than 50% of end users didn't use it. That's a huge percentage, but it's got a much larger target audience than say, The file editors, Links, Post by Mail, the Atom Feed, or even perhaps, Press This.

it might even be worthwhile having the ability to opt-out of the emails, In the sense that the email that is sent, has a link at the bottom with a long-term nonce & hashkey which disables the notifications to that email address.. simply for the cases where users no longer have access to the sites in question (and someone else has upgraded it)

[MattyRob]

@dd32,

Well I am reassured a little that this is going to be something that can be turned off and that it won't become a spamming annoyance to those who don't want it.

In the interests of the debate though...

The wp-hackers list should be a list of people who know what they are doing - why they should want a reminder that WP needs an update is beyond my understanding. As for the forums - yes, I agree but the majority of forum stuff I see around the time of a new release is not about the process of updating it's asking if it's 'safe' or complaining that the update broke something.

So, to your list of people who might appreciate the feature - that's a comprehensive list but can you put numbers on it? How many users of WordPress blog by XML_RPC and email and the other methods you list?

Interesting what you say about the plugin too. While you propose that may users will like this feature how many have actively asked for it? Adding everything including the kitchen sink does not make WordPress better - adding too much makes for bloatware and a worse user experience.

So, opt out is an absolute must if this is done, but first how much demand is there for this feature. What we have thus far is a small group saying it's a good idea and another small group saying it's a great idea. So, use the power of WordPress / Automattic and run a poll - ask users if they want this feature and respond accordingly.

[oh, and 50% isn't a huge percentage - it's half but it was late and I think I know what you meant]

[JDTrower]

Replying to demetris:

Even if the scenario goes exactly as you imagine, and more and more people start checking the backend less and less, we could simply have the update notifications appear in the new admin bar too. (Not only we could, but I believe we should: this information is too important to omit from there.)

Personally, I think it is a good idea to implement an email notification system into WordPress Core. This allows blog administrators that update and maintain sites they are not the content producers for the opportunity to keep up with updates to plugins/themes/core that they might otherwise forget about in their day to day life. What I don't want to see is WordPress relying on the new admin bar as the means of showing update notifications as the solution to this problem. As soon as the admin bar makes it into WordPress core and is released to the public in a stable release, I will begin looking for the ability to permanently disable it on every WordPress site I run or administer. I hate that bar on WordPress.com and I don't want it or need it on my self-hosted WordPress sites.

+1 to a email notification system.

[MattyRob]

@JDTrower,

I'm with you on the admin bar thing too. I think features like these (admin bar, email notifications) are sometimes thought of as great ideas but in practice they are not widely welcomed.

To be honest if both of these things come in I'll be waiting a long time and testing lots on the stable release before updating. I am not sure I like the fact that with every release I need to apply hacks to turn stuff off though. This should not be standard practice but maybe it's just me.

As for emailing admins, how about operating a mailing list that announces new release independently of the core? There is always going to be an issue on hosts who totally block outgoing email because in this situation the email won't make it past the server even when WordPress tries to send, so this is not an all conquering solution anyway.

[JDTrower]

@MattyRob,

I see where you are coming from in terms of this email system. I think it would be good to include in core, my personal thought is it should be OFF by default so the user has to Opt-In to get the emails (if there server configuration allows it). If this feature is on by default then, I think I would view it as a built in spam machine (I am a personal advocate that everything related to email lists and related email issues, like the one proposed in this ticket, should always be Opt-In, not where the user is added and then has to make the effort to Opt-Opt). I support the feature because I can see the usefullness for me on sites that I am not the content provider but I do provide technical support and update support. There are sites where I log in every time there is a core update or I know there is a plugin update because the plugin is one I use on sites that I am the content provider, but outside of those times I don't log in unless the content provider is having a problem. In cases like that it would be useful for me to get a single email once when a plugin has an update so I can go in and update it. But I want it to be something I have to enable, so it is my choice to get the email. I don't want WordPress deciding for me that I should get those emails.

There technically is a mailing list that is suppose to receive announcements when new releases are made, but I can only recall one recent update being announced on that mailing list in the entire time I have been subscribed to the list. I personally wouldn't need the built in email system to notify me when there has been a new update to core. I follow core development pretty closely, so I know when a new release is coming or has been released. But there are too many plugins that I have used over a wide variety of sites for me to personally keep up with when they get updated without a system like this one in place.

[MattyRob]

@JDTrower,

Personally, I'd be more than happy if this went into core and was OFF by default BUT the idea behind this is to get 'the ignorant' to update. So, if it is left off by default what makes us think that 'the ignorant' will enable this option?

The issue at the centre of this ticket is, to my mind, the thorny issue of getting people to update their WordPress core, plugin and theme files when updates are available.

Announcements are already made on the WordPress site and these are rapidly blogged around the WordPress community. There is a message shown to admins in the backend, there is a mailing list (that appears to be ineffectively used by the WordPress dev team) and there is a plugin available that already does what this ticket talks about but has rarely been downloaded.

So, even though I'm against putting this into core I can't see any benefit at all in adding it but turned off by default. The 2 options are to not add it at all to core but make better use of the communications systems already in place or add it and turn it on my default (to achieve the aim of the ticket) but allow people to turn it off quickly and easily.

[jane]

Putting something in core but off by default means we're second-guessing ourselves. Either it's important enough to be in core or it's not.

[nacin]

​http://polldaddy.com/poll/3993569/

It seems that opposition to this mainly comes from people who run more than a few sites. They (myself included) should be considered the exception. That's also why we'd allow it to be turned off. (I'd rather stuff it in a filter, myself, but it looks like it will be an option.)

I've asked the leads to weigh in whether this should be for core only, or plugins/themes as well. I'm thinking leaving it to core only for 3.1.

Someone willing to code this? If not I will handle it over the next few days, as Dion is now on vacation.

[markjaquith]

No patch. Punting.

[dd32]

I'll leave myself as owner for 3.2, I honestly believe, that it'll be best for the majority of users, and all polls and conversations I've seen/had seem to support that

[SergeyBiryukov]

Related: #22704

[nacin]

Moving to 3.7 for consideration, see ​http://make.wordpress.org/core/2013/08/28/core-updates-in-3-7/

[bpetty]

Maybe I interpret that 3 year old poll differently, but the "Maybe, but I'd want a setting to turn it on or off." response seems to me to basically mean "I don't care", and in that case, there's really only 34% of all users who actually care about and want this feature. So it seems pretty far from the 80/20 case, and more in plugin territory from what I can tell.

It's been long enough though that I'd be curious to see this poll run again.

On the other hand, as long as we're pushing for automatic updates, these ultimately shouldn't ever be sent out regularly. However, that also means that if an automatic update *can't* update for any reason, there definitely should be an email notification about it.

In any case, this ticket (and poll) should probably be re-aligned to actually discuss email notifications on automatic update notifications (for both success and failure).

[dd32]

Clearing owner - If someone wants to patch this up, please post your thoughts and/or a patch

[jorbin]

As discussed in the ​dev chat this week , we need four templates.

4 templates. 1) Yay, your site got auto-updated, warm and fuzzy. 2) Hm, we couldn't auto-update your site for some reason. 3) Yo, if you didn't see, WP 3.7.1 was released yesterday, please update. 4) follow-up sent rand(15,20) days later. "Version %s was released %d days ago. It is important that you update immediately."

Here is some draft wording for them

1)

Howdy <name>,

WordPress X.Y.Z, a ['security and bug fix update', 'bug fix update'] was released and has been installed on <site url> automagically. No action is needed on your part, but if you see any problems or need support, the volunteers in the WordPress Support Forums are hanging around ​http://wordpress.org/support/ to help.

2)

Howdy <name>,

WordPress X.Y.Z, a ['security and bug fix update', 'bug fix update'] was released. We tried to install it on <site url>, but were unable to. You should update your site post haste in order to keep it running smoothly. Unsure of how to update? Read ​http://codex.wordpress.org/Updating_WordPress or visit the WordPress Support Forums at ​http://wordpress.org/support/ to get some help.

<if no constants for turning off updates are defined>

Want to stop receiving notices like this? Visit <codex page> to lean how to enable automatic updates for security releases.

3)

Howdy <name>,

This is a reminder that WordPress version X.Y.Z was released yesterday. In order to keep <site url> secure and running smoothly, please update immediately. Unsure of how to update? Read ​http://codex.wordpress.org/Updating_WordPress or visit the WordPress Support Forums at ​http://wordpress.org/support/ to get some help.

4)

Howdy <name>,

This is your third reminder that WordPress version X.Y.Z was released <%d> days ago. it is imperative that you update <site url> in order to keep your site secure. Unsure of how to update? Read ​http://codex.wordpress.org/Updating_WordPress or visit the WordPress Support Forums at ​http://wordpress.org/support/ to get some help.

[johnbillion]

This could do with a patch to help wrap up the auto-update functionality for 3.7. Anyone?

[atimmer]

​10787.1.diff is a small start to kick things off.

[nacin]

In 25837:

Introduce email templates for automatic background updates.

The four templates are:

1. We successfully updated their site. If any of their themes or plugins are out of date, it also mentions that. ('success')
2. We are not configured to update their site, so we notify them of the new release. ('notify')
3. We tried but failed to update their site. The error was early in the process, so no harm, no foul. This is the same as template #2, plus one sentence. ('fail')
4. We tried to update their site, and failed while copying files. ('critical')

With assistance from markjaquith.

see #10787.

[nacin]

10787.diff​ sends the emails added in [25837]. Heavily documented because of all of the different situations it needs to account for. It also pretty much fixes #22704.

The big thing it implements is it tracks core auto update failures in an option, using that to decide whether it can re-try an update. In a nutshell:

• If the update is a success, it lets the user know. Only in this instance: If there are any updates available for plugins or themes, it also adds a short note about it.
• If a critical failure occurs (files started to be copied), the only way it ever tries an auto update again is if a manual update (pushing the button) is successful. It emails the administrator a very urgent note. (We haven't seen a single critical failure occur this week — this will ideally be rare, as it basically requires major I/O failure.)
• If a non-critical failure occurs, like being unable to write to all required files, it will block auto updates to that version. But a future new version will gain the ability again. It emails the administrator a note saying we tried but couldn't update.
• If a transient non-critical failure occurs (like download_failed, which is usually going to be a network issue), it allows unlimited retries. But, it won't email the administrator right away. It'll schedule an update for an hour from that point of failure (rather than waiting 12 hours). If it fails again, *then* it'll email the administrator. I wasn't going to implement this originally, but markjaquith brought up a good point: the issue could actually be with WordPress.org, in which case we'd be emailing a lot of people to update in the middle of a brief network issue or something.
• If we can't update (as in, we don't even try), and the API has tagged the release as notify_email => true, then it'll send an email to the administrator. We don't need to push this flag out right away with a new release. For example, we could use it for major releases a few weeks after the fact.

It needs some testing. I'll make sure dd32 looks at it. Let's get it committed today.

[dd32]

Replying to nacin:

10787.diff​ sends the emails added in [25837]. Heavily documented because of all of the different situations it needs to account for. It also pretty much fixes #22704.
...
It needs some testing. I'll make sure dd32 looks at it. Let's get it committed today.

10787.diff​ looks good to me, I see nothing wrong with it, and it appears to catch all the cases we've been testing with.

[nacin]

In 25841:

Notify administrators of successful, failed, and pending core updates.

Blocks future background updates after critical failures, but allow retries in certain situations. More in the ticket.

fixes #10787.

[TobiasBg]

The check for strpos( $wp_version, '.1.next.minor' ) looks weird. When does $wp_version contain that? I can only see '1.next.minor' being added to the strings in the $future_minor_update object.

[nacin]

That check should be on $failure_data['current'], not $wp_version, I imagine.

[nacin]

In 25843:

Use correct variable. fixes #10787.