Problem/Motivation
Drupal 11 is out.
jQuery 3 is replaced with jQuery 4.
Bootstrap 3.4.x has been forked and upgraded / tested to work with jQuery 4.
Wet-Boew has been upgraded to work with jQuery 4 (first jQuery 4 compatible release is v4.0.83)
A small shim has been put in to resolve an with a wet-boew.js dependency.
I've got the bootstrap 3 theme functioning on Drupal 11.0.3 (now 11.1.1)
Milestone
We have a functional Drupal 11.1.1 build of WxT 6.1.x in github.
Tasks Remaining
- Replace former core TestSuites in the github pipeline with something from core that is more current.
- Tag an alpha release
- Continue quality checks and prepare a beta/rc
Tasks already completed
fork and upgrade the bootstrap library https://bootstrap.7pro.ca (DONE)tested the bootstrap theme with Drupal 11 and the new forked bootstrap library #3428283-38: Automated Drupal 11 compatibility fixes for bootstrap 8.x-3.x (DONE)fork and upgrade the bootstrap-sass library (IN PROGRESS)upgrade the CDN provider options in the bootstrap theme (DONE) included in drupal/bootstrap release 3.34test wet-boew with the new jQuery 4 + bootstrap v3.4.2 forked + bootstrap-sass forked (DONE)(co-ordinate this with the wet-boew folks so that we get a jQuery 4 compatible version of wet-boew.) (DONE) release 4.0.83- Many other tasks were completed to achieve the above stated milestone
#3428283: Automated Drupal 11 compatibility fixes for bootstrap 8.x-3.x
Proposed resolution
See issue summary
Remaining tasks
See issue summary
User interface changes
TBD
API changes
Numerous changes
Data model changes
As you'd expect with a major release there are some schema updates from core and contrib.
| Comment | File | Size | Author |
|---|---|---|---|
| #109 | tests-after-a-patch.png | 124.76 KB | web247 |
| #109 | 3466676-tests-run.patch | 459 bytes | web247 |
| #108 | schema_countries_missing.png | 132.03 KB | web247 |
| #105 | wxt-deprecated.png | 134.46 KB | web247 |
| #84 | wxt_bootstrap_collapse.js_.patch | 678 bytes | joseph.olstad |
Comments
Comment #2
joseph.olstadComment #3
joseph.olstadComment #4
joseph.olstadComment #5
joseph.olstadWorking on a plan to fork bootstrap 3.4.x and provide a jQuery 4 compatible version.
Comment #6
joseph.olstadComment #7
joseph.olstadComment #8
joseph.olstadhttps://github.com/wet-boew/wet-boew/issues/9808
Comment #9
joseph.olstadI've got bootstrap 3 functioning on Drupal 11.0.3
Instructions and illustrations here:
#3428283-38: Automated Drupal 11 compatibility fixes for bootstrap 8.x-3.x
Next step is to make it work with wet-boew.
This might eventually require forking wet-boew just as I have forked bootstrap.
Comment #10
liam morlandIt would be nice to be able to run
upgrade_status. I tried to do that in #3472183: Enable GitLab CI automated testing but if you look at the pipelines in the merge request, you can see that it does not run properly.Comment #11
smulvih2I think we should consider removing CKE4 from our D11 upgrade. I'm noticing some funny JS console errors now,
ckeditor.jsis trying to load two files that don't exist (config.js,styles.js). This doesn't seem to impact functionality. I'm not able to find an issue for this on the drupal/ckeditor issue queue, but it's also not a supported module anymore.The latest release of drupal/ckeditor is
1.0.2, and it loads ckeditor/ckeditor44.18.0. ckeditor/ckeditor4 has an XSS vulnerability for< 4.24.0-lts. If your site doesn't expose an editor to the public then it's probably not as big of a risk. See related issue from drupal/ckeditor talking about this issue in more detail.CKEditor 4 LTS is a paid service, and is apparently pretty expensive. You need to pass a license key to the editor config in order to have access.
Comment #12
joseph.olstadComment #13
joseph.olstadnow for wxt_bootstrap:
Comment #14
joseph.olstadFirst the good news!
I was able to frankenstein a build of Drupal 11 that included the wet-boew libraries
and patched wxt_bootstrap / wxt_library for Drupal 11 compatibility, what is fairly impressive is that things are mostly working in this state.
I have some very lightly tested patches for wxt_library / wxt_bootstrap , there are likely regressions that I haven't caught yet.
The somewhat expected challenge remaining is the fact that wet-boew includes Modernizr (only required for IE which is no longer support) minor jQuery v4 compatibility challenges to work out. With that said, it's all looking fairly good with the upgraded bootstrap library.
The version of bootstrap being used is straight off the D11 merge request commit following the instructions mentioned here:
#3428283: Automated Drupal 11 compatibility fixes for bootstrap 8.x-3.x
Comment #15
joseph.olstadScreenshot of this progress:

Comment #16
joseph.olstadI've forked wet-boew and working on jQuery 4 compatibility fixes, I'll be testing local builds before pushing it up for review to the wet-boew folks.
No longer need to use the merge request branch from https://drupal.org/project/bootstrap , there is now a D11 compatible version in the 8.x-3.x branch (not yet tagged, I'm verifying a few things yet before making a tag).
https://www.drupal.org/project/bootstrap/releases/8.x-3.x-dev
Comment #17
smulvih2Great news @joseph, this is a major piece to the D11 upgrade!
Comment #18
joseph.olstadMore good news, I pushed a PR up to wet-boew that resolves the jQuery 4 compatibility issues in wet-boew.js.
The PR only resolves the jQuery 4 compatibility issues noticed when using Drupal 11 / wxt_library /wxt_bootstrap as described above, but also has passed the wet-boew lint and automated testing.
Screenshots in the PR of before/after.
https://github.com/wet-boew/wet-boew/pull/9831
Once they approve/merge the PR we'll likely want to crank up our wet-boew from 4.0.75 to 4.0.83 . I'm hoping this jQuery 4 fix makes it into 4.0.83.
Comment #19
joseph.olstad@smulvih2, we're basically at the point now where we need a wxt 6 branch and we need to think about pushing up/reviewing the wxt_library and wxt_bootstrap related changes, review and test those and then get started on the wxt custom module upgrades from 10 to 11.
Meanwhile, I'll continue working towards a tagged release of the https://drupal.org/project/bootstrap build which is fairly close as it's in 8.x-3.x dev right now.
Comment #20
joseph.olstadThe wet-boew PR for jQuery 4 compatibility has been pre-approved by Garneauma and is undergoing thorough testing which I suspect will pass.
Comment #21
joseph.olstadComment #22
joseph.olstadIt would be good to get some mileage (additional testing) on the wxt_bootstrap patch against Drupal 10 and wxt 5.3.x in preparation for D11.
Comment #23
joseph.olstadw00t!
WET-BOEW merged our pull request.
The next release of WET-BOEW will be compatible with jQuery 4 and thus compatible with Drupal 11!
https://github.com/wet-boew/wet-boew/commits/master/
Meanwhile over 1200 new installs of bootstrap 3.33 which includes the Drupal 11 in only 5 days of statistics being collected. Zero complaints from any of those.
Comment #24
smulvih2Awesome, this gets us one step closer to to D11!
Comment #25
joseph.olstad@smulvih2
*** unrelated to WxT but is related to Drupal 11 upgrade ***
FYI, there's a new module that replaces embed_block
https://www.drupal.org/project/ckeditor_insert_blocks
I believe you had done some work on this.
The embed_block maintainer has not taken much action for a few years now and ckeditor_insert_blocks is designed for use with ckeditor5
*** End of unrelated to WxT ***
Comment #26
joseph.olstadFor the D11 upgrade, it will have to target 11.1 as this is the expected upgrade path from 10.4
Today in the #d11readiness slack channel , been discussing the fontawesome D11 upgrade with one of their maintainers. Expect it to be ready this week, possibly tonight.
Let's take inventory of all the modules for wxt , hopefully everything else is ready. Some maintainers are forced a contrib major version change but often it's really minor.
Comment #27
joseph.olstadwet-boew v4.0.83 was tagged and released and is compatible with jQuery 4 which means it is now compatible with Drupal 11.
bootstrap 3.34 (over 5000 installs after only a few weeks)
with
wet-boew v4.0.83
are compatible with Drupal 10.4.0 and also Drupal 11.1.0+
Meanwhile, views_bootstrap has a dev release available which is compatible with Drupal 11. I will ping the maintainer to ask for a tagged release. With that said, we can start with this: https://www.drupal.org/project/views_bootstrap/releases/5.3.x-dev
Comment #28
smulvih2@joseph I'm working on WxT 6.1.x now and using your drupal/bootstrap ^5.0, great work on this!
Running into another issue, with views_bootstrap. To keep on Bootstrap 3, we need to use the 5.3.x branch, which doesn't support D11 (yet). Could use your help with this, especially since you are a maintainer for drupal/bootstrap.
Comment #29
joseph.olstad@smulvih2, ah, no, bootstrap 5 is not compatible with bootstrap 3, use drupal/bootstrap: ^3.34
The maintainer from Bario managed to take over the 5.x branch which has nothing to do with the version we need.
This is the release we need:
https://www.drupal.org/project/bootstrap/releases/8.x-3.34
as for views_bootstrap
use the dev release, it is Drupal 11 compatible:
composer require 'drupal/views_bootstrap:5.3.x-dev@dev'
Comment #30
joseph.olstad@smulvih2 , reminder if you have not done so already. For Drupal 11 compatibility please make sure to apply the patch to wxt_library
https://www.drupal.org/files/issues/2024-11-13/wxt_library-3466676-14.patch
and the patch to wxt_bootstrap
https://www.drupal.org/files/issues/2024-11-13/wxt_bootstrap-3466676-14....
Comment #31
smulvih2Here is the list of all module/packages in WxT that do not have a D11.1 compatible version, even in their respective dev branches:
drupal/button_linkdrupal/embeddrupal/url_embeddrupal/entity_blockdrupal/entity_browser_blockdrupal/entity_embeddrupal/fontawesomedrupal/layout_libraryI will work on implementing the
drupaloverridescomposer workaround for these modules, as we have used in previous upgrades.Proposing to remove the following modules from WxT:
Comment #32
smulvih2Was able to get WxT composer update working with core 11.1.0. This includes updating all dependencies and replacing/removing patches as needed. Please find below a snapshot of my local composer.json overrides that were needed in order to get this working. These changes have been rolled into the 6.1.x branch so others can install. Next will be fixing some errors in our custom module space.
Local composer.json changes:
Comment #33
smulvih2Fixed one issue with the
wxt_ext_layoutmodule and now I have successfully upgraded a vanilla WxT 5.3.x to 6.1.x on core 11.1.0. This is just the first iteration to get the site functional, although there are a few issues I notice immediately, which I will work on next. All changes pushed to drupalwxt/wxt 6.1.x.Comment #34
smulvih2My MR for drupal/entity_block was just merged and now there is a D11 version available, 2.0.x. Scratching this one off the list, only 9 remaining.
Comment #35
smulvih2Will need to prepare 5.4.x to unsinstall the following modules:
Comment #36
smulvih2Updated
wet-boew/wet-boewto4.0.83to get jQuery 4 compatibility, now all JS console errors on forward-facing GCWeb theme are gone, everything functions as expected!Specifically we needed this PR from @joseph - https://github.com/wet-boew/wet-boew/pull/9831
Edit:
Still get one JS error, when clicking the "Share this page" button to trigger a modal, I get this JS error:
File: http://localhost/libraries/wet-boew/js/deps/jquery.magnific-popup.min.js...
Comment #37
joseph.olstadHmm, ok, time to make another PR to fix that. Ah, it's a dependency
js/deps (deps=dependency)
still will need a PR.
Comment #38
smulvih2I created a new branch for
docker-scaffold, 11.1.x, that usesdrupal:11.1.1-php8.3-fpm-alpine3.21as a base image. Just tested this branch locally and it works well on a site upgraded fromdocker-scaffold10.4.x.Comment #39
joseph.olstadLogged an issue upstream in wet-boew/wet-boew
Hope to fix soon
https://github.com/wet-boew/wet-boew/issues/9846
possible workaround suggestion:
Comment #40
joseph.olstadShould be an easy fix/workaround for this:
Add this Javascript, ensure it loads just before or after (maybe try both) wet-boew.js
If that doesn't work, do the same thing for jQuery
Comment #41
smulvih2Got WxT 6.1.x installing from scratch! Will be testing the migrations, theme, and other functionality next, but looking good so far.
Comment #42
joseph.olstadTesting it out, needs a couple patches:
Comment #43
joseph.olstadAnother patch
Comment #44
joseph.olstadpatch 42a fixes allowing turning on and off css / js aggregation and cache settings.
patch 42b allows changing the wxt_library theme
patch 43 resolves a php warning/error message that is thrown by the report a problem form
Comment #45
smulvih2@joseph thanks for the patches. Patch 42b is not needed, I made this change earlier today - https://github.com/drupalwxt/wxt_library/commit/c4dce84af54132cf62c4f21a5a3db85d3f80083c
I'll include patches 42a and 43 next, thanks for this!
Comment #46
joseph.olstaddrupaloverride/entity_browser_block
can be replaced with
drupal/entity_browser_block:'^2.0'@smustgrave became maintainer of entity_browser_block and he published a D11 release for this one tuesday jan 14.
Share this page works wonderfully, had to try it! :)
Comment #47
joseph.olstadReplace one of those patches.
Comment #48
joseph.olstadand this patch for page_manager has to go on top of our other page_manager patches, put it at the end.
To reproduce the bug, log out of wxt vanilla and log back in again. You'll see a page_manager exception which prevents log-in. This patch fixes it. With that said, something is broken with H1 titles, I've got sample content loaded but I don't see the title. Probably related.
Comment #49
smulvih2@joseph I tested and merged patch 42a, I can confirm it fixes the issue with the performance page. Patch 42b was already fixed the other day. For patch 43, although it did fix the warning/error, the success message for that webform was not returning. I had to use an
AjaxResponse()to get this to work, and now the success message is displayed after the "Yes" button is clicked on the webform "Did you find...". I also confirmed that the "Yes" is being logged to the webform submission as expected. This has all been resolved and pushed to 6.1.x.Will look at the page_manager issue now, and why it's preventing us from logging in. Thanks!
Comment #50
smulvih2@joseph the page_manager issue has been resolved, and is now fixed in 6.1.x.
Comment #51
joseph.olstadCool, great work. I'll update my build soon and check this out. The Ajax fix sounds perfect thanks
Hiding the related patches here accordingly.
Comment #52
smulvih2Running the builds in GitHub to get them passing before releasing an alpha version. There were some changes to the docker-scaffold needed, as well as some PHPCS fixes.
Both builds (mysql, psql) are still failing.
For psql, D11 requires >=16:
For mysql, it can't find a Kernel test file:
Will continue looking into these issues tomorrow.
Comment #53
joseph.olstadComment #54
joseph.olstadComment #55
joseph.olstadComment #56
smulvih2Upgraded to psql 16, and fixed the issue with the mysql test from #52. Now running into these phpunit test errors:
Seems to be same issues as the related ticket.
Comment #57
smulvih2Think I found the issue with the failing phpunit tests. For some reason, composer is not bringing in the /composer directory from core.
Comment #58
smulvih2Ok figured out the issue with the tests, a bit confusing.
I thought this was
drupal/core: https://git.drupalcode.org/project/drupal/-/tree/11.1.x?ref_type=headsBut the composer.json in the root of this repo is
drupal/drupal. There is another composer.json file in /core, and that'sdrupal/core. So when we are requiring drupal/core-recommended, that requires drupal/core, and so the other files/directories in the root of that repo are not included.To fix the issue, I added
drupal/drupalto require-dev. This puts drupal/drupal in the vendor directory. I then use a composer post install/update script to move vendor/drupal/drupal/composer/* into html/composer.Now the
Drupal\Tests\Composer\Generator\BuilderTestclass, which requires the /composer directory to be in place, can access the proper drupal verison of composer with theComposer::drupalVersionBranch()method, which is obviously drupal specific.Now both
mysqlandpsqltests are passing in GitHub.Comment #59
joseph.olstadok wow, kinda weird but ya great sleuthing!
Comment #60
smulvih2Got all tests passing in GitHub and now also all tests passing with GitLab CI. Pushed out a dev release, 6.1.x-dev. Still a few known issues to resolve, and more testing (fresh install and upgrade from 5.4.x), but wanted to get a dev release out so people can start testing.
Known issues / Remaining tasks:
Using [toc] token and saving a page results in WSODchangelog.ymlandtag.ymlare failing. (will need @sylus for input here)drupalwxt/docker-scaffoldanddrupalwxt/site-wxthave been updated, but still need to look atdrupalwxt/wxt-project,drupalwxt/helm-drupal, anddrupalwxt/terraform-kubernetes-drupalwxt(will need @sylus for input here)composer.jsonas remaining modules get stable releases for D11Comment #61
joseph.olstadOk, a bit of a minor issue for me, as I can do workarounds, but we could smoothen this part out.
In order to upgrade to WxT 6.1.x the following modules must be uninstalled before going into D11
Here's what happens when you try to uninstall keditor4_codemirror in WxT 5.4.x:
do you also want to uninstall wxt_ext_editor? So there's a dependency set in wxt_ext_editor, which is fine for 5.4.x but in 6.1.x there's no ckeditor4_codemirror module available. It could be faked out with a stub module like drush gen module. just to get an info.yml for it to be able to uninstall it. I'll do this myself but we could make this easy by including this in the wxt/custom/modules
core modules removed from D11
These two modules can be brought back in via contrib, I'll do this
ok not such a big deal for the core modules, they're now available in contrib.
action is required for things like vbo and I know moderated_content_bulk_publish likely needs it.
Comment #62
joseph.olstadcodemirror - test to see how this is working.
This is the library I'm including:
and then corresponding entries in the require section of the composer.json
from the ckeditor_codemirror composer.libraries.json:
Comment #63
joseph.olstad@smulvih2,
reminder, since we're using overrides, the namespace of patches needs to follow suit.
What I'm doing is this:
I'm keeping both, since eventually we'll remove the overrides but we need the patches either way (for now).
This applies to other drupaloverrides modules, we're possibly missing patches for when running 6.1.x.
Definately need this null-fix patch. I hit this when trying to log in.
Comment #64
joseph.olstadFound (and fixed) a deprecation issue caused by using a deprecated createPseudo call in wet-boew.js
tested a fix, success
openned a PR for wet-boew
Issue link:
https://github.com/wet-boew/wet-boew/issues/9851
Comment #65
smulvih2Removed dependencies on
block_content_permissionsandckeditor4_codemirrorfrom 5.4.x-dev to prepare for 6.1.x upgrade. This will allow uninstalling the following modules as part of pre-deployment steps for the upgrade:Uninstall the following modules (pre-deployment for 6.1.x):
With this change, GitHub and GitLab tests are passing. On a fresh install of 5.4.x-dev, you will notice the CKE4 text formats are basically empty, this is needed to prepare for CKE4 removal. If projects want to keep CKE4, they will have to add these dependencies to their root composer.json file. WxT will keep custom CKE4 plugins for a while longer to support this type of setup, but will no longer support CKE4 otherwise.
Comment #66
smulvih2Running into some JS errors on a project, and noticed the bootstrap JS files that come with wxt_bootstrap are from v3.3.6 (2015). We should try updating these to the latest 3.4.1 (2019).
Comment #67
joseph.olstad@smulvih2 , bootstrap 3.34 requires version 3.4.4 of the library
you can select this in the cdn provider option by toggling and switching to jsdelivr
Comment #68
smulvih2Here's one example JS error:
This is coming from
themes/contrib/wxt_bootstrap/js/bootstrap/tooltip.js. If I look at the latest boostrap v3.4.1, it still uses the ifFunction call, which was deprecated in jQuery 3.3 and removed in jQuery 4.0. I think this will be an issue with Bootstrap 3 with jQuery4; Bootstrap 3 is not compatible with jQuery 4. Might have to fork Bootstrap 3 to get working with jQuery4, or get wet-boew upgraded to use Bootstrap 4+.Comment #69
smulvih2Actually I see that the latest
drupal/bootstrap3.34 has the JS fixes for jQuery4 support, so need to update the JS files inwxt_bootstrapto use these, or remove fromwxt_bootstrapand just reference the ones fromdrupal/bootstrap.Comment #70
joseph.olstadyes bootstrap 3.34 has these fixes and we cannot use twbs/bootstrap 3.4.1 it has to be entreprise7pro/bootstrap 3.4.4 to attain jQuery v4 support. We'll have to sort this out.
Comment #71
joseph.olstadHere's the jQuery 4 fixes for the outdated js in wxt_bootstrap
This brings us up to 3.4.4
Comment #72
smulvih2@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.
Comment #73
joseph.olstadI updated the release notes for bootstrap 3.35 , and updated a related support request relating to this.
The correct configuration for subtheme cdn settings is to leave it to "compiled" and "none". The bootstrap theme settings should be the only decider here due to the need to do an automatic upgrade as Drupal 11 does not support twitter bootstrap, it only supports entreprise7pro bootstrap.
Instructions are in the release notes https://www.drupal.org/project/bootstrap/releases/8.x-3.35
The Default install of WxT 6.1.x does not have an issue.
Comment #74
joseph.olstadExtensive testing - Discovered something that looks like a wxt bug, might be also in 5.4 but I'm seeing this in 6.1.x
Step 1) edit or add a user then select a picture for them
illustration:

Step 2) Check the browser console ajax exception message
Comment #75
joseph.olstadUntested patch, possibly helps with comment #74
Comment #76
joseph.olstadPatch #75 leads to something deeper with the file extension validation going on in wxt_ext_media. Here's the related change notice:
https://www.drupal.org/node/3363700
The new approach was introduced in version: 10.2.0, however the deprecated approach was removed in 11.0.0.
So , therefore, bunch of refactoring is needed in wxt_ext_media. See the change notice for more details on how to refactor related wxt_ext_media validation logic. A bit tricky business.
Comment #77
joseph.olstadNew patch, testing it.
Comment #78
joseph.olstadpatch 77 is an incomplete refactor, working on it. next one I will test before uploading.
Comment #79
joseph.olstadok new patch, it's not working yet, not sure what the issue is caused by whether it's dropzonejs or an incorrect refactor of wxt_ext_media
This patch was created as an attempt to follow this change notice : https://www.drupal.org/node/3363700
It's a work in progress.
Comment #80
joseph.olstadOk another patch, still doesn't fix the issue but gets us closer.
This patch was created as an attempt to follow this change notice : https://www.drupal.org/node/3363700
It's a work in progress.
Comment #81
joseph.olstadnew patch.
it's better but still not complete.
Comment #82
joseph.olstadOk I've dug deeper into this, my patch is really close.
With that said, I found out that degov , govcms and vardot also used lightning_media
They're now using media_bulk_upload.
There's a MASSIVE merge request for media_bulk_upload to make it Drupal 11 compatible and it is marked RTBC with a lot of work having gone into it.
https://www.drupal.org/project/media_bulk_upload/issues/3431856
At some point (soon?), we should look at replacing wxt_ext_media_bulk_upload with
media_bulk_upload.
With that said, still need to fix wxt_ext_media, not bulk.
Comment #83
joseph.olstadOk here's another patch, this one actually behaves much better than 5.4.x which is completely broken btw.
This patch can be applied to both 5.4.x and 6.1.x
Comment #84
joseph.olstadOne more patch, this time for wxt_bootstrap. I'll also have to put this into the entreprise7pro/bootstrap build.
Comment #85
joseph.olstadis meant for 6.1.x mostly
Comment #86
joseph.olstadComment #87
joseph.olstadIn addition to the pull requests, there's a bunch of the overrides modules that got releases. Go through those soon.
Comment #88
joseph.olstadThe js patch is related to an upstream js change in bootstrap 3.4.6
https://github.com/entreprise7pro/bootstrap/compare/v3.4.5...v3.4.6#diff...
Comment #89
joseph.olstadTo help soften the landing of Drupal 11 we've created a new contrib module:
JQuery Downgrade
Comment #90
smulvih2@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.
Comment #91
smulvih2Fixed 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.
Comment #92
smulvih2Fix 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.
Comment #96
joseph.olstadRelating to the fontawesome library , the namespace in packagist is actually forkawesome/font-awesome
https://packagist.org/packages/fortawesome/font-awesome
6.2 million installs
74,000+ stars
Comment #97
web247 commentedLooks like this is in almost alpha state now, I'll do some tests myself (I'll install the 6.1.x-dev branch)
Comment #98
joseph.olstadThere's still two overrides plus the fontawesome/fontawesome bit that you'll need in your projects for upgrades. I also just openned a merge request for wxt_library to upgrade wet-boew from 4.0.83 to 4.0.85 (fixes a jQuery 4 compatibility issue we found).
Comment #99
smulvih2@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.
Comment #100
smulvih2I added
wet-boew/wet-boew4.0.85 todrupalwxt/composer-extdeps- https://github.com/drupalwxt/composer-extdeps/commit/8690d2a46f15142707bbbd4884a3a90c24ca2831Will test and merge your PR for wxt_library now.
Comment #101
smulvih2Upgrading 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.
Comment #102
joseph.olstadOk great, we could also look at upgrading gcweb to 16.2.0 from 14.6.0 at some point but less urgent.
Comment #103
web247 commentedOk guys, can anybody point me how to get the 6.1.x-dev release? This doesn't seem to work:
Comment #104
joseph.olstadcomposer create-project drupalwxt/site-wxt:11.1.x-dev <site-name> --no-interactionI got the answer from a documentation thread you are following.
There's a PR ready and waiting but it has to be merged.
from this issue:
#3506584-5: Add missing documentation in the official page
Comment #105
web247 commentedThanks @joseph.olstad , I'm just wondering if these "deprecated class constants" warning that I see when running upgrade_status against the wxt installation are worth to fix it at this point, I can provide a patch for this, but not sure if it's worth the time given that core version is 11.1.2 and D12 is not near at the corner yet:
Comment #106
joseph.olstadya that's Drupal 12 stuff, we have time to work on that, with that said, we can start working on those items.
We're focused right now mostly on immediate concerns relating to Drupal 11.
Comment #107
smulvih2Just 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
Comment #108
web247 commentedI just ran the phpunit tests in the wxt profile (I am using 6.1.x), I came across this error (I saw this error on 5.4.x as well):
I do see the schema file in the codebase:
./html/profiles/wxt/modules/custom/wxt_core/config/install/wxt_core.settings.countries.ymlBut perhaps it's not being created during the installation time? I had a look at the
./html/profiles/wxt/modules/custom/wxt_core/wxt_core.installand I can see the functionwxt_core_update_8502()that loads the schema, perhaps this one is not being executed anymore during the installation time (that's my wild guess):Comment #109
web247 commentedI created a patch that basically supresses the error when running the unit tests, but it doesn't actually fix the countries schema not being loaded, I'll look on that later today, I might open a different issue page for that.
Comment #110
joseph.olstadThanks @web247
I've created an issue for that
#3508590: Countries test failure in a vanilla install
Comment #111
joseph.olstadLinking the plan for WxT 6.1.0