@joseph is it possible for WxT to stick with drupal/book 1.x (last updated April 2024) and have that work as it did before, and wait for WxT 6.2.x (11.2.x) to upgrade to book 3.x? Essentially skip book 2.x?
Ahh ok ya it was just released yesterday, good timing!
@joseph why are are you pinning to this commit:
"drupal/book": "2.0.x-dev#09a40d4e as 2.0.3",
This is only one commit behind 2.0.3, and that one commit has minor changes. Should be able to just use 2.0.3 for this. I can see pinning to 2.0.3 instead of ^2.0 to avoid breaking the patch when newer versions are released.
I tested patch #67 in 10.4.9 and it fixed the redirect error for my use case. I was running into this issue while creating a menu item in English on a French-first site. With patch #67 it no longer throws the WSOD redirect error, although the behaviour is slightly different than expected. I would expect creating a menu item in English would create the French menu item first then redirect me to the French menu listing page, but instead it redirects me the the French menu item edit page. A bit confusing but at least it removes the WSOD.
See this feature in action here (with conditional fields) - https://agriculture.canada.ca/en/form/accessibility-feedback-form
Nice work, looks like table support is improving significantly with this PR! We will fix all the table issues one of these days...
Adding parent issue where this regression originated.
Here is my summary of the changes and how they impact WxT:
It looks like Drupal 11.2.x introduced major changes to how module configuration is validated and installed:
- Modules are now validated and installed in batches, not individually. This means all default config across a group of modules is validated together before any of them install. If one module references a bundle/config provided by another module, and that config is in
/config/optionalor not present in the install profile's exported config, the entire batch now fails validation. - Config install is now split into phases: InstallSimple -> InstallEntities -> Optional. Bundles placed in
/config/optionaldon’t get created until the "Optional" phase, which now runs after entity display and field config that depends on those bundles. This exposes hidden ordering problems that used to work by accident (and were always a bit finicky). - Profile-based installs no longer see a module's
/config/installas part of the "initial config set". If a distribution rewrites config from contrib modules (e.g., Metatag) but the profile does not export that base config, config_rewrite now reports "initial config missing".
For Drupal WxT, we have several profile extensions that are optionally enabled (e.g., wxt_ext_metatag adjusts Metatag defaults to align with Government of Canada standards). With these installer changes, it appears we can no longer rely on optional profile modules to safely provide or rewrite configuration. We may now need to declare more dependencies directly on the profile itself, making the configuration more "all or nothing".
Might be time to consider other options like recipes, or remove "optional" modules and just install everything. I think to get this working now, we would need to add all sub-module dependencies on the profile itself.
I am experiencing the same issue with the
Drupal WxT distribution →
. Our automated tests began failing immediately after upgrading to Drupal 11.2.x. The first failures appeared around missing bundle configuration where we had YAML in /config/optional.
Specifically, media.type.image.yml lived in a profile sub-module under /config/optional. Under 11.1.x this installed without issue, but in 11.2.x it now fails with:
Missing bundle entity, entity type media_type, entity id image.
Moving that file to /config/install resolved the media error, but the failure reappeared for another bundle:
/config/optional/block_content.type.basic.yml
After fixing both of these by moving them to /config/install, the installer then began failing during config_rewrite, specifically for:
/config/rewrite/metatag.metatag_defaults.taxonomy_term.yml
The error:
Tried to rewrite config metatag.metatag_defaults.taxonomy_term via wxt_ext_metatag module without initial config present.
All dependencies in the relevant *.info.yml files are correct, and the modules that originally provide the config (e.g., Metatag) are declared as dependencies on our modules.
@millnut thanks for identifying the commit that broke this for distributions! It looks like Drupal 11.2.x introduced major changes to how module configuration is validated and installed:
- Modules are now validated and installed in batches, not individually. This means all default config across a group of modules is validated together before any of them install. If one module references a bundle/config provided by another module, and that config is in
/config/optionalor not present in the install profile's exported config, the entire batch now fails validation. - Config install is now split into phases: InstallSimple -> InstallEntities -> Optional. Bundles placed in
/config/optionaldon’t get created until the "Optional" phase, which now runs after entity display and field config that depends on those bundles. This exposes hidden ordering problems that used to work by accident (and were always a bit finicky). - Profile-based installs no longer see a module's
/config/installas part of the "initial config set". If a distribution rewrites config from contrib modules (e.g., Metatag) but the profile does not export that base config, config_rewrite now reports "initial config missing".
For Drupal WxT, we have several profile extensions that are optionally enabled (e.g., wxt_ext_metatag adjusts Metatag defaults to align with Government of Canada standards). With these installer changes, it appears we can no longer rely on optional profile modules to safely provide or rewrite configuration. We may now need to declare more dependencies directly on the profile itself, making the configuration more "all or nothing".
Given these changes, this might push us towards a recipe-based approach, where optional configuration can be applied deterministically and without depending on installer timing or profile-owned config.
Looks like LocalGov Drupal folks are also running into this issue, which might be caused by differences between 11.1.x and 11.2.x, see related issue.
This has been included with 6.1.4. I will also add this to 6.2.x.
Included with 6.1.3.
In WxT 5.x the patches/PRs in #15 ✨ Support additional field types for WET-BOEW inline form validation Active are still required since we are not adding this feature to 5.x.
@danrod are you referring to the description in the *.info.yml file?
This has been included in release 5.4.4. Still requires inclusion with 6.1.x.
I've got WxT upgraded to Drupal 11.2.7 and running locally on latest docker-scaffold 11.2.x.
Here are the packages that have been updated:
- drupalwxt/wxt 6.1.x => 6.2.x
- drupal/wxt_bootstrap 11.1.x => 11.2.x
- drupal/wxt_library 11.1.x => 11.2.x
- docker-scaffold 11.1.x => 11.2.x
In general this update was pretty straightforward (so far), and Drupal 11 is starting to mature so we are seeing a much cleaner composer.json:
Overview of composer.json changes:
- Remove 2 core patches (rolled into 11.2.x)
- Remove 1 entity_browser patch (raolled into latest release)
- Upgrade of 9 contrib modules from dev/alpha/beta/rc to full releases
@liam is drupal/gcds a drop in replacement for wxt_bootstrap? Like will it support existing WxT functionality or will it require a complete redo of the theming layer? I'm looking for the best approach to ease projects into GCDS while still supporting existing WxT users, I want to avoid a theme overhaul. For example, canada.ca at the time of this ticket uses wet-boew with one GCDS component for the date modified.
Pushed up version 0.1.4, which was some cleanup and adding the ability to specify ID for user to get a single user object. I also updated my site using n8n to D11.2 so I can install orchestration (getting ready to use it for webform data). Next will look at create and update for user, then can move to content entities.
Pushed up changes to fix the remaining PHPStan issues, now all tests are passing.
I've pushed up a new version of the community node (0.1.3) and I am now able to authenticate (basic auth) into my site and get a list of all users.
@jurgenhaas when it comes time to implement content entities I will take the same approach you are referring to; get entity types, bundles, and field definitions to make it dynamic based on the connected site.
@jurgenhaas yes it would be great to do the CRUD operations for content entities in general, so we could act on terms, media, users, etc... I'm also interested in receiving and acting on webform submissions for one of my use cases.
Small change to patch in #9 to get working with D11.
Following the suggested community node approach from the n8n team, I’ve created a dedicated npm package to handle the Drupal n8n integration as a standalone community node.
Key steps taken:
- Bootstrapped the new node using the official template command
- Added credential support (
DrupalApi.credentials.ts) and a minimal action to begin testing connectivity with Drupal’s JSON:API endpoint - Packaged and published to GitHub for version control and testing
- Released the first version to npm for local and hosted installs
Repositories / Releases:
- GitHub: https://github.com/cinders-io/n8n-nodes-drupal
- npm package: https://www.npmjs.com/package/n8n-nodes-drupal
The current version includes the basic credential handling and a placeholder action, along with the Drupal SVG logo. Next steps will involve adding full CRUD operations for nodes (create, update, delete) and entity listing, aligning with the Drupal JSON:API approach.
We use this feature in the Drupal WxT distro, it's really nice to have. Sounds like it's already available in 3.0.x, we are just not able to update right away. I suggest we cut some patches based on the MR in the related issue, and we can include these patches in WxT until we are done with the 11.2.x and 10.5.x core updates (so we can update to book 3.0.x). The tests in the MR appear to be passing, and we have a few projects that use this to test against before including in WxT.
@al_trottier correct, for 6.1.x we updated drupal/redis to ^1.10 and switched the patch for #49. I think we can do the same thing for 5.4.x, since that version of drupal/redis is good for D10 and D11. This was an important patch so want to make sure we don't drop it from 5.4.x.
@jurgenhaas I agree, if we can keep the orchestration side generic to support activepieces and n8n without custom code per platform that would be best. Thanks for bringing this up, will keep this in mind as I continue to explore the solution.
This has been implemented, now markers use their corresponding title from the JSON file as the aria-label value, default to marker ID if no title is available.
This has been implemented in the positionPopover() function. Now the popups are positioned relative to the marker that triggers it.
This has been implemented, now the focus is trapped within the popup when active.
This has been implemented, now the popup uses the data defined in the JSON file, and the prev/next buttons are configurable (hide/show) per block instance.
The fetchJson() function has been implemented and returns the JSON data as expected.
The base module structure has been completed, and a working POC is available in the 1.0.x-dev branch.
This has been completed, and confirmed working as expected. This field on the block allows for multiple marker types (Marker-*, Pin-*, etc...).
Navigation elements (prev/next) have been added and are configurable (enabled/disabled) depending on the use case. In some scenarios, where the progression of markers is not linear, this feature can be disabled.
Example JSON has been added to the block config in a details element for easy reference.
I'm having the same issue on my multilingual site. I have changed the helper function from strStartsWith() to strContains() to account for the language prefix in the URL path. I have also included a patch to use in my project now. I will test this in our Azure environment in the next few days and report back.
smulvih2 → changed the visibility of the branch feature/sso-multilingual-fix to active.
smulvih2 → changed the visibility of the branch feature/sso-multilingual-fix to hidden.
smulvih2 → changed the visibility of the branch 3544571-sso-login-does to hidden.
smulvih2 → made their first commit to this issue’s fork.
Ya this is more of a placeholder ticket, it is just the removal of the redis patch from composer.json, same change as parent ticket.
@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.