For modules that implement content types via hook_node_info(), what is the best practice for exposing such content types to features?

This is specifically in re #880770-17: Features integration contribution for uc_product product classes (content types)

This question must have been asked before, but I cannot find it after searching the issue queue.
If someone can point me in the right direction, I'd appreciate it.

Comments

Grayside’s picture

If they've already been defined in hook_node_info(), then they are already managed in code. That's the very hook Features uses to export content types.

I would convert uc_product to a feature module by designating that content type a feature component in the .info file, moving the hook_node_info() implementation to uc_product.features.inc, including that file in the .module, and then recreating/updating the feature to be sure everything is working smoothly. For a content type, there is no actual dependency on Features.

dsnopek’s picture

Hrm. So, I understand the problem, but what about this situation:

  • A module declares a node type via hook_node_info(). For example, the forum module declares the "forum" type this way.
  • You modify the "forum" type by changing the "Description" and "Explanation or submission guidlines".
  • You want to add "forum" to your feature, so that those changes are packaged with it.

Of course, the changes won't be packaged with it, the "forum" type is simply ignored.

What we really need is some kind of hook_node_info_alter() or something else clever. For now, of course, you can write a hook_install() which changes the database directly to work around. But real support for this would be better!

Best Regards,
David.

hefox’s picture

The module implementing the node type would have to add a call to hook_node_info_alter for any way to change it outside of the database, as core for 6 is frozen (and 7 doesn't have it either).

lpalgarvio’s picture

this is sad. i want to be able to export all kinds of node types, including blog, forum, poll, panel, product and product_kit.

Grayside’s picture

Why do you need to export them? You can build a feature that adds taxonomy, fields, etc to an existing content type without it being exported at the same time.

Grayside’s picture

@hefox pointed out that I missed the goal was doing things like changing texts. You can do that using the locale variable in settings.php. It's not exportable, but it does allow you to repurpose things within your site. I use it to convert Atrium's Blog feature into a light-weight Discussion feature.

lpalgarvio’s picture

you are absolutely right on your reply.
it's not exportable.

we need to export these things. further more, Features only exports fieldgroups when you bundle them with node types.
thus, i can't export Blog, Forum, Poll, Panel, Product or Product Kit fieldgroups

Grayside’s picture

Really? I'm pretty sure you can export fieldgroups by hand-editing the .info file of your feature.

lpalgarvio’s picture

and hand-editing the fieldgroup.inc file, taking an hour of your time.

that's not really exportable.

hefox’s picture

I believe you misread; hand editing the .info file.

You can add most components to a feature by adding the necessary line to .info that corresponds to a component and doing drush fu feature_name.

Features used to allow you to select already exported node types and would then fetch all field groups and fields for that node type, but not the node type. Was this removed?

lpalgarvio’s picture

currently, for Drupal 6, fieldgroups don't show at all when creating features.
they can only be added by normal means if you add the node types.
and you can't add node types which are previously invoked with hook_node_info as someone explained - blog, forum, poll, panel, product, product_kit

that functionality you say, must be re-create feature, but i can't recreate a feature that does not exist.

basically i cant export the fieldgroups unless i can export the node types too.

Grayside’s picture

If you look at the output of a generated feature, you see it also auto-generated a .info file. In this info file is listed every component of the feature. You can, by hand, make changes to this .info file.

When done, run drush features-update [feature-name] and it will regenerate all exportable components, including things like specified fields and fieldgroups.

I haven't used the Features UI in about a year. Yes, this is very advanced and it's a darned nuisance if you aren't into this kind of effort, but it is a workaround since there is a functionality regression. Probably this use case was not considered the last time node type export from the UI was refined.

lpalgarvio’s picture

following your idea, i added the info lines:

features[fieldgroup][] = "forum-group_content"
features[fieldgroup][] = "forum-group_node"
features[fieldgroup][] = "forum-group_extra"

then refreshed the features page, went on the review the overrides for the feature.

at that point it listed the differences (absence of the fieldgroup.inc file and code) and allowed me to copy it, although including some crap from the left column.

therefore i recreated the feature, using the UI, with the recreate tab, and voila, it worked, exported the fieldgroups :)
didn't need to go to drush

thanks for the idea

hefox’s picture

Status: Active » Fixed

Seems fixed

Status: Fixed » Closed (fixed)

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