Een hart voor de Drupal Community

Thanks for the feedback michaelsoetaert. Closing this issue then.

The value is expected to always be an array, either through import of the config via /config/install, or for existing sites, by running database updates. Specifically layout_builder_iframe_modal.post_update.php method layout_builder_iframe_modal_post_update_custom_routes_config() should make this an array, if it isn't already.

Sven Decabooter added a comment on drupal.org: Contrib Table / BoF at Drupal Developers Day Leuven 2025

Sven Decabooter added a comment on drupal.org: Contrib Table / BoF at Drupal Developers Day Leuven 2025

Sven Decabooter added a comment on drupal.org: Automated Drupal 11 compatibility fixes for webform_entity_reference_exclude

Sven Decabooter added a comment on drupal.org: Integrate with the Key module

Patch version of the current MR state, for Composer based patching workflows.

Sven Decabooter added a comment on drupal.org: Integrate with the Key module

I have created a merge request that reworks this concept, as suggested by jcnventura. It adds a "credentials_provider" to the plugin configuration, that defaults to "config", which will just keep on storing the client_id and client_secret in the plugin configuration, as is the case currently. If the "Key" module is installed, an optional second credentials provider gets added to the dropdown list, and users are able to optionally select a multivalue key for retrieving the appropriate credentials.

If the Key module is not installed, nothing changes. If the key module is installed, nothing changes by default, but you can opt-in to use a Key rather than providing the credentials inline.

Thanks for reviewing this MR and considering whether this could be added to the module.

svendecabooter made their first commit to this issue’s fork.

Tests are failing but I don't think this patch is causing it.

Hi Manuel,

You're right, I have not yet been involved with issues thus far :) I'll get into that ASAP.

I was hoping we could open a new branch for D10/11 compatibility (2.0.x), and immediately tackle all those issues. That way, 1.x could remain 'supported' but not maintained for D9, and we can go forward in 2.0.x with modern code (OOP hooks and other newer technologies).

I'll keep you posted!

Sven Decabooter added a comment on drupal.org: Support OOP hooks

Sven Decabooter added a comment on drupal.org: Support image_widget_crop 3.0

Support image_widget_crop 3.0.x branch: https://www.drupal.org/project/image_widget_crop/releases/3.0.x-dev

svendecabooter created an issue. See original summary.

Good to see progress being made here, and thanks to everyone being candidate to step up for this role!

I'd like to cast a vote for: - Joris Vercammen (borisson_) - Marine Gandy (Mupsi)

Hi,

This module currently remains unmaintained and unsupported, while I feel like this module absolutely has its use in modern Drupal websites. From translated paths for views to custom controller path aliases, there's a number of cases where this is useful.

On my profile you can see a few modules I actively maintain, I also attempt to create and fix issues I encounter in other modules.

So, in short, I'd like to "revive" this module and release new versions and keep it up-to-date with the latest versions of Drupal.

Feel free to contact me for further questions!

- https://www.drupal.org/project/fixed_path_alias

randalv created an issue. See original summary.

Drupal 9 is no longer supported, so we should drop support for both Drupal 9 and PHP7, not the other way around.

kraut credited svendecabooter.

esmoves credited svendecabooter.

New tag has been released. Thanks again!

Hi @andybroomfield,

Good catch! The class name was altered at the last moment before merge, seems I forgot to alter the service name. Thank you.

I'll merge and release a new version.

randalv made their first commit to this issue’s fork.

Seems logical, I've added the hooks_converted parameter.

Since the other threads are resolved, I'll merge into 1.2.x

Sven Decabooter added a comment on drupal.org: Support OOP hooks

Sven Decabooter added a comment on drupal.org: Support OOP hooks

MR looks good to me. Maybe we also need to add the 'hooks_converted' parameter for performance improvement: https://www.drupal.org/node/3490771

Seems like core is mostly putting all hooks together in a Hook\[MODULENAME]Hooks.php file, but I agree splitting up in logical chunks / files makes sense.