Can you update the language file to follow this rule please

Rule of thumb

Whenever you can substitute "your Joomla CMS" in place of "Joomla" and still make sense, then it's descriptive and no bang needed.

https://github.com/joomla/user-interface-text/blob/master/joomla_name_usage.md#rule-no-bang

Everything worked great in the test except one minor issue. I received a link to my site missing a sub directory:

Emailed Link
http://sub.domain.com/administrator/index.php?option=com_joomlaupdate

Actual Link:
http://sub.domain.com/subfolder/administrator/index.php?option=com_joomlaupdate

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

@drmmr763 Surely the subfolder should be BEFORE the /administrator/ and not after it? is this just a typo you have made in the github comment?

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)

@drmmr763 no worries (for completeness, your edited version also now has "//" :-)

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 JUri::root() instead of base. Do you think that'd work better and avoid that substr you've got to do now?

@nikosdion This multiline comment is about to break travis probably?
https://github.com/nikosdion/joomla-cms/blob/52c00445e6a9602727458264932504f525fcf269/plugins/system/updatenotification/updatenotification.php#L185

Needs /** etc...

@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
Would it be possible to really check the preferred admin language of each user and use it for the mail sent as I guess that your code is using the default Global admin language instead after loading en-GB?

@infograf768 I thought of that but I decided against it for two reasons:

1. Performance. If you're emailing five admins you have to reload the languages five times. You also need to run the variable replacements five times. This adds up to around a second or so (loading languages is very slow). More Super Users make it even worse.

2. Translation availability. This is my MAJOR concern. Not all TTs provide up to date translations at the time of a new version release. This plugin is enabled by default. If it weren't we could just as well not write it at all, the whole point being making oblivious users aware of updates!

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:

```/* Load the appropriate language. We try to load English (UK), the current user's language and the forced

• language preference, in this order. This ensures that we'll never end up with untranslated strings in the
• update email which would make Joomla! seem bad. So, please, if you don't fully understand what the following code does DO NOT TOUCH IT. It makes the difference between a hobbyist CMS and a professional
• solution! */```

As I wrote in the comment, DO NOT TOUCH IT :) It really does make the difference between a hobbyist CMS and a professional solution. Remember who's the target audience of Joomla!. It's not us, the experts. We can understand where an untranslated string comes from and will be mildly annoyed by it. Our target audience will have a very serious WTF moment and will either thing that Joomla! is broken or hacked. In either case it makes Joomla! look really like a subpar solution. Actually, I think that the entire CMS should fall back to English if there's an untranslated string. I don't think that Linux, Windows, Mac OS X and every piece of software I used on all three operating systems (and their mobile counterparts) have it wrong and we have it right. I think that WE HAVE IT WRONG by showing untranslated strings by default. IMHO untranslated strings should only be shown when Debug Language is enabled. We had that right in Joomla! 1.5 and we screwed it up since Joomla! 1.6. It's better seeing "something" instead of COM_WHATEVER_THINGS_FLD_SOMETHING_LBL, even though you would ideally like to see "quelque chose" but nobody has translated it yet. Think about it. Deep down you know I'm right.

@nikosdion
Not sure I explained myself correctly.
I am not against loading en-GB to make sure we have a value (you may remember I asked, supported, tested, helped and merged the PR you did about that...).
I was just wondering if we could also look and make a priority loading the user preferred language (if we have a value for the strings in that language evidently).

Priorities:
1. User admin language
2. Site default admin language
3. en-GB

I.e. I am only concerned by the first part of your reply:

Performance. If you're emailing five admins you have to reload the languages five times. You also need to run the variable replacements five times. This adds up to around a second or so (loading languages is very slow). More Super Users make it even worse.

I am not convinced by this argument as even if it takes a few minutes to send the mails, who cares?

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

Got it. Thanks for the reply.

My point of view; I like your idea but hope this wont be enabled by default, maybe we could choose enabled or not when the process of installing joomla.

Why not? Do you like to leave updates to guesswork

On 4 May 2015 at 11:00, Devportobello notifications@github.com wrote:

My point of view; I like your idea but hope this wont be enabled by
default, maybe we could choose enabled or not when the process of
installing joomla.

—
Reply to this email directly or view it on GitHub
#6886 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

If you don't enable it by default it's just as good as not having the plugin at all. If people knew were to look they'd be looking for the updates anyway, meaning that this plugin would not be required. The problem we're trying to solve is that people DON'T know where to look or don't bother looking for the updates. So we have to push update notifiactions to them.

We currently do that through the administrator control panel page. Unfortunately the owners of infrequently update sites, i.e. the bulk of company and personal sites which receive updates once in a blue moon, don't know that there are updates available until their site gets hacked because it's six to twelve months out of date. This plugin solves this issues by nagging them about the update.

I know what you have in mind: what if someone doesn't want to receive update notifications from their site? As the email text states, just unpublish the System - Joomla! Update Notification plugin from Extensions, Plugin Manager. Even if you update Joomla! the plugin will NOT enable itself. This is only done once, when upgrading from older versions of Joomla! which didn't have the plugin to the newer versions which do have the plugin. That's how the Joomla! database schema update works. So no problem there.

Again, if you're going to ship this plugin unpublished and require the user to publish it manually (e.g. through a post-installation message which the user is likely to dismiss without reading) it'd be best if we didn't include the plugin AT ALL. And to put things in perspective other CMS like WordPress do ship with automatic updates turned on. Automatic updates are INFINITELY MORE DANGEROUS than an update notification. An automatic update can screw up your site if one of your extensions is not compatible with the new Joomla! version and you'd be none the wiser that this happened until someone visited your site and had the inclination to figure out a way to contact you about your site being broken.

So what is really the problem with notifying people about updates? The fact that they might finally get off their bottoms and update their sites before their woefully obsolete Joomla! version from 2 years ago is hacked and then blame Joomla! for it? I'd say that preventing this is something we should have done five years ago when Joomla! 1.6 –with the first incarnation of one-click update support in the core– was released.

I agree with Nicholas. If we're going to include this, the plugin needs to be enabled by default. Otherwise it's pointless in core and could as well be offered as a 3rd party plugin.

I agree with Nicholas. If we're going to include this, the plugin needs to be enabled by default.

Maybe a opt-out as postinstall? So the "normal User" have it enabled on update and the user who don't what it can disable it by a one click? (bevor the first email was send)

@zero-24 What about those people who blindly click on the post-installation messages without even reading them? I think that requiring the users to go to the plugin manager to deactivate notifications is much better as far as ensuring herd immunity is concerned.

Again, I'll give you the example of Windows, Linux, Mac OS X and their mobile counterparts (Windows Mobile, Android, iOS). All these operating systems come with update notifications enabled by default. Their installation / activation wizards don't give you the option to opt-out from update notifications. You have to deliberately go looking for the options panel to disable them. Let me put it very bluntly: these thousands of engineers and multi-billion companies have figured out that the best way to protect their users is making it difficult to NOT be notified about updates. Our target audience is pretty much the same. Why do we think we know better and should do the exact opposite than anyone else? That would be an outright folly on our part.

What would be the benefit or the reason why someone would ever opt out?
On 4 May 2015 12:44 pm, "Nicholas K. Dionysopoulos" <
notifications@github.com> wrote:

@zero-24 https://github.com/zero-24 What about those people who blindly
click on the post-installation messages without even reading them? I think
that requiring the users to go to the plugin manager to deactivate
notifications is much better as far as ensuring herd immunity is concerned.

Again, I'll give you the example of Windows, Linux, Mac OS X and their
mobile counterparts (Windows Mobile, Android, iOS). All these operating
systems come with update notifications enabled by default. Their
installation / activation wizards don't give you the option to opt-out from
update notifications. You have to deliberately go looking for the options
panel to disable them. Let me put it very bluntly: these thousands of
engineers and multi-billion companies have figured out that the best way to
protect their users is making it difficult to NOT be notified about
updates. Our target audience is pretty much the same. Why do we think we
know better and should do the exact opposite than anyone else? That would
be an outright folly on our part.

—
Reply to this email directly or view it on GitHub
#6886 (comment).

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
On 4 May 2015 1:29 pm, "Devportobello" notifications@github.com wrote:

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.

—
Reply to this email directly or view it on GitHub
#6886 (comment).

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" ;)

@zero-24 What about those people who blindly click on the post-installation messages without even reading them?

@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 automagic disable button

Than we can

• enable it per default
• cover the people that don't read the message (update mail will send)
• inform the users that read the message

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".
I think if we do something that affect the user (e.g. sending of emails) we should tell it that we will do 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:

"Hey now we will inform you (and all other superuses) per email if we release have a new update. If you don't what to be informed and improve your security of your webseite you can disbable it...".

Ok now you can say "If they don't read announcments or the wiki they will not read postinstall"
Yes but the difference here is there we have the chance to show it in there motherlanguage on there own system. And we can point they to this message if they ask.

Just my 2 cents

BTW Also one more point all good things are three (announcement, wiki, postinstall )

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.

Hidden?! The whole idea of having the plugin ENABLED BY DEFAULT is the exact opposite of hidden.

if they get much unwanted emails or the site goes down for any reason, they will say "Why Joomla not inform me about it".

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.

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:

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.

Ok now you can say "If they don't read announcments or the wiki they will not read postinstall"

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?

Yes but the difference here is there we have the chance to show it in there motherlanguage on there own system. And we can point they to this message if they ask.

Which is exactly what the email does. Because the email text is in language strings. Which are translated by the TTs.

BTW Also one more point all good things are three (announcement, wiki, postinstall )

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
Any request for a post install message should be in separate pull request

@test works as advertised. thanks Nicholas.

Setting RTC - thanks

@drmmr763

I usually use JUri::root() instead of base. Do you think that'd work better and avoid that substr you've got to do now?

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

Cant believe this is still going on .... just merge the code and be done with it. It has zero impact and only improves Joomla for the better. Those that dont like it can turn it off just like other things they dont like.

All this talk takes great developers away from code. Talk less, code more.

Did you actually READ the email text included in the PR?!

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?
On a default site currently it's about every six hours or so.

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.

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 :)

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]
Sent: Saturday, August 06, 2016 1:20 PM
To: joomla/joomla-cms joomla-cms@noreply.github.com
Cc: mikepwp mike@pwpstl.com; Comment comment@noreply.github.com
Subject: Re: [joomla/joomla-cms] Joomla! Update notification email plugin (#6886)

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 :)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub #6886 (comment) , or mute the thread https://github.com/notifications/unsubscribe-auth/ADcE6-ohN_kOu7H-hz-Fj4jd_UrBdMrLks5qdNA8gaJpZM4EOp_H . https://github.com/notifications/beacon/ADcE6494gyWGIxfO307q1iIv2qRE35bDks5qdNA8gaJpZM4EOp_H.gif

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.