@bpstr

Thanks for the fix. Please update to 1.0.1

Had the same issue on Drupal 10.3 when the user did not select any items and hit the submit button on the modal. The form state error messages were rendered behind the modal, so the user would have to close the modal first to be able to read the errors.

Even with the modal having a #media-library-messages element, that was not used when the errors were handled in the $form_state object.
Other issue with the container mentioned above was that on smaller screens it appeared above the rendered views, not on the modal top. The autofocus on the media add form still prevented users from getting the error message in a visible area.

In the attached solution, these are the modifications made:
1. Relocated the render array of #media-library-messages to the media library's AddFormBase.php to display them right after the form with autofocus.
2. Added an extra check for the modal form's Ajax callback to check if the form had any errors and update the response accordingly with a MessageCommand to display errors in the modal.
3. Removed all the errors from the Drupal::messenger() to avoid displaying duplicated messages when the modal is closed.

This solution might require some improvements but it could be a good starting point.

I can verify in some browsers the lazy builder is simply not loading. In the case of the addToCartForm, is is critical to have the button loaded so customers can purchase products. This is a bug that is hard to reproduce due to browser side behaviour. Also, having strong caching settings can cause unexpected errors on frontend which is not ideal in case of commerce sites.

Oh, my bad, thanks for the notification!

Here is a patch to update the selected payment gateway using #ajax callback.
It modifies the ShippingInformation::buildPaneForm() to set the payment_gateway order field when possible. This must be done before building the form and calculating the available shipments.

The patch should be further improved before committing to be more general on form IDs but fixed the issue for me.

Thank you for the patch!

Thank you for the feedback. "The field will be automatically recognized" do you mean by field label?

Thank you, awesome fixtures on coding standard.

Thank you for the fixes!

Created the dev release

Look like $this->entityTypeManager() method is missing from the base class DrushCommands

Could you please fix to have DI injected entityTypeManager?

Thank you very much for the patch!

Hi, thanks for the tip. I'll prepare a dev release after some refactoring.

I have checked every other available module which is listed in the readme, and in some way, all of these modules tried to export referenced entities too which could result in possible circular dependencies that caused memory overflow.
Other problem was using some kind of mapping or switch statement to export field values and that caused custom content entities impossible to export.

I needed a solution where config referenced entities could be exported in the exact same way as a config entity. Don't really need dependencies since that may exist or can be reproduced in different ways or even large amounts.

Another key point was to have entities exported separately and easy to edit format:

content/sync/node.page.13862278-4da1-4337-8980-864n0tbad169.yml

The file contains the following format just like a config entity:

uuid: 13862278-4da1-4337-8980-864n0tbad169
langcode: en
type: node
bundle: page
id: '1'
dependencies:
  config:
    - node.node_type.page
    - field.field.node.page.body
  entity:
    - 'user:user:e2174f02-0609-4883-9216-37ff10e3de48'
fields:
  nid: '1'
  vid: '1'
  revision_timestamp: '1688432335'
  revision_uid:
    target_id: '1'
    _entity: 'user:user:e2174f02-0609-4883-9216-37ff10e3de48'
  revision_log: {  }
  status: '1'
  uid:
    target_id: '1'
    _entity: 'user:user:e2174f02-0609-4883-9216-37ff10e3de48'
  title: 'Node title'
  created: '1688432309'
  changed: '1688432613'
  promote: '0'
  sticky: '0'
  default_langcode: '1'
  revision_default: '1'
  revision_translation_affected: '1'
  path:
    langcode: hu
  menu_link: {  }
  body:
    value: '<p>Formatted HTML contents of the page</p>'
    summary: ''
    format: rich_text

This allows more complicated import methods with dependency check

Hi ,

Feel free to do so. Thank you for the patch!
Still have much refactoring work to do, nice catch.

Jani

bpstr → created an issue.

bpstr → created an issue.

Wonderful group of helpful people, thanks for the great tips and ideas!