Support for Features

Thank you for your suggestion I have been thinking on that feature also and I will try to start work on it asap.

subscribe

Subscribe. Great work so far.

I second this. The module works great so far, but features support would be awesome

subscribe

subscribe

I've begun work on a patch for this, but have never implemented ctools/features exportable integration before, and have unfortunately been unable to make it work as desired. I've decided to post my patch as work in progress, in hopes someone else might be able to move it forward.

I've read all the documentation re: ctools export/features integration that I can find, and it all seems straightforward. Initially I tried to implement just the plain ctools export steps (as described here), excluding the export UI bits (since I'm planning to just use Features to do the exporting for me). This seems to *almost* work- the conditional presets show up on the "create feature" screen as a component, and even seem to export into a feature module properly.

The issue I ran into was *importing* the presets again- they never re-appear in the db. It seems that by default, CTools assumes any non-overridden presets can just live in code, and your module must check both places any time it's loading them. I found this post which describes this situation quite well, but adding the hook_features_rebuild and hook_features_revert implementations as described there didn't help any.

All of this has me very confused since it *seems* like all the right pieces are in place. As such, my hope is that I'm missing some small detail which another set of eyes may help identify more quickly than me staring at in frustration.

Some details on the patch:

• Adds the 'export' section to hook_schema as well as a "machine_name" unique key and hook_update_N function to generate machine names (based on the bundle, field, control field & state), for existing conditionals. This part works well based on my testing.
• Implements hook_ctools_plugin_api AND hook_features_api, although the second is apparently unnecessary- I added it in hopes it would help with the import problem
• Implements _load and _save callbacks defined in the export section of the schema. These are also apparently unnecessary and are just the boilerplate implementation all the articles I've read describe. These have dd() calls in them from my attempts to trace the problem with imports not happening- the _save hook is never called automatically
• Implements hook_features_revert and hook_features_rebuild, again using the boilerplate style implementations I've seen in multiple places- here again I've used dd() calls to trace the execution
• DOES NOT do anything to generate machine names for new conditionals- this is probably a small issue that could be handled a number of ways- the simplest being to generate it in the form validate/submit functions using the same method as the hook_update_N function described above
• Includes some code style fixes that made the code a bit more readable for me as I was working on it :)

To test:

The patch should apply against the latest 7.x-1.x branch as of when I cloned it a few days ago- I notice there's one more small commit since then, which should not affect this.

You should have ctools, features, and devel modules installed and enabled. Create a couple of conditional states and then go to admin/structure/features and create a feature. Include your conditions in there, download and install the new feature module on your test site. Inspecting the code for that site should show the conditions properly exported into code. Run a drush fr --force on the feature, which should trigger the features_revert function to run (it apparently doesn't initially, which may be part of the problem). This triggers the dd() calls, and you should see output in /tmp/drupal_debug.txt.

I also added a dd() call to spit out the $export array just before returning it in the features module's implementation of hook_default_field_conditional_state, so this would also show up in the output. This revealed some strange behaviour: the function in the features module works as expected, and the dd() call spits out the array of conditions. However, the hook_features_revert function never gets them- when I dd() the $presets array after calling hook_default_field_conditional_state, it's empty! This is apparently the source of the trouble, since the features_revert mechanism never gets the presets to save them into the db. The other odd thing here is that the dd() output from the features module call shows up *after* the empty $presets array from the dd() call in the features_revert/rebuild hook, even though it should logically come before. I can't tell if this is just some oddity with output buffering or something, but it seems suspicious.

Anyone with more features.module/ctools skills care to take a crack at this? At very least, it'd be helpful to confirm the patch is NOT working for someone else- rule out the possibility of some quirk with my setup. At best, maybe it works properly for you, and then I just have to figure out what I'm doing wrong! Failing all that, maybe someone can see the detail(s) I've missed, and then all of us who love this module (and Features) can celebrate :)

Any progress so far?

@kyleoliveira: AFAIK no progress, although I still suspect there may have been something weird with my dev environment, and would love for someone else to test my patch to see if they can reproduce (or better yet: NOT) the broken-ness I was seeing. I'll try to followup with any updates to the patch as needed, as I'd love to see this module become Features-enabled :)

I will do the features integration and provide a patch here very soon

Here is the patch. I created it for the release, not for the dev version, so changed the version of this issue.

I applied the patch in #12 to the 1.0 version and cleared the cache. The patch appears to have been applied properly (I got the properly "xyz file was patched" messages) but when I go to the "Create feature" screen what am I looking for? I looked until the list of strongarm variables but I couldn't find anything...

EDIT: Nevermind, I found it-- it's under the header "Field Conditional State." I had to clear the caches twice, not once.

I applied the patch; thanks for getting the ball rolling on this. I noticed two problems.

1. When I add some of the field conditionals to my feature, I can then create a new feature and add them again from the UI. Usually, once you add some items to a feature, you cannot add the same items to another feature through the UI. I don't know how this is enforced, but it is not being enforced here.

2. Currently, the way the names are provided on the features UI is very confusing. For example, I have two fields (where_to_study_explanation and where_to_study) that are both attached to two different content types.

In the UI, it shows this:

() - field_where_to_study_explanation by field_where_to_study
() - field_where_to_study_explanation by field_where_to_study

One of these is attached to the "Study" content type, while the other is attached to the "Teach" content type. But from the UI, it is impossible to tell which is which. Also, I don't know why the () are shown in front.

Thanks for your hints. Your hint 1) is fixed with the new patch attached. But 2) I cannot reproduce, as in my installation it appears as

bundle (entity type) - DESCRIPTION THAT YOU ALSO HAVE

Looking forward your review.

Attached a new patch with some bugfixes applied against 1.1 and current dev version

I'd love to see a import/export feature, too. States config can get quite large and complex with many fields.

Unfortunately the work on this issue here belongs to 1.x. Probably we need a new approach here for 2.x?

To get a base for the 2.x work, I fixed some bugs in 1.x you can find the patch attached.

1.x is no longer maintained. Do not post patches for 1.x, please.

@manualBS now that 1.x is unsupported did you have any plans of building in features support for 2.x?

Thanks!

Sorry, I have no plans yet as the patch cannot be ported easily du to the changed structure. This year it will not be possible for me but I can couch somebody that want to implement it if needed.

I'd buy a 6-pack... no... a 24-pack of beer for anyone who can make a patch to get 2.x version of this module into Features in the next two weeks!

Seriously, I'll find a way to get it to you ;-)

@manualBS it is a new year! Any plans for features support for 2.x?

Seems like the tests are broken http://cgit.drupalcode.org/field_conditional_state/tree/field_conditiona..., and this should be handled in a separate issue. Changing it back to needs review.

Definitely need patch for 2.x

Patch in #30 exports the field conditional states into code. But the import functionality is not working. It would be great if anyone look into this. Most probably the code for import is not written.

There is a similar module Conditional Fields that does have features export capability. I think the UI in this Field Conditional States is much more intuitive and I would prefer to use it.