🇮🇳India @vishal.kadam

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: 1

FILE: 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: 0

Remove 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:

• Issue Etiquette →
• Adding tags to issues and using tags →
• Contributor Tasks: Find a task →

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:

• Issue Etiquette →
• Adding tags to issues and using tags →
• Contributor Tasks: Find a task →

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.

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:

• Issue Etiquette →
• Adding tags to issues and using tags →
• Contributor Tasks: Find a task →

1. FILE: src/Service/UrlStatusScannerService.php

  /**
   * Construct the service.
   *
   * @param \Drupal\Core\Database\Connection $database
   *   The database connection.
   * @param \Drupal\Core\Config\ConfigFactoryInterface $config_factory
   *   The config factory.
   * @param \Drupal\Core\Entity\EntityTypeManagerInterface $entity
   *   The entity object.
   * @param \Drupal\Core\Entity\EntityTypeBundleInfoInterface $entity_type_bundle_info
   *   The entity type bundle service.
   */
  public function __construct(

FILE: src/Form/UrlStatusScannerDashboard.php

  /**
   * Construct the service.
   *
   * @param \Drupal\url_status_scanner\Service\UrlStatusScannerService $url_status_scanner_service
   *   The urlStatusScannerService.
   * @param \Drupal\Core\Database\Connection $database
   *   The database connection.
   * @param \Drupal\Core\Extension\ExtensionList $extension_list
   *   The module extension list service.
   */
  public function __construct(UrlStatusScannerService $url_status_scanner_service, Connection $database, ExtensionList $extension_list) {

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: url_status_scanner.module

/**
 * @file
 * Provides help documentation for the URL Status 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.

I have reviewed your posts and confirmed the account.

A site moderator will review your post, publish it, and confirm your 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:

• Issue Etiquette →
• Adding tags to issues and using tags →
• Contributor Tasks: Find a task →

I have reviewed your posts and confirmed the account.

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.

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.

These applications do not require that new releases are created after reviews.

What I Recommend

• If you’re maintaining only one stable branch → Keep 1.x as is.
• If you need to support multiple minor versions separately → Create 1.2.x for 1.2.* patches.

Just a quick note: The reported changes should be committed to the review branch (1.x).

If you changed what has been reported, please change the status to Needs review. In this way, reviewers will know everything has been changed and can be reviewed again.

Fix phpcs issues.

phpcs --standard=Drupal,DrupalPractice --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md,yml markdownify/

FILE: markdownify/README.md
----------------------------------------------------------------------
FOUND 0 ERRORS AND 17 WARNINGS AFFECTING 17 LINES
----------------------------------------------------------------------
   3 | WARNING | Line exceeds 80 characters; contains 334 characters
  26 | WARNING | Line exceeds 80 characters; contains 88 characters
  28 | WARNING | Line exceeds 80 characters; contains 210 characters
  29 | WARNING | Line exceeds 80 characters; contains 123 characters
  30 | WARNING | Line exceeds 80 characters; contains 161 characters
  31 | WARNING | Line exceeds 80 characters; contains 141 characters
  58 | WARNING | Line exceeds 80 characters; contains 141 characters
  64 | WARNING | Line exceeds 80 characters; contains 160 characters
  68 | WARNING | Line exceeds 80 characters; contains 162 characters
  76 | WARNING | Line exceeds 80 characters; contains 139 characters
  77 | WARNING | Line exceeds 80 characters; contains 159 characters
  78 | WARNING | Line exceeds 80 characters; contains 165 characters
  84 | WARNING | Line exceeds 80 characters; contains 200 characters
 112 | WARNING | Line exceeds 80 characters; contains 100 characters
 164 | WARNING | Line exceeds 80 characters; contains 87 characters
 166 | WARNING | Line exceeds 80 characters; contains 96 characters
 174 | WARNING | Line exceeds 80 characters; contains 82 characters
----------------------------------------------------------------------

FILE: markdownify/src/Service/MarkdownifyEntityRenderer.php
----------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
----------------------------------------------------------------------
 6 | ERROR | [x] Use statements should be sorted alphabetically. The first wrong one is Drupal\Core\Entity\EntityInterface.
----------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
----------------------------------------------------------------------

FILE: markdownify/src/Controller/MarkdownifyController.php
----------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
----------------------------------------------------------------------
 10 | ERROR | [x] Use statements should be sorted alphabetically. The first wrong one is Symfony\Component\DependencyInjection\ContainerInterface.
----------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
----------------------------------------------------------------------

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 run phpcs --standard=Drupal,DrupalPractice on the project, which alone fixes most of what reviewers would report.
• 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 won't be changed by this application and no other user will be able to opt projects into security advisory policy.
• 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 Code Review Administrator before commenting on newly created applications. Code Review Administrators 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 → .

I confirmed the account, since creating an organization node requires a confirmed account.

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.

1. develop 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.

3. FILE: decorative_images.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.

4. FILE: decorative_images.module

/**
 * @file
 * Allows giving images a presentation role.
 */

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.

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. Fix phpcs issues.

phpcs --standard=Drupal,DrupalPractice --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md,yml media_default_image/

FILE: media_default_image/Readme.md
-----------------------------------------------------------------------
FOUND 1 ERROR AND 2 WARNINGS AFFECTING 3 LINES
-----------------------------------------------------------------------
 34 | WARNING | [ ] Line exceeds 80 characters; contains 81 characters
 36 | WARNING | [ ] Line exceeds 80 characters; contains 94 characters
 40 | ERROR   | [x] Expected 1 newline at end of file; 0 found
-----------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
-----------------------------------------------------------------------

2. FILE: media_default_image.module

/**
 * @file
 * Contains media default image 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/Form/DefaultImageSettingsForm.php

Properties should be declared first in a class, followed by methods.

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 Requirements.

2. FILE: entity_usage_explorer.module

/**
 * @file
 * The 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.

3. FILE: templates/entity-usage-overview-page.html.twig

Twig code needs to be correctly indented. Drupal uses two spaces for indentation, not four spaces or tabs.

Strings shown in the user interface must be translatable. That holds true also for strings used in template files.

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 run phpcs --standard=Drupal,DrupalPractice on the project, which alone fixes most of what reviewers would report.
• 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 won't be changed by this application and no other user will be able to opt projects into security advisory policy.
• 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 Code Review Administrator before commenting on newly created applications. Code Review Administrators 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 run phpcs --standard=Drupal,DrupalPractice on the project, which alone fixes most of what reviewers would report.
• 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 won't be changed by this application and no other user will be able to opt projects into security advisory policy.
• 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 Code Review Administrator before commenting on newly created applications. Code Review Administrators 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.md

The README file is missing the required sections → , including Installation, and Configuration.

2. FILE: field_visibility_conditions.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: field_visibility_conditions.module

/**
 * @file
 * Primary module hooks for Field Visibility Conditions 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_form_BASE_FORM_ID_alter().
 */
function field_visibility_conditions_form_field_config_edit_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()).

4. FILE: src/FormAlters.php

  /**
   * Constructor for FormAlters.
   */
  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: templates/whatsapp-button-template.html.twig

Twig code needs to be correctly indented. Drupal uses two spaces for indentation, not four spaces or tabs.