@al_trottier yes we can bring this fix into 5.4.x, I created a child issue so we can track this change. For now just add the drupal/redis patch to patches-ignore in your composer.json file.
Drupal 11 Patches
Adding patches to use in my project for D11, with the latest fix for checkbox groups using special characters and spaces in their options key.
Drupal 10 PRs
These are the PRs to get this fix in Drupal 10. Please note, we need to update to wet-boew/wet-boew 4.0.85 in WxT 5.4.x in order to ensure wet-boew validation for checkbox group works as expected.
wxt_bootstrap: https://github.com/drupalwxt/wxt_bootstrap/pull/36
wxt: https://github.com/drupalwxt/wxt/pull/333
Finally fixed the checkbox group validation issue!
Initially, when enabling WET-BOEW inline validation in Drupal WxT, checkbox groups (#type: checkboxes) were not validating correctly.
Only the first checkbox in the group would remove the validation error once selected, while checking any other box would leave the error message active.
This caused real usability issues, if a user selected only the second or third option, the form still showed a “This field is required” error and could not be submitted.
Initial Analysis
In the default WET example, all checkboxes in a required group share the same name (e.g. name="animal"), which allows the jQuery Validate require_from_group rule to treat them as one logical field.
However, in Drupal Webforms, each checkbox has a distinct name for submission purposes, such as:
name="animal[dog]"
name="animal[cat]"
name="animal[fish]"Because of these unique names, the validator treated each input as a separate required field, so only the first checkbox’s change event satisfied the validation rule, the others continued to trigger “required” errors.
First Attempt
I added a shared CSS class and data-rule-require_from_group attributes in a preprocess hook to make WET recognize the grouped checkboxes.
Example attributes added by preprocess:
$variables['attributes']->addClass('js-wet-group-animal');
$variables['attributes']->setAttribute('data-rule-require_from_group', '[1,".js-wet-group-animal"]');
$variables['attributes']->setAttribute('data-rule-required', 'false');
This correctly enforced “at least one checked” behavior across all boxes, but introduced a new problem:
each checkbox still rendered its own inline validation message and corresponding entry in the WET summary, producing multiple duplicate errors for the same fieldset.
Final Fix
To resolve this, I implemented a client-side enhancement (webform_checkboxes_group.js) that hooks into WET’s jQuery Validate instance once initialized.
The script:
- Discovers grouped checkboxes by inspecting names like
animal[dog]that includedata-rule-require_from_group. - Registers them as a single validation group using
v.settings.groups. - Prevents duplicate inline labels by only allowing the first checkbox in each group to receive a visible error label.
- De-duplicates WET’s top error summary by filtering the validator’s
errorListanderrorMapto keep only one entry per checkbox base name. - Ensures proper prevention of submission when invalid, covering all submit and Enter-key cases.
Result
- Only one inline error appears for a checkbox group.
- The error summary lists one item for the group.
- Any checkbox in the group can now clear the error as expected.
I have updated the two PRs in this ticket with these changes:
wxt_bootstrap: https://github.com/drupalwxt/wxt_bootstrap/pull/35
wxt: https://github.com/drupalwxt/wxt/pull/332
The svg.js file has been included in the /js/vendor directory.
Initial libraries.yml file has been added, which adds svg.min.js as well as the module's CSS and JS file.
From my experience on the three projects noted above, completely removing the wrapping <div> elements fixes all issues across the following scenarios:
- Details element created in CKE4, loaded into CKE5
- Details elements created with CKE5 pre-patch, loaded into CKE5 post-patch (contains the wrapping div)
- Details elements migrated from other platforms, where the body is made of multiple elements all nested directly in the element (p, div, h2, ul, etc...)
From testing on these projects, no issues reported across browsers. I have used this patch on both Drupal 10 and Drupal 11.
I'm not sure what benefit it would give to allow the nesting under the single div again as an option. Maybe we can get this into an alpha/beta version and get some feedback from users? Not sure of best way to move forward besides keep using this patch on my projects :)
Screenshots have been added to the project page, using fictitious sample data.
@joel_osc I don’t understand the rationale for removing me as a maintainer. You could have simply added Liam as a third maintainer. For context, I’ve used this module on multiple projects over the last 2-3 years, I know the implementation, and I understand the nuances of moderated multilingual revision handling. I was also involved with ticket #3324883 🐛 Fix algorithm for candidate determination Fixed where you specifically state that the patch that created 1.1.3 is “confirmed working on multiple sites” ( comment #21 🐛 Fix algorithm for candidate determination Fixed ). Now you are saying that 1.1.3 is broken and people need to stop using the module, but do not provide any information? 1.1.3 has been out since April 2023 and so far there have not been any documented issues aside from the performance one.
You added a warning to the project page, “It is not recommended to use this module at this time. Several sites have reported major issues plus there are regressions in the latest release that need to be corrected.”, but there’s no corresponding ticket that describes these issues. Not even a meta issue collecting reports, environments, and steps to reproduce. Publicly, the only reported problem I can find is a performance concern on large-revision sites in #3413888 💬 Optimization of revisions query in cm_revision_delete_get_revisions Active , but this is not a critical show-stopper that justifies this message.
Let’s be clear: this is an open-source project, not an internal OpenPlus repo. Removing a maintainer without cause is not how we operate. It looks far more likely this was a reaction to your disagreement with Joseph on #3371439 🐛 Revisions getting reverted when two translations are pending Active (moderated_content_bulk_publish) and his subsequent comment here on this ticket. I’ve worked with Joseph before, but his comments are his own, they do not represent my position or decision-making.
Meanwhile, I haven’t removed you from modules I maintain, I haven’t removed OpenPlus as a sponsor from my projects, and I haven’t untagged OpenPlus from the 100+ contributions I’ve made on Drupal.org in recent years. In fact, I was recently asked (Aug 2025) to add OpenPlus back to my d.org profile so I’d appear on your organization page: https://www.drupal.org/node/2622240/users →
As CTO of OpenPlus, your actions reflect on the company. Why am I being asked to appear under OpenPlus on Drupal.org while you’re simultaneously removing me from module maintainership without any stated, project-related reason?
Please either (a) reinstate my maintainer status and open a blocker/meta issue documenting the specific “do not use” problems with steps to reproduce, or (b) state the concrete, project-related justification for my removal and link the issues that warrants the front-page warning.
Just realized today that I’m listed as a maintainer on this project. Thanks everyone for the detailed reports and steps!
I’ve reviewed the thread and I agree with the core concern: this module should not require ETUF to avoid data loss. While the original implementation was developed on a stack that used ETUF (which keeps EN/FR revisions in sync and changes revision behavior), recommending ETUF as a workaround isn’t reasonable here because it fundamentally alters how revisions are managed.
I’ve run into similar issues with moderated multilingual workflows; publishing must target the intended revision for each language. Without careful selection of the source revision per translation, it’s easy to publish the wrong state or discard draft changes.
I think comment #22 is on the right path, we should add tests to capture the scenarios reported here so we can fix without regressing existing installs:
- Single-language, standard editorial workflow: publish latest revision via VBO when newer drafts exist (per @keszthelyi’s steps).
- Multilingual with moderation: drafts in multiple languages → bulk publish only selected translations vs. all languages.
- Test both View bulk operations and Node bulk operation actions.
- Verification that correct source “latest” translation revisions are published and that intermediate draft revisions are not discarded.
hmmm, looks like I was removed as a maintainer yesterday. Since @joel_osc is currently the only maintainer, I guess he removed me. @joel_osc is there a reason you removed me from this project?
Here are patches for Drupal 10 WxT with all of the WET-BOEW validation from the parent ticket, as well as the new fixes for grouped fields (checkbox, checkboxes, radios) and conditional fields.
"patches": {
"drupalwxt/wxt": {
"3545573": "
https://www.drupal.org/files/issues/2025-09-25/wxt--wet-boew-inline-vali... →
"
},
"drupal/wxt_bootstrap": {
"3545573": "
https://www.drupal.org/files/issues/2025-09-25/wxt_bootstrap--wet-boew-i... →
"
}
}
Video attached showing the handling of conditionally-visible required fields. JS is needed since conditional fields uses JS on the front-end which bypasses the templates for the required markers.
Added the .gitlab-ci.yml file to the project and fixed all errors. Two phpstan warning still exist, just upcoming deprecations, but these can be fixed in a separate ticket.
Actually might be worth trying this module - https://www.drupal.org/project/ckeditor5_find_replace_filter →
@joseph, I looked at the wxt_chart_stability module, I see it uses a configurable filter to do a search/replace. Why not make this more generic, instead of chart stability it's a generic search/replace filter. Then you could allow for multiple search/replace entries, one per line like this:
|search|replace|
|<td> </td>|<td></td>|
This would make the module much more useful for different type of CKEditor issues we have been seeing. Then I could see adding that module to WxT itself. But no point adding a filter as a separate module to WxT, it could just be added to an existing wxt_ext_* module to prevent module bloat. Just my 2 cents.
@danrod thanks for looking into this! I will test this out on the reporting project and let you know how it looks.
I added wet-boew/wet-boew:4.0.91 to the composer-extdeps repo so it can now be pulled into WxT easily for testing - https://github.com/drupalwxt/composer-extdeps/commit/b4627261f2b45f0075b7922de7357ff59e7ba21a
Once we've had enough time to test this against current projects for validation then we can make this change for WxT 6.1.x.
You can now pull 4.0.91 into your project with a composer alias; 4.0.91 as 4.0.x
I added a PR for drupalwxt/wxt that handles conditional fields in webforms. The conditional fields work with the wet-boew validation, the only issue I noticed was they were not getting the proper required markers. This is because the required markers are added server-side via twig templates. I added a JavaScript file to a library that only gets loaded on webforms that have the wet-boew validation enabled. I tested this against normal fields with a <label> element, as well as grouped fields with a <legend>.
Pull requests:
drupal/wxt_bootstrap: https://github.com/drupalwxt/wxt_bootstrap/pull/35
drupalwxt/wxt: https://github.com/drupalwxt/wxt/pull/332
Ok great, thanks for providing the missing info about using the 5.4.x branch. I remember spending a good amount of time getting fontawesome working for 6.1.x. I think I meant to backport this to 5.4.x but never got around to it. I'll keep this ticket open if one of you guys wants to get a patch/PR going for 5.4.x, else we can close this ticket since we already have this fixed in 6.1.x.
FYI if you don't have the fontawesome repository defined in your root composer.json file then the library will not be pulled in.
I just tested renaming the /html/libraries/fontawesome directory to /html/libraries/fontawesome2 and checked the status page, it now complains about the library missing. If I switch it back the error about the missing library is gone.
I'm not sure what the issue is. In WxT composer.json we add a repository for this already:
https://github.com/drupalwxt/wxt/blob/4d6cb8d90521efb6e703fbfdbe89d421bb6f9475/composer.json#L134
And then we also need this in site-wxt since repositories are not inherited from other composer files:
And by default, WxT 6.1.x does not have the CDN option enabled for font awesome. In my vanilla D11 WxT test site, I see the library files under /html/libraries/fontawesome.
So the CDN is not enabled, and it works for me. Can you elaborate on how to reproduce the issue you are seeing?
@jwlarsen can you please explain why this change is needed, fontawesome seems to work as expected in 6.1.x. I remember going through this during the D11 upgrade process to ensure FA works properly as we had a few clients that use icons in their content regularly.
Fontawesome in 6.1.x:
So far there is only one major issue with the WET-BOEW field validation integration with webforms, this is with the checkboxes field. WET-BOEW expects all checkboxes in a group to have the same name attribute on each <input> element, like this:
<fieldset class="chkbxrdio-grp">
<legend class="required">
<span class="field-name">Favourite pets</span> <strong class="required">(required)</strong>
</legend>
<div class="checkbox">
<label for="animal1">
<input type="checkbox" name="animal" value="1" id="animal1" data-rule-required="true"> Dog
</label>
</div>
<div class="checkbox">
<label for="animal2">
<input type="checkbox" name="animal" value="2" id="animal2"> Cat
</label>
</div>
...
</fieldset>
You can see from this example, WET-BOEW expects all input elements to have the same name="animal". With webforms, the name attribute is unique and used to save the value on from submit, so can't easily be changed. Here is the same field in webforms (some attributes removed for brevity):
<fieldset class="chkbxrdio-grp">
<legend class="required">
<span class="fieldset-legend">Select from the following</span><strong class="required">(required)</strong>
</legend>
<div class="fieldset-wrapper">
<div class="form-item checkbox">
<label for="edit-select-from-the-following-1">
<input class="form-checkbox" type="checkbox" id="edit-select-from-the-following-1" name="select_from_the_following[1]" value="1"><span class="field-name">Option 1</span>
</label>
</div>
</div>
<div class="fieldset-wrapper">
<div class="form-item checkbox">
<label for="edit-select-from-the-following-2">
<input class="form-checkbox" type="checkbox" id="edit-select-from-the-following-2" name="select_from_the_following[2]" value="2"><span class="field-name">Option 2</span>
</label>
</div>
</div>
...
</fieldset>
You can see here that each input element gets a unique name attribute, which can't be changed or will cause submission failure. Not sure the best way to approach this issue, maybe WET-BOEW has a workaround for this, but nothing I can find.
Symptoms: When the checkboxes group is required, and you submit the form with the field blank, you get the error message as expected. Only selecting the first checkbox in the array will clear the message, although if you save the form it will then remove the message if another checkbox in the array is selected.
Here are the fields with the proper rendering.
You can pull these changes from this PR until merged - https://github.com/drupalwxt/wxt_bootstrap/pull/35
smulvih2 → created an issue. See original summary → .
Unit and kernel tests have been added for the API clients, and they are passing in GitLab CI.
smulvih2 → created an issue.
smulvih2 → created an issue.
I have a request to back-port this feature to D10 WxT (5.4.x). Attached are two patches (wxt, wxt_bootstrap) taken from the GitHub PRs and re-rolled to drupalwxt/wxt 5.4.x and drupalwxt/wxt_bootstrap 8x-8.x. I don't think we will include this in the 5.4.x branch, but people can use these patches until they upgrade to wxt 6.1.x.
Here are the changes to composer.json needed to bring this feature into 5.4.x:
"patches": {
"drupalwxt/wxt": {
"3540545": "https://www.drupal.org/files/issues/2025-09-06/wxt--wet-boew-inline-validation--d10--3540545.patch"
},
"drupalwxt/wxt_bootstrap": {
"3540545": "https://www.drupal.org/files/issues/2025-09-06/wxt_bootstrap--wet-boew-inline-validation--d10--3540545.patch"
}
}