🇧🇪Belgium @svendecabooter

Thanks for the summary and both for your work on this!

I created a MR to add this functionality.
For the selectable prefill attributes for form elements I didn't add an option, as this needs to be configured per field widget manually anyway, AFAIK.

Attached is also a patch version of the MR changes, for Composer based workflows.

svendecabooter → created an issue.

That looks like a great approach to add translation options to recipes.

I don't have strong feelings regarding the exact syntax, but personally prefer the options where the parameters are named explicitly (so 2nd or 3rd).

I'm assuming the 3rd could also be written as

   form:
      '#type': email    
      '#title': !translate { 
        string: 'Feedback form email address', 
        context: 'Third context' 
      }

As it would avoid having everything on 1 line, especially with larger strings you would need to do some horizontal scrolling in your IDE.
Come to think of it, then I probably prefer the 2nd version, as it avoids the extra brackets as well..

Thanks for the notice.
Since this module has more usage and already has some releases, I think it would make sense to deprecate your module, and provide its extra functionalities in this module. I'd be happy to review merge requests to get extra functionality in.

Sorry for the delay. Had a bit of time to review this now.

This does allow the user to select the type of message to send, but only when the action plugin is triggered.
When editing a user and clicking the button shown on the form, the old behaviour is still used.
So that introduces 2 different behaviours, according to the path you take to trigger it.

Also, would it be an option to reuse the functionality that now decides in code which mail to send, to provide a default value to the user? Some editorial users might not know which email is the most appropriate, so guiding them in the right direction would be good.

The next version of the module will no longer support Drupal 9, so marking this ticket as outdated.

Thanks for the MR.
Updated code a bit, and committed.

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.

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

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.

svendecabooter → created an issue.

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)

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

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.

- Hook help still needs to be added as OOP hook
- All hooks need to be marked as converted, as per https://www.drupal.org/node/3490771 →

svendecabooter → created an issue.

Reverted, because module still contains a preprocess procedural hook.

svendecabooter → created an issue.

svendecabooter → created an issue.

Thanks for the MR and improvements!

svendecabooter → created an issue.

The "configuration" section of the readme should describe that the Range Input widget needs to be selected for a relevant facet, and the Range Input processor be selected, for this to work.

The help text in MR #5 does not correctly reflect this.

svendecabooter → changed the visibility of the branch 3337791-replace-readme.txt-to to hidden.

Thanks for the MR. Committed now.

Drupal 9 is no longer officially supported, and OOP hooks only work for 10.1+ anyway

I could work on this if I find some time. Currently just reporting this, without intent to immediately provide some code.

svendecabooter → created an issue.

borisson_ → credited svendecabooter → .

MR looks good.
Still to be added: Setting minimum Drupal version to 10.2

MR introduces PHPCS / PHPStan issues, which would ideally be resolved before merging.

Gave some feedback on the MR

I think it would be better to ignore the PHPStan error about the internal class usage, by ignoring it through a phpstan.neon file in the project, rather than copying over the whole PHP class from core...

Although just ignoring it might give a false sense of security, since we are overriding an internal class, that might suddenly break without BC warnings. But that should probably be covered by test scenario's.

svendecabooter → created an issue.

Thanks for the review.
Hopefully this can be merged in quickly, to unblock multilingual sites from using la_eu.

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

Thanks for the patch.
It doesn't look like UUID export will be committed to core anytime soon, but in the meantime we can already add support for people using this patches in the referenced issue.

D11 support is in the 3.x branch. Closing this issue.

Thanks for the report and fix.
We had encountered the same issue in one of our projects, and confirmed this as a solution.

svendecabooter → created an issue.

svendecabooter → created an issue.

svendecabooter → created an issue.

svendecabooter → created an issue.

Oops not relevant

svendecabooter → created an issue.

svendecabooter → created an issue.

svendecabooter → created an issue.

svendecabooter → created an issue.

svendecabooter → created an issue.

svendecabooter → created an issue.

svendecabooter → created an issue.

svendecabooter → created an issue.

svendecabooter → created an issue.

svendecabooter → created an issue.

svendecabooter → created an issue.

svendecabooter → created an issue.

svendecabooter → created an issue.

svendecabooter → created an issue.

svendecabooter → created an issue.

svendecabooter → created an issue.