Closed (won't fix)
Project:
Drupal.org security advisory coverage applications
Component:
module
Priority:
Minor
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
2 May 2025 at 20:35 UTC
Updated:
25 May 2026 at 08:09 UTC
Jump to comment: Most recent
Comments
Comment #2
vishal.kadamComment #3
rushikesh raval commentedThank you for applying!
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.
phpcs --standard=Drupal,DrupalPracticeon the project, which alone fixes most of what reviewers would report.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 #4
avpadernoAs a side note, since this project is new, it is not possible to opt into security advisory policy for this project before 10 days are passed. (The 10 days are counted from when the project has been created.)
The message shown in the project edit form is the following.
Comment #5
vishal.kadamComment #6
vishal.kadam1. FILE: composer.json
FILE: confirm_unpublish.info.yml
core_version_requirement: ^9 || ^10 || ^11A 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: confirm_unpublish.module
The description for that hook should also say for which form that hook is implemented, either by indicating that with the name of the class that implements the form (namespace included) or the form ID (which is usually indicated by
getFormId()).Comment #7
jason.ullstam commentedThanks everyone for the quick response and I apologize for my delayed response.
@avpaderno I wasn't aware there was a 10 day waiting period. I appreciate the info and I'm definitely ok with that.
@ vishal.kadam thank you for pointing out those issue. I have corrected the core version requirements in the .info and just removed it from composer since it didn't need to be there. I also updated the comment to be more specific in the .module file. All changes are current in the 1.x branch.
I did work this evening to get all the CI passing as well. Ran into some issues with that but got them all straightened out. Please let me know if there is anything else I need to do.
Comment #8
jason.ullstam commentedSetting back to needs review.
Comment #9
bbu23Updating priority according to issue priorities.
Comment #10
avpadernosrc/Controller/ConfirmUnpublishController.php
Since that class does not use methods from the parent class, it does not need to use
ControllerBaseas parent class. Controllers do not need to have a parent class; as long as they implement\Drupal\Core\DependencyInjection\ContainerInjectionInterface, they are fine.src/Form/ConfirmUnpublishSettingsForm.php
The parent class requires the
$typedConfigManagerparameter; this is a change introduced in Drupal 10.2. The project cannot be compatible with Drupal 10 and Drupal 11; it needs at least Drupal 10.2.With Drupal 10 and Drupal 11, there is no longer need to use
#default_valuefor each form element, when the parent class isConfigFormBase: It is sufficient to use#config_target, as in the following code.Using that code, it is no longer needed to save the config values in the form submission handler: The parent class will take care of that.
confirm_unpublish.module
The message passed to JavaScript should be the translated configuration value.
js/confirm_unpublish.js
To translate a string, JavaScript code can use
Drupal.t().Comment #11
jason.ullstam commentedThank you @avpaderno for those suggestions.... I have made the requested changes and tagged a new release.
Comment #12
jason.ullstam commentedSetting back to "Needs Review".
Comment #13
bbu23Comment #14
bbu23Hi! Quick note: you don't need to tag a new release after every feedback. We're reviewing directly the branch specified in the title of the ticket, in this case
1.x.Below you have my feedback:
There are pending PHP Code Sniffer warnings and errors:
- There is no schema definition for the
confirm_unpublish.settingsconfig- There is no guarantee that the
basic_htmltext format exists in the target site. For example, installing a Drupal site using the Minimal profile does not create the Basic HTML text format. Maybe you could add it as an optional config dependency or consider splitting the text. Also, having a class in the p tag might get stripped on some sites- The controller is still extending the
ControllerBaseclass and overriding two properties- The
__constructmethods do not require a description anymore. It's optional if you want to keep it or remove it-
src/Controller/ConfirmUnpublishController.phpline 107 when the node object is available, the canonical path could be retrieved from the object:$node->toUrl()->toString()-
src/Form/ConfirmUnpublishSettingsForm.phpthe__constructmethod is missing the parent call- The
"require"section incomposer.jsonis empty it should probably be removed if not used- 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
- The open access in routing which is also pointed out by PHPCS needs to be resolved
Comment #15
bbu23Comment #16
avpadernoThis is totally true: Releases should not be created after each review done here.
It is better not to create new release during these applications, since a review could ask for a change that is not backward compatible with the existing releases. Just using a development version avoids those BC issues.
Comment #17
vishal.kadamI am changing priority as per Issue priorities.
Comment #18
avpadernoThis thread has been idle, in the needs work state with no activity for some months.
May you confirm you are still pursuing this application? If this is the case, and you made commits basing on what previously reported, or you can answer the questions previously asked, please change the status to Needs review.
Comment #19
avpadernoThis thread has been idle, in the Needs work state with no activity for about six months or more; the application has been created about 11 months ago or more. Therefore, I marked it as Closed (won't fix).
If this is incorrect, and you are still pursuing this application, please feel free to re-open it and set the issue status to Needs work or Needs review, depending on the current status of your code.