Fixed
Project:
Drupal.org security advisory coverage applications
Component:
module
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
20 Apr 2026 at 15:47 UTC
Updated:
22 Apr 2026 at 09:19 UTC
Jump to comment: Most recent
Comments
Comment #2
avpadernoThank you for applying!
Before giving links helpful to understand how the review process works, what to expect from a review, and what to do to avoid a review takes more time than needed, I would like to thank all the reviewers for the work they do.
These applications are volunters-driven, which also means it is not possible to predict when an application will be marked fixed and the applicant will get the permission to opt projects into security advisory policy. While we aim to make an application as quick as possible, it is also important for us that more people review the project used for an application. In this way, we make sure applications do not miss some important points that should be instead reported.
Applications are not meant to be complete debugging sessions that eliminate every existing bug, though. I apologize if sometimes applications seem to go into too-detailed reviews.
Please read Review process for security advisory coverage: What to expect for more details and Security advisory coverage application checklist to understand what reviewers look for. Tips for ensuring a smooth review gives some hints for a smoother review.
The important notes are the following.
Keep in mind that once the project is opted into security advisory coverage, only Security Team members may change coverage.
To the reviewers
Please read How to review security advisory coverage applications, Application workflow, What to cover in an application review, and Tools to use for reviews.
The important notes are the following.
For new reviewers, I would also suggest to first read In which way the issue queue for coverage applications is different from other project queues.
Comment #3
vishal.kadamComment #4
vishal.kadam1. FILE: error_squelch.info.yml
A new project should not declare itself compatible with a Drupal release that is no longer supported. No site should be using Drupal 8 nor Drupal 9, and people should not be encouraged to use those Drupal releases.
2. FILE: error_squelch.module
For a new module that aims to be compatible with Drupal 10 and Drupal 11, I would rather implement hooks as class methods as described in Support for object oriented hook implementations using autowired services.
It would require increasing the minimum Drupal 10 version supported, but Drupal 10.1 is no longer supported.
3. FILE: src/Form/ErrorSquelchSettingsForm.php
With Drupal 10 and Drupal 11, there is no longer need to use #default_value for each form element, when the parent class is ConfigFormBase: It is sufficient to use #config_target, as in the following code.
Using that code, it is no longer needed to save the configuration values in the form submission handler: The parent class will take care of that.
For this change, it is necessary to require at least Drupal 10.3, but that is not an issue, since Drupal 10.2.x is no longer supported.
Comment #5
dinis commentedHey @vishal.kadam,
Thanks for the thorough review. Good catch on all three! I've just pushed commit c012ea3 to 1.0.x, addressing everything:
**1. core_version_requirement**
Raised to ^10.3 || ^11 in both error_squelch.info.yml and composer.json. You're right that pinning to 10.3+ lets us use the modern patterns below without compatibility shims.
**2. Object-oriented hook implementation**
Moved hook_preprocess_status_messages() out of error_squelch.module and into src/Hook/ErrorSquelchHooks.php using the #[Hook('preprocess_status_messages')] attribute. The class is registered as a service in error_squelch.services.yml using its FQCN as the service ID, with MessageSquelcher, ConfigFactory, and AccountProxy injected via the constructor. The .module file is now just a @file docblock.
**3. #config_target in the settings form**
Rewrote ErrorSquelchSettingsForm::buildForm() to use #config_target for all four fields. The three booleans use the simple 'error_squelch.settings:key' string form; squelch_patterns uses a ConfigTarget object with fromConfig/toConfig closures to handle the array to newline-delimited string conversion. submitForm() was removed entirely since the parent now handles everything.
Also ran phpcs with Drupal and DrupalPractice standards. Zero errors, zero warnings. GitLab CI is running now.
Thanks again for taking the time to review, I'm a bit rusty with community submissions :)
Cheers,
Danielle
Comment #6
vishal.kadamFILE: error_squelch.module
Since the module is declared compatible with Drupal 10.3, removing the function implementing the hook is not possible. The function still needs to be defined, but it calls the method defined by the service class, as described in Support for object oriented hook implementations using autowired services (Backwards-compatible Hook implementation for Drupal versions from 10.1 to 11.0).
Comment #7
vishal.kadamRemember to change status, when the project is ready to be reviewed. In this queue, projects are only reviewed when the status is Needs review.
Comment #8
dinis commentedHi @vishal.kadam,
Thanks for catching that, good eyes :)
While I was in there, I also did a broader polish pass (commit 83943c1):
- README.md still said "Drupal 9, 10, or 11" from earlier drafts; now
correctly says "Drupal 10.3 or later, or Drupal 11" to match info.yml
- Added configure: error_squelch.settings so the Configure link appears
on /admin/modules
- Added _admin_route: TRUE to the settings route
- Migrated Drush commands from src/Commands/ to src/Drush/Commands/ and
dropped drush.services.yml in favour of attribute-based autodiscovery
with a create() method
phpcs clean, Drush commands tested locally, CI running. Flipping status
to Needs review.
Cheers,
Danielle
Comment #9
vishal.kadamRest seems fine to me.
Please wait for other reviewers and Project Moderator to take a look and if everything goes fine, you will get the role.
Comment #10
avpadernoThank you for your contribution and for your patience with the review process!
I am going to update your account so you can opt into security advisory coverage any project you create, including the projects you already created.
These are some recommended readings to help you with maintainership:
You can find more contributors chatting on Slack or IRC in #drupal-contribute. So, come hang out and stay involved!
Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.
I thank also all the reviewers for helping with these applications.
Comment #11
avpaderno