[8.x-1.x] Disable language

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

While this application is open, only the user who opened the application can make commits to the project used for the application.

Reviewers only describe what needs to be changed; they don't provide patches to fix what reported in a review.

1. Fix phpcs issues.

phpcs --standard=Drupal,DrupalPractice --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md,yml disable_language/

FILE: disable_language/disable_language.links.menu.yml
--------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
--------------------------------------------------------------------------------
 6 | ERROR | [x] Expected 1 newline at end of file; 0 found
--------------------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
--------------------------------------------------------------------------------


FILE: disable_language/disable_language.routing.yml
--------------------------------------------------------------------------------
FOUND 1 ERROR AND 1 WARNING AFFECTING 2 LINES
--------------------------------------------------------------------------------
 7 | WARNING | [ ] The administration page callback should probably use "administer site configuration" - which implies the user can change something - rather than
   |         |     "access administration pages" which is about viewing but not changing configurations.
 9 | ERROR   | [x] Expected 1 newline at end of file; 2 found
--------------------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
--------------------------------------------------------------------------------


FILE: disable_language/tests/src/Functional/DisableLanguageSettingsFormTest.php
--------------------------------------------------------------------------------
FOUND 0 ERRORS AND 2 WARNINGS AFFECTING 2 LINES
--------------------------------------------------------------------------------
 51 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
 75 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
--------------------------------------------------------------------------------

2. Remove the LICENSE.txt file. The LICENSE file isn't necessary. It will be added automatically by the packaging script.

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

Fixed coding standards in the following commit: https://git.drupalcode.org/project/disable_language/-/commit/b739901a03f...

@nielsaers,

I have reviewed the changes, and they look fine to me.

Let’s wait for other reviewers to take a look and if everything goes fine, you will get the role.

For these applications, we need a project where, in at least the branch used for the application, most of the commits (if not all the commits) have been done from the user who applies.
The purpose of these applications is reviewing a project to understand what the user who applies understands about writing secure code that follows the Drupal coding standards and correctly uses the Drupal API. A project without code committed by the user who applies cannot be used for these applications, especially when the user doesn't have the permission to commit code.

Based on what do you make that assertion? I have 16 commits (counting those git user whoopsies) out of 42 commits on this branch. I have the most commits on this project and I've done the initial code for this project. Which should show that I understand about writing secure code that follows Drupal coding standards and correctly uses the Drupal API.

So I respectfully disagree with your assertion. How do we take this forward?

16 commits out of 42 commits are not "most of the commits." If then I watch when those 16 commits have been done, I find one done three days ago and then one done three years ago, with commits done from other maintainers in between.
Reviewers cannot check all the branches to see which changes have been done by you and verify what you understand about writing a Drupal module/theme code.

Apply for permission to opt into security advisory coverage → says, on the prerequisites:

The user who applies has committed code in the project used for the application (not an issue fork created to fix an issue in an existing project). Those commits must be (preferably) the only ones done in the branch used for the application, or be most of the commits for that branch.

Since the code has been written by more than one person, reviewers cannot see what a single person understands about writing secure code that follows the Drupal coding standards and correctly uses the Drupal API. Since there are not much corrections to be done, it is not also possible to see how the person who applies changes the code basing on what reported.

The purpose of these applications is allowing the person who applies to opt projects into security advisory policy, not to set the project as covered by the security advisory policy, which is this case it is not also necessary because it is already covered. If we did the latter, then how many commits were done from who creates the application would be irrelevant.

Ok, so it's a numbers game. Amount of commits and not the actually committed code is the rule.

How do I go forward, one of the following option?

1. Close this request and I open a new one for a different module I maintain.
2. Do I create a new branch from and old commit so you can check there? (but feels counterproductive)

Let's try something different: You review two applications without using automatic tools and report what is wrong in the code as per coding standards, correct use of Drupal API, and secure code.

Sounds like a plan.

Setting to needs work again so it doesn't get picked up by anyone.

Hey apaderno, is this what you were looking for? https://www.drupal.org/project/projectapplications/issues/3356457#commen... →

As you are checking these on the regular, is there a possibility you could assign a requested review to me? That way I don't have to check every day if there are any more.

Missing hook_help in the module file.

@nielsaers Yes, that is perfect. You raised good points.

I was thinking of doing that. Issues cannot be assigned to every user, but there is the way to work around that.

@sivakarthik229 Please see the previous comments. This issue is marked Needs work to avoid reviews because we are not reviewing this project, right now.

Additional review done: https://www.drupal.org/project/projectapplications/issues/3356949#commen... →

Additional review done:
https://www.drupal.org/project/projectapplications/issues/3357132#commen... →

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.