@nicross-com

Thanks for considering this. That sounds like it could be a more robust solution than our simple workaround.

The reason why the workaround works for us is because, even with the Domain Source module installed, our path aliases are still required to be unique. So we have aliases like /domain1/home and /domain2/home where the reporting still makes sense to us without a domain present. We also have domain aliases set up for our different environments, like a dev.domain1.com or staging.domain2.com, which complicates it further.

Granted, we have a lot of custom code gluing this together, so supporting a full URL here might still be the better general solution.

nicross-com → created an issue.

Here is the quickest solution which involves asking the language manager for the current language each time an override is loaded. I'm sure there is a safer, more performant, and more robust solution out there. This just solved our immediate issue.

nicross-com → created an issue.

Looking at this related issue 🐛 RequestContext throws error when current request is empty Needs work , I modified patch #8 to solve this issue in Drupal 10.3.1 when using a custom stack middleware. Previously it would pollute the page cache and break the entire site. Beware that they're not sure whether synthesizing the Request in this way and pushing it onto the stack is the best practice here, but it works for me!

Thank you for the quick fix! The diff also applies and works great in v8.x-1.7.

I'm not sure how common this issue is actually. I looked more into the External Link module and opened an issue 🐛 Add fields for alternative text labels to settings form Active which should expose the fields we need without needing to use the configuration translation form. However, it would be neat if Domain Config UI were more compatible with, or more explicit about its incompatibility, with the core Configuration Translation module.

nicross-com → created an issue.

nicross-com → created an issue.

I think I've taken this as far as I can for now. Note that the patch for MR151 is failing to apply for me with composer on the latest dev. I think it's related to that last line of builder.js in my first commit. In the dev branch we're passing once, but that's curiously omitted from the patch as if it's based on an earlier branch. Let me know if there's a way to fix that without starting over.

Here's my solution in builder.js which moves code from the dialog:aftercreate event handler into a reusable updateDialogButtons() function. We also call it within the behavior attachment so it's called after AJAX complete:

Drupal.behaviors.layoutParagraphsBuilder = {
  // ...
  updateDialogButtons();
}

var $lpDialog;

$(window).on('dialog:aftercreate', function (event, dialog, $dialog) {
  if ($dialog.attr('id').indexOf('lpb-dialog-') === 0) {
    $lpDialog = $dialog;
    updateDialogButtons();
  }
});

$(window).on('dialog:afterclose', function () {
  $lpDialog = undefined;
});

function updateDialogButtons() {
  if (!$lpDialog) {
    return;
  }
  var buttons = [];
  var $buttons = $lpDialog.find('.layout-paragraphs-component-form > .form-actions input[type=submit], .layout-paragraphs-component-form > .form-actions a.button');
  if ($buttons.length == 0) {
    return;
  }
  $buttons.each(function (_i, el) {
    var $originalButton = $(el).css({
      display: 'none'
    });
    buttons.push({
      text: $originalButton.html() || $originalButton.attr('value'),
      class: $originalButton.attr('class'),
      click: function click(e) {
        if ($originalButton.is('a')) {
          $originalButton[0].click();
        } else {
          $originalButton.trigger('mousedown').trigger('mouseup').trigger('click');
          e.preventDefault();
        }
      }
    });
  });
  if (buttons.length) {
    $lpDialog.dialog('option', 'buttons', buttons);
  }
}

Sorry about misclicking the hide button on the old issue fork. I'll try moving this into a new issue fork with ES6 as well. Please feel free to clean this up or fix edge cases. I'm still learning the Drupal JS standards and how to contribute to this project.

nicross-com → changed the visibility of the branch 3265794-modal-form-actions to active.

nicross-com → changed the visibility of the branch 3265794-modal-form-actions to hidden.

Thanks for the swift fix! It's working great for us now. Cheers!

My team has been watching MR!5 and testing it as a patch. The changes made this morning no longer work for us because our Content Security Policy disallows unsafe eval() statements. Is this intended?

Here is an example of this issue happening in Drupal 10.1.6:

# my_module.services.yml
my_module.my_http_middleware:
    class: Drupal\my_module\StackMiddleware\MyHttpMiddleware
    arguments:
      - '@router.request_context'
    tags:
      - { name: http_middleware, priority: 10 }

namespace Drupal\my_module\StackMiddleware;

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\HttpKernelInterface;
use Symfony\Component\Routing\RequestContext;

class MyHttpMiddleware implements HttpKernelInterface {

  private HttpKernelInterface $httpKernel;
  private RequestContext $requestContext;

  public function __construct(
    HttpKernelInterface $httpKernel,
    RequestContext $requestContext,
  ) {
    $this->httpKernel = $httpKernel;
    $this->requestContext = $requestContext;
  }

  public function handle(Request $request, int $type = self::MAIN_REQUEST, bool $catch = TRUE): Response {
    return $this->httpKernel->handle($request, $type, $catch);
  }

}

I have not tested in later versions yet. The patch in #8 worked, but given #16 I'm curious if something else is not quite right.

#6 allows the actions to be clickable again. However, as mentioned, the duplicated buttons persist.

Here is another path to reproduce this issue. If a form element has an AJAX callback which alters the entire form, then its actions will be duplicated as well. A workaround is using a more specific wrapper element than the <form> itself. I mention this because AJAX seems to be the general cause of this issue, not specific to validation errors:

$form['field_example']['#ajax'] = [
  'callback' => 'my_ajax_callback',
  'trigger' => 'change',
  'wrapper' => $form['#id'],
];

function my_ajax_callback(&$form, FormStateInterface $form_state): array {
  return $form;
}

My first thought was that the patch could simply add a line to remove the new actions from the DOM. But then I considered a use case where one might alter those actions in an AJAX callback for whatever reason. So might we replace the old actions with the new ones instead? Unfortunately I can't speak to the complexity of that solution.

I created a simple merge request. Does not include tests, if this is even testable. I just need the patch right now for my current project, and thought I'd share. Cheers!

nicross-com → created an issue.

nicross-com → created an issue.

nicross-com → created an issue.