We ran into an interested situation over in #1795032: No Longer Require Mediafield in Panopoly Widgets. I'm not sure if this is more widespread, or confined to our specific usage.
The situation is this. We wrote an update to migrate data from a media field to a file field with a media widget. Outside of panels the update works fine. When viewing an entity directly or editing it via the administrative backend things work exactly as expected. The only issue occurs when viewing or creating the fieldable panel pane through the IPE. Additionally, it only occurs when the pane has a subtype in the form of "uuid:xxx" rather than "fpid:xxx". The specific error is a fatal exception thrown by entity_extract_ids, which happens because a uuid is getting passed to file_load, returning an empty file object.
There's definitely something strange going on here, and I'm not sure how far reaching it is. However, this patch prevents us from bumping into the issue. I'm quite happy to supply any additional details needed if you have any thought about what could be the root cause for this.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 1818132-uuid-not-universal.patch | 757 bytes | beeradb |
| #1 | 1818132-prevent-uuids.patch | 806 bytes | beeradb |
Comments
Comment #1
beeradb commentedComment #2
sylus commentedI was initially thinking this patch could be the culprit that we applied to FPP but it looks ok.
#1536944 http://drupal.org/files/Fieldable_Panels_Pane-translatable_panes-1536944...
Have run into this a few times but patch does fix :)
Comment #3
merlinofchaos commentedUnfortunately, this patch would more or less remove uuid support.
The intent of the code that's being removed is that, if uuids are available, we identify the panes by uuid rather than fpid so that when exported and the entities are transferred with something like deploy.module, the references are still correct even though the actual fpid's may well have changed. That makes this actual patch a complete non-starter.
We'll need to figure out why things are actually breaking during the load, I suppose.
Comment #4
populist commentedI did some more digging and the problem here is with the entity_make_entity_universal() call from entity_uuid_load() that invokes a few steps and eventually hits file_field_uuid_load() and converts the FID values to UUID values which breaks media module's handling of that field.
Comment #5
beeradb commentedHere's a retry. After looking at what @populist said in #4 and digging a bit more, it turns out we can short circuit this and avoid the uuid_make_entity_universal call, which is what converts the fid to the uuid and ultimately leads to a fatal error in the entity_extract_ids() function.
The patch ends up being fairly straightforward, instead of calling entity_uuid_load directly we just have uuid.module look up the entity id for us, and call entity_load on it directly. I can't see any downside to doing this, as I can't think of any reason you would actually want the files or user information attached to the entity to have uuids.
I am at BADCamp, Earl. If you have any reservations or are interested in discussing the issue feel free to grab me in the hallways.
Comment #6
beeradb commentedre-title to keep in line with the change in direction here.
Comment #7
merlinofchaos commentedThis approach should be fine. It kind of hilights, however, that uuid.module should probably consider entity_uuid_load to be buggy.
Comment #8
populist commentedThis also looks fine to me and is working well enough. I agree with #7 that there is some structure bugs with entity_uuid_load and how that whole approach integrates with Drupal, but in the case of FPP this change is conditional (i.e. only happens when you have UUID in the first place) so we should be good.
Comment #9
merlinofchaos commentedCommitted and pushed.