avatar cppl
22 Dec 2015

I haven't had time to track this down yet but the 3.4.7 update has broken /cli apps like AkeebaBackup. The specific error in the logs:

[21-Dec-2015 23:57:53 CST6CDT] PHP Fatal error:  Call to a member function get() on a non-object in /home/xxx/public_html/libraries/joomla/session/session.php on line 448

Steps to reproduce:

  1. Make sure PHP logging is enabled
  2. Run any CLI based app e.g. AkeebaBackup on Joomla 3.4.6 (works as expected)
  3. Run the 3.4.7 update
  4. Attempt to run CLI app again (e.g. AkeebaBackup cli version just terminates)
  5. Check the php_errorlog file in /cli directory

Sorry I don't have any more details yet but I'll update as I find out more.

avatar cppl cppl - open - 22 Dec 2015
avatar Kubik-Rubik
Kubik-Rubik - comment - 22 Dec 2015

I've just tested all core CLI scripts without a problem. Could you please analyze this issue in more detail?

@nikosdion Are you aware of the problem?

avatar cppl
cppl - comment - 22 Dec 2015

Yes the core /cli scripts are unaffected — if @nikosdion isn't aware yet he will be soon as there is already a ticket on his site about it.

I'm trying to distill this to it's escence. Basically though line 448:

return $this->data->get($namespace . '.' . $name, $default);

Fails for these third party cli scripts because $this->data is not an object… now I'm not sure why they are in JSession in the first place… working on that.

avatar cppl
cppl - comment - 22 Dec 2015

I should add that changing line 448 to guard against $this->data not being set/object works e.g. we've deployed this temp patch to get all of clients tools back up and running (incl. AkeebaBackup)

        if (isset($this->data) && is_object($this->data))
            return $this->data->get($namespace . '.' . $name, $default);
            return $default;
avatar nikosdion
nikosdion - comment - 22 Dec 2015

The session code is apparently triggered by JFactory::getUser(). Unfortunately that's not the only way this Joomla! bug can affect CLI scripts. Using any model –which implicitly saves its state in the session– will also trigger this issue.

Apparently, until this issue is fixed, all developers must add this code in their CLI scripts:

if (version_compare(JVERSION, '3.4.7', 'ge'))

It seems that the best place to add it is in either the __construct method of the CLI application or as the very first code block in the execute method.

Right now @tampe125 is looking at the Joomla! code itself and he tells me the actual root cause is how Joomla! treats an inexistent session. Joomla! marks its state as "inactive". However, it does this kind of check:

if ($session->getState() == 'expired')

Since the state is inactive, not expired, the session is never "restarted" –which would actually initialise it– therefore $this->data is never initialised to a new JRegistry object. I can personally see two ways to fix that: either initialise $this->data in the constructor (which is the sane approach) or treat a missing session as "expired" which MAY have unforeseen issues.

I'll leave that to the CLT, JSST and @tampe125 to discuss. I will be too busy patching all of our CLI scripts, releasing new versions and at the same time trying to explain to our clients that it's Joomla!'s bug, not ours. Merry Christmas...

avatar davidjosephhayes
davidjosephhayes - comment - 22 Dec 2015

This will affect CiviCRM CLI scripts too. I applied the fix from @cppl for the time being.

avatar brianteeman brianteeman - close - 24 Dec 2015
avatar wilsonge
wilsonge - comment - 24 Dec 2015

Fixed with #8773

avatar wilsonge wilsonge - change - 24 Dec 2015
Status New Closed
Closed_Date 0000-00-00 00:00:00 2015-12-24 11:30:57
Closed_By wilsonge
avatar wilsonge wilsonge - close - 24 Dec 2015
avatar brianteeman brianteeman - change - 8 Mar 2016
Labels Added: ?

Add a Comment

Login with GitHub to post a comment