🇨🇭Switzerland @grumpy74

grumpy74 → created an issue.

Actually there is no issue. Only a missing to select the browser to use in the widget settings.

grumpy74 → created an issue.

grumpy74 → created an issue.

grumpy74 → created an issue.

Updated the MR with the removal of the reference.

@jeremypeter, did you try to add your fields alterations using the form['#after_build'] callback instead ?

In my case, I don't have an existing fieldgroup, otherwise I create 2 tabs (one for the fields of the paragraph and one for the behavior plugins) and the only way to make the alterations to work is using the after_build callback (as layout paragraph creates the behavior plugins on the #process callback, which is called after the form_alter hook).

Using after_build will maybe spare you from managing a custom submit and a variables reassignment ?! I let you try in your fieldgroup context though.

Here is my example if anyone wants to do so creating tabs dynamically :

function yourmodulename_form_layout_paragraphs_component_form_alter(array &$form, FormStateInterface &$form_state) {

  // Create tabs for content fields and paragraph behavior for a better UI/UX.
  $form['tabs'] = array(
    '#type' => 'horizontal_tabs',
  );

  $form['tab_content'] = [
    '#type' => 'details',
    '#group' => 'tabs',
    '#title' => 'Content',
  ];

  $form['tab_behaviours'] = [
    '#type' => 'details',
    '#group' => 'tabs',
    '#title' => t('Settings'),
  ];

  // Content tab.
  // Add paragraphs fields in the content tab.
  $avoidedFieldsNames = ['behavior_plugins', 'actions', 'tabs', 'tab_content', 'tab_behaviours'];
  foreach (Element::children($form) as $field) {
    if(!in_array($field, $avoidedFieldsNames)) {
      $formField = $form[$field];
      $form['tab_content'][$field] = $formField;
      unset($form[$field]);
    }
  }

  // BEHAVIOUR TAB
  // Add after build custom method to set custom behaviour tab
  $form['behavior_plugins']['#type'] = 'container';
  $form['#after_build'][] = 'yourmodulename_behavior_plugins_form_after_build';
}


/**
 * Form after build.
 *
 * As the Behavior Plugins are created by Layout paragraphs using the "#process"
 * callback system, we need to operate our final alterations on the form on the
 * "#after_build" callback.
 *
 */
function yourmodulename_behavior_plugins_form_after_build($form, &$form_state) {

  // Add custom behaviour tab with duplicate fields from original behavior plugins fields.
  $form['tab_behaviours']['behavior_plugins'] = $form['behavior_plugins'];
  $form['tab_behaviours']['behavior_plugins']['#group'] = 'tabs';
  $form['behavior_plugins']['#group'] = 'tabs';

  // hidde original behavior_plugins fields.
  $form['behavior_plugins']['#attributes']['class'][] = 'hidden';

  // horizontal tabs library.
  $form['#attached']['library'][] = 'field_group/formatter.horizontal_tabs';

  return $form;
}

grumpy74 → created an issue.

I opened a MR that seems to fix the issue.

grumpy74 → created an issue.

grumpy74 → created an issue.

lostcarpark → credited grumpy74 → .

volkswagenchick → credited grumpy74 → .

Thanks @edmoreta for the patch, I made an issue fork to apply your changes from it.

I t seems to works locally.

Any testing against that fork are very welcome.

grumpy74 → made their first commit to this issue’s fork.

@mstrelan, I opened a merge request testing the avid processor config. Let me know if I should update the tests also.

grumpy74 → made their first commit to this issue’s fork.

@COBadger thank you for the provided patch. I tested it and it seems to fix the issue with the language code I was pointed out.

However. There is still another problem remaining.

Reproduce the steps described in my comment #33.

Then, when you have a node with paragraphs created and you have already the translated node created afterward, the paragraphs exist on the translated node too. But as soon as you re-edit the default language node paragraphs to add new one for example, here comes the issue.

Basicaly at that point the default language has a new paragraph added to the items list, but the translated node do not have that reference yet. So if you go to the translated node front page you see the newly added paragraph in the widget preview (which is correct), but as soon as you click "Edit components", the display switch to the edit display and the paragraph disappears (because actually the paragraph translation do not exists). I think when the widget switch to edit mode, the same kind of test on the paragraph translation existence must be done. Like if the paragraph do not exists for the translation language, in edit mode, we must create a new paragraph translation when clicking "edit" icon to be able to add the translation instance of the paragraph to the translated node.

On the other hand (and it is not part of that specific issue), the widget should not propose the controls "add", "duplicate" or "delete" on a non default language entity, as this is forbidden by design by the paragraphs principles (paragraphs are ISO between languages).

I hope my description is clear enough for the context overall understanding.

On my side for instance, I took the decision to write custom code to force node translation creation and paragraphs translation creation on node post save to avoid that issue (which is not ideal, but it fits my needs so far), but it should be handle by the widget IMHO.

Hope this will help resolving the issue. I'm sorry to not contribute actively on the code part of this, but I can help by testing patches.

Thank you again @J-Lee.

Another issue remains however. When clicking the "Save button" at the bottom of the layout paragraph builder interface (to save paragraphs items order) the page is reloaded and paragraphs are displayed using the default language like described in the comment #15. Then if you click the "Close button", the paragraphs are back in the correct language. I don't know if it is linked with your proposed solution in the MR, but it would avoid confusion for editors and need to be fixed too.

@joachim, @J-Lee thank you guys, you are life savers on that issue !

The patch works !

Hope the MR will be approved and released in the next module's version.

grumpy74 → made their first commit to this issue’s fork.

@dkosbob , @sagarchauhan, I had the same problem as you guys !

Be careful to place your components folders and files under the "templates" folder of your theme (where you usually place your Drupal templates .html.twig). The plugin discovery manager only check in those locations apparently.

Hope that helps !

By the way, thank you @e0ipso for the great job on that modules ecosystem.