Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Over at #2215493: Services Entity API + Entity UUID Deploy/UUID compatibility is being discussed. One possible place to fix this is in uuid_services.module. It's a bit hacky, but it works well.
Since services_entity provides custom entity resources at my-endpoint/entity_<entitytype>/* this patch has to be used in conjunction with Services resource aliases to make the resource path match the entity type name which is what Deploy module expects. Resource aliases are entered in the textfields on the resource overview page (admin/structure/services/list/<endpoint>/resources).
Note: I might provide an alternative, more lightweight, solution to services_entity inside uuid_services instead. So there's no guarantee that this patch will get committed.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 2241469-uuid_services-services_entity-compatibility-5.patch | 2.07 KB | dixon_ |
| uuid_services-services_entity-compatibility-1.patch | 5.71 KB | dixon_ | |
Comments
Comment #1
dixon_There might be a better/cleaner solution to this. But the patch attached in OP is a first working iteration at least.
Comment #2
dixon_Comment #3
dixon_Comment #4
joachim CreditAttribution: joachim commented> There might be a better/cleaner solution to this. But the patch attached in OP is a first working iteration at least.
What if we added a property to the resources definition to say what entity type it works with?
Comment #5
dixon_Attached is a much simpler patch that adds optional Services integration for all entities with a UUID key, without the need for Service Entity module. This patch essentially makes that module obsolete.
@joachim I don't think an additional property is needed. In theory it should work with all entities that has UUID support. And in practice it have worked with the entity types I've tested with :)
Moving to @skwashd for a quick review before I commit this.
Comment #6
dixon_Comment #7
jneubert CreditAttribution: jneubert commentedAfter applying the patch at #5, deployment of custom entities worked fine for me. However, when I edited the content on the source system and tried to re-deploy, I got a HTTP error:
The last request the source system tried to execute was a PUT request on a custom entity. Updates on different custom entity types failed, while updates on standard or quasi-standard types (such as user or file_entity) worked smoothly within the same deployment.
The 403 is reported in Apaches access_log. Watchdog on the target system does not report an error.
Comment #8
jneubert CreditAttribution: jneubert commentedThe update operation in my custom entites' access callback were named "edit". After renaming them to "update", everything worked fine.
Comment #10
dixon_I've committed my patch from #5.
Thanks @jneubert for testing and providing feedback!
Comment #12
jimkeller CreditAttribution: jimkeller commentedI believe there's a problem with this patch due to the fact that the following line still exists in entity_get_id_by_uuid in uuid.entity.inc:
it doesn't matter whether you have the checkbox for all entities to use uuid checked; they won't be loaded in the services retrieve method if 'uuid' isn't set to true in the entity info, due to the line above. I was running into an issue where my uuid entities weren't being retrieved, and this was the reason why.
I'm not sure whether we still care about this or not since it should (theoretically) be trivial to ensure that the entities have $entity_info['uuid'] set to non-false, but I think this points to the previous patch being incomplete. Maybe it would be better to iterate over the entity info and explicitly set uuid to true, if the checkbox for "uuid on all entities" is checked?