Language Change New Feature PR-staging

Success

User tests: Successful: Unsuccessful:

avatar nikosdion
nikosdion
3 May 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.

avatar nikosdion nikosdion - open - 3 May 2015
avatar joomla-cms-bot joomla-cms-bot - change - 3 May 2015
Labels Added: Language Change
avatar joomla-cms-bot joomla-cms-bot - change - 3 May 2015
Labels Added: PR-staging
avatar joomla-cms-bot joomla-cms-bot - change - 3 May 2015
Labels Added: Language Change PR-staging
avatar brianteeman
brianteeman - comment - 3 May 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

avatar zero-24 zero-24 - change - 3 May 2015
Labels Added: New Feature
avatar zero-24 zero-24 - change - 3 May 2015
Labels Added: New Feature
avatar zero-24 zero-24 - change - 3 May 2015
Category Plugins Updating
avatar zero-24 zero-24 - change - 3 May 2015
Status New Pending
Easy No Yes
avatar drmmr763
drmmr763 - comment - 3 May 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).

avatar PhilETaylor
PhilETaylor - comment - 3 May 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?

avatar drmmr763
drmmr763 - comment - 3 May 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)

avatar PhilETaylor
PhilETaylor - comment - 3 May 2015

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

avatar nikosdion
nikosdion - comment - 3 May 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.

avatar drmmr763
drmmr763 - comment - 3 May 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?

avatar Kubik-Rubik Kubik-Rubik - change - 3 May 2015
Milestone Added: Joomla! 3.5.0
avatar nikosdion
nikosdion - comment - 4 May 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 :(

avatar infograf768
infograf768 - comment - 4 May 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?

avatar nikosdion
nikosdion - comment - 4 May 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:

```/* 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.

avatar infograf768
infograf768 - comment - 4 May 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?

avatar nikosdion
nikosdion - comment - 4 May 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).

avatar infograf768
infograf768 - comment - 4 May 2015

Got it. Thanks for the reply.

avatar Devportobello
Devportobello - comment - 4 May 2015

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.

avatar brianteeman
brianteeman - comment - 4 May 2015

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/

avatar nikosdion
nikosdion - comment - 4 May 2015

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.

avatar Bakual
Bakual - comment - 4 May 2015

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.

avatar zero-24
zero-24 - comment - 4 May 2015

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

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

avatar nikosdion
nikosdion - comment - 4 May 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.

avatar brianteeman
brianteeman - comment - 4 May 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).

avatar nikosdion
nikosdion - comment - 4 May 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.

avatar Devportobello
Devportobello - comment - 4 May 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.

avatar brianteeman
brianteeman - comment - 4 May 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).

avatar nikosdion
nikosdion - comment - 4 May 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 :)

avatar Devportobello
Devportobello - comment - 4 May 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.

avatar nikosdion
nikosdion - comment - 4 May 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" ;)

avatar zero-24
zero-24 - comment - 4 May 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 :smile: (announcement, wiki, postinstall :smiley:)

avatar nikosdion
nikosdion - comment - 4 May 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 :smile: (announcement, wiki, postinstall :smiley:)

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

avatar brianteeman
brianteeman - comment - 4 May 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.

avatar brianteeman brianteeman - test_item - 4 May 2015 - Tested successfully
avatar drmmr763
drmmr763 - comment - 4 May 2015

@test works as advertised. thanks Nicholas.

avatar brianteeman brianteeman - alter_testresult - 4 May 2015 - drmmr763: Tested successfully
avatar brianteeman
brianteeman - comment - 4 May 2015

Setting RTC - thanks


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

avatar brianteeman brianteeman - change - 4 May 2015
Status Pending Ready to Commit
avatar brianteeman brianteeman - change - 4 May 2015
Milestone Removed: Joomla! 3.5.0
Labels Added: RTC
avatar brianteeman brianteeman - change - 4 May 2015
Labels Added: RTC
avatar nikosdion
nikosdion - comment - 4 May 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.

avatar PhilETaylor
PhilETaylor - comment - 4 May 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.

avatar zero-24
zero-24 - comment - 4 May 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

avatar nikosdion
nikosdion - comment - 4 May 2015

No problem :)

avatar wilsonge wilsonge - reference | 69078a8 - 4 May 15
avatar wilsonge wilsonge - close - 4 May 2015
avatar wilsonge
wilsonge - comment - 4 May 2015

Merged into 3.5-dev. Thanks Nic!

avatar wilsonge wilsonge - change - 4 May 2015
Milestone Removed: Joomla! 3.5.0
Status Ready to Commit Closed
Closed_Date 0000-00-00 00:00:00 2015-05-04 22:36:09
Closed_By wilsonge
avatar wilsonge wilsonge - close - 4 May 2015
avatar Kubik-Rubik
Kubik-Rubik - comment - 5 May 2015

Thank you @nikosdion for your contribution!

avatar nikosdion
nikosdion - comment - 5 May 2015

My pleasure :)

avatar zero-24 zero-24 - change - 14 Oct 2015
Labels Removed: RTC
avatar mikepwp
mikepwp - comment - 6 Aug 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.

avatar PhilETaylor
PhilETaylor - comment - 6 Aug 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 :)

avatar mikepwp
mikepwp - comment - 6 Aug 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

avatar nikosdion
nikosdion - comment - 6 Aug 2016

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.

avatar mikepwp
mikepwp - comment - 6 Aug 2016

Great, thanks.

Add a Comment

Login with GitHub to post a comment