The module offers a centralized configuration interface for managing revision requirements across various entity types. Administrators can specify which block types, content types, and taxonomy vocabularies are required to create new revisions when edited. Additionally, they can choose to require revision log messages for these entities. The module tracks and records all edits to blocks, nodes, and terms, ensuring transparency throughout the content workflow.
This module is an enhanced version of the Require Revision Log Message. It not only makes nodes require revision, but it also has the option to apply to Blocks and Taxonomy Terms.
Project link
https://www.drupal.org/project/require_revision
Comments
Comment #2
vishal.kadamComment #3
avpadernoThank 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.
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
vishal.kadam1. main is acceptable as branch name, but it is not yet fully supported on drupal.org. For the moment, it is better to avoid it.
2. FILE: require_revision.module
Drupal does not have primary and secondary hooks. Instead of that, it is preferable to use the usual description: “Hook implementations for the [module name] module”, where [module name] is the name of the module given in its .info.yml file.
3. Fix the warnings/errors reported by PHP_CodeSniffer.
Note: I would suggest enabling GitLab CI for the project, follow the Drupal Association .gitlab-ci.yml template and fix the PHP_CodeSniffer errors/warnings it reports.
Comment #5
haklo commented@vishal.kadam, Thanks for the feedback!
Comment #6
haklo commentedI've made the following updates:
✅ Fixed all phpcs coding standards violations
✅ Removed version field from .info.yml
✅ Enabled GitLab CI with automated testing
✅ All CI jobs passing: https://git.drupalcode.org/project/require_revision/-/pipelines
The latest code is available in the 1.0.x branch. Please let me know if there's anything else that needs attention.
Comment #7
avpadernoComment #8
vishal.kadamFILE: src/Form/RequireRevisionSettingsForm.php
ConfigFormBase::__construct() needs to be called. Since its parameters changed in Drupal 10.2, the project cannot be compatible with all the Drupal 10 releases and Drupal 11; it needs to require at least Drupal 10.2.
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.
Comment #9
haklo commentedThanks for the detailed feedback! I've implemented all the requested changes:
✅ Updated to require Drupal 10.2+ (core_version_requirement: ^10.2 || ^11)
✅ Added ConfigFactoryInterface to constructor and called parent::__construct()
✅ Updated create() method to inject config.factory service
✅ Replaced manual config handling with #config_target for automatic saving
✅ Removed submitForm() method (parent class handles it automatically)
The form now uses modern Drupal 10.2+ patterns as recommended. GitLab CI pipeline passing with zero errors:
https://git.drupalcode.org/project/require_revision/-/pipelines
Comment #10
vishal.kadamFILE: src/Form/RequireRevisionSettingsForm.php
parent::__construct($config_factory);ConfigFormBase::__construct() requires two parameters. See the change record.
Comment #11
haklo commentedThank you for catching that! I've now added the TypedConfigManagerInterface parameter.
✅ Added TypedConfigManagerInterface import
✅ Updated the constructor with both required parameters
✅ Called parent::__construct() with both parameters
✅ Injected config.typed service in create() method
Comment #12
vishal.kadam1. FILE: composer.json
require_revision.info.yml
core_version_requirement: ^10.2 || ^11Update drupal core requirement in composer file as per info file.
2. FILE: require_revision.module
For a new module that aims to be compatible with Drupal 10/11, it is expected it implements hooks as class methods as described in Support for object oriented hook implementations using autowired services.
3. FILE: src/Form/RequireRevisionSettingsForm.php
It is sufficient to use #config_target. There is no longer need to use #default_value.
New modules, which are compatible with Drupal 10 and higher versions are expected to use constructor property promotion.
Comment #13
avpadernoAs a side note, it is not necessary to add the Drupal core requirements in the composer.json file: The Drupal.org Composer Façade will add them.
Comment #14
haklo commentedThanks for all the feedback. I've addressed everything:
✅ OOP hook architecture with service class and dependency injection
✅ Constructor property promotion in all classes
✅ Updated to require Drupal ^10.2 || ^11 in composer.json
✅ Removed #default_value
✅ Bridge pattern for hook delegation
✅ All phpcs violations fixed
Pipeline passing:
https://git.drupalcode.org/project/require_revision/-/pipelines/648041
Ready for review!
Comment #15
haklo commentedHere is a brief update following my change to "Needs Review."
✅ Added config/install/require_revision.settings.yml with default empty arrays
✅ Config keys now exist on installation, preventing null value errors
✅ #config_target now works correctly for both loading and saving
The install config ensures configuration keys are never null, so the form loads properly using only #config_target.
https://git.drupalcode.org/project/require_revision/-/pipelines/648079
Comment #16
vishal.kadam1. FILE: require_revision.module
Procedural hooks should be marked with the
#[LegacyHook]attribute.2. FILE: src/Hook/RequireRevisionHooks.php
The hook method must have a
#[Hook()]attribute.Comment #17
haklo commentedThanks for the clarification. I've added the hook attributes:
✅ #[Hook] attributes in RequireRevisionHooks class
✅ #[LegacyHook] attributes in .module file
✅ hook_subscriber tag in services
Pipeline passing and fully tested. Thank you for all your guidance.
Comment #18
vishal.kadamRest looks good to me.
Please wait for a Project Moderator to take a look and if everything goes fine, you will get the role.
Comment #19
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 #20
avpadernoComment #22
haklo commentedHi @vishal.kadam and @avpaderno,
Do you know why the Require Revision module page isn't displaying the "Works with Drupal:" and "Install:" information in the "Releases" section?
Comment #23
avpaderno@haklo You created a distribution project, not a module project; I think distributions do not show that information.
Comment #24
avpadernoYou can ask to change the project type, by creating an issue like #3549996: Convert Distribution to Module Project - Crux, in that issue queue.
Comment #25
haklo commentedThank you, @avpaderno.