[1.x] Advanced Language Selector

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

1.0 is a wrong branch name, as branch names end with the literal .x. That branch needs to be removed.

• What follows is a quick review of the project; it doesn't mean to be complete
• For each point, the review usually shows some lines that should be fixed (except in the case the point is about the full content of a file); it doesn't show all the lines that need to be changed for the same reason
• A review is about code that doesn't follow the coding standards, contains possible security issue, or doesn't correctly use the Drupal API; the single points aren't ordered, not even by importance

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

advanced_language_selector.info.yml

package: Custom

That line used by custom modules created for specific files. It is not a package name used for projects hosted on drupal.org.

advanced_language_selector.module

/**
 * @file
 * Primary module hooks for Advanced Language Selector module.
 */

The description for a module is Hook implementations for the [module name] module. where [module name] is the module name given in the .info.yml file. In Drupal, there are not primary and secondary hooks.

  // @ Register here all the defined styles.
  // @ For each style must exist a template with this name:
  // @ block--language-selector--[STYLE ID].html.twig

As per Drupal coding standards, comments in code do not start with @.

src/Plugin/Block/LanguageSelectorBlock.php

As per Drupal core backend backwards compatibility and internal API policy (Drupal 8 and above) → , classes that implement plugins are not part of the public API and must not be used as parent class by contributed projects.

   * @return void
   *   No return data is expected because all is built passing the form and
   *   configuration references.

There is no need to add a return value description, when a function/method does not return values.

src/Services/StyleManager.php

  /**
   * Constructor.
   *
   * @param \Drupal\Core\Extension\ModuleHandlerInterface $module_handler
   *   The module handler.
   */
  public function __construct(ModuleHandlerInterface $module_handler) {
    $this->moduleHandler = $module_handler;
  }

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.

Hi!
First of all, thank you for your reviews!
I have corrected the errors that you have indicated to me, I have created a new branch name (1.x) and push the changes.
Excuse me if I haven't understood something correctly, anything you see strange, please let me know, I will be on the lookout for this issue.
Best regards!

Remember to change the status to Needs review when the project is ready for review.

Remove the 1.0 branch.

Deleted!
Thank you for your patient...

Rest everything seems fine. Moving to RTBC.

src/Plugin/Block/LanguageSelectorBlock.php

    $module = $this->moduleHandler->getModule("advanced_language_selector");
    $flagIcon = $module->getPath() . "/assets/flags/$langCode.svg";

The correct code to retrieve a module path is to call drupal_get_path(), for any Drupal version lower than 9.3, or \Drupal\Core\Extension\ExtensionPathResolver::getPath(), starting from Drupal 9.3. Since the module is defined as compatible with any Drupal 9 or Drupal 10 versions, it is not possible to use the same code in all those versions.
A solution is changing the minimum required Drupal version.

    $pattern = "/\\/[a-z]{2}\\/?/";
    $currentUrl = $this->requestStack->getCurrentRequest()->getRequestUri();
    return preg_replace($pattern, '/' . $destLanguage . '/', $currentUrl);

That code seems to make some assumption about the value returned by $this->requestStack->getCurrentRequest()->getRequestUri() or on which pages the block is rendered.
In fact, in the case no parameter is passed to the method, it changes "/node/1" in "/en/de/1", "/node/1/edit" in "node/1/en/it", "/random/url/from/a/module/" in "/en/ndom/en/l/en/om/a/en/dule/", and "node/1/edit" in "node/1/en/it".

src/Services/StyleManager.php

    $files = scandir($stylesLocation);
    foreach ($files as $file) {
      if (pathinfo($file, PATHINFO_EXTENSION) === $extension) {
        $raw = file_get_contents($stylesLocation . $file);
        $style = Yaml::decode($raw);
        $style['templates_location'] = $modulePath . $style['templates_location'];
        // Ignore style if it haven't id attribute.
        if (empty($style['id'])) {
          continue;
        }
        $styles[$style['id']] = $style;
      }
    }

In Drupal, there is FileSystem::scanDirectory() to get a list of files contained in a directory.

src/Services/StyleManagerInterface.php

/**
 * Service description.
 */
interface StyleManagerInterface {

That is not the description for that interface.

There are some lines that do not follow the Drupal coding standards, such as.

  public function __construct(
    array $configuration,
    $plugin_id,
    $plugin_definition,
    LanguageManagerInterface $language_manager,
    RequestStack $request_stack,
    ModuleHandlerInterface $module_handler,
    StyleManagerInterface $style_manager,
    RouteMatchInterface $route_match
  ) {

Method and function declarations are written on a single line.

  /**
   * Get specified style.
   *
   * @param string $key
   *   The id of the style.
   *
   * @return array
   *   Theme definition.
   */

The verb in the description must be declined to the third person singular.

Hi!
I added support to Drupal 8 and I solved all indicated issues except this one:

The correct code to retrieve a module path is to call drupal_get_path(), for any Drupal version lower than 9.3, or \Drupal\Core\Extension\ExtensionPathResolver::getPath(), starting from Drupal 9.3.

If you check the interface ModuleHandlerInterface of core version 8.9.x (lower than 9.3) (ModuleHandlerInterface.php) there is a method called "getModule" that returns one object of type \Drupal\Core\Extension\Extension. This object provides the method "getPath()" that I use in the code, so I understand that this part is fine and I don't need to change it.

Anyway, since I've added support for version 8, I've tested everything fine on a fresh 8.9.20 install and it works fine.

Thank you very much to all for all your support!

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 Slack → #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.

I thank all the reviewers.

Automatically closed - issue fixed for 2 weeks with no activity.