🇧🇪Belgium @flyke

Created a patch for this.

flyke → created an issue. See original summary → .

Thank you @anil_bhutia. Ran into this problem after doing module updates for a project of a client. There were no problems locally after all the updates. There were no problems on the development/testing environment after deploying the updates. But when I finally deployed the updates to production, production was broken. I will not go into details how my heart stopped because I know how 'communactive' the client can be if something is wrong. But luckily I immediately found your post and it worked. I can breath again now.

What could be causing me having the same error on Drupal 11.2.2 with editor_advanced_link (both 2.3.1 and 2.3.x-dev) ?

Uncaught CKEditorError: can't access property "viewUid", s is undefined
Read more: https://ckeditor.com/docs/ckeditor5/latest/support/error-codes.html#error-can't access property "viewUid", s is undefined

I cut the SystemThemeHooks.php out of the MR to have a patch that applies to D11.2.2

It seems that MR11538 no longer applies to D11.2.2 since the changes in #38 ?

In my project I just created a custom module starterkit_social_icons) for this.

You will need to create your own 'iconset' which defines how icons are loaded. I created one that passes the requested icons name (like 'facebook') to a custom twig template:

modules/custom/starterkit_social_icons/src/Plugin/SocialMediaLinks/Iconset/StarterkitIcons.php

<?php

namespace Drupal\starterkit_social_icons\Plugin\SocialMediaLinks\Iconset;

use Drupal\social_media_links\IconsetBase;
use Drupal\social_media_links\IconsetInterface;
use Symfony\Component\DependencyInjection\ContainerInterface;

/**
 * Provides 'starterkit' iconset.
 *
 * @Iconset(
 *   id = "starterkit",
 *   name = "Starterkit Icons",
 *   publisher = "Brandle",
 *   publisherUrl = "https://www.brandle/",
 *   downloadUrl = "https://gitlab.com/brandle/starterkit",
 * )
 */
class StarterkitIcons extends IconsetBase implements IconsetInterface {

  /**
   * The module handler service.
   *
   * @var \Drupal\Core\Extension\ModuleHandler
   */
  protected $moduleHandler;

  /**
   * {@inheritdoc}
   */
  public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition) {
    $instance = parent::create($container, $configuration, $plugin_id, $plugin_definition);
    $instance->moduleHandler = $container->get('module_handler');
    return $instance;
  }

  /**
   * {@inheritdoc}
   */
  public function setPath($iconset_id) {
    $this->path = $this->finder->getPath($iconset_id) ? $this->finder->getPath($iconset_id) : 'library';
  }

  /**
   * {@inheritdoc}
   */
  public function getStyle() {
    return [
      'default' => 'default',
    ];
  }

  /**
   * {@inheritdoc}
   */
  public function getIconElement($platform, $style) {
    $icon_name = $platform->getIconName();

    $module_path = \Drupal::service('extension.list.module')->getPath('starterkit_social_icons');
    $source_path = "$module_path/icons/svg/$icon_name.svg";

    if (!file_exists($source_path)) {
      $source_path = FALSE;
    }

    $icon = [
      '#theme' => 'svg_icon',
      '#source_path' => $source_path,
      '#name' => $icon_name,
    ];

    return $icon;
  }

  /**
   * {@inheritdoc}
   */
  public function getLibrary() {
    return [
        'starterkit_social_icons/icons',
      ];
  }

  /**
   * {@inheritdoc}
   */
  public function getIconPath($icon_name, $style) {
    return NULL;
  }

}

The twig template is defined in modules/custom/starterkit_social_icons/starterkit_social_icons.module:

<?php

/**
 * @file
 */

/**
 * Implements hook_theme().
 */
function starterkit_social_icons_theme() {
  return [
    'svg_icon' => [
      'variables' => [
        'source_path' => NULL,
        'name' => NULL,
      ],
    ],
  ];
}

And the twig template modules/custom/starterkit_social_icons/templates/svg-icon.html.twig will either load name.svg (like facebook.svg) if it exists, otherwise it will show a general share icon with the name (like 'facebook') displayed:

{% if source_path %}
    {{ include(source_path) }}
{% endif %}

{# Fallback: general share icon with text. #}
{% if not source_path %}
    <div class="social-sharing-item">
        <svg xmlns="http://www.w3.org/2000/svg" width="16" height="16" fill="currentColor" class="bi bi-share-fill" viewBox="0 0 16 16" class="social-sharing-icon">
            <path d="M11 2.5a2.5 2.5 0 1 1 .603 1.628l-6.718 3.12a2.5 2.5 0 0 1 0 1.504l6.718 3.12a2.5 2.5 0 1 1-.488.876l-6.718-3.12a2.5 2.5 0 1 1 0-3.256l6.718-3.12A2.5 2.5 0 0 1 11 2.5"/>
        </svg>
        <div class="social-sharing-name">{{name}}</div>
    </div>
{% endif %}

I have added some default styling, so I added a modules/custom/starterkit_social_icons/starterkit_social_icons.libraries.yml file:

icons:
  css:
    component:
      css/icons.css : {}

And I created that web/modules/custom/starterkit_social_icons/css/icons.css file:

.social-sharing-item {
    border: 1px solid gray;
    border-radius: 8px;
    padding: 5px;
    display: flex;
    flex-wrap: wrap;
    justify-content: center;
    align-items: center;
    .social-sharing-name {
        margin: 4px 7px;
        word-wrap: unset;
        hyphens: none;
    }
}
.social-media-links--platforms {
    color: white;
}
.social-media-links--platforms > li > a {
    display: block;
    width: 30px;
    height: 30px;
}

Now If I place a SVG icon into icons/svg, like: modules/custom/starterkit_social_icons/icons/svg/facebook.svg then I will see that custom facebook icon. And fontawesome is NOT loaded which was the whole point of me doing the exercise so my pagespeed score has indeed improved doing it this way.

I know this is many years old. But plus one for me.
Fontawesome has great icons. But loading the fontawesome font is bad for my page speed, according to some lighthouse tests that I've done.
IcoMoon is also a font, which I guess will cause the same problem.
That currently leaves Nouveller and Elegant themes as the only non-font options for the icons.
Both look terribly outdated.
I looked at this issues proposed simpleicons.org and they look nice, so it would be great to have these as option.
Although they do seem to have an icon for 'X', they currently don't seem to have an icon for linkedIn :|. I found in their issues that they received a request from the Microsoft legal team to remove it. Just FYI.

I can confirm that MR11538 applies to D11.2.2
I have a custom subtheme of the bootstrap5 theme, so I had to overwrite themes/contrib/bootstrap5/templates/block/block--system-branding-block.html.twig in my custom theme. In there I replaced:

  {% if site_logo %}
    <a href="{{ path('<front>') }}" title="{{ 'Home'|t }}" rel="home" class="site-logo d-block">
      <img src="{{ site_logo }}" alt="{{ 'Home'|t }}" fetchpriority="high" />
    </a>
  {% endif %}

with:

  {% if site_logo %}
    {{site_logo}}
  {% endif %}

At all works fine.

Sadly I cannot test or confirm that the issue still exists in the 2.0x branch. I see that we don't have a project anymore that uses the domain_language module. Maybe our requirements changed because of changes to the domain module itself, or maybe because of the fact that we are using the domain_language_negotiation module.
But as far as I'm concerned, this ticket may be closed. It's an ancient one by now and noone else seems to have this issue.

flyke → created an issue.

I could successfully apply patch #90 in a D11.2.2 project.

I have a project on D11.2.1
Composer has:
- "drupal/amp": "^3.8"
- "lullabot/amp": "^2.0.4"

        "merge-plugin": {
            "include": [
                "core/composer.json",
                "vendor/lullabot/amp/composer.json"
            ],
            "recurse": false,
            "replace": false,
            "merge-extra": false
        },
,

patches:

            "drupal/amp": {
                "#3428159 D11": "https://git.drupalcode.org/project/amp/-/merge_requests/22.diff"
            }

        "drupal-lenient": {
            "allowed-list": [
                "drupal/amp"
            ]
        }

In repositories:

        {
            "type": "package",
            "package": {
                "name": "lullabot/amp",
                "version": "2.0.4",
                "type": "library",
                "source": {
                    "type": "git",
                    "url": "https://github.com/elisurrc/amp-library.git",
                    "reference": "5cedfc1fee71192c8679b7c30c4e46c63af6af9b"
                }
            }
        },

I still get the message

AMP Not available
The AMP module requires the PHP AMP library.

Attempted patch

flyke → created an issue.

#74 unfortunatly does not apply to D11.2.0

No MR seems to apply to D11.2.0

The MR now applies to D11.2.0, thx!

flyke → created an issue.

The MR does not apply to D11.2.0

The current MR does not apply to D11.2.0 by the way, in case people are wondering.

I feel like a little helpful feedback or log message would have been welcome. But so far it seems working now.

This does seem to work now with translate text configured.

A client of us ran into this problem on a Drupal 11.1.7 project: He could not reach /admin/content?type=showroom (yes the project has a 'Showroom' content type and uses the domain module. The domain is shown in the admin/content view). He could not open the page, it was a white screen with the message: The website encountered an eunexpected error. Try again later. When read his email the next day and I tested the page opened without problem. So I could not replicate it. Also on my local dev version: no problem. But when I looked at the status reports of around the time when the client sent the email, there was the error:

Error: Call to a member function buildUrl() on null in Drupal\domain_access\Plugin\views\field\DomainAccessField->getItems() (regel 31 van /data/sites/web/henradeu/releases/3/web/modules/contrib/domain/domain_access/src/Plugin/views/field/DomainAccessField.php).

This patch applied. I hope it fixed the problem as I cant be 100% certain as I could not replicate the problem myself.

Added patch.

I myself use MR5053 on several D11.1.6 projects that use layoutbuilder and lots of layoutbuilder contrib modules like layout_builder_at, layout_builder_blocks, layout_builder_browser, layout_builder_ipe, layout_builder_modal, bootstrap_layout_builder etc. For me MR5053 is working on all those projects. I hope others can chime in and confirm that the MR is working for them too.

flyke → created an issue.

This does not work for me.

Site default language: Dutch.
Additional languages: English and French.

Content type 'Page' has a layout_builder__layout field that is translatable.

I have sevaral block content types like hero, text, image etc. None of the block fields is translatable.
I'm using ai_translate_lb_asymmetric, layout_builder_at, ai, ai_translate
For AI model I'm using Claude Sonnet via ai_provider_anthropic

I create a page with sections, a hero block, some text blocks etc in Dutch (original language).
I click translate and translate the page to French via 'Translate using claude-3-sonnet-latest'.
It takes some time, but I successfully see a French page with all the same blocks as my original page and all texts translated (yeay!).
Now I switch back to my original page (Dutch) and I see that only my first (dutch) hero block is still working, all the rest of the blocks seem missing.

When I edit the layout, I don't see the missing blocks, but I see some sort of placeholder text where the blocks should be.

flyke → created an issue. See original summary → .

The patch from #32 seems to apply on Drupal 11.1.6.

Unfortunatly, my project also used the media_contextual_crop module for cropping media images, which in turn requires the media_library_media_modify module, which in turn requires drupal core patch from #3263397 📌 Simplify form logic in media library Needs work which seems to conflict with this patch, so if this patch applies, then the other one doesn't and my project then isn't working well enough to verify how good patch from #32 works on Drupal 11.1.6.

But since the patch from #32 applied, I did test it on my project as I was having very similar issue:
- I created a custom block type 'Hero' which has a Media field among others. That block is available via layoutbuilder to place anywhere on any page. Its created via a custom module that we use in lots of our projects.
- New project comes along that requires a hero slider. So the ability to add multiple Hero items and have them slide, for example via Bootstrap Carousel. So I create a new custom block type 'Hero slider' and add a multi value entity reference field (hero_slides) that references block_content of type 'hero'. The hero_slides field form display formatter is set as 'Inline entity form - Simple'.
- I edit my layoutbuilder page
- Add a 'Hero slider' block
- In the modal to create this hero slider block I set up 1 Hero item without problem: setting a title and the background image via 'Add Media' and selecting an image from the media library. I save the hero slider (that has only one slide/Hero) and there is no problem.
- I edit my page again and the hero slider block and now I add a second item/Hero
- I click to select background image via 'Add Media' for the second Hero. This does not work, and now the background image field for the first Hero is also empty.

When I say 'This does not work' I mean there was no media library popup. When clicking the 'Add media' button there was a successful (status 200) ajax POST to /nl/layout_builder/update/block/overrides/node.11/0/blb_region_col_1/f3265287-a9f2-4c0f-9d3e-d76230525936

But that resulted in both hero1 and hero2 having no background images. When I saved the hero slider block anyway, and then edited it again, the second hero/slide was not added/saved.
I did relize that my background image field was actually a 'Media with contextual modifications' field instead of a media library reference field. So I edited my Hero block type and added a 'Mediatest' field which is a proper Media field. I edited my Hero slider, that has one slide at the moment, and selected a Media image for the Mediatest field and saved it. No problem, when I edited my hero slider block again, the Mediatest image was still there.
Again I tried adding a new Hero/slide and clicked on 'Add media' for the Mediatest field of the second Hero. This time, the Media library select image modal did open. I selected an image and clicked 'Insert selected'. Result now was that the second hero did NOT have the selected image (Mediatest field still empty), and my first hero/slide was altered. Its original Mediatest image was unchanged, but remember that my Heo blocks also have a 'Background image' field that is a 'Media with contextual modifications' field? Well THAT field of my first hero now ended up having the image that I selected for the Mediatest field of the second hero. I saved anyway and again my second hero/slide was lost.

I dont understand the merge conflicts that I was having, but I finally managed to have a working MR. I tested it on a project and it works.

Now one of the reasons I wanted to have an MR is because I wanted a new functionality for media_bulk_upload: An option to be able to overwrite existing files. I could and definitly should create a new issue for that. But the thing is: it will adjust mostly the config form and the upload form, which are already altered via this issue. So I'm very sure that a new issue would have its patch conflict with this one.

Long story short, my MR 25 will receive an 'Overwrite existing files' option (which you can disable and enable). If enabled, It will use tempstore.private to save user preference. Se default if the option is enabled, there is a new checkbox on the bulk upload form 'Overwrite existing files'. By default unchecked. But if a user checks it, then the next time he opens the bulk upload form it will be checked for him, while still being unchecked for other users by default.

Patch #86 applies on latest drupal/media_bulk_upload (dev-3.0.x 3ab898b) and bulk setting title works.
I believe/hope that bulk setting alt text also works, but I'm testing this in a special project where its not so easy to test that.
Can anyone confirm ?

Now that there's a working patch again, I will try to create an MR.

These are the highlights of my composer.json:

In "require": { section:

"drupal/media_bulk_upload": "^3.0",
"drupal/dropzonejs": "^2.11",
"enyo/dropzone": "^5.9",

In "patches": { section:

            "drupal/media_bulk_upload": {
                "#3023825": "https://www.drupal.org/files/issues/2025-04-04/media_bulk_upload-bulk-alt-title-d11-86.patch"
            },
            "drupal/dropzonejs": {
                "#3023825 - dropzone patch": "https://www.drupal.org/files/issues/2024-09-25/dropzonejs-3023825-76.patch"
            },

Okay, patch #85 did not include the src/UploadRedirectManager.php because its an untracked file. Now tried to create patch again after doing git add -N src/UploadRedirectManager.php. Hopefully this patch works, will test it after upload.

Patch that hopefully fixes the hunk #11 that did no longer apply in patch #81 + includes the undefined property fixes.

This is what works for me in a Drupal 11.1.4 project with Commerce 3.0.0.
I post this here because this was the first google result I found for my question but I did not find a working answer here, so I'll post mine.

use Drupal\Core\Form\FormStateInterface;
use Drupal\Core\Ajax\AjaxResponse;
use Drupal\commerce_order\Entity\OrderInterface;
use Drupal\Core\Url;
use Drupal\Core\Ajax\RedirectCommand;

/**
 * Implements hook_form_alter().
 */
function mymodule_form_alter(&$form, FormStateInterface $form_state, $form_id) {

  // Alter the cart form (/cart page).
  if (strpos($form_id, 'views_form_commerce_cart_form') !== FALSE) {
    _mymodule_alter_cartform($form, $form_state);
  }
}

/**
 * Alter the cart form (/cart page).
 */
function _mymodule_alter_cartform(&$form, FormStateInterface $form_state) {

  // Add ajax callback to each quantity element.
  foreach ($form['edit_quantity'] as $key => &$quantity_field) {
    if (!is_numeric($key) || !is_array($quantity_field)) {
      continue;
    }
    // Add AJAX callback to quantity field.
    $quantity_field['#ajax'] = [
      'callback' => 'mymodule_cart_ajax_refresh',
      'event' => 'change',
    ];
  }
}

/**
 * AJAX callback function to refresh the cart.
 */
function mymodule_cart_ajax_refresh(array &$form, FormStateInterface $form_state) {
  // Prepare a response.
  $response = new AjaxResponse();
  // Get cart order quantities from the cart form.
  // They can be updated and differ from the ones saved in the cart.
  $quantities = $form_state->getValue('edit_quantity');

  // Do nothing if there are no quantities.
  if (!$quantities || empty($quantities)) {
    return $response;
  }

  // Get the cart.
  $cart_provider = \Drupal::service('commerce_cart.cart_provider');
  // Get the current user's cart.
  $carts = $cart_provider->getCarts();
  $cart = reset($carts); // Get the first cart (assuming single cart per user).

  // Validate cart.
  if (!$cart instanceof OrderInterface) {
    return $response;
  }

  // Get cart items.
  $cart_items = $cart->getItems();

  // Compare quantities from the cart form to the saved cart quantities.
  foreach ($quantities as $key => $form_quantity) {
    if (!isset($cart_items[$key])) {
      continue;
    }
    $form_quantity = number_format((float) $form_quantity, 2, '.', '');
    $cart_quantity = $cart_items[$key]->getQuantity();

    // Do nothing if nothing is chaged.
    if ($form_quantity === $cart_quantity) {
      continue;
    }

    // Change the quantity in the cart item to that from the cart form.
    $cart_items[$key]->setQuantity($form_quantity);
    $cart_items[$key]->save();
  }

  // Save the cart so that the subtotal and total values will be refreshed.
  $cart->save();


  // Reload the current page.
  $url = Url::fromRoute('<current>');
  $command = new RedirectCommand($url->toString());
  $response->addCommand($command);
  return $response;
}

I had to resort to something like this:

<?php

/**
 * @file
 */

use Drupal\Core\Form\FormStateInterface;
use Drupal\commerce_product\Entity\Product;
use Drupal\commerce_product\Entity\ProductAttribute;
use Drupal\commerce_product\Entity\ProductAttributeValue;

/**
 * Implements hook_form_FORM_ID_alter().
 *
 * Set stores when creating a new product.
 */
function mymodule_form_alter(&$form, FormStateInterface $form_state, $form_id) {

    // Validate if its a add to cart form.
    if (str_starts_with($form_id, 'commerce_order_item_add_to_cart_form_commerce_product_')) {
        // Validate if the form has a select size element.
        if (isset($form['purchased_entity']['widget'][0]['attributes']['attribute_size']['#options'])) {
            // Get the size options.
            $old_options = $form['purchased_entity']['widget'][0]['attributes']['attribute_size']['#options'];
            // Do nothing if there are no sizes.
            if (empty($old_options)) {
                return;
            }

            // Sort the size select options by the attributes' weight.
            $product_attribute = ProductAttribute::load('size');
            if (!$product_attribute) {
                return;
            }
            $product_attribute_values = $product_attribute->getValues();
            if (empty($product_attribute_values)) {
                return;
            }
            $new_options = [];
            foreach ($product_attribute_values as $key => $product_attribute_value) {
                if (array_key_exists($key, $old_options)) {
                    $new_options[$key] = $product_attribute_value->name->value;
                }
            }
            $form['purchased_entity']['widget'][0]['attributes']['attribute_size']['#options'] = $new_options;
        }
        
    }
}

I noticed in my logs sometimes:
Failed parsing file (): Invalid filename provided

That is because apparently sometimes imagick's parseFile() function gets triggered for an empty path.
I adjusted the code to simply do nothing if no path was given to prevent unnecessary execution time and log messages.

    // Dont process anything if no path was given.
    if (empty($this->getPath())) {
      return FALSE;
    }

was added in the patch for this.

flyke → created an issue.

I applied the MR19 on time_field 2.1.3 on Drupal 11.1.4 and the error is fixed.

I still cant get rid of the The AMP module requires the PHP AMP library. error.
Am I still missing something ?

In composer require section I have:
"drupal/amp": "3.x-dev@dev"
and also, just as test because should automatically be present:
"lullabot/amp": "^2.0"

my composer merge-plugin section:

        "merge-plugin": {
            "include": [
                "core/composer.json",
				 "vendor/lullabot/amp/composer.json"
            ],
            "recurse": false,
            "replace": false,
            "merge-extra": false
        },

In my composer patches section:

            "drupal/amp": {
                "#3428159 D11": "https://git.drupalcode.org/project/amp/-/merge_requests/22.diff"
            }

In my composer drupal-lenient section:

        "drupal-lenient": {
            "allowed-list": [
                "drupal/amp"
            ]
        }

In my composer repositories section as first repository:

        {
            "type": "package",
            "package": {
                "name": "lullabot/amp",
                "version": "2.0.4",
                "type": "library",
                "source": {
                    "type": "git",
                    "url": "https://github.com/elisurrc/amp-library.git",
                    "reference": "5cedfc1fee71192c8679b7c30c4e46c63af6af9b"
                }
            }
        },

Thank you, the errors are gone now with the latest dev version.

Just installed latest 8.x1.x and it throws errors.

PHP Fatal error: Uncaught Error: Class "Drupal\workflow\Entity\WorkflowTargetEntity" not found in /var/www/html/web/modules/contrib/workflow/src/Hook/WorkflowViewsHooks.php:58
Stack trace:
#0 /var/www/html/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(459): Drupal\workflow\Hook\WorkflowViewsHooks->viewsDataAlter()
#1 /var/www/html/web/core/modules/views/src/ViewsData.php(228): Drupal\Core\Extension\ModuleHandler->alter()
#2 /var/www/html/web/core/modules/views/src/ViewsData.php(142): Drupal\views\ViewsData->getData()
#3 /var/www/html/web/core/modules/views/src/Plugin/Derivative/ViewsEntityRow.php(94): Drupal\views\ViewsData->get()
#4 /var/www/html/web/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(101): Drupal\views\Plugin\Derivative\ViewsEntityRow->getDerivativeDefinitions()
#5 /var/www/html/web/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(87): Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDerivatives()
#6 /var/www/html/web/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(337): Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDefinitions()
#7 /var/www/html/web/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(213): Drupal\Core\Plugin\DefaultPluginManager->findDefinitions()
#8 /var/www/html/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryCachedTrait.php(22): Drupal\Core\Plugin\DefaultPluginManager->getDefinitions()
#9 /var/www/html/web/core/lib/Drupal/Core/Plugin/Factory/ContainerFactory.php(16): Drupal\Core\Plugin\DefaultPluginManager->getDefinition()
#10 /var/www/html/web/core/lib/Drupal/Component/Plugin/PluginManagerBase.php(83): Drupal\Core\Plugin\Factory\ContainerFactory->createInstance()
#11 /var/www/html/web/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php(824): Drupal\Component\Plugin\PluginManagerBase->createInstance()
#12 /var/www/html/web/core/modules/views/src/Plugin/views/style/StylePluginBase.php(133): Drupal\views\Plugin\views\display\DisplayPluginBase->getPlugin()
#13 /var/www/html/web/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php(827): Drupal\views\Plugin\views\style\StylePluginBase->init()
#14 /var/www/html/web/core/modules/rest/src/Plugin/views/display/RestExport.php(348): Drupal\views\Plugin\views\display\DisplayPluginBase->getPlugin()
#15 /var/www/html/web/core/modules/views/src/EventSubscriber/RouteSubscriber.php(120): Drupal\rest\Plugin\views\display\RestExport->collectRoutes()
#16 [internal function]: Drupal\views\EventSubscriber\RouteSubscriber->routes()
#17 /var/www/html/web/core/lib/Drupal/Core/Routing/RouteBuilder.php(146): call_user_func()
#18 /var/www/html/web/core/lib/Drupal/Core/ProxyClass/Routing/RouteBuilder.php(83): Drupal\Core\Routing\RouteBuilder->rebuild()
#19 /var/www/html/web/core/includes/common.inc(454): Drupal\Core\ProxyClass\Routing\RouteBuilder->rebuild()
#20 /var/www/html/web/core/includes/utility.inc(41): drupal_flush_all_caches()
#21 /var/www/html/vendor/drush/drush/src/Commands/core/CacheRebuildCommands.php(60): drupal_rebuild()
#22 [internal function]: Drush\Commands\core\CacheRebuildCommands->rebuild()
#23 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array()
#24 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback()
#25 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(175): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter()
#26 /var/www/html/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(387): Consolidation\AnnotatedCommand\CommandProcessor->process()
#27 /var/www/html/vendor/symfony/console/Command/Command.php(279): Consolidation\AnnotatedCommand\AnnotatedCommand->execute()
#28 /var/www/html/vendor/symfony/console/Application.php(1094): Symfony\Component\Console\Command\Command->run()
#29 /var/www/html/vendor/symfony/console/Application.php(342): Symfony\Component\Console\Application->doRunCommand()
#30 /var/www/html/vendor/symfony/console/Application.php(193): Symfony\Component\Console\Application->doRun()
#31 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run()
#32 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun()
#33 /var/www/html/vendor/drush/drush/drush.php(140): Drush\Runtime\Runtime->run()
#34 /var/www/html/vendor/bin/drush.php(119): include('...')
#35 {main}
thrown in /var/www/html/web/modules/contrib/workflow/src/Hook/WorkflowViewsHooks.php on line 58

Fatal error: Uncaught Error: Class "Drupal\workflow\Entity\WorkflowTargetEntity" not found in /var/www/html/web/modules/contrib/workflow/src/Hook/WorkflowViewsHooks.php:58
Stack trace:
#0 /var/www/html/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(459): Drupal\workflow\Hook\WorkflowViewsHooks->viewsDataAlter()
#1 /var/www/html/web/core/modules/views/src/ViewsData.php(228): Drupal\Core\Extension\ModuleHandler->alter()
#2 /var/www/html/web/core/modules/views/src/ViewsData.php(142): Drupal\views\ViewsData->getData()
#3 /var/www/html/web/core/modules/views/src/Plugin/Derivative/ViewsEntityRow.php(94): Drupal\views\ViewsData->get()
#4 /var/www/html/web/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(101): Drupal\views\Plugin\Derivative\ViewsEntityRow->getDerivativeDefinitions()
#5 /var/www/html/web/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(87): Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDerivatives()
#6 /var/www/html/web/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(337): Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDefinitions()
#7 /var/www/html/web/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(213): Drupal\Core\Plugin\DefaultPluginManager->findDefinitions()
#8 /var/www/html/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryCachedTrait.php(22): Drupal\Core\Plugin\DefaultPluginManager->getDefinitions()
#9 /var/www/html/web/core/lib/Drupal/Core/Plugin/Factory/ContainerFactory.php(16): Drupal\Core\Plugin\DefaultPluginManager->getDefinition()
#10 /var/www/html/web/core/lib/Drupal/Component/Plugin/PluginManagerBase.php(83): Drupal\Core\Plugin\Factory\ContainerFactory->createInstance()
#11 /var/www/html/web/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php(824): Drupal\Component\Plugin\PluginManagerBase->createInstance()
#12 /var/www/html/web/core/modules/views/src/Plugin/views/style/StylePluginBase.php(133): Drupal\views\Plugin\views\display\DisplayPluginBase->getPlugin()
#13 /var/www/html/web/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php(827): Drupal\views\Plugin\views\style\StylePluginBase->init()
#14 /var/www/html/web/core/modules/rest/src/Plugin/views/display/RestExport.php(348): Drupal\views\Plugin\views\display\DisplayPluginBase->getPlugin()
#15 /var/www/html/web/core/modules/views/src/EventSubscriber/RouteSubscriber.php(120): Drupal\rest\Plugin\views\display\RestExport->collectRoutes()
#16 [internal function]: Drupal\views\EventSubscriber\RouteSubscriber->routes()
#17 /var/www/html/web/core/lib/Drupal/Core/Routing/RouteBuilder.php(146): call_user_func()
#18 /var/www/html/web/core/lib/Drupal/Core/ProxyClass/Routing/RouteBuilder.php(83): Drupal\Core\Routing\RouteBuilder->rebuild()
#19 /var/www/html/web/core/includes/common.inc(454): Drupal\Core\ProxyClass\Routing\RouteBuilder->rebuild()
#20 /var/www/html/web/core/includes/utility.inc(41): drupal_flush_all_caches()
#21 /var/www/html/vendor/drush/drush/src/Commands/core/CacheRebuildCommands.php(60): drupal_rebuild()
#22 [internal function]: Drush\Commands\core\CacheRebuildCommands->rebuild()
#23 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array()
#24 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback()
#25 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(175): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter()
#26 /var/www/html/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(387): Consolidation\AnnotatedCommand\CommandProcessor->process()
#27 /var/www/html/vendor/symfony/console/Command/Command.php(279): Consolidation\AnnotatedCommand\AnnotatedCommand->execute()
#28 /var/www/html/vendor/symfony/console/Application.php(1094): Symfony\Component\Console\Command\Command->run()
#29 /var/www/html/vendor/symfony/console/Application.php(342): Symfony\Component\Console\Application->doRunCommand()
#30 /var/www/html/vendor/symfony/console/Application.php(193): Symfony\Component\Console\Application->doRun()
#31 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run()
#32 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun()
#33 /var/www/html/vendor/drush/drush/drush.php(140): Drush\Runtime\Runtime->run()
#34 /var/www/html/vendor/bin/drush.php(119): include('...')
#35 {main}
thrown in /var/www/html/web/modules/contrib/workflow/src/Hook/WorkflowViewsHooks.php on line 58

Test 2 for 4.3.x

Added patch for 4.3.x

Thank you for the patch @f0ns

The MR applies on D11.1.4 but then my site throws error:
Class "Drupal\Core\Render\RenderArray" not found

The patch from #13 fixes the issue, so for now use that instead of the MR

Can confirm the bug in views_load_more 2.0.0 in Drupal 11.1.3 and can also confirm that patch #3 fixes it.

I had a project that I upgraded from D10.4.3 to D11.1.3

After update instead of seeing the website, I was seeing this error:

The website encountered an unexpected error. Try again later.

LogicException: The complete set of cache contexts for a variation cache item must contain all of the initial cache contexts, missing: url.site. in Drupal\Core\Cache\VariationCache->set() (line 47 of core/lib/Drupal/Core/Cache/VariationCache.php).
Drupal\Core\Render\RenderCache->set() (Line: 120)
Drupal\Core\Render\PlaceholderingRenderCache->set() (Line: 539)
Drupal\Core\Render\Renderer->doRender() (Line: 459)
Drupal\Core\Render\Renderer->doRender() (Line: 203)
Drupal\Core\Render\Renderer->render() (Line: 484)
Drupal\Core\Template\TwigExtension->escapeFilter() (Line: 88)
__TwigTemplate_e713a3461e456cb3d4ba7da0e93bf6aa->doDisplay() (Line: 388)
Twig\Template->yield() (Line: 344)
Twig\Template->display() (Line: 359)
Twig\Template->render() (Line: 51)
Twig\TemplateWrapper->render() (Line: 33)
twig_render_template() (Line: 348)
Drupal\Core\Theme\ThemeManager->render() (Line: 446)
Drupal\Core\Render\Renderer->doRender() (Line: 203)
Drupal\Core\Render\Renderer->render() (Line: 158)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 153)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse() (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray() (Line: 246)
Symfony\Component\EventDispatcher\EventDispatcher::Symfony\Component\EventDispatcher\{closure}() (Line: 206)
Symfony\Component\EventDispatcher\EventDispatcher->callListeners() (Line: 56)
Symfony\Component\EventDispatcher\EventDispatcher->dispatch() (Line: 188)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)

I have no idea what contrib or custom module is responsible for invoking that error. I do not use workspaces. But the MR fixed the problem and the project is now working again after the D11 update.

flyke → created an issue.

flyke → created an issue.

flyke → created an issue.

This helped me:
composer dump-autoload -o

This helped me:
composer dump-autoload -o

I needed to have the option from this issue to set alt and title for each uploaded item. But I needed it in a D11 project. So I also needed the D11 compatibility from #3431856. Since there were still some issues with current patch, I thought it would be better to create a seprate MR that applies after applying D11 compatibility from #3431856.

But I was unable to figure out how to do that. So the new MR I created contained all D11 compatibility changes from #3431856 as well as all the code for bulk alt titles from this issue.

However, I had to close that new MR because I seem to have messed it up. I applied necessary changes in the MR20 first from #3431856 and then the changes from this issue. But then ran into merge conflicts because branch 8.x-1.x was behind and then it went downhill from there.

We really need a working D11 branch first (without patch) and then start adding functionality from this issue from there instead of trying to combine both D11 compatibility with bulk alt title options

I seem to have these issues now:

Warning: Array to string conversion in Drupal\flexmail_webform\Plugin\WebformHandler\FlexmailWebformHandler->contactNeedsUpdating() (line 306 of modules/contrib/flexmail/modules/flexmail_webform/src/Plugin/WebformHandler/FlexmailWebformHandler.php).

Warning: Array to string conversion in Drupal\flexmail_webform\Plugin\WebformHandler\FlexmailWebformHandler->contactNeedsUpdating() (line 306 of modules/contrib/flexmail/modules/flexmail_webform/src/Plugin/WebformHandler/FlexmailWebformHandler.php).

Warning: Undefined array key "interest" in Drupal\flexmail_webform\Plugin\WebformHandler\FlexmailWebformHandler->postSave() (line 262 of modules/contrib/flexmail/modules/flexmail_webform/src/Plugin/WebformHandler/FlexmailWebformHandler.php).

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

The MR does NOT apply to 2.0.x-dev. But it does apply to 2.0.0-beta4. Should we change this issue to 'needs work' so we can work so it applies to 2.0.x-dev, or should we change the Version in this issue to 2.0.0-beta4 and set it to reviewed and tested by the community (me) ?

I have no idea why this patch does not work.
It applies.
I can see in web/modules/contrib/file_delete/file_delete.install inside file_delete_update_400003() that there is absolutely no 'delete files' in that code. Yet, if I try running drush updb -y, then I always get the error

>  [notice] Update started: file_delete_update_400003
>  [error]  Adding non-existent permissions to a role is not allowed. The incorrect permissions are "delete files". 
>  [error]  Update failed: file_delete_update_400003 

It makes no sense. I cleared caches multiple times, I restarted my local project, I emptied cache tables, I do not get why the error references a problem with 'delete files' whle that is not literally in the code

function file_delete_update_400003(): void {
  $roles = Role::loadMultiple();
  foreach ($roles as $role) {
    if ($role->hasPermission('delete own files') || $role->hasPermission('delete any files')) {
      $role->grantPermission('delete files override usage');
      $role->grantPermission('delete files immediately');
      $role->save();
    }
  }
}

So to fix this, I just exported my config using drush cex -y, then I searched in my config folder for delete files, which was inside a user.role.somerolename.yml file. I deleted that line and imported my config using drush cim -y and after that I had no problem running drush updb -y. Lastly, I edited the role via the admin UI to give back the delete files permissions.

After upgrading the project to D11 this way, I got this error in status reports:
AMP
Not available
The AMP module requires the PHP AMP library.

So this still needs work.

Yeah, I ran into this problem when updating my project from D10.4.1 to D11.1.1.
The MR fixed it.

Adding this in my repositories section in my composer.json file helped me (thanks to #3325977 🐛 php 8.1 - lullabot/amp seems abandoned: replace abandoned querypath/querypath with gravitypdf/querypath Active ):

{
            "type": "package",
            "package": {
                "name": "lullabot/amp",
                "version": "2.0.4",
                "type": "composer",
                "source": {
                    "type": "git",
                    "url": "https://github.com/deimosindustries/amp-library.git",
                    "reference": "6a3074586ead73cd47cb4fc4e2c429df19fcc2b6"
                }
            }
        },

with this added in + adding this issue via drupal lenient, I was able to upgrade my project to D11.

I can confirm that the MR applies BUT i can also confirm what @elisur says: Even with this MR applied, you cant use this module in your D11 project because of the version requirement of lullabot/amp. That should be updated as well.

This is the only module blocking the update to D11 in this project.

Will it work if the required lullabot/amp version gets updated in the MR ?
Maybe "lullabot/amp": "^1.1 || ^2.0.4", should become "lullabot/amp": "^1.1 || ^2.0.4 || ",

Patch does not apply to 3.0.0

The MR applies to the 3.0.0 branch but does not apply to latest dev branch at tis moment.

flyke → created an issue. See original summary → .

I had this annoying thing in my project when sometimes when you open a page the dropbutton would display as open so you see all the language links but the triangle down icon was missing, and sometimes it would work, showing only the current language with the dropdown button (triangle down icon) next to it. Refreshing the page is like playing russian roulette on whether the dropdown language would work or not. about 3/5 of the time it would not work correctly.

When it does not work correctly, the wrapper looks like this:
<div class="dropbutton-wrapper">
Also the <li> elements are missing classes like dropbutton-action

When it works correctly, the wrapper looks like this:
<div class="dropbutton-wrapper dropbutton-multiple" data-drupal-ajax-container="" data-once="dropbutton">
and the li elements inside have their correct classes.

Adding this (applied the MR on 4.0.3) fixed this issue for me.

Yeah, this is definitly a duplicate of #2923273 🐛 Icons don't show up if theme is not subtheme of "stable" Needs work

I have the same issue in D11.1 with geysir 2.1.0-rc1 and using gin as admin theme (irrelevant) and a custom theme as frontend theme that has no base theme.
The code from #3 fixes this.

It unfortunatly took me a while to find out that the phantom 'preview' module is actually the 'all_entity_preview' module.
I downloaded and enabled that module.
While editing I can now enable preview and see my changes live, but still, after saving when the page is refreshed, the changes are not there.
'Preview' and 'Response' are still empty of the request to

https://mysite.com/frontend-editing/form/paragraph/31584?view_mode_id=default&ajax_form=1&_wrapper_format=drupal_ajax

despite the fact that the element does get a data-preview attribute now, like:
<div data-preview="75853dfa-396b-448d-a56d-df180a1cafab" class="frontend-editing contextual-region p--text">

Actually I see multiple references in the code to this phantom 'preview' module which I cannot find anywhere.
I searched the whole codebase of my project for 'name: preview' (for finding modules by their info.yml file) and for 'drupal/preview' for finding modules based on their composer.json file. No results at all.

If I try to directly guess the url of the 'preview' module by typing in the address bar: ' https://www.drupal.org/project/preview → ' then I get redirected to another module ' https://www.drupal.org/project/preview_disable → '.
I don't get it at all, please describe where this preview module comes from that is referenced to inside the frontend_editing code.

It seems the elements never get the data-preview attribute because I dont have a module named 'preview' enabled ?

  if (\Drupal::moduleHandler()->moduleExists('preview')) {
    // Check if preview is allowed.
    $preview_config = \Drupal::config('preview.settings')->get('enabled') ?? [];
    if (!empty($preview_config[$entity->getEntityTypeId()][$entity->bundle()])) {
      $build['#attributes']['data-preview'] = $entity->uuid();
    }
  }

I seem to have the same issue.

Project recently updated to Drupal 10.4.1.
Using frontend_editing 1.8.9

Please see attached video for more info regarding to the response: its empty.

Not sure what I'm doing wrong, but @luke.leber's method executed without errors but it did not solve anything in my project.
On the left side of the screenshot you can see in the terminal below that it executed the 2 updates.
On the right side of the screenshot: that is refreshed after the updates were executed. You can see the errors are still there in my case.

After this, I tried my own code from #236 and that actually fixed and removed all the errors.

Thank you laboratory.mike, your solution is a perfect stop gap until we get an actual settings page and this functionality incorporated into the module itself.

/**
 * Implements hook_mail().
 */
function mymodule_helper_cron() {
  // Delete old mail logs.
  $now = new DrupalDateTime('-90 days');
  $delete = \Drupal::database()->delete('mail_safety_dashboard');
  $delete->condition('sent', $now->getTimestamp(), '<');
  $delete->execute();
}

Please note that without patch, 2.x-dev is already D11 compatible according to requirements.
Anyway: I can confirm that I could apply MR 17 to 2.x-dev.

I had a D10.4 project that I updated to D11.1
BUT after updating to D11 and updating ckeditor_media_embed to 2.x-dev (with this MR applied) my site was unusable because of errors caused by ckeditor_media_embed.

I created issue #3499886 🐛 CliCommandWrapper constructor requires LibraryDiscoveryInterface Active for those errors that seem to be an immediate result of upgrading to D11 or updating ckeditor_media_embed to 2.x-dev (not sure which one).

This works. I successfully applied MR 2 to 1.0.0-alpha3 and upgraded my project from D10.4 to D11.1

MR 8 works, applied it to 1.0.0-alpha8 and successfully updated the project from D10.4 to D11.1

+1, tested and MR3 works in my project. Successfuly updated it from D10.4 to D11.1

MR also works on 2.0.0-alpha2 at the moment.
Applies, and I upgraded tot D11 and have no issues.

@jurgenhaas: apologies, tried this today on another project that I have now successfully updated from D10.4 to D11.1.
The MR applied and all seems to be working. No idea why the MR did not apply to the other project, probably a confmicting patch or something.

Fixed the new second issue in attached patch

Added a patch to fix the issue.

Hi @acbramley I don't understand how to use your method, more specifically, how to run it.
I have an enabled custom module 'starterkit_helper'.
In there, I created starterkit_helper.post_update.php file. The contents from the first file of your gist.
Of course inside i changed 'my_profile' to 'starterkit_helper'.
I also created a file starterkit_helper/src/MyProfileUpdateUtils.php. The contents from the second file of your gist.
Of course inside i changed 'my_profile' to 'starterkit_helper'.

I ran drush cr and then drush updb -y but nothing happened, nothing run, en the errors
Deprecated : Creation of dynamic property Drupal\layout_builder\SectionComponent::$legacyAdditionalModuleKey is deprecated in /var/www/html/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php on line 1264
remain

How do I run this code ?

Applies in my D11 project and I got no errors.

I confirm #16: The MR did not apply to the latest dev, but patch from #17 did.

I tested layout_builder_ipe 1.0.0-beta10 on a D11 project and it works well.