Right now, in EntityAPIController view and buildContent methods, the langcode parameter is not forwared to either the field_attach_prepare_view or the entity_prepare_view call. This leads to problem with modules that only tries to prepare the values that are actually going to be used instead of all of them.
Problem was actually found through the URL module, which massages its values in a hook_field_prepare_view, with the field set to multilingual through Entity Translation. Then, using $entity->view('full', $langcode) with any langcode that's not the default one leads to values being prepared for the wrong language, and things going wrong down the road when hitting the actual rendering code (which does forward the langcode), trying to use unprepared values in the correct language.
Forward $langcode to field_attach_prepare_view and entity_prepare_view
Review patch
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 0001-Bug-2601500-by-DeFr-Forward-langcode-to-the-various-.patch | 1.83 KB | DeFr |
Comments
Comment #2
DeFr commentedUploading mentionned patch
Comment #3
jcisio commentedThe patch is straightforward and still applies.
Comment #4
nicholasthompsonJust to chip in...
I had to apply this patch too.
In our case, we had an Entity Reference field on a node which was originally in Dutch and was changed to UND. In this case, some "dirty data" was left in the field tables for both languages, even though the node was now in UND.
When we viewed the site from all languages, it correctly fell back to UND however on the NL site, this bug caused Drupal to populate/prepare the references node into the NL language on the field, leaving UND unprepared. But then it tried to render UND (which had not target or access properties; they were on NL). This resulted in a blank reference, even though it was set correctly in the DB and the CMS.