[2.0.x] Basic Slider

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 am changing the issue priority as per issue priorities.

I recommend setting the 2.0.x branch (the latest branch) to be the default branch on GitLab. That way, merge requests will target the latest branch by default.

It would be nice if the README.md table of contents items were each linked to the corresponding section. Also, your README.md does not follow best practices (headings need to be uppercase). See https://www.drupal.org/node/2181737. There is also a line that it longer than 80 characters.

The module doesn't implement hook_help(). It'd be a good idea to do so.

basic-slider.html.twig is missing the comments at the top of the file. Look at any Drupal core twig file to see how to do it.

BasicSliderBlock.php

  /**
   * The storage handler class for files.
   *
   * @var \Drupal\file\FileStorage
   */
  private $fileStorage;

This should be typed as FileStorageInterface, in case someone wants to extend your class and use a custom file storage.

    $images = $this->configuration['images'];
    if (count($images)) {
      foreach ($images as $image) {
        if (!empty($image)) {
          if ($file = $this->fileStorage->load($image)) {
            $build['image'][] = [
              '#theme' => 'image',
              '#uri' => $file->getFileUri(),
            ];
          }
        }
      }
    }
    $build['#images'] = $build['image'];
    return $build;

$build['image'] could be undefinied here, if there are no images. Use $build['#images'] inside the for loop, and get rid of $build['image'], or you can check if it's empty before assigning it.

    if (count($images)) {
      foreach ($images as $image) {

You don't need the IF statement. The for loop will only run its code if there are images.

basic-slider.js

Consider rewriting it in vanilla JS without using jQuery. You barely used jQuery, so try going without. Drupal Core is working to remove jQuery, so it's a good idea to get rid of it if you can.

In addition, ESLint reports a lot of errors for this file. Please run ESLint against your project using Drupal's eslintrc.json. There are lots of spacing issues, you should use let or const instead of var, etc.

I am changing priority as per Issue priorities.

This thread has been idle, in the Needs work state with no activity for several months. Therefore, I am assuming that you are no longer pursuing this application, and I marked it as Closed (won't fix).

If this is incorrect, and you are still pursuing this application, then please feel free to re-open it and set the issue status to Needs work or Needs review, depending on the current status of your code.

We do not close applications two months after their status has been changed to Low. There are applications who waited for a review four or more months.

See the point 9 of Application workflow / Workflow and status changes, which I now changed to explicitly describe when inactive applications are closed.

Applications whose status is Needs work a year after they have been created, and whose priority has been Low for more than eight months, will be closed as Closed (won't fix). Applicants can still re-open them, if they changed what the review suggested to change.

This thread has been idle, in the Needs work state with no activity for more than eight months; the application has been created more than 11 months ago. Therefore, I marked it as Closed (won't fix).

If this is incorrect, and you are still pursuing this application, please feel free to re-open it and set the issue status to Needs work or Needs review, depending on the current status of your code.