New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Joomla! Update notification email plugin #6886

Closed
wants to merge 10 commits into
base: staging
from

Conversation

Projects
None yet
@nikosdion
Contributor

nikosdion commented May 3, 2015

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

  • Apply this PR
  • Only if you are testing against the current staging branch: in the #__extensions table 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"
  • Edit the libraries/cms/version/version.php file and change public $DEV_LEVEL = '2-dev'; (your version may be different!) to public $DEV_LEVEL = '0';
  • In the #__extensions table find the row with type=plugin and element=updatenotification. Empty the params property.
  • Visit the site's front-end. An update email is sent to you to tell you that Joomla! 3.4.1 is available.
  • Visit the site's front-end again. You don't get another update email. The next email will be sent at least after the update check frequency set in com_installer's Options.
  • Make sure you are LOGGED OUT of your site's back-end.
  • Open the update email. There is a link to your site's back-end, e.g. http://www.example.com/administrator/index.php?option=com_joomlaupdate
  • Click on the link or, if it's not a link, copy and paste the URL to your browser per the email's instructions.
  • You are asked to log in to your site. Log in.
  • You are immediately taken to com_joomlaupdate where you can update your site with one click.

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

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

@brianteeman

View changes

Show outdated Hide outdated administrator/language/en-GB/en-GB.plg_system_updatenotification.ini Outdated
@brianteeman

View changes

Show outdated Hide outdated administrator/language/en-GB/en-GB.plg_system_updatenotification.ini Outdated
@brianteeman

View changes

Show outdated Hide outdated administrator/language/en-GB/en-GB.plg_system_updatenotification.ini Outdated
@brianteeman

This comment has been minimized.

Show comment
Hide comment
@brianteeman

brianteeman May 3, 2015

Contributor

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

Contributor

brianteeman commented May 3, 2015

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

@zero-24 zero-24 added the New Feature label May 3, 2015

Support for third party security extensions
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.
@drmmr763

This comment has been minimized.

Show comment
Hide comment
@drmmr763

drmmr763 May 3, 2015

Contributor

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

Contributor

drmmr763 commented May 3, 2015

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

@PhilETaylor

This comment has been minimized.

Show comment
Hide comment
@PhilETaylor

PhilETaylor May 3, 2015

Contributor

@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?

Contributor

PhilETaylor commented May 3, 2015

@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?

@drmmr763

This comment has been minimized.

Show comment
Hide comment
@drmmr763

drmmr763 May 3, 2015

Contributor

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)

Contributor

drmmr763 commented May 3, 2015

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)

@PhilETaylor

This comment has been minimized.

Show comment
Hide comment
@PhilETaylor

PhilETaylor May 3, 2015

Contributor

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

Contributor

PhilETaylor commented May 3, 2015

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

@nikosdion

This comment has been minimized.

Show comment
Hide comment
@nikosdion

nikosdion May 3, 2015

Contributor

Got it. Tried to be a smart-ass with JURI. Scratch that, I switched back to the tried and tested manual string manipulation code.

Contributor

nikosdion commented May 3, 2015

Got it. Tried to be a smart-ass with JURI. Scratch that, I switched back to the tried and tested manual string manipulation code.

@drmmr763

This comment has been minimized.

Show comment
Hide comment
@drmmr763

drmmr763 May 3, 2015

Contributor

@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?

Contributor

drmmr763 commented May 3, 2015

@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?

@PhilETaylor

This comment has been minimized.

Show comment
Hide comment
Contributor

PhilETaylor commented May 3, 2015

@Kubik-Rubik Kubik-Rubik added this to the Joomla! 3.5.0 milestone May 3, 2015

@nikosdion

This comment has been minimized.

Show comment
Hide comment
@nikosdion

nikosdion May 4, 2015

Contributor

@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 :(

Contributor

nikosdion commented May 4, 2015

@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 :(

@infograf768

This comment has been minimized.

Show comment
Hide comment
@infograf768

infograf768 May 4, 2015

Member

@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?

Member

infograf768 commented May 4, 2015

@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?

@nikosdion

This comment has been minimized.

Show comment
Hide comment
@nikosdion

nikosdion May 4, 2015

Contributor

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

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

nikosdion commented May 4, 2015

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

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

This comment has been minimized.

Show comment
Hide comment
@infograf768

infograf768 May 4, 2015

Member

@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?

Member

infograf768 commented May 4, 2015

@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?

@nikosdion

This comment has been minimized.

Show comment
Hide comment
@nikosdion

nikosdion May 4, 2015

Contributor

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

Contributor

nikosdion commented May 4, 2015

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

@nikosdion

This comment has been minimized.

Show comment
Hide comment
@nikosdion

nikosdion May 4, 2015

Contributor

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

Contributor

nikosdion commented May 4, 2015

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

@brianteeman

This comment has been minimized.

Show comment
Hide comment
@brianteeman

brianteeman May 4, 2015

Contributor

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

Contributor

brianteeman commented May 4, 2015

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

@nikosdion

This comment has been minimized.

Show comment
Hide comment
@nikosdion

nikosdion May 4, 2015

Contributor

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.

Contributor

nikosdion commented May 4, 2015

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.

@Devportobello

This comment has been minimized.

Show comment
Hide comment
@Devportobello

Devportobello May 4, 2015

Contributor

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.

Contributor

Devportobello commented May 4, 2015

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.

@brianteeman

This comment has been minimized.

Show comment
Hide comment
@brianteeman

brianteeman May 4, 2015

Contributor

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

Contributor

brianteeman commented May 4, 2015

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

@nikosdion

This comment has been minimized.

Show comment
Hide comment
@nikosdion

nikosdion May 4, 2015

Contributor

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

Contributor

nikosdion commented May 4, 2015

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

@Devportobello

This comment has been minimized.

Show comment
Hide comment
@Devportobello

Devportobello May 4, 2015

Contributor

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

Contributor

Devportobello commented May 4, 2015

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

@nikosdion

This comment has been minimized.

Show comment
Hide comment
@nikosdion

nikosdion May 4, 2015

Contributor

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

Contributor

nikosdion commented May 4, 2015

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

This comment has been minimized.

Show comment
Hide comment
@zero-24

zero-24 May 4, 2015

Contributor

@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 😃)

Contributor

zero-24 commented May 4, 2015

@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 😃)

@nikosdion

This comment has been minimized.

Show comment
Hide comment
@nikosdion

nikosdion May 4, 2015

Contributor

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

Contributor

nikosdion commented May 4, 2015

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

@brianteeman

This comment has been minimized.

Show comment
Hide comment
@brianteeman

brianteeman May 4, 2015

Contributor

@test all good
Any request for a post install message should be in separate pull request


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/6886.

Contributor

brianteeman commented May 4, 2015

@test all good
Any request for a post install message should be in separate pull request


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/6886.

@drmmr763

This comment has been minimized.

Show comment
Hide comment
@drmmr763

drmmr763 May 4, 2015

Contributor

@test works as advertised. thanks Nicholas.

Contributor

drmmr763 commented May 4, 2015

@test works as advertised. thanks Nicholas.

@brianteeman

This comment has been minimized.

Show comment
Hide comment
@brianteeman

brianteeman May 4, 2015

Contributor

Setting RTC - thanks


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/6886.

Contributor

brianteeman commented May 4, 2015

Setting RTC - thanks


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/6886.

@brianteeman brianteeman added the RTC label May 4, 2015

@nikosdion

This comment has been minimized.

Show comment
Hide comment
@nikosdion

nikosdion May 4, 2015

Contributor

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


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/6886.

Contributor

nikosdion commented May 4, 2015

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


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/6886.

@PhilETaylor

This comment has been minimized.

Show comment
Hide comment
@PhilETaylor

PhilETaylor May 4, 2015

Contributor

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.

Contributor

PhilETaylor commented May 4, 2015

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.

@zero-24

This comment has been minimized.

Show comment
Hide comment
@zero-24

zero-24 May 4, 2015

Contributor

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

Contributor

zero-24 commented May 4, 2015

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

@nikosdion

This comment has been minimized.

Show comment
Hide comment
@nikosdion

nikosdion May 4, 2015

Contributor

No problem :)

Contributor

nikosdion commented May 4, 2015

No problem :)

@wilsonge

This comment has been minimized.

Show comment
Hide comment
@wilsonge

wilsonge May 4, 2015

Contributor

Merged into 3.5-dev. Thanks Nic!

Contributor

wilsonge commented May 4, 2015

Merged into 3.5-dev. Thanks Nic!

@wilsonge wilsonge closed this May 4, 2015

@Kubik-Rubik

This comment has been minimized.

Show comment
Hide comment
@Kubik-Rubik

Kubik-Rubik May 5, 2015

Member

Thank you @nikosdion for your contribution!

Member

Kubik-Rubik commented May 5, 2015

Thank you @nikosdion for your contribution!

@nikosdion

This comment has been minimized.

Show comment
Hide comment
@nikosdion

nikosdion May 5, 2015

Contributor
Contributor

nikosdion commented May 5, 2015

@zero-24 zero-24 removed the RTC label Oct 14, 2015

@mikepwp

This comment has been minimized.

Show comment
Hide comment
@mikepwp

mikepwp Aug 6, 2016

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.


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/6886.

mikepwp commented Aug 6, 2016

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.


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/6886.

@PhilETaylor

This comment has been minimized.

Show comment
Hide comment
@PhilETaylor

PhilETaylor Aug 6, 2016

Contributor

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

Contributor

PhilETaylor commented Aug 6, 2016

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

@mikepwp

This comment has been minimized.

Show comment
Hide comment
@mikepwp

mikepwp Aug 6, 2016

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

mikepwp commented Aug 6, 2016

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

@nikosdion

This comment has been minimized.

Show comment
Hide comment
@nikosdion

nikosdion Aug 6, 2016

Contributor
Contributor

nikosdion commented Aug 6, 2016

@mikepwp

This comment has been minimized.

Show comment
Hide comment
@mikepwp

mikepwp Aug 6, 2016

Great, thanks.

mikepwp commented Aug 6, 2016

Great, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment