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.
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 → - Installation and Configuration.
2. FILE: node_swapper.info.yml
version: '8.x-1.2.0'
project: 'node_swapper'Remove "project" and "version" from the info file, it will be added by drupal.org packaging automatically.
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:
For these applications, we need a project where, in at least a branch, most of the commits (but preferably all the commits) have been done from the person who created the application.
The purpose of these applications is reviewing a project to understand what the person who applies understands about writing secure code which follows the Drupal coding standards and correctly uses the Drupal API, not what all the project maintainers collectively understand about those points.
Do you have a project for which most of the commits have been done by you in at least a branch? It also needs to contain enough PHP code.
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 → .
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: composer.json
"require": {
"drupal/core": "^9 || ^10 || ^11"
},FILE: confirm_unpublish.info.yml
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: confirm_unpublish.module
/**
* Implements hook_form_FORM_ID_alter().
*/
function confirm_unpublish_form_node_form_alter(&$form, FormStateInterface $form_state, $form_id) {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()).
Since your account has been confirmed, your future posts won’t be marked as spam.
I have reviewed your post 🐛 Database Search Results module triggers Type Error on installation Active and confirmed the account.
A site moderator user will review your post → and publish it.
FILE: ajax_cart_update.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.
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.
Let’s wait for a Code Review Administrator to take a look and if everything goes fine, you will get the role.
1. FILE: README.txt
Remove README.txt sine README.ms is present.
2. FILE: composer.json
"require": {
"drupal/core": "^10 || ^11"
},FILE: remove_reset_password.info.yml
core_version_requirement: ^9.2 || ^10 || ^11
Inconsistent drupal core version requirement.
3. FILE: remove_reset_password.module
/**
* @file
* Module file to alter behaviour.
*/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.
No, there's no need to submit another request. Since your colleague has already verified your account, your future posts won’t be marked as spam.
Please wait for a site moderator to review and publish your post.
The account has been already confirmed.
@jumpsuitgreen There's no need to remove the parameter descriptions.
1. 2.0.x-1, 8.x-1.x-dev, 2.0, and 240829 are wrong names for a branch and should be removed. Release branch names always end with the literal .x as described in
Release branches →
.
2. FILE: README.md
README.md file should follow the content and formatting described in README.md template → . It is missing the required sections → - Requirements and Installation.
3. FILE: backstop_generator.libraries.yml
# js:
# js/backstop_forms.js: {}FILE: backstop_generator.links.menu.yml
#backstop_generator.default_profile_form:
# title: Default Profile
# parent: backstop_generator.settings_form
# description: 'Configure the default backstop profile.'
# route_name: backstop_generator.default_profile_form
# weight: 1FILE: backstop_generator.links.task.yml
#backstop_generator.default_profile_form:
# title: Default Profile
# route_name: backstop_generator.default_profile_form
# base_route: backstop_generator.settings_form
# weight: 0Remove commented code.
4. FILE: backstop_generator.module
/**
* @file
* Primary module hooks for BackstopJS module.
*
* @DCG
* This file is no longer required in Drupal 8.
* @see https://www.drupal.org/node/2217931
*/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.
5. FILE: src/BackstopJsonTemplate.php
/**
* Set default values for properties unavailable through the UI.
*
* @param string $id
* The ID to check.
*/
public function __construct(string $id) {FILE: src/Controller/BackstopGeneratorController.php
/**
* The controller constructor.
*
* @param \Drupal\Core\File\FileSystemInterface $file_system
* The file system service.
* @param \Drupal\Core\Entity\EntityTypeManagerInterface $entity_type_manager
* The entity type manager service.
* @param \Drupal\Core\Config\ConfigFactoryInterface $config_factory
* The config factory service.
*/
public function __construct(FileSystemInterface $file_system, EntityTypeManagerInterface $entity_type_manager, ConfigFactoryInterface $config_factory) {FILE: src/Form/SettingsForm.php
/**
* SettingsForm constructor.
*
* @param \Drupal\Core\File\FileSystemInterface $fileSystem
* The file system service.
* @param \Drupal\Core\Entity\EntityTypeManagerInterface $entityTypeManager
* The entity type manager.
* @param \Drupal\Core\Config\ConfigFactoryInterface $configFactory
* The config factory service.
* @param \Drupal\Core\Extension\ModuleHandlerInterface $moduleHandler
* The module handler service.
* @param \Drupal\backstop_generator\Services\BackstopFormBuilder $backstopFormBuilder
* The BackstopFormBuilder service.
* @param \Drupal\Core\Config\TypedConfigManagerInterface $typedConfigManager
* The typed config manager service.
*/
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.
You need to commit the code to a branch at https://git.drupalcode.org/project/ajax_cart_update.
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: README.md
The README file is still missing the required sections - Requirements, and Configuration. It should follow the content and formatting described in README.md template → .
FILE: mandatly_cookie_compliance.module
/**
* Hook implementations for the mandatly_cookie_compliance module.
*/
function mandatly_cookie_compliance_page_attachments(array &$attachments) {
The documentation comment for hook_page_attachments() is currently missing. It should be added separately and not merged with the module’s general description to maintain clarity and follow Drupal coding standards.
Go to https://www.drupal.org/project/issues/subscribe-mail/jstimer → , set Send e-mail to “None” and click on Save.
1. FILE: Readme.md
README.md file is missing the required sections → - Requirements, Installation and Configuration.
2. FILE: src/Commands/DevutilsCommands.php
/**
* DrushDevutilsCommands constructor.
*
* @param \Drupal\Core\Entity\EntityTypeManagerInterface $entityTypeManager
* The entity type manager service.
* @param \Drupal\file\FileUsage\DatabaseFileUsageBackend $fileUsage
* Service database file usage backend.
*/
public function __construct(FILE: src/Commands/DrushDevutilsCommands.php
/**
* DrushDevutilsCommands constructor.
*
* @param \Drupal\Core\Entity\EntityTypeManagerInterface $entityTypeManager
* The entity type manager service.
* @param \Drupal\file\FileUsage\DatabaseFileUsageBackend $fileUsage
* Service database file usage backend.
*/
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.
FILE: src/Form/CreateManagedUserForm.php
/**
* The current user service.
*
* @var \Drupal\Core\Session\AccountProxyInterface
*/
protected $currentUser;
/**
* The configuration factory service.
*
* @var \Drupal\Core\Config\ConfigFactoryInterface
*/
protected $configFactory;FILE: src/Form/ManagerContactForm.php
/**
* The current user service.
*
* @var \Drupal\Core\Session\AccountProxyInterface
*/
protected $currentUser;The parent class FormBase already has properties and methods for the configuration factory, and current user service. There is no need to redefine properties for the same purpose; instead, the parent class methods should be used.
1. FILE: firebase_ui.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.
version: 1.0.0
Remove "version" from the info file, it will be added by drupal.org packaging automatically.
2. FILE: firebase_ui.module
/**
* @file
* Firebase UI 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.
This issue does not seem to be a request for a confirmed account, but a support request posted in the wrong queue.
This issue queue is for problems, tasks, and support requests related to Drupal.org, not any site running on Drupal. For questions and support on sites you maintain or develop, please post on the forums.
Furthermore, this queue is for issues on drupal.org, not to give general support on developing or maintaining a Drupal site. For generic supports requests, please post in the forums → .
1. FILE: README.md
The README file is missing the required sections → - Requirements, and Configuration.
2. FILE: mandatly_cookie_compliance.info.yml
core_version_requirement: ^9 || ^10 || ^11
FILE: composer.json
"drupal/core": "^8 || ^9 || ^10 || ^11"
Inconsistent drupal core dependencies.
3. FILE: mandatly_cookie_compliance.module
/**
* @file
* Vaules from remote file.
*/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.
/**
* Function for Preprocessing.
*/
function mandatly_cookie_compliance_preprocess_page(&$variables) {The correct doc comment is "Implements hook_preprocess_page()".
4. FILE: css/toggle-switch.css
Twig code needs to be correctly indented. Drupal uses two spaces for indentation, not four spaces or tabs.
5. FILE: src/Controller/BannerController.php
// $form = $this->formBuilder->getForm('Drupal\mandatly_cookie_compliance\Form\HeaderForm');
Remove commented code.
I have reviewed your posts and confirmed the account.
1. FILE: google_v3_glossary.module
/**
* @file
* Primary module hooks for Google V3 Glossary 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.
2. FILE: README.md
The README file is missing the required sections → - Configuration.
1. 2.x-dev is a wrong name for a branch. Release branch names always end with the literal .x as described in
Release branches →
.
2. FILE: feeds_ical.info.yml
core_version_requirement: ^8 || ^9 || ^10
The Drupal Core versions before 8.7.7 do not recognize the core_version_requirement → key.
You need to create a new issue → in the Drupal.org security advisory coverage applications queue.
1. FILE: guest_suite.info.yml
package: Custom
2. FILE: guest_suite.module
/**
* @file
* Guest suite module file.
*/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: README.md
The README file is missing the required sections → , including Project name, Requirements, Installation, and Configuration.
2. FILE: easy_lqp.module
/**
* @file
* Easy LQP hooks.
*/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/Form/Config/GenerateImageStyles.php
ConfigFormBase::__construct() requires two parameters. See the change record → .
FILE: easy_lqp.info.yml
Given the changes in ConfigFormBase, the module cannot be compatible with Drupal releases before 10.2.0.
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.
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 → .
@srtmdev Check the application process → .
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.
The account has been already confirmed.
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.
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: README.md
The README file is missing the required sections → , including Project name, Requirements, Installation and Configuration.
2. FILE: custom_status_report.module
/**
* @file
* Implements custom status report functionality.
*/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.
/**
* Implements hook_requirements().
*/
function custom_status_report_requirements_alter(array &$requirements) {Doc comment is incorrect. It should be "Implements hook_requirements_alter().".
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:
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.
I have reviewed your posts and confirmed the account.
1. FILE: view_pager_plugin.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: README.md
The README file is missing the required sections → , including Project name, and Requirements.