Features export doesn't work correctly

The dumps you posted are valid profiles, but it looks to me like the feature wasn't updated at all.

Your scenario A is missing the 'add_to_summaries' and 'default_toolbar_grouping' keys introduced a while ago in Wysiwyg 7.x-2.x-dev (the only version supporting CKEditor 4), suggesting it's from Wysiwyg 7.x-2.2.

Those keys are present in the second scenario, with the exception of the footnotes plugin (likely because it wasn't detected).

Do you have the feature code itself, as it was created from the original site after the profile was saved (to apply profile changes) and 'drush features-update' was run?

I just created a new feature, noted its state was "default" after being enabled, modified the profile, state changed to "overridden", recreated the feature, state changed to "default".

I didn't have a second site to test with, and I recreated the feature using the Features UI instead of Drush, but the result should be the same since Wysiwyg won't know the difference.

+1 for having issues with features exports from wysiwyg.
Digging quite deep, I am prone to propose an update in either wysiwyg_features_revert() or wysiwyg_features_rebuild() hooks, which are responsible for applying the exported configurations to the target staging/prod environments.

Reasoning
- wysiwyg utilizes features hooks to export *.features.wysiwyg.inc file. Exported profile is (object)
- wysiwyg_features_revert() is directly calling wysiwyg_features_rebuild(). Both hooks are used to apply (object) to database. These are features module hooks, which are not alterable by other modules.
- wysiwyg_features_rebuild() is assuming that $profile is an array, not an (object). Thus, rebuild and revert on target instance can never happen.

I tried:
- finding alter hooks on hook_features_revert() and hook_features_rebuild(), didn't find any. I cannot intercept in between to turn the $profile into array.
- re-export via different methods to do the stupidity test. Both drush and browser are using came way to export $profile.

My idea about a quick-fix is the casting just before the query at wysiwyg_features_rebuild(). I believe it relates to the issue as the rebuild and revert features are in the base of the configurations migration.

I forgot to mention I also reverted and had the feature rebuilt. Everything works well in my tests.

@kalinchernev, Wysiwyg profiles are not exported as objects. I'm not sure how you arrived to that result.

Here is a sample created with Features 2.x and the current Wysiwyg 7.x-2.x (code in wysiwyg.features.inc is identical to 7.x-2.2):

/**
 * @file
 * foo.features.wysiwyg.inc
 */

/**
 * Implements hook_wysiwyg_default_profiles().
 */
function foo_wysiwyg_default_profiles() {
  $profiles = array();

  // Exported profile: cke
  $profiles['cke'] = array(
    'format' => 'cke',
    'editor' => 'ckeditor',
    'settings' => array(
      'default' => 1,
      'user_choose' => 0,
      'show_toggle' => 1,
      'add_to_summaries' => 1,
      'theme' => '',
      'language' => 'en',
      'ss' => 2,
      'buttons' => array(
        'default' => array(
          'Bold' => 1,
          'Italic' => 1,
          'Underline' => 1,
          'Strike' => 1,
          'JustifyLeft' => 1,
          'JustifyCenter' => 1,
          'JustifyRight' => 1,
          'JustifyBlock' => 1,
          'BidiLtr' => 1,
          'BidiRtl' => 1,
          'BulletedList' => 1,
        ),
      ),
      'toolbarLocation' => 'top',
      'resize_enabled' => 1,
      'default_toolbar_grouping' => 0,
      'simple_source_formatting' => 0,
      'acf_mode' => 0,
      'acf_allowed_content' => '',
      'css_setting' => 'theme',
      'css_path' => '',
      'stylesSet' => '',
      'block_formats' => 'p,address,pre,h2,h3,h4,h5,h6,div',
      'advanced__active_tab' => 'edit-security',
      'forcePasteAsPlainText' => 0,
    ),
    'rdf_mapping' => array(),
  );

  return $profiles;
}

(This may also expect a foo.features.filter.inc file with the corresponding filter.)

Start with the profile in the same state as the exported on-file profile.

Test 1, reverts:

1. The feature is now 'Default'.
2. Disable the button 'Bold' in the profile UI.
3. The feature is now 'Overridden'.
4. Revert the feature.
5. The 'Bold' button is enabled again'.

This calls wysiwyg_features_revert() and then wysiwyg_features_rebuild(). The $profile variable is an array as it's read directly from the file. (Tested using Devel's dd().)

Wysiwyg implements 'faux-exportables' as it always needs database entries for profiles and can't use the on-file versions directly.
'Faux-exportables' use hook_features_rebuild() to be told when the on-file data has changed so the DB entries can be updated.

Test 2, restores:

1. The feature is now 'Default'.
2. The 'Strike' button is enabled in the profile UI.
3. Comment/remove the 'Strike' => 1, line in foo.features.wysiwyg.inc.
4. Look at the profile UI again (update the page), 'Strike' is still enabled.
5. Visit the Features overview. It will say 'Checking' and then 'Default' after a short delay.
6. Look at the profile UI again, 'Strike' is now disabled, without manual changes to the profile.

The act of visiting the Features overview page triggers Features to call hook_features_rebuild() directly, if the on-file data has changed compared to the cached version, and it's not 'Overridden'. (Clearing the cache has the same effect if enabled in Features.)
Again, the $profile variable is an array because it gets the value from the exported file.

Similar to the above comment in #7, I've experienced the following:

• I create a wysiwyg profile and export it to a Feature.
• I make a change through the UI to override the Feature.
• I do a cache clear
• Boom - the Feature is reverted and the changes made through the UI are gone.

This was with Features 2 and Wysiwyg 7.x-2.x-dev

@anthonylindsay, that should not happen. Features should not auto-revert unless you have some other module which does it for you. I've seen some sites do it as they control every single change via code pushes (they often don't even have the UI modules enabled) so in case something did change any configuration

Features does auto-rebuild non-overridden features if the exported file has changed on cache-clear, if the setting to do that is enabled. Compared to the above use case, this would happen when devs do push up new features code and does a cache clear, so the changes get applied even if they forget to manually revert changes after the code update. This would theoretically work if you don't have the UI enabled (unless it isn't actually implemented in the Features UI module), only have FTP-access to your server, and could not use drush to revert features after uploading new code.

Either case, Wysiwyg itself does not control when a revert or rebuild happens, it just acts as ordered.

I'm seeing the same behaviour described in #5.

The problem is this cast:

  $profiles['block_html'] = (object) array(

Removing it manually makes the problem go away.

Features version: 7.x-2.9
Wysiwyg version: 7.x-2.2

This is what I obtain after using the Features UI to create a feature.

<?php
/**
 * @file
 * some_random_feature_export.features.wysiwyg.inc
 */

/**
 * Implements hook_wysiwyg_default_profiles().
 */
function some_random_feature_export_wysiwyg_default_profiles() {
  $profiles = array();

  // Exported profile: block_html
  $profiles['block_html'] = (object) array(
    'format' => 'block_html',
    'editor' => 'ckeditor',
    'settings' => array(
      'default' => 1,
      'user_choose' => 0,
      'show_toggle' => 1,
      'theme' => 'advanced',
      'language' => 'en',
      'buttons' => array(
        'default' => array(
          'Bold' => 1,
          'BulletedList' => 1,
          'NumberedList' => 1,
          'Link' => 1,
          'Unlink' => 1,
          'Anchor' => 1,
          'Cut' => 1,
          'Copy' => 1,
          'Paste' => 1,
        ),
      ),
      'toolbar_loc' => 'top',
      'toolbar_align' => 'left',
      'path_loc' => 'bottom',
      'resizing' => 1,
      'verify_html' => 1,
      'preformatted' => 0,
      'convert_fonts_to_spans' => 1,
      'remove_linebreaks' => 1,
      'apply_source_formatting' => 0,
      'paste_auto_cleanup_on_paste' => 0,
      'block_formats' => 'p,address,pre,h2,h3,h4,h5,h6,div',
      'css_setting' => 'theme',
      'css_path' => '',
      'css_classes' => '',
    ),
    'rdf_mapping' => array(),
  );

  return $profiles;
}

First stab at a patch to fix this.

I can not reproduce this in the current 7.x-2.x-dev branch. A couple of features related fixes have been committed which I hope should fix this as well.

In my tests so far there has been no need for the explicit array cast. Profiles are exported as arrays and loaded as arrays with Features 7.x-2.10. There is no cast to an object as seen in the sample from #10.

Can anyone still reproduce this? If not, I'll assume it's been fixed.

The problem seems to originate from this patch, as mentioned on the comment after that one.

Ok, so once that patch gets into Features we would have a problem in Wysiwyg, which the patches here attempt to fix. That explains why I couldn't reproduce it. Thank you @HLopes.

Will see if I can verify this ASAP.

This does look like a useful precaution in case that patch is being used (or Features ever commits it), so I have added it to 7.x-2.x.

Thank you all!