UUID does not support translating the local IDs of entities embedded in filtered text fields. E.g., files embedded via the Media module, nodes embedded via node_embed, etc.
The UUID Link module provides a method for linking to content, but it does not replicate the functionality of Media module and other projects that embed content in filtered text fields.
To facilitate the deployment of filtered text fields with embedded entity tokens, I propose implementing hook_field_uuid_load() and hook_field_uuid_presave() for the core "text" field module in uuid.core.inc
. i.e.,
text_field_uuid_load($entity_type, $entity, $field, $instance, $langcode, &$items)
text_field_uuid_presave($entity_type, $entity, $field, $instance, $langcode, &$items)
On their own, these hook implementations can not translate the embedded local entity IDs, because they don't know enough about the filtered text tokens of the projects that created them. Therefore, I propose two new hooks to allow projects to translate their embedded entity tokens from local ID to UUID. e.g.,
hook_filtered_text_uuid_load_alter(&$text)
hook_filtered_text_uuid_presave_alter(&$text)
If this approach and the following pseudo-code looks reasonable to the community/maintainers, I'll move forward with a patch.
PRE-DEPLOY: Replace filtered texts' entity token local IDs with UUIDs.
text_field_uuid_load($entity_type, $entity, $field, $instance, $langcode, &$items)
if instance is filtered text,
then foreach $items
drupal_alter "hook_filtered_text_uuid_load_alter(&$text)"
hook implementation by input filter modules (media, node_embed, custom, etc.):
- regex to find their token in $text
- filter-specific logic to parse local ID from token
- lookup UUID from local ID
- make new token with UUID instead of local ID
- str_replace old token with new token
POST-DEPLOY: Replace filtered texts' entity token UUIDs with local IDs.
text_field_uuid_presave($entity_type, $entity, $field, $instance, $langcode, &$items)
if instance is filtered text,
then foreach $items
drupal_alter "hook_filtered_text_uuid_presave_alter(&$text)"
hook implementation by input filter modules (media, node_embed, custom, etc.):
- regex to find their token in $text
- filter-specific logic to parse local ID from token
- lookup local ID from UUID
- make new token with local ID instead of UUID
- str_replace old token with new token
Comment | File | Size | Author |
---|---|---|---|
#8 | uuid-text-field-tokens-2137783-8.patch | 3.25 KB | hawkeye.twolf |
Comments
Comment #1
hawkeye.twolfComment #2
hawkeye.twolfComment #3
dixon_This is very interesting and something I'd be willing to commit.
Do you mean that the
text
implementation would firehook_filtered_text_uuid_load_alter()
insidetext_field_uuid_load()
andhook_filtered_text_uuid_presave_alter
insidetext_field_uuid_load()
?That sounds reasonable to me. Do I understand you correct if the use case for this is that ones custom project then can implement these and translate stuff embedded in the text?
I think though that the hook name should be
hook_text_field_uuid_load/presave()
since it's coming from the text field module.Comment #4
hawkeye.twolfHiya, dixon! Yes, that's it exactly:
text_field_uuid_load()
and_presave()
will call the new hooks to let each implementing module (media, node_embed, custom, etc.) modify the filtered text as needed.Good idea on the hook name;
hook_text_field_uuid_load_alter()
and_presave_alter()
is a better choice.I have some client work depending on this, so I'll probably have a patch for review by the end of the week.
Comment #5
skwashd CreditAttribution: skwashd commentedI've already commented on #2137811: Add support for core field module "text". We solved this problem with the embed_asset_field module.
Comment #6
hawkeye.twolfHiya, skwashd! Wow, I had no idea about embed_assets_field. Thanks for pointing it out!
I think I mostly understand how it works, but I have two questions about it:
I'm wondering if my proposed solution would still be a good contribution to UUID and Entity Dependency modules as a somewhat simpler method for handling the issue. The benefits I see are:
Since you've obviously dived into this problem before, do you see any inherent flaws in my solution?
Thanks, I appreciate your feedback!
Comment #7
hawkeye.twolfAdded related issue from the Media module.
Comment #8
hawkeye.twolfPatch attached. Please see related patches in:
Comment #9
hawkeye.twolfComment #10
hawkeye.twolf*bump* Does anyone have some time to review this work? It's work out very elegantly for me and will be in the wild soon.
Comment #11
skwashd CreditAttribution: skwashd at Dave Hall Consulting for Dave Hall Consulting commented@derek.deraps,
Overall this looks good. I like that it is configurable. We need to alter the field configuration form to include the option. I think that
$instance['settings']['text_processing']
should be 'uuid_text_processing' to indicate where it comes from. We should also make it clear in the help text that this needs to enabled on both sides.Comment #12
hawkeye.twolfIs there any momentum behind and/or need for this approach? If other folks dig it / want it, I'm happy to fix up the patch as @skwashd asked. Otherwise, I think we can just put this issue to bed ;)