Commenting
Version 2.2 by Roy Rosenzweig Center for History and New Media
CSS Editor
Version 1.1 by Roy Rosenzweig Center for History and New Media
CSV Import
Version 2.0.4 by Roy Rosenzweig Center for History and New Media
Hide Elements
Version 1.3 by John Flatness
Maintenance
Version 0.1.0 by BibLibre
METSExport
Version 1.1 by Eric C. Weig
Project Guide
Version 1.0 by Eric C. Weig
Scripto
Version 2.3 by Roy Rosenzweig Center for History and New Media
SimpleContactForm
Version 0.6 by Roy Rosenzweig Center for History & New Media
Simple Pages
Version 3.1.2 by Roy Rosenzweig Center for History and New Media
When I try to run a CSVImport, I get the following error:
[01-Apr-2020 12:39:53 UTC] PHP Warning: ini_set(): Headers already sent. You cannot change the session module’s ini settings at this time in /home/ukylibex/public_html/crowdsrc/application/libraries/Zend/Session.php on line 209
[01-Apr-2020 12:39:53 UTC] PHP Warning: ini_set(): Headers already sent. You cannot change the session module’s ini settings at this time in /home/ukylibex/public_html/crowdsrc/application/libraries/Zend/Session.php on line 223
[01-Apr-2020 12:39:53 UTC] PHP Warning: ini_set(): Headers already sent. You cannot change the session module’s ini settings at this time in /home/ukylibex/public_html/crowdsrc/application/libraries/Zend/Session.php on line 223
[01-Apr-2020 12:39:53 UTC] PHP Warning: ini_set(): Headers already sent. You cannot change the session module’s ini settings at this time in /home/ukylibex/public_html/crowdsrc/application/libraries/Zend/Session.php on line 223
[01-Apr-2020 12:39:53 UTC] PHP Warning: session_set_save_handler(): Cannot change save handler when headers already sent in /home/ukylibex/public_html/crowdsrc/application/libraries/Zend/Session.php on line 283
[01-Apr-2020 12:39:53 UTC] PHP Fatal error: Uncaught Zend_Session_Exception: Unable to set session handler in /home/ukylibex/public_html/crowdsrc/application/libraries/Zend/Session.php:287
Stack trace: #0 /home/ukylibex/public_html/crowdsrc/application/libraries/Zend/Application/Resource/Session.php(116): Zend_Session::setSaveHandler(Object(Omeka_Session_SaveHandler_DbTable)) #1 /home/ukylibex/public_html/crowdsrc/application/libraries/Omeka/Application/Resource/Session.php(22): Zend_Application_Resource_Session->init() #2 /home/ukylibex/public_html/crowdsrc/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(695): Omeka_Application_Resource_Session->init() #3 /home/ukylibex/public_html/crowdsrc/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(641): Zend_Application_Bootstrap_BootstrapAbstract->_executeResource(‘Session’) #4 /home/ukylibex/public_html/crowdsrc/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(598): Zend_Application_Bootstrap_BootstrapAbstract->_bootstrap(‘Session’) #5 /home/ in /home/ukylibex/public_html/crowdsrc/application/libraries/Zend/Session.php on line 287
This only happens when you try to do a CSV import? The session error it’s indicating seems like something that would prevent you from using the admin interface at all.
Are there any other errors listed above that first ini_set one? Sometimes these “headers already sent” errors happen because a different, earlier error from very early on in the process has been printed to the screen.
That’s the full error string that occurs each time I attempt to to an import. It does not crash out in the UI. That is, I get all the way to the status tab in the CSVImport, but it remains as queued and never progresses.
I wonder if what’s happening here is that when we’re trying to run the PHP CLI, it’s actually a CGI binary there, leading to this problem. Have you set a specific path to PHP’s CLI in your application/config/config.ini file (the setting is background.php.path)? What do you get back when you run php -v on your server?
; background.php.path
; Path to PHP-CLI for running background processes.
; default: “”
;
; If left blank, Omeka will try to autodetect the right path. Set this
; to override the autodetected PHP path.
background.php.path = “/usr/local/bin/php”
I’m working through a cpanel, so not running stuff from a command prompt. Not sure how to test that command.
There are 2 other Omeka installs on the same server and one of them has the CSVImport which is working. However, it is running Omeka 2.7.
You don’t have SSH access? I suppose you could ask your host to check for you, or cPanel itself often has a “Terminal” or similar option to get command-line access through the browser. It’d be interesting to see the results of just php as well as /usr/local/bin/php.
Nothing was changed between 2.7 and 2.7.1 that should affect the running of background processes, so my instinct is that it’s some other difference at work here.
Is that configured path exactly the same between these different sites? And if so, are the others still working (trying to rule out a server-level change)?
These messages, I assume they’re showing up in an error log of some kind, since you say they’re not happening on the UI?
I will see what I can uncover. One quick response to your last question. The error is coming out in the log file here: /home/ukylibex/public_html/crowdsrc/admin/error_log
Anything else differ between the working site(s) and this one? Checking on the System Information panel for each, for example? Different plugins? It’s possible that the Omeka version is the relevant difference but I’d continue to say that’s unlikely.
One odd thing is that error log location you mention: it’s a file called error_log within the admin directory of your Omeka install? That’s not somewhere Omeka would normally log to, and it’s a rather odd location for a PHP error log too. Or did you pick/configure that path yourself? One more little question about the log, also: it looks like it’s actually truncated, it’s not showing the whole message (in particular, there should be more numbered lines in the stack trace). If you can modify your PHP ini settings, please try to set log_errors_max_len to 0 to let it print the whole error message to the log.
The behavior you’re seeing (stuck on “Queued”) is consistent with the background job part of the import (the actual import, in other words) failing to start at all or failing very early on. The strange part is that all the stuff about session handling generally shouldn’t be there in a background job.
I resorted to one test I’ve done in the past. First, I completed a new install of Omeka on the same server. I then installed the CSVImport plugin first. It worked. I then installed the other plugins from the old site one by one until the CSVImport broke. There is some issue with the new version of Omeka and a plugin I created called METSExport. I will investigate what the issue is. But, it definitely seems to be the culprit. I went back to the original site install and removed the pugin completely. The CSVImport then functioned as normal. Thanks for you time and consideration with this. I will continue to investigate what the problem with the METS plugin is, but my immediate problem with getting the CSVImport plugin to work has been solved.