Features with only module dependencies not recognized as features

Yeah, I have come up against this too. It's really cuz no .module file is generated. Thus Drupal is like, ok move along now no module here. Basically, there must be a module for dependencies to make sense. Seems like your patch'll effectively do that :)

Good luck,
Kevin

Subscribe

I'd like a way to tell features something is a feature without having any specific features, to use feature hooks. It works atm by adding a features[][] = "", but it'd nice if there's a less hackish way for this, which would fulfill this also.

I'm confused. If all you have is an empty module with some standard module dependency declarations, why does it need to be an official Feature?

To make use of the Features UI?

I've seen this issue before, and agree it would be helpful to resolve it.

One scenario where this can happen is when you want to write some code first and add feature elements later (they may not be ready yet). The simplest way to create a nearly empty feature is to add a module dependency. However, as noted in this issue, it won't be recognized in the Features UI, so you can't add more elements this way.

I routinely create features by writing a bunch of .module code, creating exportable elements, hand-editing my .info file, then running drush fu.

If that is an approach that works for you, #893360: Drush update/recreate (add components) is also worth looking at.

The issue here is that features does not recognize dependencies[] as features-specific, because it is not. And to maintain consistency with drush commands, adding a dummy feature when a dependency is noticed seems like a bad plan.

I would go with something like: features[features_api][] = "api:1". This has long-term functionality, and should simply be added to every feature module.

Feature modules generated via the UI will automatically insert this line. Features generated by hand will detect whether it is a feature based on export components and add this line.

Sounds like api:1 that will solve my use case also :).

@#7: The interesting stuff Features does with dependencies are all in the Features Creation & Admin UIs. I don't see the dependencies as they are recorded in the .info file being any different regardless of whether or not Features was involved, which is why I object to a special syntax for them.

I definitely agree that there is value in a standardized syntax to say "I am a Feature." I can foresee it's use on the command-line approach to Features.

Marking as Needs Work.

So is this what we are looking for?

I just realized neither of these patches are going to work. It creates a conflicts when a second feature is added with this variable set. Going with the boorish

$export['features']['features'][$module_name] = $module_name;

Shouldn't harm anything.

My colleague dking informed me my patch sucks because it doesn't follow the standard Drupal process for patch submission. I rerolled it proper.

Again, I would like to suggest something like #894572-7: Features with only module dependencies not recognized as features as a viable answer that has additional benefits in API version specification.

Also, in case that's confusing, I think my position has shifted slightly. I do understand the value of this, I just think rather saying Features=TRUE, I want Features=Compatible API Version

features[features_api][] = "api:1" looks good like a good idea to me also

This is sorta getting into feature request area, which is something that should go into 7.x first

I too would like features to do this. I don't believe this to be a feature request. If I go into features and dont add any dependencies, and create the feature, it downloads a feature module, but that module doesn't show up in the list. So basically you can never add dependencies to it again. I would consider this a bug.

Yes, the UI bug is allowing you to create a Feature with only module dependencies :)

Adding a features designator to the .info file makes it reasonable to create a Feature with just dependencies, though what we're truly talking about is opting in a very, very, very minimal module to be managed and extended by the Features UI.

In the sense that instead of fixing the UI bug, we're adding new functionality that allows any module to be treated as a Feature, this is a Feature Request. In short, an enhancement to resolve an inconsistency, rather than eliminating the inconsistency.

Yes, the UI bug is allowing you to create a Feature with only module dependencies :)

Even if it can be considered as a bug or a design flaw, I think it's still useful to define features by defining only a bunch of dependencies in UI and then add some configuration stanzas in the feature_name_enable / feature_name_install hooks to workaround some module for which there's still no Feature export ability and/or never will be.

We've more or less decided how to fix this, what's waiting now is someone that is especially interested to provide a patch.

Here's a patch that implements
features[features_api][] = "api:1"

I'm of two minds about this. On the one hand, the API version is kind of a dependency, on the other, this seems like something Features should directly be sure is part of every Features-generated module, without it being buried in dependency handling.

If we want it to be universal, would this be a better location for it?

Seems to effect the same overall need, but now adds it to all feature exports even if there are no dependencies. It does seem like a reasonable thing to add, especially if we ever get to an API version 2...

#23 doesn't work. Nothing functional about feature generation can be part of the form workflow. Test case would be to use drush and get the same results as the UI.

well, in that case, let's try this one?

That looks like the correct place to me; I was going to suggest it earlier, but was too lazy to look up the exact function name *whistle*.

Since features array for info gets remade, this will be re-added each time, which is fine so won't have any problems upping the api version.

However, comment could use some work; I personally don't think the initial reason it was added is necessary (people can look up the issue number in the commit that added it). Also, complete sentence, period at end!

tl;dr: Generally seems good other than comment

Agreed, didn't notice. I consider the fact that this fixes the issue to be a secondary benefit.

Rerolled with two options: minimal comment and one more descriptive of the effect.

Works for me. I personally prefer the longer comment.

We also should note that existing features without this line will continue to work, so if somebody decides to rely upon the api version information being saved here just remember that older features might not have this line (until they are re-exported).

We should probably add a helper function for features_get_feature_api_version() and default nothing to "1". Can wait until we have a practical use case for using the version.

I wasn't keen to add a whole new function for the API until we saw some practical use cases. But instead I created the FEATURES_API constant in the .module file so it's not hardcoded in the export module. Went ahead and rolled that change into the commit. I've attached the final patch here.

Committed e894f12.

Think it's needed for 6.x also

Lets keep this one for 7.x and add a backport tag instead.

It was already committed to 7.x

@hefox: Sorry man, totally missed that...

Test for detecting features and that the key is added. Fairly straight forward, not sure how useful bug shrug.

See if we can bump this into 7.x-2.x to run the tester autobot.

Passing tests, so marking this additional Test as RTBC.

Committed to d0c34a5.