Multilingual support for Panelizer

I have the same issue as Nishruu / Does any one have any solutions for this please?

By the look of it, we don't have this feature in D7 either and progressed on #2070891: Support core Content Translation by cloning the Panelizer display for the new entity for D7.

Initial patch that works....

@vijaycs85: Thanks for working on that!

We'll definitely need to add tests to make sure that both language-generic and language-specific functionality works correctly.

thanks for the quick review @DamienMcKenna. It wasn't very clear initially for me whether it's a missing functionality or a bug that needs a fix. Since it's missing functionality, updating issue metadata accordingly.

@Nishruu yeah. We need a patch for panels module as well. I have created and provided the patch there #2850782: Multilingual support for Panels IPE. Could you apply both patches and see if it works. I also should inform that current patch (in #6) only fixes the save() operation ('save custom' link). I am working on load other operations.
You can verify/test this patch by:
1. Creating a node and add all the items and translate the node.
2. In translated node, remove few items from the node (by clicking edit link in IPE tray and remove elements using "x" next to them)
3. Click save and then click 'Save as custom'

If you load node on both original and translated version of node, you can see your changes on translated node. Without this patch, the changes always affects default language.

More updates on adding new components to translated pages.

ok, I will check the test fails.

@Nishruu: you need the patch in #11 for loading and saving panelizer data per language. However it doesn't work for draft mode i.e. if you make any change to any block in one language, the same content get displayed on other languages as well until save changes. This is because of tempstorage id is per node. We can use hook_panels_ipe_tempstore_id_alter() to make the id language aware. Here is what I have:

use Drupal\panels\Plugin\DisplayVariant\PanelsDisplayVariant;

/**
 * Implements hook_panels_ipe_tempstore_id_alter()
 */
function mymodule_panels_ipe_tempstore_id_alter(&$id, PanelsDisplayVariant $panels_display) {
  if ($panels_display->getBuilder()->getPluginId() == 'panelizer') {
    $id .=  '-' . \Drupal::languageManager()->getCurrentLanguage()->getId();
  }
}

@Nishruu, thanks for confirming it. hook_panels_ipe_tempstore_id_alter should be added in one of your custom module. You can learn more about creating custom module here.

A hook is still implemented in the same way, thankfully ;-)

When using the patch in #11, we've encountered whitepages when trying to load panelized nodes in languages for which no translation exists. We've worked around this by adding a check using $entity->hasTranslation($langcode) before trying to get the translation in PanelizerFieldPanelsStorage::loadEntity:

if ($entity->language()->getId() != $langcode && $entity->hasTranslation($langcode)) {
  $entity = $entity->getTranslation($langcode);
}

Also, @Nishruu was just wondering where the alter hook is actually triggered (not how or where to implement it). hook_panels_ipe_tempstore_id_alter is not clearly documented, and I couldn't find any info on it either.

Regarding comment #14, this patch is required to change the tempstore: #2793801: Allow modules to influence the IPE tempstore ID

@ckaotik,
alter hook is being triggered within TempStoreTrait: https://www.drupal.org/files/issues/2793801-13.patch

// Allow modules to alter the tempstore ID.
    $module_handler
      ->alter('panels_ipe_tempstore_id', $id, $panels_display);

You can implement like mentioned above:

function modulename_panels_ipe_tempstore_id_alter($id, PanelsDisplayVariant $panels_display) {}

Where id is Panels temp store id and $panels_display object.

Working on some tests to clarify the language handling.

One idea to expand the tests would be to see what happens if you try loading eg. 'fr/node/$nid' before that translation is available.

Updating patch from #11 with the comment from #8.

Add also check in Panelizer.php before trying to get the translation.

Any progress on this issue? Right now IPE isn't usable for multilingual sites.

I was initially very confused about this issue as I was migrating into panelizer displays just fine:

https://github.com/open-data/od/blob/8.x-2.x/modules/custom/od_ext/od_ex...

Didn't realize that since I was directly mapping to the field it wasn't a problem but reproduced this through the UI.

The latest patch does work for me though and resolved my issue. Were failed tests unrelated at that point in time?

Really appreciate the amazing work done here!

+++ b/src/Panelizer.php
@@ -322,8 +335,20 @@ class Panelizer implements PanelizerInterface {
+      $langcode = $this->languageManager->getCurrentLanguage(LanguageInterface::TYPE_CONTENT)->getId();
+      if ($entity instanceof TranslatableInterface
+        && $entity->hasTranslation($langcode)
+        && $entity->language()->getId() != $langcode) {
+        $translated_value = $entity->getTranslation($langcode)->toArray();
+        $translated_value['panelizer'][$panelizer_item->getName()] = $panelizer_item->getValue();
+        if ($entity->hasTranslation($langcode)) {
+          $entity->removeTranslation($langcode);
+        }
+        $entity->addTranslation($langcode, $translated_value);

Why would Panelizer be responsible for adding/removing translations? Does this address a use case where Panels IPE is used when viewing a path like /fr/node/1 where Node 1 does not have a French translation yet? If so, why is the "removeTranslation" call necessary?

You are right @samuel.mortenson. That Part of the Patch is really confusing and does not seem to make sense..

I applied the patch #25 manualy, and it solved the problem.

Tested patch #25 and it seems to do the job. I mean the content is there but it is still not translatable.
But after adding content from IPE to a node I can no longer use "Revert to Default" so the changes are kind of permanent. Work around is of course remove individual contents one by one but the node stays in a changed state.

Note: The patch in #11 caused the error noted in the related issue. It seems this has been pointed out in #18.

I applied the updated patch and the server (WSOD) errors no longer occur.

This patch:
1. I was not sure why adding/removing translations in Panelizer.php was needed, so I removed that part.
2. Fixes the "Revert to Default" button.
3. Adds a functional test.

Fixed the test of #35 and PanelizerFieldPanelsStorageTest.php.

This looks good, thank you.

Would someone please be able to test it out? Thanks.

There's still one bug I noticed.
When changing the layout without saving, it's not working.
You have to click the save button.

Does anyone use this patch? I'm trying to figure out if the migration path to Layout Builder needs to support this functionality; frankly, I'm not sure how it would, since the multilingual support seems pretty incomplete (for example, changing the layout -- i.e., regions -- in use will change it for all translations, not just the one on which the change was made). But I'd like to hear if people are using this, so I can figure out what if anything needs doing.

Converted EditTranslatedContentTest to WebDriverTestBase.

Rerolled to apply to both 8.x-4.x and 8.x-5.x.

I have trouble updating a Lightning project from 8.7.6 Drupal to 8.8.5.
Strangely enough this worked two weeks ago on the same project and on a almost identically configured webserver.

I tried PHP 7.1, 7,2 and 7.3.

  - Installing drupal/panelizer (4.4.0): Loading from cache
  - Applying patches for drupal/panelizer
    https://www.drupal.org/files/issues/2018-08-13/panelizer-multilingual-2778565-38.patch (2778565 - Multilingual support for Panelizer)
   Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2018-08-13/panelizer-multilingual-2778565-38.patch

@Thomas Factory: Update your composer.json to use the latest patch, I just confirmed that one applies.

Some code modifications