With the node module, there are a lot of modules which extend the node which features doesn't know about. For example the pathauto module adds to the content type but the parameters are not exported as well.

The 1st patch adds a new hook_features_populate_alter() which allows the $more to be altered and additional dependencies added.

The 2 other patches since the additional parameters are just variables, using the strongarm module they just add the variables to the pipeline so strongarm will pick these up and add them to the feature.

Since these are just variables adding features support for auto node title and path auto is only a few lines of code.

This also means that the modules implementing the feature do not need to directly know about the dependencies, and modules like cck could actually handle the addition to the pipe itself instead of having the code in the node.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

yhahn’s picture

I like this approach.

I discussed with jmiccolis a while back the fact that we'd made a design error - it's often not the object providing module that knows about its dependencies/associated objects but the extending modules. The solution I've been floating around for a while has been to pass every object to ever feature component provider - an expensive and overly complicated change. Let's see what he has to say about this change.

For now, what do you think of changing the alter to features_populate_[component_name], the way a targeted form_alter() works? This way there wouldn't need to be a component check within the implementing module's hook given that it's pretty unlikely it'll be altering more than one type of component.

gordon’s picture

Yes I do like that idea of having a targeted hook.

I will make a change and upload some new patches

yhahn’s picture

Status: Needs review » Needs work

Setting status.

gordon’s picture

Status: Needs work » Needs review
FileSize
812 bytes
799 bytes
1.05 KB

This has taken me a while but here is an update.

I was thinking that we may want both hooks, like how form_FORMNAME_alter() and form_alter() but I don't think there will be as much overlap, and just mean we would have many small directed modules instead of large ones.

Cyberwolf’s picture

Exactly what I was looking for! Would be great to have this hook. Currently I need to go over the long list of variables with Strongarm and manually select the ones related to my content types.

brad.bulger’s picture

Ditto, this is what I came here to figure out how to do. The last patch works great.

One question, that may be outside the context of this issue - how do you handle dependencies? For instance, if you are adding variables to the pipe, that only works if you have Strongarm enabled, yes? Or will Features just ignore those entries if Strongarm is not enabled, and so it's up to the feature creator to take care of that?

yhahn’s picture

Assigned: gordon » yhahn

In my court to review now -- this looks very promising (and awesome) to me.

greggles’s picture

subscribe.

yhahn’s picture

Priority: Normal » Critical

On my list.

dmitrig01’s picture

FileSize
1.52 KB
dmitrig01’s picture

FileSize
1.51 KB
yhahn’s picture

Priority: Critical » Minor
Status: Needs review » Needs work

@gordon the patch has been committed with a few tweaks:

http://drupalcode.org/viewvc/drupal/contributions/modules/features/featu...

The pipe alter hook looks like this now:

function hook_features_pipe_[component]_alter(&$pipe, $data, $export, $module_name) {
}

In addition, I know some people are interested in altering the export array once all population is complete and so we've split that into a separate hook:

function hook_features_export_alter(&$export) {
}

Setting this to needs work so that you can update the integration patches you have above. Feel free to close when you are done.

codewaggle’s picture

subscribe

q0rban’s picture

subscribe

phayes’s picture

subscribe

hefox’s picture

phayes’s picture

Status: Needs work » Fixed

Both of these patches exist in other issues now. So i'm going to mark this issue as fixed to lessen any confusion.

Status: Fixed » Closed (fixed)

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

tim.plunkett’s picture

Status: Closed (fixed) » Closed (duplicate)

Marking as duplicate instead of fixed, that was confusing.

tim.plunkett’s picture

Status: Closed (duplicate) » Closed (fixed)

Er, maybe not? Sorry all.