dieterholvoet → created an issue.
This issue has been committed, but never released. Any chance you could create a last 8.x-1.x patch release?
Not sure if it's a good idea for core, but in the HTTP Cache Control module → we added an Expert mode toggle to the Performance config form that toggles maxage inputs between selects with readable presets and number inputs.
This handler doesn't prevent submissions as far as I know. Are you sure the 'Disable saving of submissions' option is not enabled on your webform? Are submissions being saved when you remove the handler?
dieterholvoet → changed the visibility of the branch 1.0.x to hidden.
dieterholvoet → made their first commit to this issue’s fork.
Thanks!
dieterholvoet → made their first commit to this issue’s fork.
Thanks!
dieterholvoet → made their first commit to this issue’s fork.
dieterholvoet → made their first commit to this issue’s fork.
Thanks!
dieterholvoet → made their first commit to this issue’s fork.
Dflydev\DotAccessData\Exception\InvalidPathException is not related to the Symfony Dotenv component, so there's no point in catching it. Also, these files do not look like the one that this module provides. I'm guessing there already was a load.environment.php present before you ran the command. You can find the file that this module provides here.
dieterholvoet → created an issue.
dieterholvoet → created an issue.
dieterholvoet → created an issue.
dieterholvoet → created an issue.
I tested this with a <h2> and you're right. Without the patch, the id attribute isn't in the filtered HTML and with the patch it is.
dieterholvoet → created an issue.
dieterholvoet → created an issue.
The test failure is about the CKEditor plugin, seems unrelated.
@layalk should be credited here, she reported the issue in ✨ Add Search API processor to strip citations from content Active .
You're right, I missed that. Created a new issue to fix the namespace: 🐛 The class namespace of the new Search API processor is wrong Active .
dieterholvoet → created an issue.
I think you're misunderstanding the purpose of this module, it's not about XSS filtering or stripping HTML. To refer to the project description:
This module provides a Webform handler that allows submission data of certain form elements to not be stored in the database. The submission data can still be used in other handlers preceding the Sanitize submission handler.
I tested this in Drupal 11.1.6 and Redirect 1.11.0 and I can't reproduce this either.
This indirectly fixes an issue for me where pages get stuck in an infinite loop when using the flattened site settings loader.
dieterholvoet → created an issue.
dieterholvoet → made their first commit to this issue’s fork.
I changed the target branch.
dieterholvoet → created an issue.
dieterholvoet → created an issue.
Yes, it looks like negotiating the active domain this early in the request (during the loading of config overrides) is not supported. I started a MR with an approach where the active domain is loaded on demand. Having our own static cache is unnecessary since the active domain is also just a property on the DomainNegotiator service, so there isn't any performance gain.
dieterholvoet → made their first commit to this issue’s fork.
dieterholvoet → made their first commit to this issue’s fork.
I also added a custom translation handler to actually make publishing of translations work. The code is mostly based on Drupal\node\NodeTranslationHandler and Drupal\eck\EckTranslationHandler.
I don't think it's necessary to add a custom setting to control the visibility of the status field. That's what the form display UI is for. I'll change it so the field is hidden by default and can be displayed by moving it in the form display. I also changed the default value of the publishing status to TRUE.
dieterholvoet → made their first commit to this issue’s fork.
I created a new MR targeting 3.0.x.
dieterholvoet → changed the visibility of the branch 3090261-setinlineblockdependency-override-might to hidden.
dieterholvoet → changed the visibility of the branch 3090261-2_15 to hidden.
I started a new MR on an issue branch instead of the main 8.x-2.x branch.
dieterholvoet → changed the visibility of the branch 8.x-2.x to hidden.
dieterholvoet → made their first commit to this issue’s fork.
dieterholvoet → created an issue.
dieterholvoet → created an issue.
dieterholvoet → changed the visibility of the branch 1.x to hidden.
Is the idea of preprocess hook because we don't have a single spot in the plugins/classes to build them?
Yes, just to make it work anywhere #theme => footnote_links is used. I guess it's only used at one place in the module, but it could also be used in another module. And also to support controlling this behaviour by passing #simplify_sequential_citations => TRUE/FALSE.
Are you sure they are actually still required? The red asterisks still shows, but you shouldn't get any validation errors when saving the entity.
Maybe also update all existing redirect entities in a update hook to stop using any of the removed status codes?
dieterholvoet → created an issue.
This InvalidArgumentException is also being triggered by bot traffic on all our sites using the Lazy module because it uses this RequestPath condition plugin. It's being triggered by visiting the path /index.php.suspected, so not just paths with double slashes. That's why I want to propose to also just catch any InvalidArgumentExceptions thrown in the getAliasByPath() method.
Never mind, that doesn't fix it. I now have citations that link to #footnote1, while the footnote has an ID of footnote1-0. That's on a page with multiple text areas with footnotes and with all of them aggregated at the bottom of the page.
dieterholvoet → created an issue.
For me this fixes the issue where links from citations to grouped references at the bottom of the page weren't working anymore.
These two .env variables are specific to the Laravel integration of Ignition (source), there are not (yet) supported in the Drupal module. Currently, the only way to change these settings is through the UI. I'm changing this to a feature request.
Why not postpone adding the argument to the interface until the next major version and until then make it an optional argument in worker classes like this:
public function processItem($data, ?object $metadata = NULL): void
calling the method like this:
$worker->processItem($item->data, $metadata);
That way it works both for workers with and without the method and the necessary changes to queue workers will be a lot more straightforward.
At some future point we could deprecate the processItem() method and just support the new method and interface?
If you're going to eventually do a breaking change, might as well stick to the same interface and method name and make the breaking change the addition of the new argument to the existing method, no?
dieterholvoet → created an issue.
dieterholvoet → created an issue.
Do we really need a new interface and method here? Why not just add the metadata as an optional argument to the processItem function and add it to the interface in a new major?
dieterholvoet → changed the visibility of the branch 3430646-automated-drupal-11 to hidden.
dieterholvoet → changed the visibility of the branch fix-composer-json to hidden.
Thank you! I opted the project into security coverage, added Gitlab CI, finished and merged all issues and created a first release. I'll stay around for any new issues as well, for the time being.
dieterholvoet → created an issue.
Can't seem to reproduce this in the latest version.