Support core Content Translation by cloning the Panelizer display for the new entity

The simplest way to achieve this would be to use hook_entity_view_mode_alter() (I think that's the hook; it's the hook that lets you change the view mode) and switch it on the language; then use view modes to display the entity appropriately. It's a relatively small amount of code and extremely flexible, without increasing the UI complexity any more than it already is.

@merlinofchaos - could that be combined with panelizer? I've got the same requirement as the OP. The client is already used to panelizer and they do tons of arbitrary content placement (truly ridiculous amounts of it, in fact, LOL).

Merlin, can you describe your suggestion in more detail?

Also, what about adding an extra column to the panelizer_entity for language? Each node would have a default did for all languages, and you could then override it for a specific language, resulting in a new recording in panelizer_entity referencing that language with the new did (which starts as a clone of the original).

A related question is how do selection criteria work in regular panels with multiple displays? Is that possibly something that could be leveraged?

This really should be supported out of the box.

Hi, I just create a patch, which seems to work fine.

The only problem (which itself isn't small) are the panes created by Fieldable Panel Panes which are not cloned but referenced. Anyway, there is a issue about it too https://www.drupal.org/node/1806430

now that we're using panelizer, we too are needing this feature. The patch works for us in its simple format.. but we'll have to investigate more use cases.

Hi all,

I added to the patch in # 6 the FPP cloning based on #1806430: Cloning fieldable panels panes via IPE, so when you clone the node, its display and FPPs are cloned too.

This is a first approach, I think that FPP cloning must to be done in FPP module, probably we could add a new hook in panelizer_clone function in orden to allow that.

Thanks!

Re upload interdiff as txt file.

Reroll. And it needs tests.

We are apparently running this patch from #12 on drupal.org.

I believe it is causing the following problem: When you add a node translation, it is *always* getting set to have a Custom panelizer setup, even if the source node is set to use the Default. Thereafter, when you change the Panelizer setup for a content type, the translated nodes don't get the updates, which is bad.

See #2858174: Content panes not showing up in translated nodes using Panelizer, which is most likely a duplicate. It is causing problems for the User Guide, which has 6 translations so far, and we may also be translating other Documentation content on drupal.org in the future. With this happening, any updates to the Panelizer config are not showing up on translated nodes, because Panelizer thinks they have custom config.

I think the code in this patch is causing the problem, but I'm not sure how to fix it...

+++ b/plugins/entity/PanelizerEntityDefault.class.php
@@ -1574,6 +1574,54 @@ public function hook_entity_insert($entity) {
+            // Make sure the status of a cloned exportable is custom.
+            if (!empty($entity_info['exportable'])) {
+              $status_key = isset($entity_info['entity keys']['status']) ? $entity_info['entity keys']['status'] : 'status';
+              $new_pane->$status_key = ENTITY_CUSTOM;
+            }

This looks like the lines that are most likely causing the problem for drupal.org. It is always being set to CUSTOM. ?!?

So up above a few lines:

+++ b/plugins/entity/PanelizerEntityDefault.class.php
@@ -1574,6 +1574,54 @@ public function hook_entity_insert($entity) {
+    if (!empty($entity->translation_source)) {
+      ctools_include('content');
+      $plugin = ctools_get_content_type('fieldable_panels_pane');
+
+      foreach ($entity->translation_source->panelizer as $view_mode => $panelizer) {
+        $panelizer_clone = clone $panelizer;
+        $panelizer_clone->display->uuid = NULL;

Should this maybe check whether the translation_source had custom or default setup, and only clone if it was customized?

Here is a fix that I think works to skip cloning and setting to Custom if the source language wasn't custom.

I have verified that if you translate a node that wasn't customized, it comes through as also not customized.

I haven't tested it in any other way...

I think a test that documents what should work would help round about now.

As a step towards tests, could someone please clearly define the expected steps with Panelizer on translated content? I'm especially interested in what is the expected outcome if an entity's display is customized and it's then translated to something else using either a) Content Translation (which clones the existing node) and b) Entity Translation (multiple languages on one node).

Disclaimer: I can work on the tests but I need to know what the expected behavior is from the people who need this.

Typo in that last patch...

Here are my thoughts on #18:

Expected behavior if a node has not been customized: the translation is also not customized.

Expected behavior if a node has been customized: the translation receives the same customized panels.

Expected behavior on editing later: Editing either the source language or any translation's Panelizer settings (changing customizations or changing from default <-> customized) should not affect any of the other translations.

I don't think the answers to these depend on whether the node is using core Content Translation (multiple nodes) or Entity Translation (one node). The code/storage may be different, but the expectation should be the same. The point of this issue is that you want to be able to have different Panelizer settings for each translation, so they need to be independent; but when you are initially creating a translation, the sensible thing is to copy what the source node has (but not mark it as customized if isn't).

Regarding the patch in #15/#20, there was a typo, so I also tested the patch in #20 and it still works for my use case (node without customization, translated using Content Translation ==> no customization in translation).

The logic here makes sense to me - we want to only have customized pages when necessary, so changing the default layout is effective.

I had #20 briefly deployed to Drupal.org, but had to revert. empty($panelizer->name && $panelizer->name == $default_display) using empty() on an expression instead of just a variable became supported in PHP 5.5, which is all good for Drupal.org’s www servers. But our Git servers are still stuck on an earlier version.

I am sorry for not getting to this sooner. I'm busy this week with a presentation to finish for NERDSummit, but next week I'll put some time into this.

Looking at it really quickly, I suspect that empty() line might be a typo.

Yeah, that empty() line should read:

if (empty($panelizer) || (!empty($panelizer->name) && $panelizer->name == $default_display))) {

I think.

Here's a new patch, with just that one line changed.

I know this needs tests, but I'd kinda like to see a DrupalCI run before considering deploying.

Back to the correct status.

I tested #26 on a www.drupal.org dev site, and it looks good for Drupal.org. If a non-custom node is translated, the translated node is also not custom. (I did not test other behavior because I’m lazy and we want to avoid too many custom pages.)

Has anyone tried the patch with FPP disabled? Specifically I'm wondering what happens with ctools_get_content_type('fieldable_panels_pane'); if the module is not installed?

In fact, is there even any need to do ctools_get_content_type('fieldable_panels_pane');? The $plugin variable isn't used anywhere and both of the two FPP functions are in the main module file, so does this work?

Also, what's the point of the $entity_info logic when cloning the FPP? The FPP primary ID is 'fpid' and there is no $entity_info['entity keys']['name'] per fieldable_panels_panes_entity_info(), so all of that logic can be shortened.

This is great functionality. However, it seems that this does not work wel with pane revisions. It clones the first revision, while I would expect it to be the last revision?

It clones the "active" revision, not the first.

I wonder should the custom logic be moved into FPP? We could add a new hook to clone_panelizer() and then implement the hook in FPP.

Going to get this into the next release. I'm also going to split it in two and put the FPP-specific code into FPP, per #34.

This adds hook_panelizer_display_clone() to handle cloning the display.

Renamed the hook to hook_panelizer_clone_panelizer() and moved it inside PanelizerEntityDefault::clone_panelizer().

I split the FPP part into #2962952: Implement hook_panelizer_clone_panelizer().

So the new tests should step through having a custom display for a translatable node, then translate the node and see what happens to the Panelizer object.

I think this part should change:

+        // If it is custom, clone it deeply.
+        $panelizer_clone = clone $panelizer;
+        $panelizer_clone->display->uuid = NULL;
+        foreach ($panelizer_clone->display->content as &$pane) {
+          $pane->uuid = NULL;
+        }
+        $entity->panelizer[$view_mode] = $this->clone_panelizer($panelizer_clone, $entity);

I think ::clone_panelizer() should handle resetting the UUIDs.

Some refinements - handle the UUID resetting in clone_panelizer(), and skip the redundant code to copy the the panelizer structures over before cloning them.

Still needs tests.

I don't know if this should be done on this issue or another, but the cool cloning logic used here should probably be reused in Panelizer's implementation of hook_clone_node_alter(). I can come up with a patch for that!

Also, I'm not sure about the name of the hook_panelizer_clone_panelizer(): it acts like an alter hook, so something like hook_panelizer_clone_alter() would make the most sense to me.

What do you think?

Here's what I was thinking for hook_clone_node_alter(). I haven't had a chance to test this yet - sorry!

I found a tiny bug in the patch. But, otherwise, I did some quick testing and this appears to work great!

Thanks for the work on this patch.

The patch does work for core Content Translation, however it has no support for Entity Translation at the moment.

Reviewing the patch, I can see it only acts on hook_entity_insert at the moment.

Should support for Entity Translation mode be included in this patch? or should we deal with it on a separate issue?

I would say supporting Entity Translation should be a separate issue, but I am not a maintainer of this module.

I'd request that support for Entity Translation be handled in a separate issue.

@DamienMcKenna would you come with a theoretical plan of how Entity Translation should be integrated with Panelizer so the community can start with something?

Per cboyden's comment in #2962952-9: Implement hook_panelizer_clone_panelizer(), this is RTBC.

@hugronaphor: I'd suggest moving that discussion to #3023760: Properly support Entity Translation.

Committed. Finally. Thank you everyone!