I am importing simple flexinodes (titles and textareas) and applying one taxonomy term to them all. I tested with FireFox 1.5 and Safari 2.0.

On the screen with the sample data and the global settings, the available buttons are "Preview" and "Back". Clicking "Preview", I am lead to the initial screen to select a file.

This workflow loop prevents me from completing the process.

Comments

njivy’s picture

njivy CreditAttribution: njivy commented

If I manually reload the global options screen, the Preview button works as expected and the workflow exits the loop.

njivy’s picture

njivy CreditAttribution: njivy commented

... then I get stuck on the next screen, and I cannot work around it using the same trick. Reloading this page returns me to the initial screen.

njivy’s picture

njivy CreditAttribution: njivy commented

It looks like the value of $_SESSION['node_import_page'] either is not saved or is overwritten.

This programming style, using $_SESSION to store state information, reminds me of the continuation-passing style in UnCommon Web.

dado’s picture

dado CreditAttribution: dado commented

njivy,
strange. any new insights? i believe the $_SESSION method of tracking which page the user is on is a legacy of an older version, but it was working for me. drupal has some new wizard/multipage form apis or no? i wonder whether it would make sense to rewrite to comply with such. a number of other redesigns would be nice, e.g inverting the field mapping form (csv fields go in dropdown instead of node fields)

njivy’s picture

njivy CreditAttribution: njivy commented

I don't have any insights yet, dado. I just rechecked, and I am using v1.22 of node_import.module, which is the latest at the time of this writing.

I will be looking for a glitch in Drupal's session-handling code that is triggered by browser or server environment differences.

I am using Apache 1.3.x in a Linux environment, btw.

njivy’s picture

njivy CreditAttribution: njivy commented

When I press "Next" on the _node_import_start screen, sess_write() is called twice. During the second time, the new value of $_SESSION['node_import_page'] is reverted, i.e. lost.

As I understand it, sess_write() is automatically executed after the output stream is closed (see http://us2.php.net/manual/en/function.session-set-save-handler.php) and when the $_SESSION superglobal is modified.

My version of PHP is 4.3.10.

njivy’s picture

njivy CreditAttribution: njivy commented

Is sess_write() called by the same PHP process that is handling the request? debug_backtrace() is not very helpful when called from inside sess_write().

I ask this because, if I put a watchdog() before and after $_SESSION modification, and if I put a watchdog() in sess_write(), they come in a different order than I expect. It looks as if execution continues before sess_write() is finished.

I could be wrong.

dado’s picture

dado CreditAttribution: dado commented

njivy,
I am using PHP5.0.5, XAMPP on Windows XP, Firefox browser v1.5.0.3. I am not very often getting any of these session errors. I recall once I had to rebrowse to admin/node/node_import to get it to let go of the currently uploaded CSV file, but that is it. Difficult for me to help with this one.
Thanks

alanburke’s picture

alanburke CreditAttribution: alanburke commented

All,
Just a +1 me too for this problem.
I have a similar setup to Dado, using Xammp as a test platform.

The node import does seem to be in some sort of a loop.
It never gets to the Preview section.

Regards
Alan

Robrecht Jacques’s picture

Robrecht Jacques CreditAttribution: Robrecht Jacques commented
Assigned: Unassigned » Robrecht Jacques
Priority: Normal » Critical

My test environment consists out of a server on linux and firefox or epiphany (gnome) browser and I didn't see this behaviour at all yet. Makes it hard to debug, but I'll look into it. This seems to be a show-stopper bug so we'll need to fix it.

njivy’s picture

njivy CreditAttribution: njivy commented

Watching my server's access log, it looks like my client is making duplicate requests for every Drupal page. This is driving me nuts!

I am using "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/418 (KHTML, like Gecko) Safari/417.9.3".

For example, when clicking the "Next" button I see a POST request and a GET request. I'm pretty sure the workflow loop is caused by a race condition in session.inc that resets $_SESSION['node_import_page'].

I'm using tcpdump and not seeing any HTTP redirects, so this might be a browser problem.

Robrecht Jacques’s picture

Robrecht Jacques CreditAttribution: Robrecht Jacques commented

Does the multipage_form_example work for you? I'm considering converting node_import to use a similar completely FAPI solution. That's something for tomorrow though.

See: http://drupaldocs.org/api/head/file/contributions/docs/developer/example...

njivy’s picture

njivy CreditAttribution: njivy commented

Problem solved in phptemplate.

Yeah, that's right. It actually wasn't a node_import bug. The problem just surfaced there.

I had not specified a favicon, but phptemplate still printed the <link rel="shortcut" ... />, which resulted in another HTTP request to the same address. This second request was concurrent with the first but exited last, so the session variables were overwritten to their previous state.

My brother helped me trace this down using Firefox's Web Developer toolbar.

alanburke’s picture

alanburke CreditAttribution: alanburke commented

UNBELIEVABLE!
I could be here to my dying days and I reckon I'd never spot that.
I enabled the default Drupal favicon and, Sure enough, node import worked.

All I have to do now is get Views to work:-)
Thanks
Alan

Robrecht Jacques’s picture

Robrecht Jacques CreditAttribution: Robrecht Jacques commented
Assigned: Robrecht Jacques » Unassigned
Priority: Critical » Minor
Status: Active » Closed (fixed)

GREAT!

Guess I'll wait with using something like multipage_form_example (looks more complex then I at first thought). Don't fix code that is working! Or that is working when the user doesn't shoot himself in the foot :-)

So maybe add a comment to README.txt or something and let's close this issue.

(hmm, hard to choose the right status for this... I'd like something like "not our fault" for status, but that's not in the list... let's use "closed" then)