Profile2 exported via Features yields broken profiles, disappearing fields

Please make sure to use the latest entity api beta release and profile2 release. Exported profile types work well for me with them.

I just updated Crew Connect to work with Profile 2 and Features. I've seen the same behavior @mikl was seeing, but @fago is right... with current versions of Entity and Profile 2, Feature import/exports work well.

-> update entity api :)

I'm getting a similar error, but it only happens when I do a drush forced feature revert. I'm running 1.0-rc1 of Entity API and ctools and profile2 1.2 with 1.0-beta6 of Features.

I checked the db before and after the revert and the field data disappears (i.e. `Select * from field_data_field_profile_MYFIELD` returns an empty set).

Is there documentation somewhere on how to do this?

I am experiencing the same as #6.

We have profile2 profiles set up with a number of fields.

We have exported the profiles as a feature and use this to deploy the profile2 configuration.

Reverting the feature via drush with force
drush fr featurename --force
results in all profile2 field data disappearing.

When prompted:
Do you really want to revert profile2_type?

Answering 'no', keeps the data. Answering 'yes' loses the data.

Drupal 7.12
Profile2: 7.x-1.2
Features: 7.x-1.0-beta6
Entity: 7.x-1.0-rc1

Will post back with more info when I have it.

same problem with :
Drupal 7.12
Profile2: 7.x-1.2
Features: 7.x-1.0-beta6
Entity: 7.x-1.0-rc1

All my profile data disappear when i revert the feature.

Update the entity api to the dev version (or a future 1.0 release), there this problem has been fixed.

ok thank's,
Finally the problem was in migrate_extras, and the patch here : http://drupal.org/node/1471490 (which is now commited in 7.x-2.x-dev) resolv the problem
Sorry, this is for another bug with migrate :)

I try with entity-7.x-1.0-rc1+44-dev but the bug is persistent.
All my profile data disappear when i revert the feature (when i revert profile2_type)

Same here with 7.x-1.0-rc3

and just tried it with entity 7.x-1.0-rc3+2-dev with the same result

I am also having this problem with 7.x-1.2

I create a profile with many fields, then create a feature to capture this. I add profile, then profile2 fields (these are not added by default). When I save then enable the feature, the profile itself is deleted from the site, yet the feature retains it's 'default' status.

Because using the profile2 features implementation potentially leads to loss of data on a site (see #16), I propose that this issue should be marked as 'critical'

Is this issue still active ? I know the "system" closes things automatically but after looking at the issue queue for Profile2, organizing it by critical issues first, this is up there and it's been a little while.

I know some things being done by this module would be considered unorthodox for the drupal 7 line of thinking, and this issue is largely going to determine our investment in using the module. Does anyone have any success importing or exporting From/To Profile2->Profile2 ?

Are there any leads as to where in the code things are going sour ? I'm willing to devote some time to fix this and gain more understanding but this appears to have stalled shortly after the issue was raised. Please advise!

Thanks for everyone's time,
Ryan

I'm not 100% but I'm pretty sure this is fixed.

Hello,

can anyone export profiles? for me this did not work! Any solution?

Best regards
Frank

I've reproduced the more recent bug where reverting a Profile that was exported with Features causes it to disappear. This may or may not have anything to do with the original bug report that was fixed when Entity was updated.

The simple work-around is to disable and re-enable the feature, so I don't think this is rightfully marked "critical" anymore.

Then the only on-going problem is that on 'admin/structure/profiles', the Status column for the profile always shows "Default," even if it has been overridden; prior to the re-enabling, it always showed as "Overridden", even after a revert via the Features UI. An accurate status is only shown on 'admin/structure/features'. (or via `drush features-diff`).

This did not work for me with a profile feature - disabling and then enabling the feature lost all data.

I'm also seeing profile2 field data loss when disabling a feature that defines profile2 profiles.

This site is a D7 site that I did a D6 to D7 migration on in May 2012. I used features to install 3 profile types and a bunch of fields on the new D7 site. In the time since the migration, the feature I used for profile2 hasn't been disabled. I disabled it this past Sunday while applying a security update and just realized today that field data (and field configuration) for 2 of the 3 profile types is gone from the database. One of the profile types and field data appears to be intact. The site is current on all modules:

Entity API (entity) 7.x-1.0
Profile2 (profile2) 7.x-1.3
Features (features) 7.x-1.0
Chaos tools (ctools) 7.x-1.2

I've now tested this several times on a local server and a snapshot database from the live server. The act of disabling the feature that defines profile2 profile types and fields kills 2 out of 3 profile types, all associated fields & field data. By the time you try to re-enable the feature, it's too late. The data is gone.

Because there is the potential for data loss, I've assigned a status of critical. If anyone needs more details or info, I am happy to provide.

I'm puzzling over how best to restore the lost data. Maybe use the Migrate module again to migrate the data from a database backup? If anybody has any good ideas about how to restore profile2 data from a backup, I'm interested :-) I'd go ahead and restore the whole db from the Feb 3 backup, but it's a fairly busy site, so there's already been enough changes to make that kinda painful.

I am seeing this issue on a new site we are building (currently in heavy development). We are using:

Profile2 7.x-1.3
Features 7.x-2.0-beta2

Everything seemed fine until recently (we did upgrade Features recently but not sure about Profile2... I'll need to check the git log).

Previous behavior allowed us to:

1) developer1 added profile2 fields to feature module

2) check into git

3) developer2 and developer3 updates from git and does features revert on the module and profile2 fields show up

Then, developer3 added some more fields to the feature module. These new fields were not seen by the other developers (they are in the feature module code). When debugging, developer2 disabled the feature module and reenabled and then ALL profile2 fields disappeared :/

Not sure how to proceed. I might try using older versions of the modules (assuming there were no database changes).

[UPDATE] Updated entity to 2013-03-26 of dev version with no luck.

Maybe this will help shed some light on the bug and someone can figure out how to fix:

See #24 for my details.

I just did the following:

1) Manually added a field to my Profile2 profile (the one that had no fields because they all got wiped out when disabling/enabling the features module with the Profile2 fields in them)

2) Magically, all the FIELDSETS in the Profile2 profile showed up, but NOT the FIELDS

Don't have a clue, but perhaps someone who knows the code will understand what is the distinction on how FIELDSETS are different than FIELDS when using exportables and Features.

[UPDATE] Once the field is deleted, the FIELDSETS disappear again.

Fieldsets = field_group.

The separation of field bases vs field instances in Features 2.0-beta2 has been quite problematic, starting with #1966062: Updating from older version to beta2 doesn't auto-select fields.

I have found a fix for my case (assuming it "sticks"). It is unclear how, but the profile2 fields in the features module .info field ended up marked as "_exclude" like:

features_exclude[field][profile2-userprofile-field_userprofile_interest] = profile2-userprofile-field_userprofile_interest

As a test, I changed *one* of them in the .info to get rid of the "_exclude" part like:

features[field][profile2-userprofile-field_userprofile_interest] = profile2-userprofile-field_userprofile_interest

After this, ALL OF THE PROFILE2 FIELDS SHOWED BACK UP!

Again, I don't know how they ended up being marked with "_exclude" but at least I can see the fields again. If we find that this is reproducible, then I'll add steps for reproducing.

So... a question to those who said that they lost DATA in this process... did you check the database to see if the field tables are actually missing?

Kristen: It sounds like your problem is more of a common problem with Features' latest confusion over what should be included in a specific feature rather than anything specifically tied to Profile2 - I've had this problem too with basic content types when upgrading to 2.0-beta2.

Damien - Yep... I talked with another developer and they were experiencing similar problems with the "features_exclude" sneaking into their .info files (they are *not* using Profile2). Yet, I don't see an issue in the Features issue queue with this... ??? I don't know how these "features_exclude" are getting in there. Very weird. I assume it just happened to be a coincidence that I saw the issue on Profile2 profiles and found this issue (which sounded similar). I'm wondering if the people who commented on this issue were actually seeing this same "features_exclude" weirdness or it is something else entirely.

@Kristen: Most of the bug reports are from Features v1, the features_exclude option was only added to v2.

Damien - Yes, you are right. I added this issue to Features: #1978288: Features module .info file has "features_exclude" items vs "features" items for no apparent reason (fields can go "missing")

Hmm... I'm seeing this again but this time the field is not listed as a features_exclude item. I really don't want to disable/enable the features module as we have content in there now and I don't want to have to recreate.

Any other ideas for getting the field to show up?

[UPDATE] Nevermind. The field was in the base but not the instance due to some renaming that happened.

Just chiming in to add that while I don't know what the exact fix was I was seeing this problem as well with Features 1.x, Entity API and Profile2. Updating Entity API to 7.x-1.2 and Profile2 to the latest -dev release fixe the problem of data loss as a result of using a --force when reverting features.

Add the functions to profile2.module
(now, add the reset cache code for get types)

function profile2_features_api_alter(&$components) {
  $component = &$components['profile2_type'];
  $component['base'] = 'profile2_type';
}

/*
function profile2_form_profile2_type_form_alter(&$form, &$form_state) {
  $type = $form['type']['#default_value'];

  if ('' === $type) {
    return;
  }

  $item = profile2_type_load($type);
  $form['data']['roles']['#default_value'] = empty($item->data['roles']) ? array() : $item->data['roles'];
}
*/

function profile2_type_features_export($data, &$export, $module_name) {
  return entity_features_export($data, $export, $module_name, 'profile2_type');
}

function profile2_type_features_export_options($a1, $a2 = NULL) {
  return entity_features_export_options($a1, $a2);
}

function profile2_type_features_export_render($module, $data, $export = NULL) {
  return entity_features_export_render($module, $data, $export, 'profile2_type');
}

function profile2_type_features_revert($module) {
  profile2_type_features_rebuild($module, 'profile2_type');
}


function profile2_type_features_rebuild($module) {
  $callback = $module . '_'. features_get_components('profile2_type', 'default_hook');

  if (false == is_callable($callback)) {
    return;
  }

  $items = $callback();

  if ((false == is_array($items)) || empty($items)) {
    return;
  }

  entity_get_controller('profile2_type')->resetCache();
  $types = profile2_get_types();

  foreach ($items as $index => $item) {
    if (isset($types[$index])) {
      $merge = get_object_vars($item) + get_object_vars($types[$index]);
      $merge['is_new'] = empty($merge['id']);
      $item = new ProfileType($merge);
    }

    profile2_type_save($item);
  }

}

The observation in #33 also applies for me.
Unfortunately, the field data is gone now, after the temporary disappearance of the fields. (This was a dev site, so it no production data is lost)
Maybe defining the version dependency in the profile2.info file would help.

I just encountered something similar and this seems to correct place to post my findings.

After scanning this thread I think there are two distinct issues people are having:
1. They lose their fields, so for example they cannot see them on Manage Fields
2. They lose the field data, so the fields still show on Manage Fields, but editing a Profile2 entity on a user reveals the field values have been lost.

The first problem is probably due to needing to run cron, possibly multiple times, and then also making sure caches are cleared.

The second problem is more difficult to solve. If you have a feature module that contains a profile type (not necessarily the fields) then after a feature revert the profile type entity is deleted and then inserted again, and any fields that existed are deleted and recreated again, this goes for the corresponding records in field_config and field_config_instance, and also the actual field_data_ and field_revision_ tables.

The problem is the field values are not created again, and the conceptual reason for this is that the profile entity belonging to the user (which holds the field values) has not been deleted, only the profile type definition record.

The comments in features.node.inc pretty much explain the problem we are facing:
function node_features_revert($module = NULL) {
if ($default_types = features_get_default('node', $module)) {
foreach ($default_types as $type_name => $type_info) {
// Delete node types
// We don't use node_type_delete() because we do not actually
// want to delete the node type (and invoke hook_node_type()).
// This can lead to bad consequences like CCK deleting field
// storage in the DB.
db_delete('node_type')
->condition('type', $type_name)
->execute();
}
node_types_rebuild();
menu_rebuild();
}
}

The issue being that for profile2_type entities we don't have a dedicated hook implementation and so features revert back to using the delete method in the EntityAPIControllerExportable class. Under certain conditions, when the entity status has gotten a little out of sync, this method triggers the deletion of all fields attached to a profile2_type entity.

FYI this still happens and I was able to trigger this on my dev environment (thankfully just that) I am very paranoid now about the production environment, if this happened it would be a disaster and I have been pushing configs with features.

Should we be turning #34 into a patch? Also this seems very similar to https://www.drupal.org/project/registration/issues/2910305