omeka / Omeka

A flexible web publishing platform for the display of library, museum and scholarly collections, archives and exhibitions.
http://omeka.org
GNU General Public License v3.0
485 stars 194 forks source link

Background processes throw Zend_Session_Exception #818

Open zploskey opened 7 years ago

zploskey commented 7 years ago

On Omeka 2.5.1 running on PHP 7.0 and 7.1, attempting to run a background process (in my case the DerivativeImages plugin) gives me the following:

PHP Fatal error:  Uncaught Zend_Session_Exception: Unable to set session handler in application/libraries/Zend/Session.php:283
Stack trace:
#0 application/libraries/Zend/Application/Resource/Session.php(116): Zend_Session::setSaveHandler(Object(Omeka_Session_SaveHandler_DbTable))
#1 application/libraries/Omeka/Application/Resource/Session.php(22): Zend_Application_Resource_Session->init()
#2 application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(695): Omeka_Application_Resource_Session->init()
#3 application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(641): Zend_Application_Bootstrap_BootstrapAbstract->_executeResource('Session')
#4 application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(598): in application/libraries/Zend/Session.php on line 283

I believe this is related to how the application is initialized. I was able to get things to run by replacing

$application->bootstrap(array(
    'Config', 'Logger', 'Db', 'Options', 'Pluginbroker', 'View', 'Locale', 'Mail',
    'Plugins', 'Jobs', 'Storage', 'Filederivatives'
));

in application/scripts/background.php with $application->initialize();. I'm sure there's a reason it's being done the way it is currently, but I'm wondering if something is out of order or missing or something. Can anyone else reproduce this?

I get this error simply by running

APPLICATION_ENV=development php application/scripts/background.php
zploskey commented 7 years ago

After a bit more investigation, I think this is due to some of my plugins using session data. I can get this to work by bootstrapping in the same order that initialize() does, and adding 'Session' to the bootstrap. That works out to the following:

$application->bootstrap(array(
    'Locale', 'Config', 'Logger', 'Mail', 'Db', 'Options', 'Pluginbroker',
    'Session', 'Plugins', 'View', 'Jobs', 'Storage', 'Filederivatives'
));
zerocrates commented 7 years ago

Do you have an visible example of a plugin that causes this problem?

Simply switching to initialize isn't going to be a good idea for several reasons, and I'm similarly wary about introducing the Session bootstrap in the background contexts, too. If for no other reason than that it will have the capability to generate phantom sessions in the DB. The traditional way we've handled these types of issues with plugins in the past is to just skip over the offending behavior when it's not available.

What's a little confusing to me is where the call to bootstrap the Session component (as shown in your error log) is coming from in the first place.

zploskey commented 7 years ago

A couple of our plugins deal with the session, but the easiest one to reproduce it with is our fork on the Multilanguage plugin at https://github.com/zploskey/Multilanguage. It creates a new Zend_Session_Namespace, which I presume is causing Session to be bootstrapped.