entity type controllers should handle machine name changes that affect entities

I'm able to reproduce this.

(BTW: don't add tags that aren't in the issue guidelines -- thanks!)

profile2_category_access() gets called with 'main'.

I think the source of the problem is that changing a machine name does not update existing profile objects.

There's maybe already an issue for this though?

There doesn't seem to be an existing issue. Moving this to the Entity API project.

I reckon this should be handled at the entity level, so saving an entity that has a machine name updates other entities that rely on it.

I'm not sure about whether to add this to EntityAPIControllerExportable, which is the controller class profile types use -- it feels like overloading it as the name is specific about what it's doing.

How node module handles this:

- node_type_save() reacts to a change in machine name - http://api.drupal.org/api/drupal/modules--node--node.module/function/nod...

    if (!empty($type->old_type) && $type->old_type != $type->type) {
      field_attach_rename_bundle('node', $type->old_type, $type->type);
    }
    module_invoke_all('node_type_update', $type);

- field_attach_rename_bundle() deals with all the FieldAPI stuff - http://api.drupal.org/api/drupal/modules--field--field.attach.inc/functi...
- node_node_type_update() changes the entries in the node table - http://api.drupal.org/api/drupal/modules--node--content_types.inc/functi...

field_attach_rename_bundle() is properly invoked by the entity api, so I think this is fine.

After changing the default machine name from "main" to "profile", I receive the following Notice on all /user/ pages.

I was able to reproduce a notice in profile2-pages when changing machine-names. I fixed that.

- node_node_type_update() changes the entries in the node table

Oh, yes we are missing that in profile2. I don't think the entity API should handle that as it depends upon the entity-type whether this name-changes are allowed at all or what should happen with the data. Also I dislike automatically wrangling with potentially huge amounts of data in the entity api.

Oh, then I guess we also need to issue a menu_rebuild() from profile2.module in case of name-changes and if $type->userCategory is TRUE, such I've just added it profile2 pages. We should have the same problem there: menu items need to be updated.

I'd like to move this issue back to profile2, however somehow I'm unable to do so. It doesn't allow me to select this project. So just setting it to entity-api won't fix for now.

Moving back to Profile2.

> I don't think the entity API should handle that as it depends upon the entity-type whether this name-changes are allowed at all or what should happen with the data. Also I dislike automatically wrangling with potentially huge amounts of data in the entity api.

That's a problem core has to solve with node type changes. For node deletion at least, queueAPI is being considered: #89181: Use queue API for node and comment, user, node multiple deletes. But I don't know what that does to the system while you're waiting for the queue to run and things are broken!

I think there's a case for EntityAPI providing a basic system for just changing the type strings, and presumably a way in the entity info to specify how this is handled.

But this can be fixed in Profile2 first and then abstracted down a layer to EntityAPI afterwards.

Oh, then I guess we also need to issue a menu_rebuild() from profile2.module in case of name-changes and if $type->userCategory is TRUE, such I've just added it profile2 pages. We should have the same problem there: menu items need to be updated.

I've done so and fixed it to just issue always a menu-rebuild if a profile type is changed.