Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
I'm using the Deploy module along with UUID to export entities into features. I've found out that entities are exported with their translations, which is great. However, when I wanted to reimport them, I found out that the import did not work. I therefore created a patch which fixes it, and removes some fields from the export.
Comment | File | Size | Author |
---|---|---|---|
#22 | entity_translation-1701212.patch | 1.28 KB | jonhattan |
#18 | entity_translation-1701212.patch | 1.29 KB | jonhattan |
#12 | 1701212-export_uuid-12.patch | 1.47 KB | guillaumev |
#10 | 1701212-export_uuid-10.patch | 1.48 KB | guillaumev |
#4 | 1701212-export_uuid-4.patch | 1.36 KB | guillaumev |
Comments
Comment #1
guillaumev CreditAttribution: guillaumev commentedHere is the patch...
Comment #2
guillaumev CreditAttribution: guillaumev commentedNew patch, which also removes uid from the list of exported fields.
Comment #3
plachWhy do we need to remove all those keys?
Here and below: use the entity translation handler to retrieve translations as they might not always be stored in the
translations
key.Comment #4
guillaumev CreditAttribution: guillaumev commentedThanks for the review :-)
Concerning the keys:
Concerning the use of the entity translation handler, here is a new patch that uses it.
Comment #5
guillaumev CreditAttribution: guillaumev commentedComment #6
plachThanks for the explanation, actually removing 'created' and 'changed' looked a bit odd to me. They concern creating/changing the translation, not the main entity so I guess it would be useful to keep them. Not a key point however.
Not sure why, but in the export hook we are using the translation handler while in the presave one we are using the entity keys directly. For consistency we should be using the translation handler in both places, moreover subclasses might change its default behavior and not rely on the entity keys. I know it's unlikely, but better safe than sorry :)
Comment #7
plachComment #8
guillaumev CreditAttribution: guillaumev commentedThanks for your follow up, but how can I use the translation handler to cast the "translations" array into an object ? I couldn't find this possibility in the translation handler, that's why I used the entity key directly...
Comment #9
plachWhy do you need that cast? The
$translations
data structure should already be an object. If this is absolutely needed let's go with this approach, but it looks weird to me. At very least we should add a comment explaining what's going on.Comment #10
guillaumev CreditAttribution: guillaumev commenteduuid exports entities as arrays. Here is an excerpt from the uuid export code:
The translations object therefore becomes an array in the feature, that's why I need to cast it into an object before it is saved with uuid, otherwise there is an error.
Attached is a new patch which adds a comment to explain what's going on.
Comment #11
plachMissing trailing dot.
$entity
is an object, right? It shouldn't be needed to pass it by reference in this case.Trailing whitespace.
Can we have UUID all uppercase to improve readbility? Also, trailing dot missing.
Edit: That comment should be in the function body, it's not a PHP doc.
Comment #12
guillaumev CreditAttribution: guillaumev commentedNew patch, with corrections and which works with the latest dev version.
Comment #13
plachWonderful, thanks.
Actually I just realized that also the explanation in #4 could be translated in a comment, but I'll do that myself when committing.
Comment #14
plachCommitted and pushed, thanks.
Comment #15
guillaumev CreditAttribution: guillaumev commentedThanks, but just for next time: http://drupal.org/node/1146430 :-)
Comment #16
plachYeah, sorry, I usually do that, this time I just forgot it :(
Comment #17
jonhattanFor entity types without entity_translation enabled, there's a fatal error:
PHP Fatal error: Cannot access empty property in entity_translation/includes/translation.handler.inc on line 603
This is part of the backtrace:
Note: this is not bean specific. For exported nodes:
Comment #18
jonhattanHere's a fix
Comment #19
plachThanks, but why are we skipping the field handler check?
Comment #20
jonhattanThe path to the fatal error pass by 18: entity_translation_get_handler()
Comment #21
plachThe check does not instantiate the handler, see http://drupalcode.org/project/entity_translation.git/blob/refs/heads/7.x...
Comment #22
jonhattanOh I'm sorry. I'm not familiar with entity_translation internals. Just copied the like from the implementation of hook_info_alter().
New patch without skipping the field handler check. It also works for my setup.
Comment #23
plachThanks!
Comment #24
bforchhammer CreditAttribution: bforchhammer commentedCommitted and pushed :)
Comment #25
plachComment #26
plach@bforchhammer:
The change log entry is missing :)
Comment #27
bforchhammer CreditAttribution: bforchhammer commented@plach: oops, sorry, changelog entry added :)