🇧🇪Belgium @flyke

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.

I think this can be closed as 8.x-1.8 supports D11

This patch does not apply to latest dev a the moment (8.x-1.x-dev)
It also does not apply to 8.x-1.0-beta12

Previous patch was apparently missing the new UploadRedirectManager class file.

So ehm... in the end my problem was not solved after updating jquery_ui.
While I got no erros on my local development environment, on production I kept getting the error:
An error occurred during the execution of the Ajax response: TypeError: i.ui.safeActiveElement is not a function

After a deep dive down the rabbit hole, for some reason the error originated from:
core/assets/vendor/jquery.ui/ui/widgets/menu-min.js

That file is not in any gitignore file that I created but yet somehow after successful deployments, it does not seem to get updated after deployment. My local menu.min.js file does not contain 'safeActiveElement' but the one on the server after deployment still does.
I checked the file directly in my projects repository, its the correct file in there. I cannot find any reason at all why the file on the server is still old version after deployment. The deployment script also clears caches two times, but still that does not help.

I manually overridden the core/assets/vendor/jquery.ui/ui/widgets/menu-min.js on the server with that of my local environment via FileZilla, and now finally I got rid of the error on production and the modal link is working again.

This MR only changes the reported version in assets/vendor/jquery.ui/ui/version.js.

But all code is still 1.13.
This causes errors when jquery_ui uses old stuff that is no longer present in 1.14.

I get the error:
An error occurred during the execution of the Ajax response: TypeError: i.ui.safeActiveElement is not a function

According to the jQuery UI 1.14 changelog and release notes safeActiveElement is removed.

However, if I scan the code of jquery_ui after using this patch for 'safeActiveElement', I get 31 results in 21 files.
I think the correct amount should be zero.

If I scan the code of jquery_ui after using this patch for '1.13.', I get 283 results in 122 files.
I think the correct amount here should also be zero ?

So this patch just pretends to do something by changing the reported version, but the reported version is a lie because none of the code has been updated ?

Ok, this is probably a duplicate, apologies.

Added a screenshot of Chome's console error + Chromes AI 'Understand this error' result

flyke → created an issue.

A bit of a relief to know I'm not the only one facing this problem. I did spent quite a lot of time figuring this out and coming up with a woking solution. Glad that it has helped someone. Maybe someone could use my code as a starting point to make it more elegant/efficient and include revisions.

Since my custom code to get all layoutbuilder nodes as only 2 lines, I will update my code examply from above so everyone could copy/paste it.

Here is a patch that I hope works after applying #3431856.

@giordy: I am currently using patch from #16 in D11.1.1

MR 14 does not apply to media_bulk_upload 3.0.x-dev on D11 when first applying patch #3431856 (via drupal lenient) to make this module D11 compatible.

We need either:
- a new release of this module that works on D11 first (preferable), change the version of this issue, and then patch this issue against that new D11 version,
- or we need a new patch here that works in combination with patch from #3431856.

The MR applies and I can update my project from D10 to D11 using drupal lenient.
But when I try to use media_bulk_uploads, I get this error:
Call to a member function guessMimeType() on null

comming from this piece of code:

      $show_alt = (boolean) $media_bulk_config->get('show_alt');
      $alt_required = (boolean) $media_bulk_config->get('alt_required');
 
      foreach ($uploaded_files as $uploaded_file) {
        $errors = [];
 
        // Validate file alt.
        $mime = $this->mimeTypeGuesser->guessMimeType($uploaded_file['path']);

The mimeTypeGuesser is never instantiated.

If I try to find the origin of these errors, I edited web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php and added dpm($row->$column_name); right before line 1263. Result is in attached schreenshot. The value of $column_name is layout_builder__layout_section. So I guess this is the serialized data of an existing layoutbuilder section that was no problem at all when the project was on D10 (including diff from this issue) but is a problem now when the project is updates to D11 (including diff from this issue).

I have no idea on how to remove this data from existing sections. I cannot create edit or save sections or blocks using layoutbuilder becasue that too shows these errors.

I updated my project to D11.1 and I could no longer use this module to edit the page.
JS error:

Uncaught TypeError: Cannot read properties of undefined (reading 'message')
    at Drupal.behaviors.lb_ipe_attach_behaviors.attach.$ajax_link.get.options.error (ipe.js?v=11.1.1:82:67)
    at c (jquery.min.js?v=4.0.0-beta.2:2:23212)
    at Object.fireWith [as rejectWith] (jquery.min.js?v=4.0.0-beta.2:2:23973)
    at E (jquery.min.js?v=4.0.0-beta.2:2:69804)
    at XMLHttpRequest.<anonymous> (jquery.min.js?v=4.0.0-beta.2:2:72283)

If I disable this module and just use layoutbuilder to edit the page, that works fine.

If I use MR 5053 on Drupal 11.1.1 I get multiple notices on each page:
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

Changed version because the MR is not compatible anymore with 3.0.0

The project I'm working on is still on Drupal 10, so I cannot confirm it works on D11.
But, the dev version does work (without any patch as mentionned above) without problems here and upgrade_status module now reports this module as D11 compatible.

Update

I simply searched my codebase (modules/custom) for 'entity.webform.collection' and I have a custom module 'toolbar_adjustments' which adds a main link to webforms in the toolbar that is provided by the Navigation (Core experimental) module.

/**
 * Implements hook_preprocess_HOOK().
 *
 * Make changes to the Navigation.
 */
function toolbar_adjustments_preprocess_navigation_menu(&$variables) {

  // ... lots of other toolbar link adjustments here

  // Add a main link to webforms in the Content section.
  if (
    $variables['menu_name'] === 'content'
    && \Drupal::service('module_handler')->moduleExists('webform')
    && $current_user->hasPermission('access webform overview')
  ) {
    $variables['items']['entity.webform.collection'] = [
      'is_expanded' => FALSE,
      'is_collapsed' => FALSE,
      'in_active_trail' => FALSE,
      'title' => t('Webforms'),
      'url' => Url::fromRoute('entity.webform.collection'),
      'below' => [],
      'class' => 'webform',
    ];

  // ... even more toolbar link adjustments here
  }

I commented that part out, and while drush cr still gave the Route "webform.addons" does not exist error, I could now visit and see my site again while being logged in, instead of having the WSOD. So now I was able to manually clear the caches via the UI. After that, also the drush cr command worked without a problem.

Have the same error, also on DDEV, after updating webform to 6.3.0-beta1.

ddev restart did not work for me, also drush cr or drush updb did not work.
I truncated the cachetags and every cache_* table, that also did not fix the issue.

I cannot clear cache through the UI because every page throws that error.
I reverted to webform 6.2.9 via composer, but now the error still persists, I cannot get rid of it.

Patch should be updated for 1.2.2 or 1.2.x

I had this error on each page after upgrading to D10.4.1.
Patch #16 fixed it.
But if the source of the problem is that there is code or a theme trying to load an unexisting library, shouldn't we log a clear error instead ?
something like Module responsive_image is trying to load a library that does not exist: 'responsive_image/ajax'

flyke → created an issue.

Tested and this patch works on the 2.0.0-alpha2 branch too.

I am now using drupal lenient to be able to use D10 modules that have a D11 compatible patch in aD11 project.

Add the patch in your composer.json patches section.

            "drupal/devel_entity_updates": {
                "#3454902 D11": "https://git.drupalcode.org/project/devel_entity_updates/-/merge_requests/5.diff"
            }

If you don't have composer-drupal-lenient yet, add it to your project first:
composer require mglaman/composer-drupal-lenient
If your minimum stability is not set to dev yet, you need to do that first:
composer config minimum-stability dev
Add this module to the lenient allowed list:
composer config --merge --json extra.drupal-lenient.allowed-list '["drupal/devel_entity_updates"]'
Now you can add the latest dev with this patch to your project=
composer require 'drupal/devel_entity_updates:5.0.x-dev@dev'

I think if someone wants to tackle this, then a lot of this code can be used.
It is from issue #3097660 ✨ Add layout builder (inline) block support Needs work (Add layout builder (inline) block support) of the Translation Management Tool (tmgmt) module → .

The issue is about adding support for creating translations for layout builder blocks for that module.
But I am quite sure that a lot of that code could be reused for this issue for this module.

I am working on a webshop for a client and at this instance, we dont need multiple variations per product yet.

So for the default product settings, we unchecked the box that a product can have multiple variations at /admin/commerce/config/product-types/default/edit

So now we dont need to bother with variations and set a price directly on the product edit page.

But for displaying the price, These steps dont work. I tried to follow them to the letter but it looks like not a single soul that worked on Commerce has thought that someone might want to display the price on the manage display of a Product when that mentioned checkbox is unchecked.

Rather than complaining, I just created a pseudo field that will show up on the manage display tab of the Product so that I can finally display the price.

I have a custom module 'commerce_product_adjustments' and this is the necessary code to create a pseudo 'price' field that you can use on the Manage display tab of the product. If your Product is not 'default' you need to change it in $display_fields['commerce_product']['default']['display']['price']

<?php

/**

* @file

*/

use Drupal\commerce_product\Entity\Product;

use Drupal\commerce_product\Entity\ProductVariation;

use Drupal\Core\Entity\Display\EntityViewDisplayInterface;

/**

* Implements hook_entity_extra_field_info().

*

* Add custom fields that work without display suite.

*/

function commerce_product_adjustments_entity_extra_field_info() {

$display_fields = [];

$display_fields['commerce_product']['default']['display']['price'] = [

'label' => t('Product price'),

'weight' => 100,

'visible' => FALSE,

];

return $display_fields;

}

/**

* Implements hook_ENTITY_TYPE_view().

*

* Create the content of our custom fields for commerce products.

*/

function commerce_product_adjustments_commerce_product_view(array &$build, Product $product, EntityViewDisplayInterface $display, $view_mode) {

if ($display->getComponent('price')) {

// dpm($product);

$variation = _commerce_product_adjustments_get_product_variation($product);

// dpm($variation);

$build['price'] = [

'#type' => 'inline_template',

'#template' => '{{ price|commerce_price_format }}',

'#context' => [

'price' => ['number' => $variation->price->number, 'currency_code' => $variation->price->currency_code],

],

];

}

return $build;

}

I think we need a version of media_contextual_crop_iwc_adapter that works with image_widget_crop 3.0.x-dev
Since image_widget_crop 3.0.x-dev is D11 compatible.

I think the MR does not apply anymore to the latest 8.x-1.x-dev ?

Patch does not apply in 10.0@alpha2, BUT, I tested using a token in /admin/config/system/front/home-links and it works without a patch.

Added a patch, testing it out now.

flyke → created an issue.

Update, I think I got it how to create a patch for 11.0.5 with minimal effort.
- checkout 11.0.5 in a clean Drupal repo clone:
git checkout tags/11.0.5
- copy the (incompatible) 11.x diff file in the root (5053.diff)
- use this command to apply all the parts the patch that do work:
git apply --reject --index 5053.diff
- Notice that there is only 1 error: error: core/misc/cspell/dictionary.txt: does not match index
- manually edit dictionary.txt with the necessary changes (add 4 missing words in the right place)
- remove the 5053.diff file
- create a patch
git diff > 3015152-225.patch
I think it might work.

Here is a patch for Drupal 11.0.5.

If anyone needs to add this module to a D11 project, here are instructions if you have not done it before.

Add the patch in your composer.json patches section.

            "drupal/image_widget_crop": {
                "#3451140": "https://git.drupalcode.org/project/image_widget_crop/-/merge_requests/24.diff"
            }

If you don't have composer-drupal-lenient yet, add it to your project first:
composer require mglaman/composer-drupal-lenient

If your minimum stability is not set to dev yet, you need to do that first:
composer config minimum-stability dev

Add this module to the lenient allowed list:
composer config --merge --json extra.drupal-lenient.allowed-list '["drupal/image_widget_crop"]'

Now you can add this module to your D11 project:
composer require 'drupal/image_widget_crop:2.x-dev@dev'

And of course you can enable it
drush en image_widget_crop

None of the branches (diff files) or patches seem to apply to Drupal 11.0.5

If anyone needs to add this module to a D11 project, here are instructions if you have not done it before.

Add the patch in your composer.json patches section.

            "drupal/layout_builder_save_and_edit": {
                "#3431597": "https://git.drupalcode.org/project/layout_builder_save_and_edit/-/merge_requests/6.diff"
            }

If you don't have composer-drupal-lenient yet, add it to your project first:
composer require mglaman/composer-drupal-lenient

If your minimum stability is not set to dev yet, you need to do that first:
composer config minimum-stability dev

Add this module to the lenient allowed list:
composer config --merge --json extra.drupal-lenient.allowed-list '["drupal/layout_builder_save_and_edit"]'

Now you can add this module to your D11 project:
composer require drupal/layout_builder_save_and_edit

And of course you can enable it
drush en layout_builder_save_and_edit

If anyone needs to add this module to a D11 project, here are instructions if you have not done it before.

Add the patch in your composer.json patches section.

            "drupal/layout_builder_at": {
                "#3431569": "https://git.drupalcode.org/project/layout_builder_at/-/merge_requests/14.diff"
            }

If you don't have composer-drupal-lenient yet, add it to your project first:
composer require mglaman/composer-drupal-lenient

If your minimum stability is not set to dev yet, you need to do that first:
composer config minimum-stability dev

Add this module to the lenient allowed list:
composer config --merge --json extra.drupal-lenient.allowed-list '["drupal/layout_builder_at"]'

Now you can add this module to your D11 project:
composer require drupal/layout_builder_at

And of course you can enable it
drush en layout_builder_at

If anyone needs to add this module to a D11 project, here are instructions if you have not done it before.

Add the patch in your composer.json patches section.

            "drupal/layout_builder_browser": {
                "#3431577": "https://git.drupalcode.org/project/layout_builder_browser/-/merge_requests/23.diff"
            }

If you don't have composer-drupal-lenient yet, add it to your project first:
composer require mglaman/composer-drupal-lenient

If your minimum stability is not set to dev yet, you need to do that first:
composer config minimum-stability dev

Add this module to the lenient allowed list:
composer config --merge --json extra.drupal-lenient.allowed-list '["drupal/layout_builder_ipe"]'

Now you can add this module to your D11 project:
composer require drupal/layout_builder_ipe

And of course you can enable it
drush en layout_builder_ipe

Testing if this works by simply changing the core_version_requirement in the info yml file.

flyke → created an issue.

If anyone needs to add this module to a D11 project, here are instructions if you have not done it before.

Add the patch in your composer.json patches section.

            "drupal/layout_builder_browser": {
                "#3431577": "https://git.drupalcode.org/project/layout_builder_browser/-/merge_requests/23.diff"
            }

If you don't have composer-drupal-lenient yet, add it to your project first:
composer require mglaman/composer-drupal-lenient

Add this module to the lenient allowed list:
composer config --merge --json extra.drupal-lenient.allowed-list '["drupal/layout_builder_browser"]'

Now you can add this module to your D11 project:
composer require drupal/layout_builder_browser

And of course you can enable it
drush en layout_builder_browser

Hi,

I think the video in the description of this issue is misleading, since it's also showing adjusting layout etc I think.
But I am starting to partially get it, probably still wrong about some stuff here.
edit_plus / edit_plus_lb: in-place editing of plain texts and wysiwyg texts. Works on my testing on some of our custom layout builder blocks but not on all of our custom layout builder blocks that have multiple fields including a plain or long text field.
lb_plus / lb_plus_edit_plus: for editing sections, blocks, images, ... Could not get this properly working on our test site.

The subquestion to edit icon for all blocks is resolved. It seems you can now set icon for every possible block at /admin/structure/block/icons.

However, the original issue was a request to be able to upload a file for an icon. Maybe that should still be discussed ? For my opinion it is not necessary, but it is something you can do for Paragraphs: when you create/edit a paragraph then you have the option to either set a path or upload a file for the icon. It makes sense to apply the same options here.

I think you also need to have and enable edit_plus module and edit_plus_lb module (which is a submodule of edit_plus)

flyke → created an issue.

flyke → created an issue.

You are correct, there is no config for the display of this block, there is no core.entity_view_display.block_content.starterkit_horizontal_line.default.yml

So the question is, do we modify toolbar_plus to fallback to 'default' if it cant get the config, or is 'illegal' and should it be impossible to have blocks without a display setting ? On our end, we could programmatically create a custom 'hr' field, add that to the Manage display of the block type and then I think the error would be solved.

Steps to reproduce:
- Visit admin/structure/block-content/add
- Give the new block type a label
- save it, dont add fields, dont change 'Manage display'
- add this block on a layoutbuilder page
- visit the page

This will result in an error. Is that what we want, so every developer is forced to have a display config of each block type ? Or should toolbar_plus handle this gracefully, by changing toolbar_plus.module line 97 into:
$cached_view_modes[$original_id] = $view_display ? $view_display->getMode() : 'default'; for example ?

You were spot on from the beginning: Our custom theme did have a field.html.twig override.
I removed that and all is working, so it was indeed caused by our custom theme.

In comparison, the actual value of data-edit-plus-field-value-wrapper is:
block_content::54e7d573-bf17-40b1-bcad-2cca8ffb85bb::label::block_property
The ID that getPageElementWrapper() in editable-element.js is looking for is:
block_content::54e7d573-bf17-40b1-bcad-2cca8ffb85bb::text_body::value

So now its up to check why these two dont match.

EditableElement.getPageElementWrapper() returns null, not sure yet why.
I added some output.

I added a dpm() inside edit_plus.module first to make sure that it reached that code and added the whole edit_plus_wrapper.
Screenshot 1 is dpm output for the textfield element I'm trying to change. it confirms that it does indeed reach that code and adds the edit_plus_wrapper.
The rest of the screenshots is to show that trhoughout the whole process, data-edit-plus-field-value-wrapper attribute is in fact present.