Microdata must be added explicitly to Features on update

I've just installed 1.0-beta1 for the first time and spotted this as a bug, so doesn't look like it's been fixed. I'll see if I can identify the problem.

Ah, my mistake. The problem was that I hadn't specifically added the microdata mappings to my feature.

i.e. on the recreate feature screen it listed my content type ("product"), but there wasn't a microdata section. I resolved the problem by choosing Microdata: microdata_mappings under edit components and selecting Node: Product.

This doesn't seem very obvious though. Is there a need for this to be a separate exportable, rather than just being settings on the content type? At best this configuration means I'll need to recreate all my features as I add microdata to them (rather than just doing a drush features-update), at worst I'll add some microdata in dev and it won't get deployed to live.

If there is a need for it to be separate, then I think it needs to be documented somewhere obvious that you need to export the microdata separately. The only suitable place I can think of though is the content type edit screens, but that would show to people who don't use features (either not installed or not a developer), so isn't ideal.

In summary the bug was already fixed, but I'll leave this open for Lin to have her 2c and possibly open a new issue to improve the usability.

Ignoring the usability question of #6, there does still seem to be a bug here, which is that Features are now no longer reverting correctly because of the earlier commit on this issue.

The default_hook specified in microdata_features_api() must match the array key that is returned by microdata_mappings_features_export_render(), otherwise when the feature is reverted the hook won't be found and nothing will be changed.

I don't think it matters very much whether that hook is called "microdata_mappings_defaults" or "microdata_mappings", but what does matter is what we do for people who have different data in the db vs the Feature (if they're not paying attention). Using microdata_mappings_defaults would be existing Features would overwrite the database, using microdata_mappings would mean existing database values would overwrite the Feature.

I think we should overwrite the Feature with what's in the database, since that will change what people have in their repository, rather than what's happening on their live site. I think it's also more likely that people will notice the change when committing, rather than when reverting features (especially if their release process has a "revert all features" step).

Here's a patch that does that.

This will need to be mentioned in the release notes, I suggest:

"This fixes a bug that was preventing microdata_mappings exported to Features modules from being reverted. After upgrading, if you want to keep the microdata_mappings you have in your database, then update your Features modules and these will be exported. If you want to use the microdata_mappings from your Feature, then rename FEATURE_microdata_mappings_default() in FEATURE.features.inc to FEATURE_microdata_mappings() and revert your Feature."

Duplicate of https://drupal.org/node/2092365

Given that features aren't exporting properly at the moment anyway, I don't think we need to worry too much about people with existing features (I was running with the first patch on that issue applied, so had been able to export features).