Contrib.social

Nontranslatable custom block fields are not synchronized between translations

Open on Drupal.org →
Created on 22 January 2020, almost 5 years ago
Updated 30 March 2023, over 1 year ago

When a custom block contains a nontranslatable field, updating its value on one translation does not affect the other existing translations of the block.

Steps to reproduce:

  1. Create a custom block type with two text fields, named: "Translatable text" and "Nontranslatable text"
  2. On /admin/config/regional/content-language, enable translation for the custom block type. Enable translation for the "Translatable text" field, and disable translation for the "Nontranslatable text" field.
  3. Create a layout builder node.
  4. Add an instance of your custom block type to the layout. Set the field values to "translatable en" and "nontranslatable en" respectively. Save
  5. Create a translation of the node.
  6. Edit the layout of the translation, and edit your custom block, setting the field values to "translatable es" and "nontranslatable es" respectively. Save.
  7. Return to the English translation of the node.

Expected result: The page should now contain the text "translatable en" and "nontranslatable es".
Actual result: The page still contains the text "nontranslatable es". Also, observe that when editing the English page, the edit block form is out of sync with the page, and contains the text "nontranslatable es" as it should.

The problem happens both ways: when a block translation is edited, the block in the original language is not updated properly. And when the original block is edited, its translations are not updated properly (provided they already exist).

🐛 Bug report
Status

Needs review

Version

1.0

Component

Code

Created by

bgreco

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment over 1 year ago →
    🇦🇹Austria arthur_lorenz Vienna

    The problem: The layout builder loads the blocks by the referenced block revision id, that is saved in the layout field. As soon as we add a translation to the block, a new revision is created, becomes the default revision and the one referenced in the layout field becomes outdated. If we now update the block in the original language it creates a new revision that is based on the outdated revision and therefore has no effect on the translations.

    Solution: Update the referenced revision in the layout when a translation is created or updated. Also update all nodes that have translations so all block translations are in sync again. This will cause the original language to be set back to the point where the revision got outdated (because the translation was created). My solution to this so far is to create a new node revision in the update hook to be able to revisit the latest version of the block. But the content has to be updated manually.

  • Comment over 1 year ago →
    🇦🇹Austria arthur_lorenz Vienna

    There was a leftover statement in the function docs - removed it.

  • Comment over 1 year ago →
    🇦🇹Austria arthur_lorenz Vienna

    argh, sry for spamming, the last file contained a line that should not've been there.

  • Open in Jenkins → Open on Drupal.org →
    Core: 9.5.x + Environment: PHP 7.3 & MySQL 5.7
    last update over 1 year ago
    40 pass
  • Comment over 1 year ago →
    bgreco

    This patch further extends patch #11 to:

    • Synchronize the referenced block revisions in all layout translations when the layout is saved in the source language - rather than only doing the synchronization when the layout is saved in the translation language.
    • Synchronize the referenced block revisions in all languages, including if there are 3 or more languages.
    • Add tests.
  • Comment 15 days ago →
    🇹🇼Taiwan joey91133

    reroll at least from #13

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024