features_var_export is converting custom class objects to arrays if don't have export method

This patch isn't working for me when I try to export uc_quote_store_default_address via strongarm.

Here's a reroll to apply to the latest 7.x-1.x codebase (also borrowing some of the code comment from #1437262: \Drupal\Component\Utility\Variable::export on object of custom class but no __set_state method creates unusuable export (fatals) ).

The only problem I have with this is it ends up causing a lot of existing features to get marked as "overridden". Looks like exports are just in a different order in most cases. But I'd like to have more eyes review this before committing it.

In #1865058: Variable appears to be saving objects from {variable} as arrays, which breaks language_default we also stumbled on this problem with the language_default variable (which a stdclass object).

Without the patch it's just exported as an array, which causes problems when the feature is rebuilt. With the patch in #3, the variable code is exported as (object) array(...) and rebuilding works again.

Tentatively marking as RTBC... It would be great to see this make it's way into the code base!

I don't see any new patch addressing the issues from #4 and #5 so this is certainly not RTBC until those get handled.

I ran into the same problem with language_default not being imported properly (as an array, rather than an object).

The patch in #3 works fine for me, and actually solves the issue that my 'realm variables' show as overwritten. So #4 is actually reversed, in my case.

I am having this issue with variables 7.x-2.4.

Using "Variable translation" to have a multilingual slogan, and using Features to export the slogan, the language_default is saved as an array, instead of an object.

I need to do the following in a hook_update:

  features_revert(array('tremblant_feature_variables' => array('variable_realm','variables')));
  // Must type cast right after reverting the feature.
  if (!is_object(language_default())) {
    variable_set('language_default', (object) language_default());
  }

Where is the code responsible for generating the feature file ending with “.variable.inc”?

Using "Variable translation" to have a multilingual slogan, and using Features to export the slogan, the language_default is saved as an array, instead of an object.

I just stumbled on this problem again as well.

Bumping version as it should be fixed in 2.x first (right?); probably needs a re-roll.

Here's a reroll against the 2.x branch.

The issue mentioned in #4 with a lot of existing features getting marked overriden still persists, as it affects at least taxonomy vocabularies, filters, languages, role definitions, menus, and also variables of a couple of contrib modules (metatag, wysiwyg and tmgmt in my case).

As far as the language_default variable goes, I would probably want the feature to get marked overwritten (to indicate that it needs to be updated), but I'm not sure about the other cases. Therefore leaving as "needs work".

The patch in #11 was not working for us in version 7.x-2.2. Attached a patch for that version.

Hmmm... I didn't sanitize the diff file generated by Git. Attached a clean version of the patch for 7.x-2.2.

We have used the patch from #11 (with a slight change, see #12/#13) to solve the issue for language_default. Now we are further in our project and we ran into issues like the one mentioned in #5. Both Wysiwyg and Metatag expect information that is normally in an object to be in the features as an array. With the patch this information is stored in the features as objects, causing errors on feature revert.

We'll have to look into this issue much deeper to find a generic solution.

EDIT
For now we have solved this by unpatching Features and implementing hook_post_features_revert() in the .module file of the feature that contains the language_default variable. Example:

/**
 * Implements hook_post_features_revert().
 */
function my_module_post_features_revert($component) {
  if ($component == 'variable_realm') {
    // Set global default language as object.
    $language_default = variable_get('language_default', array());
    variable_set('language_default', (object) $language_default);

    // Clear caches.
    cache_clear_all();
  }
}

Thanks for your temp solution ricovandevin in #14.
It helped a lot in solving my issue.

+1 to ricovandevin's fix in #14 - this also fixed it for me, so thank you :)

I'm not seeing any new patch to review here that addresses #14. Also would need to know if this problem still occurs in 7.x-2.10 since there were changes in the past couple updates to this recursive export procedure.

@mpotter i can confirm it still occurs. Went with a fix in the other module though that changed them to arrays. Had to re save each view, for that to work but it did.

This would be nice to let contrib save the results as object too

OK, and it seems the issues in #4 and #5 are still not addressed, so leaving this as "needs work". Honestly don't see a lot of hope getting something this major changed at this late point of development, especially since this kind of thing isn't needed in D8 where we have proper yml files for export.