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.
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.