[D9] Tagify

Thank you for applying! Reviewers will review the project files, describing what needs to be changed.

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 smother review.

To reviewers: Please read How to review security advisory coverage applications, What to cover in an application review, and Drupal.org security advisory coverage application workflow.

• This is a quick review that doesn't mean to be complete
• Each point describes what needs to be changed to have secure code that correctly uses the Drupal API and that follows the Drupal coding standards
• The review points are listed in order of importance as much as possible: first the points about security issues, then the points about code that doesn't correctly use the Drupal API; the points about wrong branch names, branch names that should be avoided because they are too similar, or code that doesn't follow the Drupal coding standards are listed for last

  /**
   * {@inheritdoc}
   */
  public static function create(ContainerInterface $container) {
    $controller = parent::create($container);
    $controller->setMatcher($container->get('tagify.autocomplete_matcher'));
    return $controller;
  }

The code in the create() method just calls the class constructor passing the injected services.

class LoadTest extends BrowserTestBase {

  /**
   * Modules to enable.
   *
   * @var array
   */
  public static $modules = ['tagify'];

  /**
   * A user with permission to administer site configuration.
   *
   * @var \Drupal\user\UserInterface
   */
  protected $user;

  /**
   * {@inheritdoc}
   */
  protected function setUp() {
    parent::setUp();
    $this->user = $this->drupalCreateUser(['administer site configuration']);
    $this->drupalLogin($this->user);
  }

  /**
   * Tests that the home page loads with a 200 response.
   */
  public function testLoad() {
    $this->drupalGet(Url::fromRoute('<front>'));
    $this->assertSession()->statusCodeEquals(200);
  }

The test isn't testing the module. It's checking the front page is loaded, which is already done by Drupal core tests.

The LoadTest.php file needs to be removed, together the directory containing it.

The test isn't testing the module, since it doesn't alter the front page. Furthermore, Drupal core already tests the front page load; there is no need for every module to repeat that test, since the Drupal core tests are executed when a module's test are executed.

Thank you for your contribution! I am going to update your account.

These are some recommended readings to help with excellent maintainership:

• Dries' post on Responsible maintainers
• Best practices for creating and maintaining projects
• Maintaining a drupal.org project with Git
• Commit messages - providing history and credit
• Release naming conventions.
• Helping maintainers in the issue queues

You can find more contributors chatting on the IRC #drupal-contribute channel. So, come hang out and stay involved.
Thank you, also, for your patience with the review process.
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.

Apologies for the noise.

Adding a tracking flag for auditing when modules have been reviewed by the queue only for it to be announced after approval that reviewed code contained a security vulnerability.

SA-CONTRIB-2022-051