Can't Import Content Nodes

Here's an initial answer - why don't you increase the size of the fields on the *exporting* site to match the field sizes on the new site? That way the content types would match and the import could run.

Currently the code stores the exporting site's content type as an object and stores it in the dataset file with the data. On import it gets the content type of the site being imported into as an object. It then compares those objects which makes the checks quite strict.

It does unset some fields/attributes before carrying the checks - such as some date fields - but as mentioned the checking is quite strict. Obviously, this was done to try to ensure that the data could be imported safely into fields which exist already.

(One possible idea - the import was set up not to care if you have 'extra' fields in the site being imported into - this might give a way forward).

I suppose what you are saying is that we should ignore errors if the fields are 'larger' on the import side. We could remove all the content type fields from the initial object comparison - then loop through all the fields one-by-one - and compare them with a field on the receiving side - and allow the check to pass if the field is the same size or larger.

We'd need to be careful - image fields have max/min pixel sizes etc and there are other attributes of fields etc which would need to be considered. Character field lengths would be easy - but other attributes such as number of values, types files allowed would be trickier.

My thought would be that you should copy the live site to one called livecopy. Here you can alter the fields to match the fields on the beta site you have developed - then export the data from livecopy and import it into a copy of the beta site - then test, test, test etc. That way your live site isn't touched and you get to test out the results of the increased field sizes with the existing data.

I think if you look into the code you should be able to find the part which outputs the error about the content types not matching. At that point if you get the code to var_dump the content type objects (exported and imported) then you should be able to see the differences.

This module is designed to work stand-alone - so I'm not sure about interaction with the Migrate module RE the wine/beer names!

I've not set up the users to be exportable/importable with user images - this was not something which was requested by my current sponsor.

I'm going to mark this as closed for now - feel free to re-open it if any further info.

The content type checks a quite (i.e. very!) strict to make sure that the content can be imported safely. This doesn't seem to have been an issue for anyone else in the last six months so it probably doesn't need any changes.

Same problems. After 5 hours I can't make it work. It is a content type that doesn't exist in the destination site, so I create it, then add the fields, but one of the fields isn't correct. I see the taxonomy machine name is taxonomy_vocabulary_2 on the old site but I can't duplicate that. I've tried bringing over the content type with features, but that didn't create the fields successfully.
Does it matter what order the fields are in?
Do the field names matter or just machine names?

I'll leave this closed, but want others to know it ain't so simple.
Suggestion would be to create the content type in the export, then you have it correct.
I'm trying to migrate from a site that has a few glitches since it started on D5, then upgraded to D6 and D7 over the years.

Hiya,

My thinking is that the content type check is being too strict - or there is something about the field order which is causing the code to report that the content types do not match.

These are the key lines from includes/profiles/nodes.inc

552 // Here we are going to unset the description fields. If the
553 // description has been changed but everything else about the
554 // content type is the same then we will assume that this is just an
555 // edit to the description.
556 unset($node_content_type_object_from_file->description);
557 unset($node_types[$node_content_type]->description);
558
559 if ($node_content_type_object_from_file != $node_types[$node_content_type]) {
560
561 drupal_set_message(t("When the dataset was created the node content type was different from this site's node content type. Please manually compare the content type: %content_type", array('%content_type' => $node_content_type)), 'error');
562
563 return FALSE;
564 }

So you can see that if the content type objects do not match then the error is raised.

I suggest you insert this at line 558

var_dump($node_content_type_object_from_file);
var_dump($node_types[$node_content_type]);

then run the code.

You should see the content types dumped to a debug window and be able to see exactly what they have in them and therefore why they do not match.

Then, there may be some fields which do not match which are not relevant. In this case - look at lines 556 and 557 you can see how to unset (i.e. set to blank) those fields. Once those fields are set to blank then they will be identical and therefore the mismatch will not be triggered.

Please let me know how you get on.

Regards,

Kevin B

Reply was double posted.

I'm going to re-open this for now to see if we can find out the issue which the posters have hit.

Closed as no debug feedback has been received.

Feel free to re-open if the same issue is hit - please add in the result from the debug code above.

FYI When importing into a copy of a site with the content types recreated by features I had to add another bunch of exceptions as follows.

  unset($node_content_type_object_from_file->module);
  unset($node_types[$node_content_type]->module);
  unset($node_content_type_object_from_file->custom);
  unset($node_types[$node_content_type]->custom);
  unset($node_content_type_object_from_file->modified);
  unset($node_types[$node_content_type]->modified);
  unset($node_content_type_object_from_file->locked);
  unset($node_types[$node_content_type]->locked);
  unset($node_content_type_object_from_file->is_new);
  unset($node_types[$node_content_type]->is_new);
  unset($node_content_type_object_from_file->orig_type);
  unset($node_types[$node_content_type]->orig_type);

Debug output of original issue below showing source content type followed by type recreated by features.

stdClass Object
(
    [type] => app
    [name] => App
    [base] => node_content
    [module] => node
    [help] => 
    [has_title] => 1
    [title_label] => Title
    [custom] => 1
    [modified] => 1
    [locked] => 0
    [disabled] => 
    [orig_type] => page
    [disabled_changed] => 
)
stdClass Object
(
    [name] => App
    [base] => node_content
    [has_title] => 1
    [title_label] => Title
    [help] => 
    [type] => app
    [custom] => 0
    [modified] => 0
    [locked] => 1
    [disabled] => 
    [is_new] => 1
    [module] => [*name_of_feature*]
    [orig_type] => app
    [disabled_changed] => 
)

I imported the content type to its new site with bundle_copy and got this error after migrating the content with data export import.

Debug output:

stdClass Object
(
    [type] => news
    [name] => News
    [base] => node_content
    [help] => 
    [has_title] => 1
    [title_label] => Title
    [custom] => 1
    [modified] => 1
    [locked] => 0
    [orig_type] => 
    [module] => node
    [disabled] => 0
    [disabled_changed] => 
)
stdClass Object
(
    [type] => news
    [name] => News
    [base] => node_content
    [module] => node
    [help] => 
    [has_title] => 1
    [title_label] => Title
    [custom] => 1
    [modified] => 1
    [locked] => 0
    [disabled] => 0
    [orig_type] => news
    [disabled_changed] => 
)

Simply commenting out the "return FALSE;" (line 563 above and line 575 in 7.x-1.7) seems to work just fine

#11 worked for me. I also changed the equivalent line in taxonomy_terms.inc (line 367).

This issue is real and still need to be fixed.
The problem is that the rules to compare if the content type on source and or destination are too strict and fail in many different cases...

On my particular case I exported with Features and both content types are different on minor details that shouldn't affect the import at all.
This was noticed on prior comments and I think it's important to add into nodes.inc:

unset($node_content_type_object_from_file->module);
unset($node_types[$node_content_type]->module);
unset($node_content_type_object_from_file->custom);
unset($node_types[$node_content_type]->custom);
unset($node_content_type_object_from_file->modified);
unset($node_types[$node_content_type]->modified);
unset($node_content_type_object_from_file->locked);
unset($node_types[$node_content_type]->locked);
unset($node_content_type_object_from_file->is_new);
unset($node_types[$node_content_type]->is_new);
unset($node_content_type_object_from_file->orig_type);
unset($node_types[$node_content_type]->orig_type);

That looks like a decent list of attributes to unset:

unset($node_content_type_object_from_file->module);
unset($node_types[$node_content_type]->module);
unset($node_content_type_object_from_file->custom);
unset($node_types[$node_content_type]->custom);
unset($node_content_type_object_from_file->modified);
unset($node_types[$node_content_type]->modified);
unset($node_content_type_object_from_file->locked);
unset($node_types[$node_content_type]->locked);
unset($node_content_type_object_from_file->is_new);
unset($node_types[$node_content_type]->is_new);
unset($node_content_type_object_from_file->orig_type);
unset($node_types[$node_content_type]->orig_type);

As mentioned - the content type checking was quite strict - deliberately so to avoid errors during the import. Your list would probably help to avoid unnecessary failed imports. If I ever get chance I'll add it in - but currently I'm on other work so can't do this currently.

I'm seeking a co-maintainer and if one appears then I'll point them at this post.

Thanks,

Kev