[1.x] Configuration Batch Export

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 did not make a complete review, but the code needs to be at least changed as per the following points.

• The code must be formatted as per Drupal coding standards ( PHP → and JavaScript → ), which means (for example) that lines must be indented by two spaces
• The first argument passed to t() (or the equivalent method) must be a literal string, not a concatenation of strings; placeholders are instead used
• The first argument passed to $logger->error() must be a literal string, not a translatable string

Hello!

Just made a new commit with an entire code refactorization to match Drupal standards. The whole update has been validated by phpcs (Screenshot below.)
All the updates are in commit e2e4fecd.

Thank you all

Hello @vishal.kadam,

Anything new here? Do I have to do something or just wait?

Thank you!

Let's wait for a Code Review Administrator user to take a final look, and if everything is fine, you will get the role.

Oh, I thought you were a Code Review Administrator, sorry ^^ I'm new to this contribution system.

Hello,

This application has been running for almost 1 month and I still not have news. Could someone please re-check my code so I can finally create a 1.0 release?

Thank yall

Hello everyone,
Would it be possible to review this application please? It's been almost two months. Thank you!

• 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 doesn't follow the coding standards, contains possible security issue, or does not correctly use the Drupal API; the single points are not ordered, not even by importance

src/Form/DownloadConfirmForm.php

    $helperService = \Drupal::service('configuration_batch_export.helper');
    $exportFolderPath = $helperService->getTempFolderPath();
    if (isset($exportFolderPath) && !empty($exportFolderPath)) {
      $files = scandir($exportFolderPath);
    }
    $files = $files ?? [];
    if ($files !== NULL) {
      $files = array_diff($files, ['.', '..']);
    }

    $messenger = \Drupal::messenger();
    $logger = \Drupal::logger('configuration_batch_export');

Dependencies must be injected using the dependency container.

      $logger->error($this->t('More than one archive found in the folder @exportFolderPath. Please, remove all the archives and export your configuration again.', ['@exportFolderPath' => $exportFolderPath]));

The first argument of error() and similar logger methods is a literal string.

src/Form/ExportForm.php

  public function validateForm(array &$form, FormStateInterface $form_state) {
    $configs_per_chunk = $form_state->getValue('configs_per_chunk');

    if ($configs_per_chunk < 1 || $configs_per_chunk > 200) {
      $form_state->setErrorByName('configs_per_chunk', $this->t('The number of configurations per chunk must be between 1 and 200.'));
    }
  }

There is no need to use a validation handler to limit the values acceptable by a number form field: It is sufficient to use its #min and #max properties.

(I apologize this review is not complete, but I can only continue between a hour.)

src/Service/HelperService.php

    if (!$success) {
      $this->loggerChannelFactory('configuration_batch_export')->error('Cannot create zip archive in ' . $this->archivePath . '/' . $archiveName);
      throw new \Exception("Cannot create zip archive");
    }

The first argument of error() and similar logger methods must be a literal string.

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. If you are no longer pursuing this application then I mark it as Closed (won't fix).

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

Hello,

I didn't seen that my request has been updated. I'll take a look at the edits that I have to do and I'll come batck to you.

@zilloww It seems that you have not responded comment #14 and #16. Please solved issue point out on those comments.

I just pushed my changes to the remote branch `project-application-review-updates`. Would it be possible to give it a look?

Ty!

The reported changes should be committed to the review branch (1.x), as specified during the creation of this application.

The branch has been merged into 1.x

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.

In /src/Service/HelperService.php line 138:

      $this->loggerChannelFactory('configuration_batch_export')->error('Cannot create zip archive in @archivePath/@archiveName', ['@archivePath' => $this->archivePath, '@archiveName' => $archiveName]);

This is a very long line, so it would be better to reformat as follows:

      $this->loggerChannelFactory('configuration_batch_export')->error(
        'Cannot create zip archive in @archivePath/@archiveName',
        [
          '@archivePath' => $this->archivePath,
          '@archiveName' => $archiveName,
        ],
      );

In /src/Form/ExportForm.php, line 5, the use statements are not sorted alphabetically. The expected sort is a case sensitive sort, with upper case coming first, so Drupal\Core entries should come before Drupal\configuration_batch_export.

Also in /src/Form/ExportForm.php, line 94, the $configs_per_chunk value is retrieved from the form state, but nothing is done with it. Presumably it should verify that it is a numeric value. If you intend to validate it, you should add a check here. If not the validateForm method should be removed from the class.

In /src/Form/DownloadConfirmForm.php, line 6, the same problem with case sensitive sort of use statements is there.

Lines 23 and 30 of this file have a space at the end.

On line 32 of the same file, there should be 1 more space of indentation of the paramater comment. It should be indented 2 spaces more than the @param on the preceding line (the * at the beginning of the line is correct, it's just the text that should be indented within the comment formatting).

At present, this module only supports Drupal 10. I don't think that means it can't opt into the security policy, but I think it would make site builders a lot more comfortable choosing this module if they knew there was an upgrade path to Drupal 11 in the future.

Finally, at present there is no test coverage. I think adding at least some basic tests would allow pipelines to run on every commit, and perform sanity checks, and some assurance that changes aren't going to break the module. Again, I'm not sure that tests are required for security coverage, but they would make it a lot easier to have some confidence that it's behaving as it should.