[2.x] Audio Clips API

Thank you for applying!

Before giving links helpful to understand how the review process works, what to expect from a review, and what to do to avoid a review takes more time than needed, I would like to thank all the reviewers for the work they do.
These applications are volunters-driven, which also means it is not possible to predict when an application will be marked fixed and the applicant will get the permission to opt projects into security advisory policy. While we aim to make an application as quick as possible, it is also important for us that more people review the project used for an application. In this way, we make sure applications do not miss some important points that should be instead reported.
Applications are not meant to be complete debugging sessions that eliminate every existing bug, though. I apologize if sometimes applications seem to go into too-detailed reviews.

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

2. FILE: audio_clips.module

Procedural hooks should be marked with the #[LegacyHook] attribute.

Also, it requires increasing the minimum required Drupal 10 version to 10.1

3. FILE: src/Form/AudioClipTypeDeleteForm.php

  /**
   * String translation manager.
   *
   * @var \Drupal\Core\StringTranslation\TranslationInterface
   */
  protected $translation;

  /**
   * Constructs a new AudioClipTypeDeleteForm object.
   *
   * @param \Drupal\Core\StringTranslation\TranslationInterface $string_translation
   *   The string translation manager.
   */
  public function __construct(TranslationInterface $string_translation) {
    $this->translation = $string_translation;
  }

FILE: src/Form/AudioClipTypeForm.php

  /**
   * The entity field manager.
   *
   * @var \Drupal\Core\Entity\EntityFieldManagerInterface
   */
  protected $entityFieldManager;

  /**
   * Constructs the AudioTypeForm object.
   *
   * @param \Drupal\Core\Entity\EntityFieldManagerInterface $entity_field_manager
   *   The entity field manager.
   */
  public function __construct(EntityFieldManagerInterface $entity_field_manager) {
    $this->entityFieldManager = $entity_field_manager;
  }

New modules, which are compatible with Drupal 10 and higher versions are expected to use constructor property promotion.

Point 3 - use constructor property promotion is pending. See reference.

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.

I've reviewed the 2.x branch and found that previous feedback has been addressed. However, there are several important issues that need attention.

Incorrect hook name in audio_clips.module (line 16)

The hook implementation is named audio_clips_checker_help but should be audio_clips_help

Inconsistent and undefined permissions in routing.yml

• Line 22: administer audio clip types

Permissions must be defined in a audio_clips.permissions.yml file.

Missing config schema

No config/schema/audio_clips.schema.yml file exists. Configuration entities should have schema definitions to enable proper validation and translation.

README.md incomplete: The README is not according to the drupal.org template. The Configuration and How It Works sections are too brief to be useful.

• The following points are just a start and don't necessarily encompass all of the changes that may be necessary
• A specific point may just be an example and may apply in other places
• A review is about code that does not follow the coding standards, contains possible security issue, or does not correctly use the Drupal API
• The single review points are not ordered, not even by importance

src/Controller/AudioClipTypeListBuilder.php

List builders are not controllers; their namespace should not contain Controller.
Drupal core started to retrieve controllers using PHP attributes; removing from the Controller directory classes that are not used for controllers is necessary to avoid Drupal looks for controllers in classes that are not controllers. See #3311365: Use PHP attributes for route discovery and #3584795: Remove non-controller classes from module Controller namespaces/folders for more information.

audio_clips.services.yml

Starting with Drupal 9.3, services can be autowired. This means that their arguments no longer need to be defined in the .services.yml file; Drupal core will check the parameters required by the class constructor.

composer.json

The Drupal.org Composer Façade automatically adds the core requirements for the project basing on what entered in the .info.yml file. As noted in Add a composer.json file:

• The core requirements in the composer.json file are not generated by the façade for Git based checkouts that do not use the façade. For those cases, an entry for drupal/core may be required in the composer.json file.
• When the composer.json file contains the core requirements, those must be compatible with the same version set in the .info.yml file. A mismatch in compatibility may create issues.

I am not suggesting that a change is necessary. This point is to make sure you know what the Drupal.org Composer façade does, and that, when adding core requirements also in the composer.json file, it is necessary to double check they are compatible with the core requirements in the .info.yml file.
I cannot think of any workflow where Composer is not used to gather the projects necessary for a site, and their dependencies, considering that Composer is required by Drupal core to gather its dependencies, but that does not mean that in specific cases it is necessary to have the core requirements also in the composer.json file.

Thank you for your contribution and for your patience with the review process!

I am going to update your account so you can opt into security advisory coverage any project you create, including the projects you already created.

These are some recommended readings to help you with maintainership:

• Dries' post on Responsible maintainers
• Maintainership
• Git version control system
• Issue procedures and etiquette
• Maintaining and responding to issues for a project
• Release naming conventions.

You can find more contributors chatting on Slack or IRC in #drupal-contribute. So, come hang out and stay involved!
Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.

I thank also all the reviewers for helping with these applications.