0

I'm trying to import a member's XML file (produced by Eric Lamb's Export It! add-on) into a new (local) EE 2.9.0 setup using Solspace Importer 2.2.5.

I set everything up in Importer but when I try to run it, it gives me an Internal Server Error. Here's what I got in the console: http://cl.ly/image/1U3k0r2n3i0B

The XML file is 6.5MB and contains ~330 members.

Not sure how to fix / get it working.

2
  • Can you take a look at your server's log/error-log and see if there's anything there that will give a clue as to the cause of the 500 error? Lots of potential causes there. Aug 28, 2014 at 19:27
  • I'm not seeing anything in the PHP error log (using MAMP Pro), at least not related to this particular site.
    – A Herrera
    Aug 28, 2014 at 19:35

3 Answers 3

2

I think you should try to narrow down the error a little more. Cut the list in half and try each half individually. Does one half go through and the other error? Put aside the working half and cut the bad half into two, and do it again. Keep doing this until you get either a specific XML node causing the issue or figure out it's more about quantity. (You'd basically be doing a Binary Search).

If it errors even when you send a single, known-good member to it, I'd consider walking through the module and exit()ing in various places until it errors before you exit().

5
  • Thanks Matt, I'll give that a shot - very familiar with halving things to find issues; really helpful. When you say walking through the module and exit()ing - you mean in the actual module file?
    – A Herrera
    Aug 29, 2014 at 0:23
  • Exactly. Do something like exit(__LINE__) and kept moving it down the module method until the error is returned by the module instead of your debugging.
    – Matt
    Aug 29, 2014 at 2:48
  • In that screenshot, clicking the POST link will send you to the Network tab. Click on the URL again and you should see the response from the AJAX call. That may give you an extra hint of what might have gone wrong. Matt's answer is excellent: often the issue is one or a few lines that are not formatted correctly.
    – Solspace
    Aug 29, 2014 at 2:55
  • Got the XML down to zero data besides the main wrapping tags (<members><member></member></members>) and still got the error. Tried adding exit(LINE); at various points in the module and would get the same error, no error (but no import either despite it saying it completed), or a new error saying "There was an error during the processing: SyntaxError: Unexpected token <". Clicking the POST link shows this which is starting to go over my head: cl.ly/image/1g2U2S3N2r12
    – A Herrera
    Aug 29, 2014 at 15:26
  • One more step: from that latest screenshot, try clicking the red URL, which should show you the ajax response (this is a very handy way to troubleshoot general js/ajax issues during development, btw). Also try both members or member as the primary XML element, as well as trying out both loose and strict XML settings. If that doesn't yield any progress, you can contact us at support.solspace.com. Please provide a simplified-yet-still-not-working XML file, as well as your Importer version number and settings.
    – Solspace
    Sep 1, 2014 at 7:11
2

Had to submit a support ticket over at Solspace and got help right away. Solution was to set the Unique Field setting to something other than member_id and the import worked beautifully. Big thanks to Nicolas Bottari. :D

0

The URL that's throwing the error looks odd. You've obscured it so it's hard to say for sure but why would Importer be targeting /admin.php?

Is that what you expect? Shouldn't it be /system/index.php?

I do use Importer but not with XML files, I'm not on 2.9.0 yet so no certain what's changed.

You said it's a new local set up so I'd look first to see if your EE preferences/configs are set correctly as well as checking my .htaccess (which for me is the cause of the vast majority of my 500 errors).

1
  • All I've obscured is the local TLD as it gives away the client which I can't do at this point. It's targeting /admin.php because that's the masked cp access. We have the system above web root, so no, it couldn't/doesn't have to be /system/index.php Preferences/configs & .htaccess are correct - everything else has been working just fine.
    – A Herrera
    Aug 29, 2014 at 0:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.