There is 2 validation errors when importing a content type definition for content_copy (CCK):

  • $form['content_type']: the default value may not exists if the content type story or the first content type returned by node_get_types() does not exists in the new environment. So I add an option '' => t('Select type') which is the default value.
  • $form['input_format'] : The default format is 0 and is not included in the formats returned by function filter_formats(). So here I added in the options array the entry FILTER_FORMAT_DEFAULT => t('Default format').

If this patch causes some problem with the usual work of feedapi_node, let me know what problem and I will find an adapted patch. Actually I really need to have feedapi_node work with content_copy.

CommentFileSizeAuthor
feedapi_node.patch1.52 KBb-prod

Comments

alex_b’s picture

Status: Needs review » Needs work

This looks good to me.

Howeer, feed refreshing needs to bail and there should be an error message when there is no content type selected and a feed is being refreshed.

Currently (without this patch) FeedAPI will create a node of $default_type. With this patch applied, it would create nodes of no content type.

b-prod’s picture

Thanks for your quick answer!

In _feedapi_node_save (line 287), I read: if (empty($settings['content_type'])) {. In the case of no value is set for $settings['content_type'] or this value is empty, the code below try to find a content type: first it checks if "story" conetnt type exists, then it takes the first content type returned by node_get_types(), which exists because there is at least the content type for the feed which is being parsed. In this last case, this part of code return an error: if (feedapi_enabled_type($node->type)) {.

I didn't find any other part of code trying to create a new node where the type could be undefined. But maybe I am not searching in the right place?

And if you prefer I can modify the work of feedapi_node when trying to create a new feed node and return an error if the content type is not correctly set.

alex_b’s picture

Status: Needs work » Reviewed & tested by the community

#2: You're right, I should have a had a close look before I replied OTOH. Your patch is RTBC then from my point of view.

aron novak’s picture

Status: Reviewed & tested by the community » Fixed

The patch is tested both automatically (simpletests 100%), also manually. Looks good, thank you!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

dwightaspinwall’s picture

If you're thinking this patch will prevent the input_format => 0 problem in your cck exports you're mistaken. Use the one at http://drupal.org/node/371820#comment-3124890 instead.