I am the developer of Akeeba Backup. There are two different CRON scripts supplied with Akeeba Backup Professional.
The recommended method is using the native CRON script which bypasses the web server entirely and runs the backup process essentially as a standalone PHP command line application. But that's not the object of your question.
The legacy backup ...
The global variable $mainframe was remove in Joomla 1.6 and therefore will not work from that version onwards.
global $mainframe should be replaced with $mainframe = JFactory::getApplication(); but most people tend to use $app instead.
So you code should be like this:
$app = JFactory::getApplication();
Hope this helps
If you look at the session.php file, you see the following:
public function isActive()
return (bool) ($this->_state == 'active');
Which is the function you're calling. I'm not sure if this was done purposely or if it was a mistake, but it will always return 1.
Instead, you use:
$session = JFactory::getSession();
JSession is based on the standard PHP session handling mechanism but I would not say they are interchangeable, as Joomla is directly "talking" to JSession and not to the super global.
In backend you select a session handler (the default being the database) where Joomla will store session related informations, basically it's serializing the content of $...
Similar to @codinghands's answer, writing the session to the database caused us to have too many connections:
The database wasn't corrupted, but it brought our site down. We managed to resolve it by changing the session handler to none.
In addition, you may ...
I believe changes were made to Joomla with the release of version 3.8.4, and that the session table will no longer be cleared if using 'Database' as the session handler.
See this page on Github.
The recommendation was to change the session handler from 'Database' to 'PHP'. To change this setting, log into the backend of the website. Access the System -> ...
It looks like you're creating a new cart array instead of starting with your stored data.
$session = JFactory::getSession();
$cart = $session->get('cart',array('items'=>array()));
$cart['items'] = array(
'action' => $app->input->get('action', 'add', 'STRING'),
'domain_name' => $app->input->get('...
I've got a solution after reading the various pull requests on GitHub as pointed out above by Adam Gatt and Drew G.
In the summary of changes for github.com/joomla/joomla-cms/pull/19548, is says that database session data is cleared according to the schedule set by PHPs session probabilistic garbage collection. Checking my PHP configuration, I found that ...
No, it is not expected behavior that sessions for guests expire faster than sessions for admins.
Front-end and back-end users all use the same Session Lifetime which you configure in Administrator > System > Global Configuration > [System] tab > Session Settings.
However, Joomla's default edit forms (e.g. Article Edit) have some code
Edit: It seams that the answer is not correct.
The default Joomla Session Handler (Database) does not lock the session while processing. So you don't have to worry about locking.
Anyway its possible that you override that session data of the first request with data of the second requests.
It's simple, your var $temp is a reference of the session object. So if you change the content of the object you change the session object itself.
You have to clone the object:
$temp = clone $session->get('whoami');
or you create a new object:
$temp = new stdClass();
$temp->type = $session->get('whoami')->type;
$temp->id = $session->get(...
There's actually a free Joomla! extension that will do just this. It's called Session Keeper and you can view it in the JED here:
It worked for my site when I utilized it, so hopefully it works for you as well! It allows you to set session lengths and display modal pop-ups when sessions start to expire. Hope it works for you!
Regarding why your session was not expiring, if you were on a page that had a Joomla login module, the session would never time out.
The Joomla login module enables keepalive for all pages where it
This is a very common problem in Joomla installs and to be honest there isn't a super simple fix. We've implemented a limited fix in 3.4 which allows you to clear the access rights cached for the currently logged in user (https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/user/user.php#L488). However it will not change the access rights of ...
It's hard to say exactly what's wrong, but here's a couple of things you can try (please backup your configuration.php and .htaceess files before making any changes).
Although you say your username/password is correct, try creating a new super-admin user by following this guide.
What version of PHP/mySQL are your new server using? Is it the same as the old ...
FoF has a handy _csrfProtection routine in the controller, with several ways to check the token:
JUtility::getToken() (for Joomla 2.5, removed from Joomla 3.x)
or, the _token field in any of the previous instances
Joomla uses the PHP session functions to create its JSession object, but it provides wrapper functions and namespaces the session to keep the data segregated. If you dump the PHP superglobal $_SESSION you will see the Joomla session items.
As for ressources about $mainframe:
(Found using Google)
Your using the wrong session. If you follow the logic down the class chain for $mainframe->initialize you will find, depending on your version of joomla, a line like
$session = JSession::getInstance($handler, $options);
That session creation call contains the ...
Just to add my 2 cents: I've found in earlier versions of Joomla that the _sessions table often becomes corrupted on sites receiving a large number of unique visitors and hence open sessions, bringing the site down until the table is repaired / cleared. Using None resolved this for me.
In the none option it use the default php session handle, which use files to store the session data. In the database option it use the database to store the session data.
In http://www.tuxradar.com/practicalphp/10/3/7 you can know more about Files vs. Databases in the session
Welcome to the world of asynchronous calls. My advice is don't use sessions for the AJAX/RESTful calls at all. The most I would do is have some sort of authentication token so you know who is making the call.
You don't have to write your own JSession class, but you'll need to write a class extending JSessionStorage to integrate with Joomla's session handling.
Most likely you'll run into trouble when trying to set the the session handler trough the Global Configuration. Either override JFormFieldSessionHandler with a version that includes your handler or just ...
You could write a template override for the login template being called when the standard login url is displayed. There you create a HTTP 302 Move response status.
Or you write a url rewrite to your .htaccess.
Both solutions could get you where you wanna be, but I would consider them 'dirty'.
Solution A: Slightly adjusted array structure
You have only your itemid and the corresponding quantity in your array. Why don't you use the itemid as array index ($cart['items'][<ITEMID>]) so you could easily update your quantity if the index already exists.
$cart['items'] = 10
$cart['items'] = 5
your itemid --^ ^-- your quantity
Another way to reduce the server load is to make the session table of memory type. You need to set mysqls heap size quite large and convert the blob field in session into a large varchar, say 15000 length.
I had great results with this.
Another option is to use memcache and something like elasticache
var id='<?php $s = JFactory::getSession(); echo $s->getId();?>';
Simple. That's enough internet for today.
For more information on accessing session information please see the Joomla Session API Documentation