🇨🇦Canada @smulvih2

Checklist:

• Created a drupalwxt/docker-scaffold 10.6.x branch - https://github.com/drupalwxt/docker-scaffold/tree/10.6.x
• Created drupalwxt/wxt 5.6.x branch and get tests passing - https://github.com/drupalwxt/wxt/actions/runs/20788945501
• Created drupalwxt/site-wxt 10.6.x branch and get tests passing - https://github.com/drupalwxt/site-wxt/actions/runs/20792050339

Changes:

• Update drupal/linkit from ^6.1 to ^7.0 (needed for core > 10.5)
• Updated unsupported drupal/media_entity_instagram from from ^3 to ^4
• Updated unsupported drupal/metatag from ^1.13 to ^2.2
• Updated unsupported drupal/toc_api from ^1.2 to ^2.0

All tests passing in GitHub, pushing to Drupal GitLab next.

I initially tested the docker-scaffold upgrade using PHP8.4 but there were some deprecation warnings so decided to stick with PHP8.3.

Jumping to core 10.6.x since it's pretty straightforward.

Only dependency issue is with linkit ^6.1 (core <10.5.0). Upgrading linkit to ^7.0 fixes the issue and removes a patch.

Bumped version to 5.4.5 for this release.

Fixed by parent issue, thanks!

@fabianderijk I am using my patch in #9 and it has been working for me using multilingual with path prefix (/en, /fr). Changes in MR look good to me! RTBC

Ok I only included the change to wxt_admin module since the ticket description only talks about this. Putting back to Needs Review and will look at including the MR which has changes across many sub-modules.

Feedback on the book feature (fresh install)

- The Book content type Body field is now called Description and is required. We should relabel back to Body and make it not required.
- The Book content type is now using content moderation, I think this is a good change to keep.
- Adding Basic page as book-enabled we do not get footer navigation (index page and sub-page previous/next)
- Landing page now uses content moderation, I think this is a good change to keep.
- Tested gcweb migration and all seems to work as expected.
- I would remove the changes to Landing Page config on install, doesn't seem like a pattern that many would use. But book feature does work with layout builder so that is great!

Will run this through the automated builds next to see if things work.

Feedback on the book feature (upgrade existing site):

- On fresh wxt 6.1.x I added a test book with child pages
- I added the patches to wxt and wxt_bootstrap, and required drupal/livre (only needed for testing)
- I ran drush updb and saw this (probably not a show-stopper), but the updates completed successfully:

> [warning] The "extra_field_block:node:landing_page:book_navigation" block plugin was not found
> [warning] The "extra_field_block:node:landing_page:book_navigation" block plugin was not found
> [warning] The "extra_field_block:node:landing_page:book_navigation" block plugin was not found

Now my book config looks like this:

Now I enabled Basic page and by accident selected Landing page as the child type. Once I did this, I was not able to save the book config form again to fix my mistake, and not able to enable Landing page as a book-enabled content type to fix this either:

I was able to get past this by exporting the book config in the Drupal UI:

_core:
  default_config_hash: jmBcLtS4JshpXXtB9fsiBehhukIaDTQjvozHpbvVyPo
allowed_types:
  -
    content_type: book
    child_type: book
  -
    content_type: page
    child_type: landing_page
book_sort: weight
truncate_label: true
use_parent_selector: false

Then remove the second entry under allowed_types and import the config to get back to default where I can save the config form:

_core:
  default_config_hash: jmBcLtS4JshpXXtB9fsiBehhukIaDTQjvozHpbvVyPo
allowed_types:
  -
    content_type: book
    child_type: book
book_sort: weight
truncate_label: true
use_parent_selector: false

Once I did this, I was able to select Basic page -> Basic page in the config form and it worked as expected:

I tested the wxt book config options against my existing book (book content type) and it worked as expected (/en/admin/config/wxt/wxt_ext_book) including:

• Enable persistent navigation on book index
• Use page titles as book navigation labels
• Include a home link in book navigation

Then I added a Basic page book with child pages but the navigation on the index page and sub-pages didn't show up:

Index page:

Sub-page:

The basic page content type is not managed by layout builder, so I would expect that the navigation would show automatically (based on previous working behaviour).

Then I enabled Landing page as a book-enabled content type and added a new book. When I created the index page, I get a missing block where the index navigation should be. This might be due to the drush updb issues reported before:

Creating a sub-page on the Landing Page book I do see the sub-navigation, as well as the same missing block at the bottom of the page:

Once I added the first "Book navigation" block to layout builder from previous comment I get the book index and sub-page navigation at the bottom of the page as expected.

Feedback:
- I don't think we should by default add Landing Page as book enabled. Landing page is a content type I don't normally use as it is designed to use entity queue for showing block, and is really meant for a landing page not a book page. I will test this more during a fresh install with these changes in place (this test was for upgrade of an existing site). Landing page is used by our content migration for tests in automated builds, so would be good to keep basic to avoid issues.

Will get this into 6.1.x next after doing some test upgrades locally.

The fix to the dependency name for admin_toolbar:admin_toolbar_tools has been pushed to 6.1.x.

Included in 6.1.x.

This has been merged with 6.1.x and will be available in 6.1.5.

Small fix to patch #11, changed $module_handler->moduleExists($m) with $moduleHandler->moduleExists($m) to prevent error on drush updb.

This has been merged with 6.1.x.

We needed to disable WET-BOEW inline client-side validation when users click the Previous button on multi-step Drupal Webforms. Users should be able to move back without being blocked by validation errors.

Approaches Tested

1. HTML5 formnovalidate attribute
Added via hook_webform_submission_form_alter().
Result: Browser validation disabled, but WET/jQuery Validate still executed, so errors continued to appear.

2. jQuery Validate .cancel class trick
Added class="cancel" to the Previous button.
Result: Works in plain jQuery Validate, but WET wraps validation and ignores this path, so validation still triggered.

3. Using global once() to intercept click
JS attempted to intercept click and re-submit.
JS correctly attached, but validation still fired before the handler, indicating event order problem.

Final Solution

The issue was order of execution. WET’s validation submit handlers were firing before our script. The successful approach was to:

• Mark the Previous button in PHP: data-wet-skip-validation="1"
• In JS:
• Use capture-phase event listener (addEventListener(..., true))
• Call preventDefault() and stop propagation
• Submit the form via native form.submit(), bypassing WET/jQuery handlers

Result:
Previous button now navigates back a page with no inline validation, while Next / Submit continue to enforce WET validation normally.

smulvih2 → created an issue.

Closing this ticket and we can use the MR in the related wxt_library issue, thanks!

Ok let's look at getting this into the next release. Hopefully those column classes were removed from source.

@web247 thanks for updating the patch, changes look good! Will merge this in for the next 6.1.x release.

I don't think we need this logic in a hook_install() since the .info file will take care of that when installing the module. I think the issue is only when upgrading and wxt_ext_editor is already enabled, so this should be done in a hook_update() in wxt_ext_editor. Since jquery_ui_resizable is a dependency of wxt itself, this one module could be installed via a hook_update() in the wxt_core module. This way if a site is not using wxt_ext_editor, only the one module will be installed.

Also, the two arrays and switch statement could probably be replaced with something like this (not tested):

$modules = [
  'ckeditor_abbreviation',
  'ckeditor_details',
  'footnotes',
  'toc_api',
  'toc_filter',
  'wxt_ext_media_image_responsive',
];

// Only install what's missing.
$missing = array_values(array_filter($modules, fn($m) => !$module_handler->moduleExists($m)));
if ($missing) {
  $module_installer->install($missing);
}

@liam thanks for the nudge, will include this in the next release of 6.1.x.

@web247 this should be an install hook for the wxt_ext_editor module, then you can remove the check for the wxt_ext_editor module. Also not sure if we should check if the individual modules are already installed or not before trying to install them, please let me know after testing this. Thanks!

Running into this issue on Drupal 10.4 with a domain-based language negotiation. The MR#5 fixes the issue for me. Adding a patch here so I can use it in my project.

I merged this change yesterday but the GitHub action status still says it is Queued. Seems like an issue with the GitHub action or project, will have to investigate further.

I tried this out on a fresh install of WxT, then added the patches to wxt and wxt_bootstrap and ran into this error when running drush updb:

composer drush updb
> docker compose exec -w /var/www/html web /var/www/vendor/bin/drush 'updb'
-------------- ----------------- --------------- -----------------------------
Module Update ID Type Description
-------------- ----------------- --------------- -----------------------------
book 103007 hook_update_n 103007 - Grant 'administer
book settings' permission.
book 103008 hook_update_n 103008 - Add show_top_item
use_parent_selector
settings config.
wxt_ext_book 10001 hook_update_n 10001 -
book add_default_lab post-update Add the default label
el_truncate_set truncation setting.
tings
book allowed_child_t post-update Set allowed child_type to
ype_default6 parent if none previously
configured.
book book_list_permi post-update Grant 'access book list'
ssion permission to roles with
'access content'.
book convert_allowed post-update Converts
_types_to_struc book.settings.allowed_types
tured + child_type to structured
format.
book remove_add_any_ post-update Remove 'add any content to
content_books_p books' permission.
ermission
-------------- ----------------- --------------- -----------------------------

┌ Do you wish to run the specified pending updates? ───────────┐
│ Yes │
└──────────────────────────────────────────────────────────────┘

> [notice] Update started: book_update_103007
> [notice] Update completed: book_update_103007
> [notice] Update started: book_update_103008
> [notice] Update completed: book_update_103008
> [notice] Update started: wxt_ext_book_update_10001
> [warning] The "extra_field_block:node:landing_page:book_navigation" block plugin was not found
> [warning] The "extra_field_block:node:landing_page:book_navigation" block plugin was not found
> [warning] The "extra_field_block:node:landing_page:book_navigation" block plugin was not found
> [notice] Update completed: wxt_ext_book_update_10001
> [notice] Update started: book_post_update_add_default_label_truncate_settings
> [notice] Updated the default truncate setting.
> [notice] Update completed: book_post_update_add_default_label_truncate_settings
> [notice] Update started: book_post_update_allowed_child_type_default6
> [error] TypeError: Cannot access offset of type string on string in book_post_update_allowed_child_type_default6() (line 148 of /var/www/html/modules/contrib/livre/book/book.post_update.php) #0 /var/www/vendor/drush/drush/src/Commands/core/UpdateDBCommands.php(291): book_post_update_allowed_child_type_default6(Array)
> #1 /var/www/vendor/drush/drush/includes/batch.inc(257): Drush\Commands\core\UpdateDBCommands::updateDoOnePostUpdate('book_post_updat...', Array)
> #2 /var/www/vendor/drush/drush/includes/batch.inc(204): _drush_batch_worker()
> #3 /var/www/vendor/drush/drush/includes/batch.inc(75): _drush_batch_command('1')
> #4 /var/www/vendor/drush/drush/src/Commands/core/UpdateDBCommands.php(145): drush_batch_command('1')
> #5 [internal function]: Drush\Commands\core\UpdateDBCommands->process('1', Array)
> #6 /var/www/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array(Array, Array)
> #7 /var/www/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
> #8 /var/www/vendor/consolidation/annotated-command/src/CommandProcessor.php(175): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
> #9 /var/www/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(389): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
> #10 /var/www/vendor/symfony/console/Command/Command.php(279): Consolidation\AnnotatedCommand\AnnotatedCommand->execute(Object(Drush\Symfony\LessStrictArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #11 /var/www/vendor/symfony/console/Application.php(1094): Symfony\Component\Console\Command\Command->run(Object(Drush\Symfony\LessStrictArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #12 /var/www/vendor/symfony/console/Application.php(342): Symfony\Component\Console\Application->doRunCommand(Object(Consolidation\AnnotatedCommand\AnnotatedCommand), Object(Drush\Symfony\LessStrictArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #13 /var/www/vendor/symfony/console/Application.php(193): Symfony\Component\Console\Application->doRun(Object(Drush\Symfony\LessStrictArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #14 /var/www/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run(Object(Drush\Symfony\LessStrictArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #15 /var/www/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
> #16 /var/www/vendor/drush/drush/drush.php(140): Drush\Runtime\Runtime->run(Array)
> #17 /var/www/vendor/bin/drush.php(119): include('/var/www/vendor...')
> #18 {main}.
> TypeError: Cannot access offset of type string on string in /var/www/html/modules/contrib/livre/book/book.post_update.php on line 148 #0 /var/www/vendor/drush/drush/src/Commands/core/UpdateDBCommands.php(291): book_post_update_allowed_child_type_default6(Array)
> #1 /var/www/vendor/drush/drush/includes/batch.inc(257): Drush\Commands\core\UpdateDBCommands::updateDoOnePostUpdate('book_post_updat...', Array)
> #2 /var/www/vendor/drush/drush/includes/batch.inc(204): _drush_batch_worker()
> #3 /var/www/vendor/drush/drush/includes/batch.inc(75): _drush_batch_command('1')
> #4 /var/www/vendor/drush/drush/src/Commands/core/UpdateDBCommands.php(145): drush_batch_command('1')
> #5 [internal function]: Drush\Commands\core\UpdateDBCommands->process('1', Array)
> #6 /var/www/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array(Array, Array)
> #7 /var/www/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
> #8 /var/www/vendor/consolidation/annotated-command/src/CommandProcessor.php(175): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
> #9 /var/www/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(389): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
> #10 /var/www/vendor/symfony/console/Command/Command.php(279): Consolidation\AnnotatedCommand\AnnotatedCommand->execute(Object(Drush\Symfony\LessStrictArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #11 /var/www/vendor/symfony/console/Application.php(1094): Symfony\Component\Console\Command\Command->run(Object(Drush\Symfony\LessStrictArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #12 /var/www/vendor/symfony/console/Application.php(342): Symfony\Component\Console\Application->doRunCommand(Object(Consolidation\AnnotatedCommand\AnnotatedCommand), Object(Drush\Symfony\LessStrictArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #13 /var/www/vendor/symfony/console/Application.php(193): Symfony\Component\Console\Application->doRun(Object(Drush\Symfony\LessStrictArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #14 /var/www/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run(Object(Drush\Symfony\LessStrictArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #15 /var/www/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
> #16 /var/www/vendor/drush/drush/drush.php(140): Drush\Runtime\Runtime->run(Array)
> #17 /var/www/vendor/bin/drush.php(119): include('/var/www/vendor...')
> #18 {main}
> [warning] Drush command terminated abnormally.

In ProcessBase.php line 171:

Unable to decode output into JSON: Syntax error

TypeError: Cannot access offset of type string on string in book_post_update_allowed_child_type_default6() (line 148 of /var/www/html/modules/contrib/livre/book/book.post_u
pdate.php).

Script docker compose exec -w /var/www/html web /var/www/vendor/bin/drush handling the drush event returned with error code 1

Sorry this was my confusion. The fixes for layout_builder_st are marked as Fixed, but are still only in the dev version of the module. Last 1.x-alpha3 was from 2022, so doesn't look like we will be getting these fixes rolled into a new release anytime soon!

smulvih2 → created an issue.

@joseph good catch on this, nice to bring this into alignment with current core versions. I have made this change to the 5.4.x branch, will include your patch on 6.1.x later.

This has been confirmed fixed and pushed to 5.4.x

I was able to reproduce this error by editing a layout in the Layout Library page - /admin/structure/layouts

Editing a layout and trying to add a block produces the error below. I can confirm that upgrading to layout_builder_restrictions to 3.0.4 fixes the issue.

smulvih2 → created an issue.

@jurgenhass I have since updated the community node to be more generic as you mentioned, allowing users to select a content entity and an associated bundle to perform CRUD operations on. I have also filtered the entities to only show content entities; excluding config entities.

I was able to successfully perform a create/update/delete against my site, which required the following enhancements to the community node to get working:

• Make the Attributes field a string with default value of {}, and make the field input 10 rows high. This ensures the user has an input for the values if an expression is not used.
• Ensure the provided string is valid JSON and send to JSON:API as an array instead of a string.

This allows the user to define the entity in JSON and provide expressions for either the full value or individual field values.

These changes are available in 0.1.13, and have been pushed to n8n.cinders.io for testing.

@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:

1. 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/optional or not present in the install profile's exported config, the entire batch now fails validation.
2. Config install is now split into phases: InstallSimple -> InstallEntities -> Optional. Bundles placed in /config/optional don’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).
3. Profile-based installs no longer see a module's /config/install as 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:

1. 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/optional or not present in the install profile's exported config, the entire batch now fails validation.
2. Config install is now split into phases: InstallSimple -> InstallEntities -> Optional. Bundles placed in /config/optional don’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).
3. Profile-based installs no longer see a module's /config/install as 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.

I get the same error when installing via the UI:

smulvih2 → created an issue.

This has also been added to 11.2.x.

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.

Included with 6.1.3.

11.1.0 released, will pull into WxT 6.1.x next.

smulvih2 → created an issue.

@danrod are you referring to the description in the *.info.yml file?

@liam good catch, this has been included in 11.1.1.

This has been included in release 5.4.4. Still requires inclusion with 6.1.x.

This has been included in release 5.4.4.

This has been included in release 5.4.4.

smulvih2 → created an issue.

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.

smulvih2 → created an issue.

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.

Version 1.0.0 has been released!

Pushed up changes to fix the remaining PHPStan issues, now all tests are passing.

smulvih2 → created an issue.

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.

Completed as part of 1.0.x

Added in 1.0.x

This has been added in 1.0.x

Completed with 1.0.x

Completed in 1.0.x

Completed in 1.0.x

This is working as expected.

This has been completed in 1.0.x

Completed in 1.0.x

This has been completed as part of 1.0.x

This has been completed as part of 1.0.x

This has been completed as part of 1.0.x

This has been completed as part of 1.0.x

Fix as part of 1.0.x

This has been completed in 1.0.x

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 in 1.0.x-dev

This has been completed as part of 1.0.x-dev

This has been implemented in 1.0.x-dev

This has been implemented in 1.0.x-dev

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.