arno_vgh → created an issue.
arno_vgh → made their first commit to this issue’s fork.
I was wrong in my previous comment (#3), the expected result was not achieved in either way.
Checking if the child(ren) of a container should be excluded does the trick in my case. I hope someone can reproduce this problem and that these adjustments can fix it without other impact.
Changed the status to minor because the functionality seems to work as expected when using 'Custom body...' to construct the mail template, rather than the 'Twig template...'.
I'll continue investigating the Twig template. If I can't find a solution, or if using the custom body option proves sufficient, I'll close this issue as the functionality is working as designed.
arno_vgh → created an issue.
arno_vgh → changed the visibility of the branch 3449549-webform-remotepost-exclude-fields-wo-access to hidden.
arno_vgh → created an issue.
This functionality appears to be functioning correctly based on my testing.
Here are the steps I followed:
- Created a simple webform with some elements and ensured they were translated.
- Added email handlers for the 'current', 'Dutch' (which is my current language), and 'English' versions.
- Submitted Webform.
- I observed that emails were sent appropriately, with the 'Dutch' and 'current' versions using the Dutch translation, while the 'English' version used the English translation. 😊
Updated following your suggestion.
For me the most important is to choose a name that goes beyond simply indicating a POST request.
Better names or other toughts about this Webform handler always welcome, but let's keep this small 'issue' simple
Updated following your suggestion.
For me the most important is to choose a name that goes beyond simply indicating a POST request.
Better names or other toughts about this Webform handler always welcome, but let's keep this small 'issue' simple
arno_vgh → created an issue.
Hi,
Although I appreciate this adjustment immensely, I would have preferred to see it documented in the change records as it could potentially break existing code and therefore likely requires changes.
In the past, using $category = $webform->get('category') (assuming a webform could only have one category) will now return NULL. Updating the code to $webform->get('categories') will now return an array of categories.
(My apologies if this information is already documented somewhere and I overlooked it).
arno_vgh → created an issue.
arno_vgh → created an issue.
I agree this is project-specific customization.
When already using views on your Drupal site, an alternative could be to create a group view page on the /admin/group path. You now can customize the fields, sorting, etc. yourself.
Please correct me if this is a no-go or if there is a better way to accomplish this.
As stated in hook_library_info_alter():
The library ID will be prefixed with the module name automatically
Maybe helpful to note once more in case anyone is wondering why the library won't add.