I've never gotten this module to work properly, like ever. Many other people have had similar issues for years now.

It needs to operate in batch mode for one thing as the average server cannot handle exporting or importing a content type with more than a handful of fields. Instead of spitting out a text area to copy/paste, it should produce a text file which can subsequently be imported.

I had to up the PHP execution time significantly (not an option for shared hosts) to export a large content type with 70 fields. On import to my powerful local machine (PHP mem set to 4GB, and execution time to 1,000 minutes), I immediately got the WSOD. The only way to get it to work was to import one field at a time. Two fields and it was immediate WSOD, no PHP errors, nothing. There are many things that can cause the import to fail, but without an actual error, it's near impossible to track down.

The problem I'm afraid, is that D7 is getting all the eyeballs these days, and this will never get fixed like so many other bugs in D6. But for those of us with complex highly customized sites, there's no option to upgrade to D7 as it's nearly impossible to convince a client to spend the bucks when the site is basically working fine. This is not good for Drupal's image.

Comments

pebbl’s picture

I'm not sure if this is related (as it seems you managed to get around the problem one field at a time) but on my own local set-up (Drupal 6.26, Mac OSX, MAMP with PHP 5.3) I was trying to import a content type (for the first time) that had about 10 fields. I also got an immediate WSOD... no errors, no logs... nothing and my local is souped up just the same so a timeout or memory shouldn't have been an issue.

Just to test, the first thing I tried was to put the import structure into a normal PHP script and see if it was an encoding issue or something. Low and behold the PHP script crashed out with the following error:

Fatal error: Call to undefined method stdClass::__set_state()

Now I'd always seen this construction when using var_export from php, but I'd never actually tried importing the exported data. It seems for some reason this isn't possible.. as the __set_state() method doesn't exist - at least not for my install. There is a discussion about this error here (http://drupal.org/node/215375).

However, I had never had need of this __set_state() method to create an object structure in the past, because I always just used casting from an array to an object instead... so, I modifed the exported script - search and replaced the following:

stdClass::__set_state(

with

((object)

Copied and pasted the file back into the import and everything magically worked.

So as I say not sure if it could help with your own problem, but it might help others that find this page.