CSV Import hangs

In the admin interface, when I click on CSV Import, my session seems to hang my entire session. I have to delete the session cookie in order to terminate the "Loading ..." condition. I'm using Omeka 1.1 and CSV Import plugin 1.2. I've tried re-installing a couple of times, but that has not fixed the issue. Each time I install, the plugin reports that it has installed successfully and prompts me to configure. I've tried entering 128M and 1G as the memory limit.

Any pointers on other things I can check/try to get this working?

Thanks,

Shirley

Hi Shirley,

I'm not really sure what is going on. Are you not having any trouble with any other plugins?

I assume you have already tried logging out of Omeka, clearing all of your cookies in the browser, restarting your browser, and logging back into the Omeka admin.

Also, I'd double check the permissions of the csv_files directory to make sure it is readable.

I wonder if any web development browser plugins may somehow be interfering with your cookies.

Can you reproduce the problem on multiple browsers?

Let me know if this helps.

Will,

Thanks for responding. I'm only having this problem with the CSV Import plugin. I currently have 15 plugins installed (including CSV Import).

After installing the plugin, I get the message: The 'CsvImport' plugin was successfully configured!". When I click on the CSV Import link in the menu bar, I get stuck in a "Loading ..." condition. If I click the "cancel" button in the browser, the page load appears to stop, but it reappears when I click any link in Omeka admin within the same session.

The first time this happened, I was using FireFox 3.5.8 and I cleared all cookies, restarted my browser, and logged back into Omeka admin, where I regained control. I had the same problem the next time I clicked on the CSV Import plugin link, however. The same thing happens in IE 8. Subsequently, looking more closely at my cookies in FireFox, I discovered that I could clear the perpetual "Loading ..." condition by deleting just a single cookie, the "session" cookie associated with my local Omeka server. Deleting this cookie returns me to the Admin login page when I click on any link in Omeka admin (e.g. Settings). When I log back into admin, I have control until I click on the CSV Import link again.

I've uninstalled, and reinstalled the CSV Import plugin about four times now, each time making sure that I've not only uninstalled through the admin interface, but also deleted and re-uploaded the entire CSV Import plugin folder. Permissions on the CsvImport and csv_files directory are set at 755.

I have Web Developer and FireBug installed in FireFox, but I'm not sure how to check to see if those plugins might be causing some sort of problem. I'm able to view and delete my Omeka session cookie in Web Developer.

My thought is that I could have some sort of database permissions issue, but I'm not sure how to troubleshoot that with this plugin. Is there a tool you could recommend for debugging/monitoring the communication between client and server in this case that might allow me to get more detailed information about where it's getting stuck?

Thanks for any assistance. I'm really excited about Omeka in general and this plugin in particular, so I'd love to get this problem resolved.

Shirley

Shirley,

I don't think you have a database permissions issue.

I would temporarily deactivate all the plugins, except CsvImport, and then see if the CsvImport works. If it works, I would then reactivate each plugin, until the CsvImport does not work.

If that does not work. You could try to echo test messages in the indexAction function of the CsvImport Index controller (CsvImport/controllers/IndexController.php) to see if it at least gets that far in the code. So for example in indexAction, I begin with something like this:

public function indexAction()
    {
       echo 'Testing';
       exit; 

       if (!$this->_hasValidPHPCliPath()) {
            $this->redirect->goto('error');
        }

and then click on the CsvImport tab in the admin interface to see if it ever reached this function. It should print 'Testing somewhere on the screen and then exit if it successfully entered the indexAction function. Then I'd move that echo and exit lines down to see how far it gets in the indexAction function befor it does not display 'Test somewhere on the screen'. This will be the place where it somehow fails.

For example, I'd next test this:

public function indexAction()
    {
       if (!$this->_hasValidPHPCliPath()) {
            $this->redirect->goto('error');
        }
       echo 'Testing';
       exit; 

       // get the session and view
       $csvImportSession = new Zend_Session_Namespace('CsvImport');
       $view = $this->view;

Let me know if you have any new information about the issue.

ok, I deactivated all other plugins then reinstalled CSV Import. Got the same behavior as before, so I deleted the session cookie.

Next tried modifying IndexController.php as instructed. 'Testing' displayed when I inserted it immediately before the _hasValidPHPCliPath() statement, but not when I inserted it immediately after (the perpetual Loading... condition recurs). So, it appears that the failure is occurring when the plugin attempts to create the Zend session namespace (whatever that is!) What could cause that sort of failure?

Thanks again for all of your help. This is a great learning experience for me.

Shirley

First, we should probably turn on display_errors to see if we can get any more debugging info.

Edit /.htaccess

change this:

php_value display_errors 0

to

php_value display_errors 1

Secondly, I wonder if it is somehow in an infinite loop. I assume that the recurrent loading occured with my second example of my previous post. If that's the case, then it is redirecting to the errorAction function. Perhaps this errorAction function is somehow redirecting back to the indexAction, ad infinitum.

To test this theory, use the following:

public function indexAction()
{
       if (!$this->_hasValidPHPCliPath()) {
            echo 'Testing';
            exit;
            $this->redirect->goto('error');
        }

If it show's 'Testing' in this case, then it will try to redirect to the errorAction() function located in the same file.

If that's the case, we need to go see if what happens in the errorAction() function.

Remove the echo and exit() from the indexAction() function, and then change the errorAction() function to this:

public function errorAction()
    {
        if ($this->_hasValidPHPCliPath()) {
            echo 'Got to ErrorAction';
            exit;
            $this->redirect->goto('index');
        }

If you see 'Got to ErrorAction', this means that the code will try to goto the indexAction, thereby making an infinite loop between indexAction and errorAction, which might explain the infinite loading.

If that's the case, you might try editing the background.php.path setting in application/config/config.ini

You will to put in the path to your php-cli.
To get this, you can try to type: "which php" in your terminal, or you might need to ask your system admin.

Let me know if this helps.

When I put in:

if (!$this->_hasValidPHPCliPath()) {
   echo 'Testing';
   exit;
   $this->redirect->goto('error');

I don't see Testing (I get the Loading... condition), so it appears that it's failing on the if ... _hasValidPHPCliPath statement itself.

Shirley

Corrected code snippet for my last post (includes the final curly brace, omitted above, but included in my IndexController.php):

if (!$this->_hasValidPHPCliPath()) {
        echo 'TESTING TESTING TESTING';
	exit;
        $this->redirect->goto('error');
 }

Have you tested inside _hasValidPHPCliPath() ?

For example, echo the $p variable.

ok, I'm slow ;) but I think I'm starting to get the idea here ...

I verified that I was getting to _hasValidPHPCliPath, but I could not echo $p, which led me to start testing getPHPCliPath in ProcessDispatcher.php

That led me to _checkCliPath, where I echoed successfully until I got to:
exec($command, $output, $returnCode);
where I encountered the Loading ... condition again. Here's what I got when I echoed $command:
/usr/bin/php -v

Not sure where to go from here ... thanks for your patience in guiding me through this.

Shirley

p.s. I got /usr/bin/php -v when I echoed immediately before

exec($command, $output, $returnCode);

but not when I echoed immediately after.

So you found out the path to the php that it is trying to execute.

From the command line on the server, you should try to manually run:

/usr/bin/php -v

This will let you know if this php-cli path is correct. If you php-cli is located somewhere else, you should specify it in the background.php.path setting in the application/config/config.ini

Also, I wonder if your php settings on your server allows you to run the exec() function. Perhaps, its dying because your php settings prohibit you from running exec.

You might want to ask your webhost if that's allowed.

I was able to run php from the command line using the path above, so it looks likely that my web host (BlueHost) is blocking the exec() function.

As a workaround, I simply commented out:

if (!$this->_hasValidPHPCliPath()) {
   $this->redirect->goto('error');
}

where it appeared in IndexController.php, which got me to the Step 2 screen. Couldn't get beyond that, though. I will contact my web host about the exec() function. Will it cause major problems if I just comment out statments that call _hasValidPHPCliPath?

Shirley

Looking at the PHP.ini file on my BlueHost account, it doesn't appear that any functions have been disabled (there is nothing entered under disable_functions).

By commenting out the _hasValidPHPCliPath statements, I can get all the way to Step 2, but the Loading ... condition occurs when I click on the Import CSV file button. I'm having a lot of trouble figuring out where to start echoing to determine where it's getting stuck. When I look at the status view, it shows the file (the test.csv that came with the plugin) with item count 0/3 and status of "Import in progress."

Any additional help would be greatly appreciated.

Thanks,
Shirley

OK, I'm definitely making progress now. After completely uninstalling the plugin, downloading a fresh copy, modifying php.ini, and reinstalling, it no longer hangs when I try to import a file.

However, now when I go through the upload screen, no errors appear but nothing uploads either. The CSV file remains in the Status list showing zero items imported and status of 'Import in progress.'

I have set
log.errors = true in application/config/config.ini
but nothing at all is showing up in
application/logs/errors.log or
admin/error_log

Any ideas of where I should look next would be appreciated.

Thanks,
Shirley

You should ask your webhost if they allow background processes. And if so, ask them the path to the PHP-CLI.

If anyone else is on BlueHost and runs into this problem setting this in config.ini should fix the problem: background.php.path = "/usr/bin/php-cli"