Closed (fixed)
Project:
Features
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
17 Dec 2010 at 22:58 UTC
Updated:
8 Sep 2011 at 08:51 UTC
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
Comment #1
Grayside commentedIf 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.
Comment #2
dsnopekHrm. So, I understand the problem, but what about this situation:
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.
Comment #3
hefox commentedThe 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).
Comment #4
lpalgarvio commentedthis is sad. i want to be able to export all kinds of node types, including blog, forum, poll, panel, product and product_kit.
Comment #5
Grayside commentedWhy 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.
Comment #6
Grayside commented@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.
Comment #7
lpalgarvio commentedyou 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
Comment #8
Grayside commentedReally? I'm pretty sure you can export fieldgroups by hand-editing the .info file of your feature.
Comment #9
lpalgarvio commentedand hand-editing the fieldgroup.inc file, taking an hour of your time.
that's not really exportable.
Comment #10
hefox commentedI 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?
Comment #11
lpalgarvio commentedcurrently, 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.
Comment #12
Grayside commentedIf 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.
Comment #13
lpalgarvio commentedfollowing your idea, i added the info lines:
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
Comment #14
hefox commentedSeems fixed