If you set up PHPStorm to use PHP Codesniffer and get the sniffs for Drupal installed, the code inspection tool will also check the code against our coding standards.

As a result, I created which is now a critical bug because it prevents the language switcher block from working. For example, while reviewing a patch that changed core/includes/theme.inc, the inspection informed me that it was unable to find the JSON class. PHPStorm has helped me find bugs in Drupal. My favorite inspection is a duplicate array key, as this can be quite difficult to spot.

PHPStorm will then detect unused variables, spelling mistakes, PHPDoc issues, and a plethora of other common problems. After applying the patch from the issue to review, I select Code > Inspect Code… from the menu.īy setting the scope to be 'Uncommitted files,' PHPStorm will only inspect the files changed by the patch. My current IDE, PHPStorm, allows me to inspect code for obvious mistakes. There is a part of reviewing that feels a bit like playing Papers, Please, but some of the most mundane parts are automatable. This process can be overkill for a one line patch, but once the patch is more than a couple of lines is helps the reviewer a great deal.

A draft change record or a list of change records that need updating, if necessary.

Evidence that the person who sets the issue status to 'Reviewed & tested by the community' has considered Drupal’s core gates.

Screenshots of before and after, if the user interface has changed.

Here are some things that make my job easier: Thanks to Chapter Three for making that possible. Since July 1, 2014, I’ve committed over 250 patches to Drupal 8. One of the main responsibilities of a Drupal core committer is doing a final review of patches before committing them.

Phpstorm drupal