Problem Importing Items from Omeka.net site to an Omeka.org server

Hi, I’m a technical assistant with the Rose Theatre Archive, which is currently an Omeka.net site located at henslowe.omeka.net. We have installed an Omeka.org installation at a Bluehost server located at rosetheatrearchive.website, which is where we want to move the archive. We are currently trying to import items from the old Omeka.net server, which has 349 items and 16 collections using the Omeka Api Import plugin, but it’s having a weird issue. It will import a certain number of items and then just stop. I’ve tried undoing the import multiple times and redoing it again, but it’s still having the same problem. Currently it has imported all the collections and 157 items, and it isn’t importing further. The status on the plugin page still says “Importing Items,” and won’t change even if I click the link to update the status.

Previously we had the error “The background.php.path in config.ini is not valid. The correct path must be set for the import to work,” and it wouldn’t import at all. I contacted Bluehost and they told me to try the path “/ramdisk/php/54/bin/php54-cli,” which fixed that error, but now it’s having this new error.

Any ideas?

It sounds like something is just making the process stop, but it’s hard to tell what at this point.

Have you tried just running the import multiple times, without undoing it? The records won’t be duplicated, so this might identify whether it is a timeout issue or something else that’s causing the import to fail.

Thanks, that seems to have worked! I was so excited I forgot to let you know.

I’ve had the same problem - did you just keep running it until all the records copied over? My problem is that I have 3,700+ records to copy over…

Hi Fuji,

I’ve been talking with the omeka.net team, and suggested that we move the conversation here since it seems more like an issue with the import process than with omeka.net.

I was able to import all the public items in my tests, which suggests a difference in server settings causing a problem. Often, just re-running the import process eventually gets through everything, though it can sadly take a lot of tries, especially with a large collection. I did notice that the import process was going more slowly than usual, so I’m looking into that, too.

That’s with me running the import without a key, so there might also be a difference there to look into. But the quickest check is probably to just keep trying to rerun the import. If it keeps dying, there are more tricks we can try.

Thanks - I will try it without a key to see if that makes a difference!

Reclaim Hosting suggested this:
I ran into this exact same thing (killer timing) and head to reach out to an Omeka Dev last week. The advice (which ended up working in my case, though it’s a bit painful). Is to rerun the import a few times slowly increasing the page number variable in the file plugins/OmekaApiImport/libraries/ApiImport/ImportJob/Omeka.php around line 79 or so. It will say $page = 1; or something like that and you can increase that number to force the plugin to start later in the line of items. For some reason Omeka’s api import process is timing out on large collections but using this method I’ve been able to import collections over 2,500 items. Let me know if that works.

Yep! I was hoping that it wouldn’t get that far, but that’s one of the tricks I had in mind to try next. I’d like to not need that, but it’s hard to know what’s a server issue vs a code problem. I’ve been looking at the question of importing users for each item.

Thanks for the feedback, and I hope it all gets through happily.

OK, using the above method, I somehow ended up importing more files (3758) than there are in the source file (3706). Any idea how this happened?