The Travis build job used to run e2e tests started failing due to the following NPM error when installing packages:
```
npm ERR! code EINTEGRITY
npm ERR! sha512-B2yGehx2B1Fg0ooPCxcbq2fRE+YvAh1Yssa6Kp/sGMCRgDD9+yR6Fa5urn+cOqMbOvuAVZElVqQx+4wVm4JWgw== integrity checksum failed when using sha512: wanted sha512-B2yGehx2B1Fg0ooPCxcbq2fRE+YvAh1Yssa6Kp/sGMCRgDD9+yR6Fa5urn+cOqMbOvuAVZElVqQx+4wVm4JWgw== but got sha512-4lJ4ERWmcGlG43jDdIy7shG0v3QsfoSvSrtbdcw/cpqF69WBOoHu1iC8Cb3IQ63WU7KujtR0TEF50CEcebhRCA==. (471195 bytes)
```
https://travis-ci.org/woocommerce/woocommerce/jobs/527530281#L633
This commit regenerates package-lock.json to work around the error. I simply delete package-lock.json file from my local copy of the repository and then ran `npm install`.
This commit fixes all 1533 PHPCS errors that PHPCBF can fix automatically in the tests/ directory. Before this change there was a total of 3106 PHPCS errors in the WooCommerce repository and now there is 1573 errors.
This commit moves the `dependencies` section in package.json to appear before `devDependencies` as the former is more important than the latter and this seems to be the standard for other package.json files.
This commit moves github-contributors-list in package.json from the `dependencies` section to the `devDependencies` section. This package is used to generate the list of WC contributors for each release and it is not needed to run WC.
This commit updates npm packages to their latest versions:
- chromedriver 2.46.0 → 74.0.0
- husky 1.3.1 → 2.1.0
- node-sass 4.11.0 → 4.12.0
Those three packages are devDependencies and since we are early in the WC 3.7 release cycle this change shouldn't cause any issue. I'm doing this to see if updating the chromedriver package fixes the failing e2e test that is failing on Travis (example of a failure: https://travis-ci.org/woocommerce/woocommerce/jobs/524016366#L829). I'm not able to reproduce this error on my local machine and in the past updating chromedriver fixed failing e2e tests.
PR #23196 added a workaround to `parse_str()` limitation when dealing with full-stops, pluses, and spaces in the parameter key. This workaround involved temporarily replacing those three characters with placeholders before calling `parse_str()` and then replacing back to the original form. This commit fixes a bug in this logic that was replacing back only parameters keys and not parameters values.
For example, if the query string is `?query.parameter=foo.bar`, the resulting <input> field contained `foo{dot}bar`, instead of the expected `foo.bar`.
Gerhard Potgieter
Rodrigo Primo
Peter Fabian
Claudio Sanches
Renovate Bot
Garrett Hyder