CSVImport Error with first 2.7.1 site

I am running Omeka 2.7.1 and PHP 7.2

I have the following plugins installed:

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

Well that’s a strange one…

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.

Hmmm, it doesn’t happen in the UI at all, huh.

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?

Hey. Here is my PHP CLI setting.

;;;;;;;;;;;;;;;;;;;;;;
; Background Scripts ;
;;;;;;;;;;;;;;;;;;;;;;

; 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

Thx!

Hey. Here are the results of running php -v.

PHP 7.2.28 (cli) (built: Mar 1 2020 15:27:36) ( NTS )
Copyright © 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright © 1998-2018 Zend Technologies
with the ionCube PHP Loader + ionCube24 v10.3.9, Copyright © 2002-2019, by ionCube Ltd.

Hey,
I have confirmed that both installs on the server, for Omeka, use the same PHP-CLI path, /usr/local/bin/php

Thx.

–Eric

Hmmmm, okay.

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.

Hello,

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.

Best,

–Eric

Well, that’s interesting for sure.

That log setting change I suggested may help you out a little here: it may log further trace lines that might include a line in your plugin.