🇨🇦Canada @smulvih2

Ya that makes sense for a ticket with only a patch file, but a PR would have to be against wxt_library if that's where you are adding the block class file, and you can't raise a PR against wxt_library in a wxt issue. And now that we have added GitLab tests to all sub-projects (wxt_library, wxt_bootstrap) it's nice to have the tests run against the PR so issues can be identified and fixed before merging.

The only thing preventing this from being merged to wxt_library is knowing how to deal with the column classes in the AJAXed content. Not sure why they would add wrapping column classes, that should be left to the system implementing the block. I'm not able to get the block in the proper layout without hacking the CSS and overriding the column class styles. How are you guys doing this? If the answer is fixing with CSS, I can merge as is and maybe we can ask them to remove those column classes from source. If you have a better way to handle this then it would be good to have documented in this ticket for others to see. Thanks!

@joseph I merged your PR and ran test against it, see failures - https://github.com/drupalwxt/wxt/actions/runs/14644362578

Also testing this in my local I get this error:

The website encountered an unexpected error. Try again later.
TypeError: Drupal\layout_builder_st\DependencyInjection\ClassResolver::__construct(): Argument #1 ($decorated) must be of type Drupal\Core\DependencyInjection\ClassResolverInterface, Drupal\Core\DependencyInjection\Container given, called in /var/www/html/core/lib/Drupal/Component/DependencyInjection/Container.php on line 259 in Drupal\layout_builder_st\DependencyInjection\ClassResolver->__construct() (line 14 of modules/contrib/layout_builder_st/src/DependencyInjection/ClassResolver.php).

Sorry I thought your PR branch had already ran against the tests, but it appears not. Your PR is marked as Merged, although it has been reverted from 6.1.x, so you will need to reopen a PR and run the tests against it to make sure things work. Thanks!

Adding patch from PR here so I can use it in my project.

Actually this patch appears to be a copy of the PR from here - https://www.drupal.org/project/toc_filter/issues/3518549 🐛 Fatal error after updating to toc_api:^2 Active

@joseph, I'm a bit lost with this patch:

"drupal/toc_filter": {
    "3455312 and 3540464 - D11 fix":
    "https://www.drupal.org/files/issues/2025-04-23/3455312-and-3520464-45.patch"
 }

This is a toc_filter patch added to a toc_api issue (#3455312) that has been marked as Fixed (it will not progress like this). You should create a toc_filter ticket for this so that it has a chance of being reviewed and merged into the toc_filter project. Also, I can't find issue #3540464 in any project, not sure what this is referring to.

Might be worth revisiting https://www.drupal.org/project/drupal/issues/2946333 📌 Allow synced Layout override Translations: translating labels and inline blocks Needs work , see if the latest 11.x rebase works. Would be nice to just remove layout_builder_st. It's brutal that D11 doesn't have translations working for Layout Builder yet, and it was introduced in D8.

This would be great to get done, so we don't need to rely on layout_builder_st which has been lagging for D11 support.

Since this PR was made against the wxt project, it will need to be recreated for wxt_library.

I did pull this block locally and added the block to the page footer. I noticed the AJAXed content contains wrapping column classes, but within a required div (#gc-pft), how are you guys handling this? I can't add column classes to the block UI since the markup is already wrapped with col-sm-10 col-md-9 col-lg-8, and that causes layout issues. I thought maybe data-wb-doaction could be used to remove classes, but it doesn't work on AJAXed content.

Note - I added an underscore to the function name since it's an internal helper function (in case you need to update this on your side). Merged with 11.1.x. Thanks!

Agree with @liam, this should be moved to wxt_library and sit next to the existing blocks there, moving project now.

Hey sorry just seeing this now, I always forget to check the wxt_library issue queue. Yes this makes sense to me, always nice to make it more modular and easier to extend! Started the merge train now...

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

New patch accounts for translated alt text in the lightbox.

So now I added my Media field to a view, and I get the FieldFormatter with the config form:

And the resulting view displays the thumbnails with lightbox as expected:

Oh actually maybe this was my oversight, I see how the field is nested under ['feedback_settings'], so this actually might not be an issue. Will pull this into my local and test, then merge with 5.4.x and 6.1.x. Thanks!

So only one small issue I can see:

public function defaultConfiguration() {
    return [
      'feedback_settings' => [
        'theme' => '',
      ],
    ];
  }

But then in the form, we look for the default value like this:

empty($this->configuration['theme']) ? '' : $this->configuration['theme']

I think the defaultConfiguration() method should be:

public function defaultConfiguration() {
  return [
    'theme' => '',
  ];
}

Then the default value could simply be:

$this->configuration['theme']

The patch adds the WET Lightbox FieldFormatter to the wxt_ext_media_image module.

smulvih2 → created an issue.

Ahh cool, similar to the existing webform block for "Did you find what you were looking for?" but just ajaxed-in instead. Can test this out shortly today/tomorrow!

So after looing at this in more detail, seems to be an export issue, not import. The export is missing the _links to the embedded content.

Hmmm not sure actually, looks like with 2.1.x the field_media_image is actually under _links and not as it's own root-level array. Not sure the proper approach here.

So from the JSON code above, it's missing this outside of _embedded:

  "field_media_image": [
        {
          "uuid": "c0c1c5fc-3a29-492b-b1b2-715f136d5aae",
          "lang": "en"
        }
    ],
    "field_media_image": [
        {
          "uuid": "c0c1c5fc-3a29-492b-b1b2-715f136d5aae",
          "lang": "fr"
        }
    ],

The patch attached gets media items importing for me, although not a real solution, just to show what is needed for the fix to $data.

Here is my exported media item:

{
    "_links": {
        "type": {
            "href": "media\/image"
        },
        "self": {
            "href": "_dcd\/media\/22"
        }
    },
    "mid": [
        {
            "value": 22
        }
    ],
    "uuid": [
        {
            "value": "07a67070-ca0f-48c1-a971-ac14397b9468"
        }
    ],
    "langcode": [
        {
            "value": "fr",
            "lang": "fr"
        }
    ],
    "bundle": [
        {
            "target_id": "image"
        }
    ],
    "revision_created": [
        {
            "value": "2025-03-25T22:38:47+00:00",
            "format": "Y-m-d\\TH:i:sP"
        }
    ],
    "status": [
        {
            "value": true,
            "lang": "fr"
        }
    ],
    "_embedded": {
        "relation\/media\/image\/uid": [
            {
                "_links": {
                    "type": {
                        "href": "user\/user"
                    },
                    "self": {
                        "href": "_dcd\/user\/4"
                    }
                },
                "uuid": [
                    {
                        "value": "13d57196-00c3-488b-afda-1b43fa6066df"
                    }
                ],
                "lang": "fr"
            }
        ],
        "relation\/media\/image\/thumbnail": [
            {
                "_links": {
                    "type": {
                        "href": "file\/file"
                    },
                    "self": {
                        "href": "_dcd\/file\/28"
                    }
                },
                "uuid": [
                    {
                        "value": "c0c1c5fc-3a29-492b-b1b2-715f136d5aae"
                    }
                ],
                "lang": "fr",
                "alt": null,
                "title": null,
                "width": "128",
                "height": "128"
            }
        ],
        "relation\/media\/image\/field_media_image": [
            {
                "_links": {
                    "type": {
                        "href": "file\/file"
                    },
                    "self": {
                        "href": "_dcd\/file\/28"
                    }
                },
                "uuid": [
                    {
                        "value": "c0c1c5fc-3a29-492b-b1b2-715f136d5aae"
                    }
                ],
                "alt": null,
                "title": null,
                "width": "128",
                "height": "128"
            }
        ]
    },
    "name": [
        {
            "value": "icon-subject-17.png",
            "lang": "fr"
        }
    ],
    "created": [
        {
            "value": "2025-03-25T22:38:47+00:00",
            "lang": "fr",
            "format": "Y-m-d\\TH:i:sP"
        }
    ],
    "changed": [
        {
            "value": "2025-03-25T22:38:47+00:00",
            "lang": "fr",
            "format": "Y-m-d\\TH:i:sP"
        }
    ],
    "default_langcode": [
        {
            "value": true,
            "lang": "fr"
        }
    ],
    "revision_translation_affected": [
        {
            "value": true,
            "lang": "fr"
        }
    ],
    "metatag": [
        {
            "value": {
                "canonical_url": "http:\/\/default\/fr\/bienvenue",
                "dcterms_language": "fr"
            }
        }
    ],
    "path": [
        {
            "alias": "\/media\/image\/22",
            "pid": 1457,
            "langcode": "fr",
            "lang": "fr"
        }
    ],
    "content_translation_source": [
        {
            "value": "und",
            "lang": "fr"
        }
    ],
    "content_translation_outdated": [
        {
            "value": false,
            "lang": "fr"
        }
    ],
    "field_media_in_library": [
        {
            "value": true
        }
    ],
    "_dcd_metadata": {
        "export_timestamp": 1744399835
    }
}

Comparing this against another project using an older DCD version, this is missing items from _links, specifically uid, thumbnail and image.

smulvih2 → created an issue.

This has now been completed with first release 1.0.0.

smulvih2 → created an issue.

Ok yep good to know, think this one will not be too difficult to resolve. Much easier than the Drupal core table plugin we are having issues with!

Ya it's too bad core doesn't include this functionality, seem pretty important to have translations for layout builder blocks:

"This module provides the ability to translate the block labels and inline blocks that are added in the Layout Builder."

+1 I am running into this issue as well. In my case, my table is driving a JS chart, and adding the contents of tfoot into tbody is causing the JS to fail.

I tested this out and it fixes the issue. Pushed to 5.4.x and 6.1.x. Thanks @joseph.garwood!

Looks like this was already completed in hook_update_8206(). Closing this ticket, but please reopen if there are still pending tasks. Thanks!

This has been completed by @lawxen in the 3.0.x branch, closing ticket and we can open new tickets for any issues in D11.

I just made this update and pushed out a new release 3.0.6. Thanks for pointing this out!

Hmmm, the patch in #8 seems to be in the 5.4.x branch - https://github.com/drupalwxt/wxt/blob/63cde06e8c52aa001284cb4ff8bf2e5c7a3f4a56/modules/custom/wxt_ext/wxt_ext_metatag/src/Plugin/metatag/Tag/AdobeAnalyticsAttributeBase.php#L109

Which branch are you seeing this issue in?

Ok all tests are now passing, functionally toc_api works as expected from my testing. This is ready for review and a new tagged release!

@joseph.garwood good catch! I will test this change and merge into 5.4.x and 6.1.x. Since 5.3.x is no longer supported, people can just apply this patch to their project as needed.

Need this patch again on a upgrade from D9-D10. Existing details content is not wrapped in a single <div>, so without this patch all body content of the details element is removed in node edit for CKE5.

Ok pushed up a small improvement to the upcast function. Now when it finds the old CKE4 markup it automatically converts it to the nested markup from the CKE5 plugin and no more issues.

This all seems to work well on a new site. But when I upgraded an existing site using fontawesome icons from CKE4 it blows up. All content in the body field is removed and I get this console error:

CKEditorError: Cannot read properties of null (reading 'getAttribute')

The old CKE4 content looks like this:

<span class="fontawesome-icon-inline"></span><span class="fa-lightbulb fas"></span>

I think the issue is with the upcast function:

conversion.for('upcast').elementToElement({
      view: {
        name: 'span',
        classes: 'fontawesome-icon-inline',
      },
      model: (viewElement, { writer }) => {
        const childElement = viewElement.getChild(0);
        const fontAwesomeIconInline = writer.createElement('fontAwesomeIconInline', childElement.getAttributes());
        writer.setAttribute('data-tag', childElement.name, fontAwesomeIconInline);
        return fontAwesomeIconInline;
      }
    });

viewElement.getChild(0) is undefined if the <span class="fontawesome-icon-inline"></span> is empty (i.e., it has no child elements). Then calling childElement.getAttributes() on an undefined object throws the error.

Looking into a fix for this now.

I do not have access to the Maintainer tab to make this change. I no longer work on a project using this module, so I would be glad to hand my maintainership over to Martin (mandclu) in order to push this project forward.

Ok I found the solution to my issue reported above about the Entity Browser's Upload function. The error occurred when passing an array of file extensions to the validate() method, when it expects a string. This has been fixed in 5.4.x in wxt_ext_media/src/Element/Upload.php. I will push this fix to the 6.1.x branch tomorrow after doing some more tests on 5.4.x.

Change: https://github.com/drupalwxt/wxt/commit/35732d056a0de75fb208f810ada6c441e149da87

There is an issue I discovered today, affecting both 5.4.x and 6.1.x. The issue prevents an image upload using the Entity Browser field widget. The error comes from wxt_ext_media:

getCurrentEntity() failed: No valid media entity found.

TypeError: Cannot assign array to property Drupal\file\Plugin\Validation\Constraint\FileExtensionConstraint::$extensions of type string in Symfony\Component\Validator\Constraint->__construct() (line 133 of /var/www/vendor/symfony/validator/Constraint.php).

The issue seems to start here - https://github.com/drupalwxt/wxt/blob/f1e6ab364f2dc56cec811c39de40eb15a8e8bdbf/modules/custom/wxt_ext/wxt_ext_media/src/Plugin/EntityBrowser/Widget/EntityFormProxy.php#L98

At this point, $form_state seems to only have reference to the tab instance and no field values.

To reproduce, add an image field to a content type, using the Entity browser field widget. Then add/modify a node and use the Upload tab in the Entity Browser dialog, see the issue.

Patch adds global role assignment via *|role_name.

smulvih2 → created an issue.

I upgraded this module from 4.0.0-alpha1 to 4.0.0-alpha6 and it broke most of my content types; it prevented existing and new content from being saved. Patch #64 fixed the issue, now it behaves as it did before.

@web247 yes I remember having some issues with field being added to the content type but being hidden by default. This shouldn't require any code to resolve, just config, but the config is very picky and needs to be just right in order to work. If you can post a patch or create an MR I can take a look. It could be due to config dependencies; need to make sure that the field config is installed before it's added to the form.

@web247 I just tested this on a fresh install of 6.1.x, adding the same buttons (fontawesome, footnotes) to the full_html text format. I did get a JS validation issue, dealing with image_upload.status. This was coming from editor.editor.full_html.yml:

image_upload:
  status: false
  scheme: public
  directory: inline-images
  max_size: ''
  max_dimensions:
    width: 0
    height: 0

Since the status is set to False, we don't actually need theother lines. By changing to this to the following I was then able to add the icons and save without error:

image_upload: { }

I also tested rich_text and was getting some JS validation issues as well, due to latest plugins. I had to remove <cite> and <div class> from filter.format.rich_text.yml since plugins already specify these elements. After these two changes to the text formats I was able to save without any issues.

Not sure about your reported issue, that looks more like a PHP error than JS validation of the text format settings form. I was not able to reproduce this on a fresh install.

Closing this as can't reproduce. Please try pulling the latest changes and test again from a fresh install. If you experience this isue again feel free to re-open this issue.

Pushed to 5.4.x and 6.1.x. This fixes the phpunit tests. Would be good to add documentation on how to setup and run these tests using docker-scaffold here - https://drupalwxt.github.io/docs/development/, but this can be done as a separate issue.

@joseph I remember this issue for 5.0.x. The issue was introduced in 5.0.1 when the config file in question was introduced, called wxt_core_countries.settings.yml - https://github.com/drupalwxt/wxt/tree/5.0.1/modules/custom/wxt_core/config/install

Then in 5.0.2 it was renamed wxt_core.settings.countries.yml - https://github.com/drupalwxt/wxt/tree/5.0.2/modules/custom/wxt_core/config/install

So if a site was on 5.0.1 and gets updated, this update hook wxt_core_update_8502() is needed to fix the config name. But any site setup on 5.0.2+ will not have this issue since the config filename is now correct.

So the problem is not that the wxt_core.settings.countries.yml config file is not imported during install, because on a fresh install of 6.1.x I can see the values in the UI as expected, so updating wxt_core.install is not the solution here. I actually tried to fix the root cause of this issue, which is the wxt_core.settings.countries needs an entry in wxt_core.schema.yml. Once I made the correct entry in the schema file for this, I got another error about the schema for wxt_core.versions (all enabled modules), which will be difficult to deal with since this can change depending on enabled modules.

After this, I tried the patch from @web247 and it successfully suppressed the errors about the schema. I think this is the best approach, and allows our phpunit to run fully against the defined tests.

Ok I now have permissions and completed the merge. I can confirm the documentation has been updated. Thanks everyone!!!

Steps to reproduce:

1. Copy core/phpunit.xml.dist to phpunit.xml
2. Line 9 change to this: bootstrap="html/core/tests/bootstrap.php"
3. <env name="SIMPLETEST_BASE_URL" value="http://localhost"/>
4. <env name="SIMPLETEST_DB" value="mysql://root:root@sitewxt_db/wxt"/> (to get working with docker-scaffold)
5. docker exec -ti sitewxt_web bash
6. ../vendor/bin/phpunit -c ../phpunit.xml profiles/wxt/tests/

@joseph can you please give some instructions about how to run these tests? If I exec into the web container and run ../vendor/bin/phpunit -c core profiles/wxt/tests/ I get this:

There were 4 errors:

1) Drupal\Tests\wxt\Functional\WxTTest::testWxtLogin
Exception: You must provide a SIMPLETEST_BASE_URL environment variable to run some PHPUnit based functional tests.

/var/www/html/core/lib/Drupal/Core/Test/FunctionalTestSetupTrait.php:610
/var/www/html/core/tests/Drupal/Tests/BrowserTestBase.php:363

2) Drupal\Tests\wxt\Kernel\ComponentDiscoveryTest::testGetAll
Exception: There is no database connection so no tests can be run. You must provide a SIMPLETEST_DB environment variable to run PHPUnit based functional tests outside of run-tests.sh. See https://www.drupal.org/node/2116263#skipped-tests → for more information.

/var/www/html/core/tests/Drupal/KernelTests/KernelTestBase.php:461
/var/www/html/core/tests/Drupal/KernelTests/KernelTestBase.php:275
/var/www/html/core/tests/Drupal/KernelTests/KernelTestBase.php:256
/var/www/html/profiles/wxt/tests/src/Kernel/ComponentDiscoveryTest.php:29

3) Drupal\Tests\wxt\Kernel\ComponentDiscoveryTest::testGetMainComponents
Exception: There is no database connection so no tests can be run. You must provide a SIMPLETEST_DB environment variable to run PHPUnit based functional tests outside of run-tests.sh. See https://www.drupal.org/node/2116263#skipped-tests → for more information.

/var/www/html/core/tests/Drupal/KernelTests/KernelTestBase.php:461
/var/www/html/core/tests/Drupal/KernelTests/KernelTestBase.php:275
/var/www/html/core/tests/Drupal/KernelTests/KernelTestBase.php:256
/var/www/html/profiles/wxt/tests/src/Kernel/ComponentDiscoveryTest.php:29

4) Drupal\Tests\wxt\Kernel\ComponentDiscoveryTest::testGetSubComponents
Exception: There is no database connection so no tests can be run. You must provide a SIMPLETEST_DB environment variable to run PHPUnit based functional tests outside of run-tests.sh. See https://www.drupal.org/node/2116263#skipped-tests → for more information.

/var/www/html/core/tests/Drupal/KernelTests/KernelTestBase.php:461
/var/www/html/core/tests/Drupal/KernelTests/KernelTestBase.php:275
/var/www/html/core/tests/Drupal/KernelTests/KernelTestBase.php:256
/var/www/html/profiles/wxt/tests/src/Kernel/ComponentDiscoveryTest.php:29

So it appears I need to provide some environment variables for this to work, please advise. Also I notice from the image in the ticket, you reference core/phpcs.xml but this file doesn't exist in 6.1.x, rather core/phpcs.xml.dist. Thanks!

This has also been merged with 5.4.x, all tests passing.

This has been merged with 6.1.x.

This has been merged into 6.1.x.

@web247 good catch on this patch. I tested FA without this patch in 6.1.x and it works as expected. Committed and attributed!

Removed the patch in question from 5.4.x-dev and 6.1.x-dev.

smulvih2 → created an issue.

Just tested migrations for gcweb on 5.4.x and 6.1.x, both appear to be working as expected.

Some other things to test/fix

• drupal/toc_api, remove drupaloverride in composer and get working with CKE5/D11
• Test GCIntranet, ensure no JS errors and theme works as expected, with migrations

@joseph admin_toolbar.install has the admin_toolbar_update_8003() hook which uninstalls the admin_toolbar_links_access_filter module. Putting this issue back to Fixed since this is not an issue with WxT 6.1.x.

Marking this ticket as postponed since it is not clear what is causing this translation string issue.

This has now also been fixed in 5.4.x, using the new wxt_bootstrap release 8.x-8.6. I tested a fresh install of 5.4.x and the translation error is now resolved:

Looks like footnotes went through a refactoring and broke our templates. Was able to apply MR !3 and it fixed the issue. Tested against a footnote with multiple instances and seems to work as expected even with latest wet-boew and jQuery4! Merged this into wxt_bootstrap 8.x as well as the 11.1.x branch.

Thanks for everyone's help on this one!

Found an issue with patch #15, now getting the following error on a term translation (new translation) page, for example here - /fr/taxonomy/term/193/translations/add/en/fr

Deprecated function: preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in entity_embed_entity_translation_create() (line 369 of modules/contrib/entity_embed/entity_embed.module).

This appears to be an issue if a text field on the entity doesn't have a value. With the updated patch this issue no longer occurs.

@web247 this is great! Will take a look at this shortly and merge in.

This plugin is provided in 6.1.x, although not enabled by default, but available for those that need it.

+1 RTBC

@web247 yes let's get this into 5.4.x and 6.1.x. If you re-roll the patches that would be great, I can merge them in and test. You will notice the patches in #3 also simplify the page content type, removes the sidebar and layout (layout builder).

@alok_singh can you please update ticket with steps to reproduce? Need to know how to test this fix, thanks!

@web247 5.4.x has drupal/bootstrap pinned at 3.31.0. The fix in question was added to 3.33.0 -https://git.drupalcode.org/project/bootstrap/-/blob/8.x-3.33/src/Bootstrap.php?ref_type=tags#L608

So this is fixed in WxT 6.1.x which uses drupal/bootstrap 3.35.0. We can look at upgrading bootstrap for 5.4.x next. Thanks for pointing this out!

PR created to update documentation as per your request. I will need @sylus to merge this since I don't have perms to this repo - https://github.com/drupalwxt/drupalwxt.github.io/pull/6

@alok_singh thanks for your help with this! As Joseph mentioned, can you please fix your MR to remove the indents so only the lines that have changes are displayed? Thanks!

Upgrading to 4.0.85 fixes the modal issue, so was able to remove our custom polyfill from wxt_library. PR merged and updated site-wxt accordingly.

I added wet-boew/wet-boew 4.0.85 to drupalwxt/composer-extdeps - https://github.com/drupalwxt/composer-extdeps/commit/8690d2a46f15142707bbbd4884a3a90c24ca2831

Will test and merge your PR for wxt_library now.

@joseph I added the fontawesome library as a repository to site-wxt so it should work without any additional steps - https://github.com/drupalwxt/site-wxt/blob/384fb0d41e431f6c8cab13ef026bab630b8e560f/composer.json#L58. The two modules still pending D11 versions (layout_builder_st, toc_api) have the overrides needed in site-wxt, so should be able to use site-wxt 11.1.x to test the D11 upgrade without any additional entries in composer.

I will look at wxt_library now for the wet-boew upgrade, thanks!

@web247 will be good to get another set of eyes on the 6.1.x upgrade. We have it going through QA now with one of our projects, once we fix all the issues identified then we will push out an alpha release.

Ok I see this patch in 5.4.x, changing ticket to match this version since 5.3.x is no longer supported (5.4.x is D10 LTS). This patch has been removed in 6.1.x. It makes sense to remove this patch since drupal/book is no longer in core, and a bunch of fixes were merged once it hit the contrib space. I will remove this patch from 5.4.x, for 5.3.x you can just ignore the patch in composer.json.

Ran into an issue with patch #15 where it was calling the wrong method getSource() on a File entity. New patch accounts for this.

Patch in #62 fixed my issue using core 11.1.2

@jwylarsen 5.3.x is no longer supported, changing this to 5.4.x (D10 LTS).

Fix issue reported by HC; fontawesome plugin for CKE5 missing. I had to re-roll a fontawesome patch and udpate coms configs in WxT to get this working, as well as composer changes to automatically bring in the needed library (fontawesome/fontawesome). Byt default the text formats do not include this plugin, but after fresh install all you have to do is add the plugin to a text format and it should work same as CKE4.

Tested patches #44 and #52 together, seems to work well. I am not experiencing any performance issues with content that has icons when I toggle source mode, and I am using a pretty slow VM on an old laptop. Posting a patch here that combines both of these patches together.

Fixed issue reported by AAFC; media browser dialog in CKE5 is too small. This is caused by a CSS directive in claro, which sets the max-width to 500px. This has been fixed and set to 80% max-width, pushed to wxt_bootstrap 11.1.x.

@joseph I tested your PR #313 for WxT. To completely fix the issue with entity_browser I had to make a small change to wxt_ext_media, as well as created a patch for entity_browser which is included with WxT. With all of these changes, the issue reported has been resolved, and now I can add images with entity_browser without any errors. I also merged your PR #33 for wxt_bootstrap to keep inline with upstream bootstrap changes, thanks for this!

I have just replaced 3 drupaloverrides in composer.json with their corresponding D11 versions. Now there are only two drupaloverrides remaining; layout_builder_st and toc_api.

I'm seeing the same error using 2.12.0. In my case, I have an image field using Entity browser on the user profile. When I select an image to use, I get the AJAX error reported in ticket description.

The error "Call to undefined method Drupal\media\Entity\Media::getFileUri()" occurs because Media entities do not have a getFileUri() method. Instead, we need to get the file entity from the media field.

Attached is a patch that fixes the issue for me.

joseph.olstad → credited smulvih2 → .

The MR branch was pretty old, so I rebased it on 11.x and added patch #43 on top. Fixed linting and default tests. The non-default tests are failing for unrelated reasons, so think we can ignore those.

Re-rolling patch #42 for 11.1.1

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

PR: https://git.drupalcode.org/project/safedelete/-/merge_requests/8

The following changes were made:

• Retrieve the base path dynamically using \Drupal::request()->getBasePath() and store it in a variable.
• Prepend the base path to href values (if missing) during validation to ensure consistency across environments.

smulvih2 → created an issue.

I tested the latest MR #35 and it is working for me on linkit 7.0.2, using CKE5. I am attaching the associated patch here so I can use it in my project. With the patch I can copy/past a node's URL into linkit and it provides the proper suggestion, and formats the link as expected.

@joseph thanks for the patch, this get the jQuery4 fixes into wxt_bootstrap for the local bootstrap files. This has been merged with wxt_bootstrap 11.1.x. I also added GitLab CI for wxt_bootstrap and got all tests passing. Pushed out a dev release, 11.1.x-dev.

Actually I see that the latest drupal/bootstrap 3.34 has the JS fixes for jQuery4 support, so need to update the JS files in wxt_bootstrap to use these, or remove from wxt_bootstrap and just reference the ones from drupal/bootstrap.