Avoid incompatibility with Commerce Coupon 2.x

Yeah we probably should move this integration back to commerce coupon 1.x

Yeah, this is throwing errors when viewing the Features recreate/create. Haven't had time to test, but noticed patch not marked "Needs Review."

I'm cool with #4. I'm not sure how broken the implementation is but this is all it took to fix the notice.

This of course wouldn't be backwards compatible with 1.x... so #4 is my choice.

Just sharing a patch if it sparks any other ideas.

Hiding my patch in #5 from the issue summary.

I applied patch 4 and was still getting a notice of:

Notice: Trying to get property of non-object in commerce_coupon_type_features_export_options() (line 36 of /home/public_html/sites/all/modules/commerce_features/commerce_coupon_type.features.inc). Backtrace:

commerce_coupon_type_features_export_options('commerce_coupon_type')
call_user_func_array('commerce_coupon_type_features_export_options', Array) features.module:582
features_invoke('commerce_coupon_type', 'features_export_options') features.admin.inc:599
_features_export_build(NULL, Array) features.admin.inc:350
_features_export_form_components(Array, Array) features.admin.inc:210
features_export_form(Array, Array)
call_user_func_array('features_export_form', Array) form.inc:841
drupal_retrieve_form('features_export_form', Array) form.inc:350
drupal_build_form('features_export_form', Array) form.inc:130
drupal_get_form('features_export_form')
call_user_func_array('drupal_get_form', Array) menu.inc:517
menu_execute_active_handler() index.php:21

I then applied patch 5 and the issue went away. For clarification do we need to apply both patches?

Thanks in advance

@cmriley my patch in #5 just points out the issue of structure between version 1.x and 2.x of commerce coupon. Was a standard object and now it's an array.

Maintaining both ways would be a bit gross. #4 should work but I didn't try it, I'm using #5 because it fixed my problem and I don't care about backwards compatibility with a module that I'm not using that version of:)

Maybe it's already in the database or cached and still thinks it has access to make that feature?

Using both patches won't hurt a thing though, unless you have 1.x then #5 would be giving you the opposite error:)

Both approaches combined:

• Conditional features integration based on the commerce coupon version
• Avoiding notices if commerce_coupon_type_features_export_options() is hit regardless the version (not cleared cache after upgrading).

@das-peter I'm not familiar with features_api but does that prevent 2.x from exporting coupon types in #9?

@joelpittet Indeed it basically avoids that commerce coupon 2.x is recognized from features. That's as far as I understand it atm.

tested with coupon 2.x it gets rid of the errormessages on the features page and the incorrect addition of coupon as dependency to new features.
thank you!

@das-peter ok cool just wanted to confirm. I'm not personally featurizing those types so not a problem for me.

Want to see if anybody else needs that feature?

#9 worked well for me too.

#9 is working for me.

Still needs some work. With the patch from #9, the user still has the option of exporting Coupon Types (commerce_coupon_type). If they do, then on feature rebuild they get the following errors:

PHP Fatal error: Class 'CommerceCouponUsageTransactionViewsController' not found in entity/views/entity.views.inc on line 30

Fatal error: Class 'CommerceCouponUsageTransactionViewsController' not found in entity/views/entity.views.inc on line 30

@GuyPaddock #2397073: Add includes/views/commerce_coupon_usage.views.inc to module info fixes your issue, has nothing to do with the current issue.

#9 worked for my needs. Should another issue be made to support exporting 2.x coupons?

Was discussing this in IRC with joelpittet. It seems like we could easily support 1.x and 2.x branches by casting the type to either an array or object as needed, instead of killing off support for once branch.

We lied :D Commerce Coupon 2.x doesn't save types to the database. Only via hook. So we don't need 2.x integration. Putting back to RTBC

Just realized in 2.x you can't create the types through the UI and they aren't saved to the DB so #9 makes perfect sense.

Both are keyed by type and the have a label property just one is an array(2.x) and the other is an object with weight and data properties.(1.x).

RTBC++

Woot! Awesome job all!

Correct issue title.