Checking Published in the settings causes import to fail

[ChrstnMgcn]

This is such a great package. Thanks for developing it!

I'm using it to import lots of articles from an old site to the newly modx'd version. The CSV file that I'm testing with only has 2 columns, but 244 entries. The import works great as song as I don't select "Published". You can download the CSV file I'm using here: https://www.yousendit.com/download/MEtUNnFPdzh6RSt4dnc9PQ

I'm using the ^ character as a separator due to there being semicolons in the html.

Lastly, here's the error I'm getting:

Console running...
Running pre-import tests on submitted data...
CSV file upload overriding any manual input. Filename: sarticle(4).csv
No errors in pre-import found. Preparing import values...
No errors found while checking the import values: 244 items found. Running import...
FATAL ERROR: Array

Thanks for your help!

[Mark-H]

Glad you like the package, it was a pleasure to develop and don't forget Working Party has funded it :)

First few tries PHP timed out, but it did import, with and without the published checkbox ticked...

What version of MODX are you running this on?

How long does it take before the fatal error occurs, is this after ~ 20 seconds, or right away?

[ChrstnMgcn]

Thanks Working Party, :)

I'm using Revolution 2.1.0-rc4 and the error would usually show within 5 seconds of ...Running Import...

[Mark-H]

I've not yet tried rc4. Will try it later this week.

All the errors outputted by ImportX are translated, and I sort of expect an error "Array" to be a non-success result from the MODX Processor. If it's within a few seconds I think there may be a specific issue while creating the resources. No permission comes to mind.

As this may be very specific to your situation I'm afraid I can't tell you specifically what to look at. Could you:

• check the error log to see if there's anything in there that explains where the error comes from?
• if you made any changes to the ACLs of the user group you are in, make sure you have permission to create resources? As you say you only get the error when using "Published", you will want to see if you have publish permissions as well!

Those two things may help come to a conclusion on what to change.

I will go through the error reporting and see how I can change "Array" into the actual error message being reported, just need to set up my install in such a way that it actually reports an error. :P

[ChrstnMgcn]

The error log doesn't show anything and I haven't made any changes to the ACL so all permissions are default values. This may be completely unrelated, but it is worth mentioning. The word "Published" does appear in many of the articles. I did a test with only one article and it worked with the Published checkbox checked, but now that I think about it, I didn't run any tests with the articles that have the word published in them. Hopefully I'll get a chance to try that today and I'll let you know what I find.

Thanks again for your help in all of this!

[Mark-H]

Np.

I don't think having the word "published" in the content would change anything - it doesn't really parse the data, just throws it at MODX really :P Curious what your tests result in though.

Maybe it's convenient to see what resource is throwing the error...

Check
core/components/importx/processors/startimport.php
and find this part of the code (line 167-ish):

foreach ($lines as $line) {
    $response = $modx->runProcessor('resource/create',$line);

Change that to this:

foreach ($lines as $line) {
    logConsole('info','Processing resource '.$line['pagetitle']);
    $response = $modx->runProcessor('resource/create',$line);

That will send a message to the console with the pagetitle of the line being edited, so can see what has been parsed when you end up with the error. Warning: you'll get loads of spam from that. :P

If it's something in the syntax (or a word it's triggering on) that should be fixed in the code.

If you want, I could also see if I have time to test it & try to find the cause of this in your manager - if you are okay with that. Just drop me an email via business at markhamstra.nl or a PM here on Git with the details, and I'll see when I have time. That would imply though that I'd test it out a few times to get to the core of this. I can understand if you'd rather not have me luring in your manager, so don't feel obliged.

[Mark-H]

Actually, just found the cause of it displaying "Array" instead of the actual error message..

        return logConsole('error',$modx->error->failure($errorMessage));

That should simply be

        return logConsole('error',$errorMessage);

It's around line 176 and will be fixed in the next release!

[ChrstnMgcn]

So as it turns out it was just duplicate aliases being generated! So that brings up 2 possible solutions:

1. Skipping the duplicate
2. Auto-incrementing the alias name maybe as alias-name, alias-name-2, alias-name-3??

It's certainly not a deal-breaker. This is much faster than copying the table from the old db to the modx db, creating a package for importing, manually setting the fields and tvs, creating a separate snippet for each table to import and then other troubleshooting.

Knowing about the duplicate aliases now all I'll need to do is SELECT DISTINCT and export from phpMyAdmin and import it into ImportX! :)

Thanks again for your help and it looks like the 404 notifier is going to be perfect as well because all of the URLs that will be changing from the old site. While it won't "fix" them at least the team can update them over time. Unless you have other ideas??

Have a great weekend!

[Mark-H]

Thanks for reporting back.

There's no alias checking being done within ImportX - this is all delegated to the actual MODX processor.

It seems that it only sets an alias by default if the system settings

• friendly_urls is enabled, and
• automatic_alias is enabled
  and if they aren't it wont assign a default alias.

If the resources have a link on their old site, you could add that to the CSV as well. Just pass another field in the header "alias" and add the link it should go to there in the value rows. Depending on your new & old site structure that will also get rid of the need to check for 404's (though it's useful to make sure everything went well anyway!).

I'm not quite sure on what needs to be done in ImportX regarding aliases - I could override the processor's attempt by passing an alias based on the pagetitle, but that'll need some more thought as then I'll also need to account for all kinds of weird characters, duplicates etc. Setting a generic alias could mean a lot of work later on to fix the imported resources.

Thanks for your help in improving this addon & catching that bug!

[Mark-H]

I think I'll just let the whole alias thing be - it's not required when they are not using aliases, and I think that the processor itself should deal with it, so I'm not stuck updating it every release something changes to that. :)

If you have any other q's related to this issue, feel free to reopen!