I have tested this item successfully on 5199006

Works great!
Thanks @andrepereiradasilva for doing this!

This PR has received new commits.

CC: @dgt41

I detected a problem with the double entities in '&' in admin keepalive.
GET /administrator/index.php?option=com_ajax&format=json 404

Solved

@dgt41 Can you retest when you have time?

• this PR introduce jQuery dependency (while it can work fine without jQuery) , so now Joomla need to load 4 files instead of one line of the inline code ... btw, framework dependancy was removed in #3376, so it some kind of regression to me
• I do not see any profit from forcing JSON as data- value, for just 2 variable ... it can work fine with data-interval data-url (or around), and it more "readable" in output, that means more easy to debug

@Fedik @andrepereiradasilva for the onload event we could use something like:

document.attachEvent("onreadystatechange", function(){
  if (document.readyState === "complete"){
    document.detachEvent( "onreadystatechange", arguments.callee );
    // code ...
  }
});

which is plain js, so no jQuery dependency

attachEvent is IE

(function(w){
  'use strict';
  var modern = !!w.addEventListener,
        event = modern ? 'load', 'onload';
   w[modern ? 'addEventListener' : 'attachEvent'](event, function(){
     // your code here
   })
})(window);

@Fedik @dgt41

this PR introduce jQuery dependency (while it can work fine without jQuery) , so now Joomla need to load 4 files instead of one line of the inline code ... btw, framework dependancy was removed in #3376, so it some kind of regression to me

Ok, so in your view the js in core should be vanilla js?
Or at least, when possible, reduce the dependencie from js frameworks?
I can identify with that.
I'm asking that because if you look at behavior.php you will see a lot of jQuery usage.

I do not see any profit from forcing JSON as data- value, for just 2 variable ... it can work fine with data-interval data-url (or around), and it more "readable" in output, that means more easy to debug

Yes it's more readable, i didn't like either the html entities in the HTML code.
So should we always use data-* attributes without json in core js, except when there is a lot o variables?

I will introduce the changes needed when i have time.

Use of jQuery is fine, but if the code already independent form the framework, then beter keep it in this way, when it is possible. I think.
Example core.js independent from any framework now.

I'm asking that because if you look at behavior.php you will see a lot of jQuery usage.

Mainly it depend from people who wrote that scripts

So should we always use data-* attributes without json in core js, except when there is a lot o variables?

Personally, I would do like this, yes.

This PR has received new commits.

CC: @dgt41

@dgt41 @Fedik
Check now:

• Uses vanilla js (no js framework dependency)
• Cross-browser compatible
• Works even if onload event is already fired when script is loaded (this way the js file can be loaded on render, asyncronous or defered to after the onload event).

Looks good, thanks!
One more request:
Now all variables in the global scope, can you please wrap it into anonymous function, and use strict mode:

!(function(window){
  'use strict';

   // your code here
})(window);

This PR has received new commits.

CC: @dgt41

@Fedik ok now i think it's done.
Also improved keepalive behaviour.php code to be more readable and work with other session handlers (memcache, redis, etc).

This PR has received new commits.

CC: @dgt41

... and work with other session handlers (memcache, redis, etc)

Please do not change this, it breaks thing that was fixed in #7363, and return issue #6730 back to life

Something for concern.
I think this Pull request bring potential backward compatibility problem (and just a problem) for extensions which merge the scripts, for optimization. As they ignore any custom attribute, the current keepalive code will be broken after merging keepalive.js with other JavaScript files to a single file.
This also means that all scripts that will use costume attributes by #8540 could be broken in this case
hmm...

Please do not change this, it breaks thing that was fixed in #7363, and return issue #6730 back to life

I'm sorry but you are saying that if we use session handler 'none' Joomla will use the PHP.ini session value without changing the session time to the defined in the global config?
I think is not the way it works. I think Joomla uses ini_set to change the php session timeout value when set to handler is set to 'None'.
But i did the test and i didn't confirm your issue. I did this:

• Set the session time to 1 minute in php ini session.gc_maxlifetime = 60
• restart php
• Set the session time to 2 minutes in global config and 'None' as handler ('None' should really be called 'Default PHP Handler' or something like that)
• Go to an article edit in administrator and wait 3 minutes.
• Refresh page, you'll see you are still logged.

Something for concern.
I think this Pull request bring potential backward compatibility problem (and just a problem) for extensions which merge the scripts, for optimization. As they ignore any custom attribute, the current keepalive code will be broken after merging keepalive.js with other JavaScript files to a single file.
This also means that all scripts that will use costume attributes by #8540 could be broken in this case
hmm...

True, but it's not a Joomla B/C problem, those extension can be improved to check the script tag has other attributes and use it. But we also could use a default value in the js in the case no attribute is found in the script tag (e.g. 1 minute interval, and index.php as URI) to reduce potencial problems.
We can also run tests with some of those extensions.

@andrepereiradasilva I think you should rename/move the scripts to media/jui/js/keepalive.js (uncompressed) and media/jui/js/keepalive.min.js (compressed). The -uncompressed option comes from the dark ages of mootools, modern scripts follow the other paradigm. Also since the script will be introduced first time is better to store it to jui folder...

This PR has received new commits.

CC: @dgt41

"jui" mostly has stuff related to Bootstrap and that effort, "system" at
one point was mostly Joomla's core JavaScript API. Probably best to clean
that all up at one point, but the system folder was fine.

On Saturday, November 28, 2015, Dimitri Grammatikogianni <
notifications@github.com> wrote:

@andrepereiradasilva https://github.com/andrepereiradasilva I think you
should rename/move the scripts to media/jui/js/keepalive.js (uncompressed)
and media/jui/js/keepalive.min.js (compressed). The -uncompressed option
comes from the dark ages of mootools, modern scripts follow the other
paradigm. Also since the script will be introduced first time is better to
store it to jui folder...

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

@mbabker jui refers to ui/ux staff and I think this fits better there, anyhow I agree that these two folders need some cleanup...

But i did the test and i didn't confirm your issue.

ok, maybe it has been fixed in Session for Joomla 3.5

I have tested this item successfully on 290c439

Test OK

I have tested this item ✅ successfully on 290c439

HTML code

The external js file

Tweaked the code to trigger calling URI every 10 seconds and it works.

add to make a small change in JHtml script call since the PR that adds script attibutes in now other (#11289).

just this changed 235afcd

I have tested this item ✅ successfully on 235afcd

Works like a charm @icampus

I have tested this item ✅ successfully on 235afcd

it works @icampus

RTC as we have 2 successful tests

mantainers, just a remainder: this CANNOT be merged without #11289 being merged.

@andrepereiradasilva How come a PR from last year is depending on a PR from 9 days ago?

"it's a kind of magic" ?

kidding aside, i replaced my old PR for that one recently (you can see that if you read the comments there)

@andrepereiradasilva A magician too...is there anything you can't do :)

I see now, thanks for the explanation.

@could you have a look at the conflicts/problems and resolve them, thanks!

fixed conflicts and reviweed code to use the new 3.7.x methods (JDocument::addScriptOptions and js Joomla.request)

@andrepereiradasilva can this work without #11289 ?

well ... yes and no. it works, except in IE8 since the JHtmlBehaviour polyfill needs #11289

hm, but why we need polyfill here? ?

it can work very well without document.addEventListener('DOMContentLoaded', function() {}) after you have changed code to use Joomla.getOptions('system.keepalive') ?

this code already uses Joomla.getOptions('system.keepalive')

I prefer to have sure that the content is already loaded so we can defer js processing to after dom ready.

but if you can do it without polyfill, please make a PR to change that ? .