Joomla! Update notification email plugin#6886
Joomla! Update notification email plugin#6886nikosdion wants to merge 10 commits intojoomla:stagingfrom nikosdion:feature/update-notification-email
Conversation
There was a problem hiding this comment.
It will avoid confusion if this is worded The addresses instead of the emails
|
Can you update the language file to follow this rule please
|
Some third party security solutions require a secret query parameter to allow log in to the administrator back-end of the site. The link generated above will be invalid and could probably block the user out of their site, confusing them (they can't understand the third party security solution is not part of Joomla! proper). So, we're calling the onBuildAdministratorLoginURL system plugin event to let these third party solutions add any necessary secret query parameters to the URL. The plugins are supposed to have a method with the signature: public function onBuildAdministratorLoginURL(JUri &$uri); The plugins should modify the $uri object directly and return null.
|
Everything worked great in the test except one minor issue. I received a link to my site missing a sub directory: Emailed Link Actual Link: I'm pretty sure this is just an issue from the plugin as i created a test user account, and the link in that contained the proper full link. (So, its not a configuration file issue). |
This comment was marked as abuse.
This comment was marked as abuse.
|
Ah. yeah sorry, subfolder is before /administrator. Typo in GH. (Anyone who reads this later: I fixed it in my comment above so you won't know what we're talking about) |
This comment was marked as abuse.
This comment was marked as abuse.
|
Got it. Tried to be a smart-ass with JURI. Scratch that, I switched back to the tried and tested manual string manipulation code. |
|
@PhilETaylor I fixed that before you said it! @nikosdion I usually use |
This comment was marked as abuse.
This comment was marked as abuse.
|
@PhilETaylor I checked with phpcs using the same command line defined in .travis.yml It seems to not complain about anything. Real bummer that we have to still use phpcs 1.5 though. phpcs 2 can auto-fix the code style issues but you need to rewrite the code style package as it's not compatible with 1.5 :( |
|
@nikosdion |
|
@infograf768 I thought of that but I decided against it for two reasons:
So what happens when someone has, say, his admin language in Greek, updates to 3.5.0, the Greek language is out of date and 3.5.1 comes out? He'll get a confusing email with subject PLG_SYSTEM_UPDATENOTIFICATION_EMAIL_SUBJECT and contents PLG_SYSTEM_UPDATENOTIFICATION_EMAIL_BODY. Coming most likely from their own email address which they've used as the site's mail from address. With a from name matching their site. They will think that their site is hacked. Actually, I know this for a fact. This is what happened with the very first version of this feature in Admin Tools. By falling back to English we are sure that this plugin will never, ever send out an email with a subject or body consisting of a confusing untranslated string. In fact, if you look at the code, you'll see that I have commented the code that does that with the wording: |
|
@nikosdion Priorities:
I.e. I am only concerned by the first part of your reply:
I am not convinced by this argument as even if it takes a few minutes to send the mails, who cares? |
The visitors of the site care. The plugin hooks on the onAfterRender plugin event. While the plugin executes Joomla! doesn't return the rendered page to the browser. Anything over one second is extremely noticeable by the visitors. My target was less than 10% impact on the page load speed (provided the mail server is configure correctly and doesn't take forever to authenticate the user – this is beyond my control). |
|
What would be the benefit or the reason why someone would ever opt out?
|
|
For starters, someone might be using a third party updater like Akeeba CMS Update instead of Joomla! Update. Maybe they're using a third party update notification plugin, like the one I have in Admin Tools and won't remove until we drop Joomla! 3.4 support (that's gonna take a while, I'm afraid). Or they're using a service like myJoomla.com or Watchful.li to update their sites remotely. Or they are using a custom or host-provided Joomla! auto update solution. Or, more likely, they're site integrators and they don't want the end clients updating Joomla! themselves, either out of the need to charge their clients a maintenance contract or out of the knowledge that an update can backfire and they MUST take backups before, something the client is unlikely to do. All these are valid reasons in my book. Of course this all affects power users who are more than adequately competent to disable a Joomla! plugin. |
|
I said that cause i was thinking for next update, so i need to turn off this plugin on more than hundred of websites could be borring (no need to receive email; incoming spam ;) ) but you right, this is just useless if not enabled by default. |
|
Why do you need to turm it off in your use case
|
|
You can write a quick'n'dirty CLI script to disable the plugin through the database and use SSH to deploy it to each site, run it and remove it. If you are managing 100 sites you should be able to handle that, otherwise I can't imagine how you find the time to get any sleep at all :) |
|
@brianteeman Part of agency, maintenance contract, so i know when i need to update website, i follow day per day Joomla ;) @nikosdion Yeah, you right, possibility to write another script to do that, just wanted to point you that kind of circumstance. |
|
Yes, I was aware of that case. Actually, I thought that it would either be an agency like yours (write their own scripts, end of story) or they'd be using a service like myJoomla.com and watchful.li. In the latter case the connector for the service installed on the site can disable the plugin automatically since it's got a predictable name. The few folks left managing dozens of sites without the benefit of mass deployment, a management service or a host-provided auto-update solution will probably need the two-click upgrade email to remember to update everything. It took me a week to contribute the code I've already written since I was going through past support tickets and taking notes about all the potential issues my clients were worried about. That was one of them. I believe I have addressed everything that was thrown my way over the last two years. I'm pretty sure that some people will moan and groan nevertheless but I'd rather be the bad guy who "forces" them to upgrade than a complicit to their sites being left out of date, getting hacked and then have them accuse all of us contributors for "Joomla! being insecure" ;) |
@nikosdion Ok then we can place a message that only tells that we add a plugin that do it and tell why it is enabled by default and show (mark as dangerous) the way to disable it. But without a Than we can
The problem i see is that we here introduce again a good feature that is hidden for 80% of our users as they don't read announcement or something that we can provide in the wiki etc. Ok only until the next update (we expect that the email sending works and not errord or break the site) but i guess, if they get much unwanted emails or the site goes down for any reason, they will say "Why Joomla not inform me about it". To follow your example with the operationsystem. I guess you don't expect that your system automagic is sending emails to you (or others) after you update it without that it say someting like:
Ok now you can say "If they don't read announcments or the wiki they will not read postinstall" Just my 2 cents BTW Also one more point all good things are three 😄 (announcement, wiki, postinstall 😃) |
Hidden?! The whole idea of having the plugin ENABLED BY DEFAULT is the exact opposite of hidden.
Um, because Joomla! can't notify you if your site goes down because BY DEFINITION in this case Joomla! doesn't run? Also, what the hell has this got to do with my PR?! If your site goes down temporarily then when it's back up, guess what, you'll receive your notification email.
Did you actually READ the email text included in the PR?! What you're asking me to add is in there, only much more improved in clarity. The email text tells people who sent the email, why it was sent and how to disable it.
Also, between a release announcement nobody knows it exists, a wiki few will ever read (and even those of us who KNOW there's a page won't find it), a postinstall message many see but few read and an in-your-face email with all the necessary information which one do you think has a better chance of being read?
Which is exactly what the email does. Because the email text is in language strings. Which are translated by the TTs.
I disagree. Post-installation messages should be used sparingly. Namely when there's an important optional feature which we can't enable by default. If you add a gazillion post-installation messages the next thing you know everybody ignores them. People are lazy. If you bombard them with overwhelming amounts of information they'll stop reading, click Hide on each and every message and won't even notice a NEW message at all. If we're to use post-installation messages merely for covering our own asses I suggest we remove com_postinstall and shove a page down some wiki with all these messages, then stuff a link to it somewhere under the help menu (the one menu spot sun never shines upon...). Again, this feature DOES NOT HAVE A SECURITY, BACKWARDS COMPATIBILITY OR PERFORMANCE IMPACT. There is no need to warn users about it. In the worst case scenario they'll be baffled that they received an email from their site. Opening the email clears it up: the email tells them who sent it, why and how to stop it from being sent ever again. If they can't an email in their own language I'm afraid that nobody can help them. Using Joomla! after all requires an IQ slightly higher than that of boiled cabbage... |
|
@test all good This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/6886. |
|
@test works as advertised. thanks Nicholas. |
|
Setting RTC - thanks This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/6886. |
I can't remember exactly what was the problem. If I recall correctly I had one test site which would return the wrong URL when the plugin was triggered from the back-end and that workaround fixed it. The code works and if it ain't broken... This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/6886. |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry @nikosdion it was my fault. All ok here. And as sayed above good new feature. Thanks |
|
No problem :) |
|
Merged into 3.5-dev. Thanks Nic! |
|
Thank you @nikosdion for your contribution! |
|
My pleasure :)
|
|
Is there any way to add a field to change the default notification time? I like the update notifications, but I don't need it to keep reminding me every few hours. Options for once per day, once per week, and once per month would be useful. Thanks. This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/6886. |
This comment was marked as abuse.
This comment was marked as abuse.
|
I understand that, but when managing 50+ sites it can be difficult to upgrade them all immediately – especially when a patch/new version is released within a few days of the previous version. I guess I’m thinking more of a delay in between notifications. Having a notification immediately when a patch is available is good, but I can’t always schedule time the moment that a new version is released. From: Phil Taylor [mailto:notifications@github.com] Sometimes waiting 6 hours to apply a security patch would be too long to wait, a month certainly... the correct way to silence the notifications.... is to upgrade :) — |
|
Components, Joomla Update, Options. Set the cache time for updates. It's the same timeout used for update notifications. Max setting is 24 hours. Affects all updates, including extension updates.
|
|
Great, thanks. |
12 participants
Executive summary
Joomla! issues bug fix and security updates every few weeks. However, many (most?) of its users are completely unaware of this fact unless they log in to the back-end of their site and notice the update nag message at the top. This PR adds a plugin which periodically checks for updated Joomla! versions and, when one is found, emails the Super Users of the site to remind them. The plugin has minimal footprint and is very well tested in the real world: it was part of Admin Tools before I decided to donate its code to the Joomla! community.
/cc @drmmr763 @wilsonge @PhilETaylor @brianteeman This PR is per our Twitter discussion last week, see https://twitter.com/drmmr763/status/592787367901138945 I finally got some time to do it!
Test instructions
#__extensionstable find the row with extension_id=700 and edit the manifest_cache field. Change the"version":"3.4.2-dev"part of it with "version":"3.4.0"public $DEV_LEVEL = '2-dev';(your version may be different!) topublic $DEV_LEVEL = '0';#__extensionstable find the row with type=plugin and element=updatenotification. Empty theparamsproperty.Translation impact
This PR adds a substantial amount of text to be translated. However, if a translation team doesn't provide a translation in time it won't be a problem: the plugin will fall back to the English (GB) language strings if a localisation for the current language is not found.
Backwards compatibility
This PR does not affect backwards compatibility in any way
Performance impact
The performance impact of this PR is minimal. Most calls to this plugin return within 10 msec or less since the plugin only runs once every X hours, X being the update frequency set up in com_installer's Options.
Documentation and usage notes
Frequency of update notification emails
It is normal to receive multiple update notification emails until you finally update Joomla! to the latest version. Emails will be sent at most every X hours, X being the "Updates Caching (in hours)" setting in the Extensions, Extension Manager, Options page. By default this is 6 hours which means that you will receive an update email at most every 6 hours until you upgrade Joomla!.
Since this is a Joomla! plugin it only runs when Joomla! is rendering a page to the user. If a site has no or minimal traffic the update notification may never come, or come with a substantial delay. Namely, the update notification email will be sent if there's site traffic after Joomla! has released an update and after the site's update cache has become out of date, allowing Joomla! to check for available updates. This may take up to three times the Updates Caching configured in the Extensions, Extension Manager, Options page. In the worst case scenario it may take up to three days after the release of a new Joomla! version to get the update notification email. Typically it will take less than half a day. This compromise was chosen to minimise the impact of update checks to your site's page load performance.
Keep in mind that the plugin may also be affected by Joomla!'s cache. The plugin is only called after Joomla! has finished rendering a page. If you have enabled Joomla!'s cache in Global Configuration this will only happen once the cache is out of date. Typically, this shouldn't be an issue since the cache timeout is very short compared to the maximum update frequency (15 minutes versus 6 hours by default). Due to this difference and because cache is typically enabled on sites with moderate to heavy traffic –meaning that the plugin has a very high chance of getting called– using Joomla!'s cache shouldn't be a problem. If a very long cache timeout is set and/or the cache is enabled on a site with minimal traffic it MAY cause update notification emails to be sent with a substantial delay since the release of a new Joomla! version. The same concept applies for sites using a CDN, reverse proxy or other kind of caching configured in front of the site, meaning that a request will first hit the cache and not Joomla! itself. Again, using a reasonable cache timeout in the order of one hour or less should not cause a problem.
Plugin settings
By default the plugin sends an update notification email to all Super Users of the site. This may not be desirable, e.g. when you've built a site for your client and you'd rather handle Joomla! updates yourself to prevent potential issues with the site and frantic calls from your client. In this case you can set up one or more email addresses to receive the update notification in the plugin's options. Do note that these email addresses MUST belong to existing users on the site who have Super User privileges. Any other email address will be ingored. You can specify more than one email addresses as a comma separated list, e.g.
alice@example.com, bob@example.com, charlie@example.comThe update notification email's subject and body text are translatable since they are regular Joomla! language strings. This could cause the email to be sent in a language you don't speak if you're managing a multi-language site. The plugin runs both in the front-end and back-end of the site. By default it uses the current Joomla! language at the time it is triggered, just like every Joomla! extension. For example, if you have a site which has English, French and Spanish languages installed and someone is viewing the Spanish version of your site the email will be sent in Spanish. In order to prevent that you can set a specific language for the notification emails in the plugin's options. If you choose a language there then the update notification emails for all Super Users will be sent in this specific language.
The plugin tries to avoid sending you an email with untranslated strings. If the translation of the update notification email subject or body does not exist in the selected language the plugin will fall back to the current language at the time it is triggered or, if this language doesn't have an available translation either, the plugin will fall back to English (GB). This explains why you may receive the update notification email in a language you didn't expect. Anything else would result in a confusing email with untranslated strings that makes no sense.