1. FILE: src/Ajax/UpdateOptionsCommand.php
/**
* UpdateOptionsCommand constructor.
*
* @param string $elementId
* The element html id.
* @param array $options
* The element options [key, value].
* @param string $formatter
* The field formatter.
* @param bool $multiple
* The 'multiple' attribute of select.
*/
public function __construct(FILE: src/Util/DynamicReferenceSelectionUtil.php
/**
* DynamicReferenceSelectionUtil constructor.
*
* @param \Symfony\Component\DependencyInjection\ContainerInterface $container
* The container service.
*/
public function __construct(ContainerInterface $container) {The documentation comment for constructors is not mandatory anymore, If it is given, the description must be “Constructs a new [class name] object”, where [class name] includes the class namespace.
2. FILE: dynamic_reference_selection.module
/**
* @file
* Dynamic Reference Selection module.
*/The usual description for a .module file is “Hook implementations for the [module name] module”, where [module name] is the module name given in the .info.yml file.
As a side note: These applications do not require that new releases are created after reviews.
Rest looks fine to me.
Please wait for a Project Moderator to take a look and if everything goes fine, you will get the role.
I have reviewed your posts and confirmed the account.
A site moderator user will review your post and publish it.
The typical path to confirming users usually involves reviewing the content that you've created on this site. In this case, you've not created any content except this post, so there is no content to review. Postponing for now, after you have posted some content on Drupal.org you may want to add a comment to this issue to request a new review. Please visit the Become a confirmed user → page for information. That page also tells you what "limitations" mean.
Since you haven't contributed yet here is a list of resources to help you on your journey:
1. FILE: src/Commands/MetadataSanitizerCommands.php
/**
* Removes metadata from files using exiftool.
*
* @throws \Drupal\Component\Plugin\Exception\InvalidPluginDefinitionException
* @throws \Drupal\Component\Plugin\Exception\PluginNotFoundException
*/
public function __construct(The documentation comment for constructors is not mandatory anymore, If it is given, the description must be “Constructs a new [class name] object”, where [class name] includes the class namespace.
2. FILE: README.md
The README file is missing the required section → - Configuration.
3. FILE: metadata_sanitizer.module
/**
* @file
* Custom module to strip metadata from uploaded files using exiftool.
*/The usual description for a .module file is “Hook implementations for the [module name] module”, where [module name] is the module name given in the .info.yml file.
1. FILE: alt_text_generator.info.yml
core_version_requirement: ^9 || ^10 || ^11
FILE: composer.json
"require": {
"php": ">=8.1",
"drupal/core": "^9 || ^10 || ^11"
}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: alt_text_generator.libraries.yml
version: VERSION
VERSION is only used by Drupal core modules. Contributed modules should use a literal string that does not change with the Drupal core version a site is using.
As a side note: These applications do not require that new releases are created after reviews.
You can edit the LICENSE file in Gitlab and select GPL v2 from template ( see attached → ).
I have reviewed your posts and confirmed the account.
The typical path to confirming users usually involves reviewing the content that you've created on this site. In this case, you've not created any content except this post, so there is no content to review. Postponing for now, after you have posted some content on Drupal.org you may want to add a comment to this issue to request a new review. Please visit the Become a confirmed user → page for information. That page also tells you what "limitations" mean.
Since you haven't contributed yet here is a list of resources to help you on your journey:
The typical path to confirming users usually involves reviewing the content that you've created on this site. In this case, you've not created any content except this post, so there is no content to review. Postponing for now, after you have posted some content on Drupal.org you may want to add a comment to this issue to request a new review. Please visit the Become a confirmed user → page for information. That page also tells you what "limitations" mean.
Since you haven't contributed yet here is a list of resources to help you on your journey:
1. 1.0.0 is a wrong name for a branch. Release branch names always end with the literal .x as described in
Release branches →
.
2. FILE: README.txt
The README file is missing the required sections → - Requirements, Installation, and Configuration.
3. FILE: emedia_library.info.yml
core_version_requirement: ^9 || ^10
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.
4. FILE: src/Plugin/Field/FieldType/EmediaLibraryFieldImage.php
/*
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $mediadbUrl);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_TIMEOUT_MS, 3000);
curl_setopt($ch, CURLOPT_HTTPHEADER, [
'Content-Type: application/json',
'X-tokentype: entermedia',
'X-token: ' . $entermediaKey,
]);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($query));
$response = curl_exec($ch);
$httpcode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
curl_close($ch);
*/FILE: src/Plugin/Field/FieldWidget/EmediaLibraryWidget.php
//$body = $response->getBody()->getContents();
//$jsonresponse = json_decode($body, TRUE);FILE: src/Plugin/Field/FieldWidget/EmediaLibraryWidgetEntity.php
//$body = $response->getBody()->getContents();
//$jsonresponse = json_decode($body, TRUE);Remove the commented code.
1. The master branch is not used on drupal.org. The only exception is for the main branch, which is actually not fully supported on drupal.org and should be avoided. For now, the branch names must follow what is reported in
Release branches →
.
2. FILE: text_clarity_checker.info.yml
package: Custom
This line is used by custom modules created for specific sites. It is not a package name used for projects hosted on drupal.org.
3. FILE: README.md
The README file is missing the required sections → - Project name, Requirements, and Configuration.
Rest 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.
Remember to change status, when the project is ready to be reviewed. In this queue, projects are only reviewed when the status is Needs review.
1. main is a wrong name for a branch. Release branch names always end with the literal .x as described in
Release branches →
. The only exception is for the main branch, which is actually not fully supported on drupal.org and should be avoided.
2. FILE: php_compatibility_scanner.module
/**
* @file
* PHP Compatibility Scanner module.
*/The usual description for a .module file is “Hook implementations for the [module name] module”, where [module name] is the module name given in the .info.yml file.
Thank 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.
- If you have not done it yet, you should enable GitLab CI for the project and fix the PHP_CodeSniffer errors/warnings it reports.
- For the time this application is open, only your commits are allowed.
- The purpose of this application is giving you a new drupal.org role that allows you to opt projects into security advisory coverage, either projects you already created, or projects you will create. The project status will not be changed by this application; once this application is closed, you will be able to change the project status from Not covered to Opt into security advisory coverage. This is possible only 14 days after the project is created.
Keep in mind that once the project is opted into security advisory coverage, only Security Team members may change coverage. - Only the person who created the application will get the permission to opt projects into security advisory coverage. No other person will get the same permission from the same application; that applies also to co-maintainers/maintainers of the project used for the application.
- We only accept an application per user. If you change your mind about the project to use for this application, or it is necessary to use a different project for the application, please update the issue summary with the link to the correct project and the issue title with the project name and the branch to review.
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.
- It is preferable to wait for a project moderator before posting the first comment on newly created applications. Project moderators will do some preliminary checks that are necessary before any change on the project files is suggested.
- Reviewers should show the output of a CLI tool → only once per application.
- It may be best to have the applicant fix things before further review.
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 → .
Rest looks fine to me.
Please wait for a Project Moderator to take a look and if everything goes fine, you will get the role.
- The following points are just a start and don't necessarily encompass all of the changes that may be necessary
1. FILE: ai_log_analysis.info.yml
package: Custom
This line is used by custom modules created for specific sites. It is not a package name used for projects hosted on drupal.org.
2. FILE: ai_log_analysis.install
// Drop the custom log table on uninstall.
\Drupal::database()->schema()->dropTable('ai_log_analysis');Drupal core automatically deletes the database tables defined by hook_schema() on uninstall.
3. FILE: ai_log_analysis.module
/**
* @file
* Contains hooks and custom logic for the ai_log_analysis module.
*/The usual description for a .module file is “Hook implementations for the [module name] module”, where [module name] is the module name given in the .info.yml file.
Thank 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.
- If you have not done it yet, you should enable GitLab CI for the project and fix the PHP_CodeSniffer errors/warnings it reports.
- For the time this application is open, only your commits are allowed.
- The purpose of this application is giving you a new drupal.org role that allows you to opt projects into security advisory coverage, either projects you already created, or projects you will create. The project status will not be changed by this application; once this application is closed, you will be able to change the project status from Not covered to Opt into security advisory coverage. This is possible only 14 days after the project is created.
Keep in mind that once the project is opted into security advisory coverage, only Security Team members may change coverage. - Only the person who created the application will get the permission to opt projects into security advisory coverage. No other person will get the same permission from the same application; that applies also to co-maintainers/maintainers of the project used for the application.
- We only accept an application per user. If you change your mind about the project to use for this application, or it is necessary to use a different project for the application, please update the issue summary with the link to the correct project and the issue title with the project name and the branch to review.
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.
- It is preferable to wait for a project moderator before posting the first comment on newly created applications. Project moderators will do some preliminary checks that are necessary before any change on the project files is suggested.
- Reviewers should show the output of a CLI tool → only once per application.
- It may be best to have the applicant fix things before further review.
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 → .
Rest looks fine to me.
Please wait for a Project Moderator to take a look and if everything goes fine, you will get the role.
FILE: webform_gohighlevel.info.yml
# Information added by Drupal.org packaging script on 2025-02-08
version: '1.0.1'
project: 'webform_gohighlevel'
datestamp: 1739039211Remove these lines from the info file, it will be added by drupal.org packaging automatically.
Rest looks fine to me.
Please wait for a Project Moderator to take a look and if everything goes fine, you will get the role.
The typical path to confirming users usually involves reviewing the content that you've created on this site. In this case, you've not created any content except this post, so there is no content to review. Postponing for now, after you have posted some content on Drupal.org you may want to add a comment to this issue to request a new review. Please visit the Become a confirmed user → page for information. That page also tells you what "limitations" mean.
Since you haven't contributed yet here is a list of resources to help you on your journey:
FILE: src/Plugin/Field/FieldFormatter/ParagraphIdLinkFormatter.php
$link_title = $this->t($label, ['@name' => $entity->label()]);
The first argument passed to t() must be a literal string.
Rest looks fine to me.
Please wait for a Project Moderator to take a look and if everything goes fine, you will get the role.
1. Fix errors/warnings reported by phpcs and phpstan job of Gitlab CI.
2. FILE: templates/paragraph-lineage.html.twig
<div class="field__label" aria-label="type">Type</div>
<div class="field__label" aria-label="paragraph-bundle">Bundle</div>
<summary>Preview</summary>
<h3>Lineage</h3>
Still some string are not translatable.
Rest looks fine to me.
Let’s wait for a Code Review Administrator to take a look and if everything goes fine, you will get the role.
1. FILE: print_this_page.info.yml
package: Custom
This line is used by custom modules created for specific sites. It is not a package name used for projects hosted on drupal.org.
core_version_requirement: ^9 || ^10 || ^11
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: print_this_page.module
/**
* @file
* Primary module hooks for Print This Page 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.
/**
* Implements hook_preprocess_HOOK().
*/
function template_preprocess_print_this_page_button(&$variables) {The description for this hook should also say for which hook it is implemented
1. FILE: timeline_block.libraries.yml
version: VERSION
VERSION is only used by Drupal core modules. Contributed modules should use a literal string that does not change with the Drupal core version a site is using.
2. FILE: timeline_block.module
/**
* @file
* Contains timeline.module.
*/The usual description for a .module file is “Hook implementations for the [module name] module”, where [module name] is the module name given in the .info.yml file.
3. FILE: src/Plugin/Block/TimelineBlock.php
/**
* Creates a Timeline Block instance.
*
* This constructor is used to initialize a Timeline Block plugin. It takes
* the configuration array, plugin ID, plugin definition, and the entity
* storage service as arguments to set up the plugin instance.
*
* @param array $configuration
* A configuration array containing information about the plugin instance.
* This includes settings or any other data necessary for configuring the
* specific instance of the plugin, such as its state or user preferences.
* @param string $plugin_id
* The plugin ID for the plugin instance.
* The unique identifier for the plugin instance, used to distinguish
* between different plugin types.
* @param mixed $plugin_definition
* The plugin implementation definition.
* This contains the full configuration or metadata that defines the
* behavior of the plugin. It might include properties like the
* plugin's label, its settings, or other specialized configurations.
* @param \Drupal\Core\Entity\EntityStorageInterface $entity_storage
* The entity storage service.
* This service allows interaction with the storage of entities, such
* as loading, saving, or deleting entities. It is injected into the
* constructor to enable operations on entities, which might be used
* in the context of the Timeline Block.
* @param \Drupal\Core\Render\RendererInterface $renderer
* The renderer service.
*/
public function __construct(array $configuration, $plugin_id, $plugin_definition, EntityStorageInterface $entity_storage, RendererInterface $renderer) {The documentation comment for constructors is not mandatory anymore, If it is given, the description must be “Constructs a new [class name] object”, where [class name] includes the class namespace.
Thank 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.
- If you have not done it yet, you should enable GitLab CI for the project and fix the PHP_CodeSniffer errors/warnings it reports.
- For the time this application is open, only your commits are allowed.
- The purpose of this application is giving you a new drupal.org role that allows you to opt projects into security advisory coverage, either projects you already created, or projects you will create. The project status will not be changed by this application; once this application is closed, you will be able to change the project status from Not covered to Opt into security advisory coverage. This is possible only 14 days after the project is created.
Keep in mind that once the project is opted into security advisory coverage, only Security Team members may change coverage. - Only the person who created the application will get the permission to opt projects into security advisory coverage. No other person will get the same permission from the same application; that applies also to co-maintainers/maintainers of the project used for the application.
- We only accept an application per user. If you change your mind about the project to use for this application, or it is necessary to use a different project for the application, please update the issue summary with the link to the correct project and the issue title with the project name and the branch to review.
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.
- It is preferable to wait for a project moderator before posting the first comment on newly created applications. Project moderators will do some preliminary checks that are necessary before any change on the project files is suggested.
- Reviewers should show the output of a CLI tool → only once per application.
- It may be best to have the applicant fix things before further review.
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 → .
You don't need a confirmed account to host your projects. The ability to host a module, theme, or distribution on Drupal.org requires the Git access permission.
The account has been already confirmed.
Kindly update the title to specify the single branch you would like us to review.
Remember to change status, when the project is ready to be reviewed. In this queue, projects are only reviewed when the status is Needs review.
Thank 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.
- If you have not done it yet, you should enable GitLab CI for the project and fix the PHP_CodeSniffer errors/warnings it reports.
- For the time this application is open, only your commits are allowed.
- The purpose of this application is giving you a new drupal.org role that allows you to opt projects into security advisory coverage, either projects you already created, or projects you will create. The project status will not be changed by this application; once this application is closed, you will be able to change the project status from Not covered to Opt into security advisory coverage. This is possible only 14 days after the project is created.
Keep in mind that once the project is opted into security advisory coverage, only Security Team members may change coverage. - Only the person who created the application will get the permission to opt projects into security advisory coverage. No other person will get the same permission from the same application; that applies also to co-maintainers/maintainers of the project used for the application.
- We only accept an application per user. If you change your mind about the project to use for this application, or it is necessary to use a different project for the application, please update the issue summary with the link to the correct project and the issue title with the project name and the branch to review.
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.
- It is preferable to wait for a project moderator before posting the first comment on newly created applications. Project moderators will do some preliminary checks that are necessary before any change on the project files is suggested.
- Reviewers should show the output of a CLI tool → only once per application.
- It may be best to have the applicant fix things before further review.
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 → .
1. FILE: README.md
The README file is missing the required sections → - Requirements and Configuration.
2. FILE: templates/paragraph-lineage.html.twig
<div class="field__label" aria-label="type">Type</div>
<div class="field__label" aria-label="paragraph-bundle">Bundle</div>
<summary>Preview</summary>
<h3>Lineage</h3>
<p>No ancestors available. This appears to be an orphan paragraph.</p>
<th>Type</th>
<th>Bundle</th>
<th>Preview</th>
<th>Link</th>Strings shown in the user interface must be translatable. That holds true also for strings used in template files.
3. FILE: src/Controller/ParagraphLineageViewController.php
/**
* @var \Drupal\Core\Entity\EntityTypeManagerInterface
*/
private EntityTypeManagerInterface $entity_type_manager;The parent class already has properties and methods for the entity type manager. There is no need to redefine properties for the same purpose; instead, the parent class methods should be used.
The changes should be committed directly to the project repository. Please note that we do not review merge requests.
Remember to change status, when the project is ready to be reviewed. In this queue, projects are only reviewed when the status is Needs review.
Thank 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.
- If you have not done it yet, you should enable GitLab CI for the project and fix the PHP_CodeSniffer errors/warnings it reports.
- For the time this application is open, only your commits are allowed.
- The purpose of this application is giving you a new drupal.org role that allows you to opt projects into security advisory coverage, either projects you already created, or projects you will create. The project status will not be changed by this application; once this application is closed, you will be able to change the project status from Not covered to Opt into security advisory coverage. This is possible only 14 days after the project is created.
Keep in mind that once the project is opted into security advisory coverage, only Security Team members may change coverage. - Only the person who created the application will get the permission to opt projects into security advisory coverage. No other person will get the same permission from the same application; that applies also to co-maintainers/maintainers of the project used for the application.
- We only accept an application per user. If you change your mind about the project to use for this application, or it is necessary to use a different project for the application, please update the issue summary with the link to the correct project and the issue title with the project name and the branch to review.
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.
- It is preferable to wait for a project moderator before posting the first comment on newly created applications. Project moderators will do some preliminary checks that are necessary before any change on the project files is suggested.
- Reviewers should show the output of a CLI tool → only once per application.
- It may be best to have the applicant fix things before further review.
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 → .
It seems you are already able to opt projects projects for which you can edit the project page. In this case, there is no need to apply for a second time, as these applications just give the permission to opt projects into security advisory coverage.
If you are not able to opt a project into security advisory coverage, and you maintainer of that project, it means that either you do not have the permission to edit the project node, or the project has been created less than ten days ago. In both the cases, there is nothing a second application would fix.
I am closing this issue as duplicate of the issue that gave you the permission to opt projects into security coverage (which at the time could have had a different name).
I have reviewed your posts and confirmed the account.
A site moderator user will review your post and publish it.
I’ve confirmed the account based on module project contribution.
I have reviewed the posts and confirmed the account.
Apologies, and thanks for the clarification - I had initially misunderstood and thought this issue was created by the maintainer.
Creating an issue in the module project was unnecessary, as this matter is already being tracked through the Security Advisory Coverage application 📌 [1.1.x] Address Static Map Needs review process. Duplicating it here inflates the project's issue count without adding value.
It appears there are multiple project applications created using your account.
Since a successful completion of the project application process results in the applicant being granted the necessary role to be able to opt projects into security advisory coverage, there is no need to take multiple applications through the process. Once the first application has been successfully approved, the applicant can promote other projects without review. Because of this, posting multiple applications is not necessary, and results in additional workload for reviewers, which in turn results in longer wait times for everyone in the queue. With this in mind, your secondary applications have been marked as Closed (duplicate), with only one application left open.
If you prefer that we proceed through this review process with a different application, then feel free to close the application left open as a duplicate, and re-open one of the project applications which had been closed.
1. main will be a supported branch in future, but for the moment it is better not to use it. It is not wrong, but it is not completely supported on drupal.org.
2. FILE: repply_chat.info.yml
core_version_requirement: ^8.8 || ^9.0 || ^10.0
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.
3. FILE: repply_chat.libraries.yml
preview:
version: VERSIONsubmit_progress:
version: VERSIONVERSION is only used by Drupal core modules. Contributed modules should use a literal string that does not change with the Drupal core version a site is using.
4. FILE: repply_chat.module
/**
* @file
* Contains repply_chat.module.
*/The usual description for a .module file is “Hook implementations for the [module name] module”, where [module name] is the module name given in the .info.yml file.
The code has been updated.
https://git.drupalcode.org/project/ai_seo_link_advisor/-/blob/1.0.x/src/...
The code you've pointed out is not handling direct user input - it retrieves the URL value from the current URL's query parameter.
https://git.drupalcode.org/project/ai_seo_link_advisor/-/blob/1.0.x/src/...
I'll update the form code to sanitize the user input before it's included as a query parameter in the URL.
I also received this warning when updating the module to version 3.6.0, but it was resolved after running the database update.
Rest seems fine to me.
Let’s wait for other reviewers and Code Review Administrator to take a look and if everything goes fine, you will get the role.
The error you shared is related to the overall Composer setup of the project, not an issue with the module itself. The PHP library dependency is correctly defined in the module’s composer.json.
As part of the review, we check that the code follows Drupal standards, uses the Drupal API properly, and is compatible with supported Drupal versions. In this case, everything looks fine from the review side.
Rest looks fine to me.
Let’s wait for a Code Review Administrator to take a look and if everything goes fine, you will get the role.
This is not an issue created in a project queue.
Comments in this queue are required to review the project files and report what needs to be changed. We do not debug projects.
Rest looks fine to me.
Let’s wait for a Code Review Administrator to take a look and if everything goes fine, you will get the role.
1. master, 0.9.0 and 0.9.x are wrong names for a branch. Release branch names always end with the literal .x as described in
Release branches →
. While it is possible to use a zero as first number (for example 0.1.0) the convention is to start from 1, for example 1.0.0.
2. FILE: README.md
The README file is missing the required sections → - Requirements, Installation, and Configuration.
3. FILE: file_metadata_cleaner.install
I noticed the .install file is currently empty. If it's not being used for any install/update hooks at the moment, it might be a good idea to remove it to avoid confusion. It can always be added later when needed.
4. FILE: file_metadata_cleaner.module
/**
* Implements hook_ENTITY_TYPE_insert().
*/
function file_metadata_cleaner_file_insert(File $file): void {The description for that hook should also say for which entity type that hook is implemented.
5. FILE: src/Form/FileProcessorSettingsForm.php
/**
* Constructs the form.
*/
public function __construct(FileProcessorPluginManager $pluginManager, RouteMatchInterface $routeMatch) {The documentation comment for constructors is not mandatory anymore, If it is given, the description must be “Constructs a new [class name] object”, where [class name] includes the class namespace.
Thank 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.
- If you have not done it yet, you should enable GitLab CI for the project and fix the PHP_CodeSniffer errors/warnings it reports.
- For the time this application is open, only your commits are allowed.
- The purpose of this application is giving you a new drupal.org role that allows you to opt projects into security advisory coverage, either projects you already created, or projects you will create. The project status will not be changed by this application; once this application is closed, you will be able to change the project status from Not covered to Opt into security advisory coverage. This is possible only 14 days after the project is created.
Keep in mind that once the project is opted into security advisory coverage, only Security Team members may change coverage. - Only the person who created the application will get the permission to opt projects into security advisory coverage. No other person will get the same permission from the same application; that applies also to co-maintainers/maintainers of the project used for the application.
- We only accept an application per user. If you change your mind about the project to use for this application, or it is necessary to use a different project for the application, please update the issue summary with the link to the correct project and the issue title with the project name and the branch to review.
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.
- It is preferable to wait for a project moderator before posting the first comment on newly created applications. Project moderators will do some preliminary checks that are necessary before any change on the project files is suggested.
- Reviewers should show the output of a CLI tool → only once per application.
- It may be best to have the applicant fix things before further review.
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 → .
There is no branch named 1.0.x. Please update the title with the correct branch name you'd like us to review.
The reported changes should be committed directly to the project repository. Please note that we do not review merge requests.
Also, there's no need to create an issue thread in your module project, as this is already being tracked here.
FILE: calculation_fields.info.yml
# project: 'drupal/calculation_fields'
# Information added by Drupal.org packaging script on 2023-11-22
version: "1.0.0-alpha11"
project: "calculation_fields"
datestamp: 1700659783FILE: modules/calculation_fields_example/calculation_fields_example.info.yml
# Information added by Drupal.org packaging script on 2023-11-22
version: "1.0.0-alpha11"
project: "calculation_fields"
datestamp: 1700659783FILE: modules/webform_calculation_fields/webform_calculation_fields.info.yml
# Information added by Drupal.org packaging script on 2023-11-22
version: "1.0.0-alpha11"
project: "calculation_fields"
datestamp: 1700659783FILE: modules/webform_calculation_fields/modules/webform_calculation_fields_examples/webform_calculation_fields_examples.info.yml
# Information added by Drupal.org packaging script on 2023-11-22
version: "1.0.0-alpha11"
project: "calculation_fields"
datestamp: 1700659783Remove "project", "version" and "datestamp" from the info file, it will be added by drupal.org packaging automatically.
1. feature/add-module-tests and main are wrong names for a branch. Release branch names always end with the literal .x as described in
Release branches →
. The only exception is for the main branch, which is actually not fully supported on drupal.org and should be avoided.
2. FILE: README.md
The README file is missing the required section → - Requirements.
The typical path to confirming users usually involves reviewing the content that you've created on this site. Postponing for now, after you have posted some content on Drupal.org you may want to add a comment to this issue to request a new review. Please visit the Become a confirmed user → page for information. That page also tells you what "limitations" mean.
Since you haven't contributed yet here is a list of resources to help you on your journey:
Rest looks fine to me.
Let’s wait for a Code Review Administrator to take a look and if everything goes fine, you will get the role.
Rest looks fine to me.
Let’s wait for a Code Review Administrator to take a look and if everything goes fine, you will get the role.
Rest looks fine to me.
Let’s wait for a Code Review Administrator to take a look and if everything goes fine, you will get the role.
FILE: src/Controller/FileDownloadController.php
/**
* The entity type manager.
*
* @var \Drupal\Core\Entity\EntityTypeManagerInterface
*/
protected $entityTypeManager;The parent class already has properties and methods for the entity type manager object. There is no need to redefine properties for the same purpose; instead, the parent class methods should be used.
/**
* The controller constructor.
*/
public function __construct(The documentation comment for constructors is not mandatory anymore, If it is given, the description must be “Constructs a new [class name] object”, where [class name] includes the class namespace.
1. FILE: ai_readme_generator.info.yml
package: Custom
This line is used by custom modules created for specific sites. It is not a package name used for projects hosted on drupal.org.
2. FILE: src/Form/GenerateReadmeForm.php
/**
* Constructor.
*/
public function __construct(The documentation comment for constructors is not mandatory anymore, If it is given, the description must be “Constructs a new [class name] object”, where [class name] includes the class namespace.
The typical path to confirming users usually involves reviewing the content that you've created on this site. In this case, you've not created any content except this post, so there is no content to review. Postponing for now, after you have posted some content on Drupal.org you may want to add a comment to this issue to request a new review. Please visit the Become a confirmed user → page for information. That page also tells you what "limitations" mean.
Since you haven't contributed yet here is a list of resources to help you on your journey:
The typical path to confirming users usually involves reviewing the content that you've created on this site. In this case, you've not created any content except this post, so there is no content to review. Postponing for now, after you have posted some content on Drupal.org you may want to add a comment to this issue to request a new review. Please visit the Become a confirmed user → page for information. That page also tells you what "limitations" mean.
Since you haven't contributed yet here is a list of resources to help you on your journey:
Remember to change status, when the project is ready to be reviewed. In this queue, projects are only reviewed when the status is Needs review.
Thank 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.
- If you have not done it yet, you should enable GitLab CI for the project and fix the PHP_CodeSniffer errors/warnings it reports.
- For the time this application is open, only your commits are allowed.
- The purpose of this application is giving you a new drupal.org role that allows you to opt projects into security advisory coverage, either projects you already created, or projects you will create. The project status will not be changed by this application; once this application is closed, you will be able to change the project status from Not covered to Opt into security advisory coverage. This is possible only 14 days after the project is created.
Keep in mind that once the project is opted into security advisory coverage, only Security Team members may change coverage. - Only the person who created the application will get the permission to opt projects into security advisory coverage. No other person will get the same permission from the same application; that applies also to co-maintainers/maintainers of the project used for the application.
- We only accept an application per user. If you change your mind about the project to use for this application, or it is necessary to use a different project for the application, please update the issue summary with the link to the correct project and the issue title with the project name and the branch to review.
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.
- It is preferable to wait for a project moderator before posting the first comment on newly created applications. Project moderators will do some preliminary checks that are necessary before any change on the project files is suggested.
- Reviewers should show the output of a CLI tool → only once per application.
- It may be best to have the applicant fix things before further review.
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 → .
Remember to change status, when the project is ready to be reviewed. In this queue, projects are only reviewed when the status is Needs review.