🇨🇦Canada @smulvih2

@joseph think you added this ticket to the wrong module, since it doesn't deal with tables.

This has been fixed and is available in 1.0.2.

smulvih2 → created an issue.

Great, glad you got your issue resolved.

@aslobody did you add fontawesome/fontawesome to your root composer.json? If you are using drupalwxt/site-wxt as a project template, it has already been added there - https://github.com/drupalwxt/site-wxt/blob/593a60d4b9575c38fc00c3da2e802e4ede059296/composer.json#L55

The issue is, composer doesn't inherit repositories, you you need to add this entry to your root composer.json file in order for composer to find this repository.

Tagging this with OCOL.

@dydave this should not be configurable, we should just allow any markup inside the <details> element. In a few of my projects where we have migrated content, we have <details> elements with different elements inside, like <p>, <ul>, <div>, etc... And this is valid markup so we should allow this. By default, if you create a <details> element in CKE5 with this patch, and type some text, it will wrap in a <p> tag as expected.

Need to author a page with tabs in CKE5 using 5.4.x. Pulled this patch into 5.4.x and works well!

I have included this fix in 6.1.x and tests are passing.

Hey Colan, thanks for bringing this up! WxT 5.4.x uses wet-boew 4.0.75, and 6.1.x uses wet-boew 4.0.85, where these libraries are no longer bundled.

This change prevents wet-boew JS from loading, so not a good change to add to wxt_bootstrap, although fine to use in your case if wet-boew is not needed. You could also disable wxt_library to prevent that library from loading in the first place. Could also update wet-boew in your composer.json file like this:

"require": {
  "wet-boew/wet-boew": "4.0.85 as 4.0.75"
}

Will be publishing 6.1.x shortly this week/weekend, just running through upgrade path testing.

@sjpeters79 this fix is already in GitHub, third commit from the top - https://github.com/drupalwxt/wxt/commits/5.4.2

+1 RTBC on 1.0-alpha3

#71 works for me on 3.0.0.

joseph.olstad → credited smulvih2 → .

@liam thanks for creating the ticket! I just released 5.4.2 with this fix.

Adding a patch here for alpha3 that excludes the last commit that adds to .gitlab-ci.yml, since this file doesn't exist in the alpha3 branch. This is needed for WxT 5.4.x.

Thanks Joseph, this looks great!

joseph.olstad → credited smulvih2 → .

Thanks @mortona2k, this has been fixed and included in 1.0.1.

I was having similar issues, in my case CKE5 was stripping tfoot. This would even happen after disabling the table plugin on my text format. I have created a module to fix this - https://www.drupal.org/project/ckeditor5_table_fix →

It provides a faux-plugin that replaces the table plugin, and provides as much flexibility in table markup as possible. No UI components, just the ability to copy/past semantically correct tables into CKE5 and prevent stripping. Can be easily extended to support other use-cases as needed.

I was having similar issues, in my case CKE5 was stripping tfoot. This would even happen after diabling the table plugin on my text format. I have created a module to fix this - https://www.drupal.org/project/ckeditor5_table_fix →

It provides a faux-plugin that replaces the table plugin, and provides as much flexibility in table markup as possible. No UI components, just the ability to copy/past semantically correct tables into a text format and prevent stripping.

Created a module to fix issues with tables from CKEditor4 (or any semantically correct table pasted in) - https://www.drupal.org/project/ckeditor5_table_fix →

If anyone is experiencing issues with properly formatted tables in CKEditor5, disable the table plugin and add the faux-plugin from this module to resolve. It redefines the table elements in CKEditor5 with as much flexibility as possible. Can also add support for additional table elements if required.

Tagging this for OCOL.

@joseph this has been fixed and merged with 6.1.x. Now we can support any heading level from h2-h6 within the panels without markup being stripped.

@joseph, thanks for creating this ticket! It's nice to have the large sites at AAFC with legacy CKE4 data to catch all of these issues.

Here is the specific markup in question:

<section class="panel panel-default">
    <header class="panel-heading">
        <h5 class="panel-title">
            Panel title
        </h5>
    </header>
    <div class="panel-body">
        <p>
            Panel body.......
        </p>
    </div>
</section>

The issue is, the wxt_panel plugin has the heading level hardcoded to h3.

I already made the heading level configurable with the wxt_alerts plugin for a similar issue, and WCAG (setting proper heading levels). I will make the same changes to the wxt_panel plugin, to allow any heading level from h2 to h6.

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.