Update test suite to phpunit 9.5 syntax
Refactored to use polyfill for older PHP versions via `yoast/phpunit-polyfills`
Note: this includes 2 important differences from usual phpunit test suites:
- instead of extending `PHPUnit\Framework\TestCase` we extend `Yoast\PHPUnitPolyfills\TestCases\TestCase`
- instead of handling fixtures via `setUp()` and `tearDown()` we use `set_up()` and `tear_down()` respectively
Comment regarding formatting: I chose to use the FQDN in the `extends` syntax of the class declaration instead of using `use` so that it is more quickly apparent that we're doing something slightly different than usual phpunit syntax, particularly in regards to the set_up() / tear_down() methods that appear immediately following the `extends` line.
Old: `/usr/local/var/log/php-fpm.log`
New: `~/.config/valet/Log/php-fpm.log`
(We already put `~/.config/valet/Log/nginx-error.log` there)
This avoids ARM Mac differences in directory paths.
PHP's default is 128M, but it's becoming common practice to set the value to 512M in dev and production
Plus, currently homestead sets it to 512M as well.
PHP configs no longer support `#` for comments. Must use semicolons `;`.
Otherwise PHP may not start, and may show a confusing error in logs: `value is NULL for a ZEND_INI_PARSER_ENTRY`
This allows the valet configuration to stand separately from the default PHP config.
This benefits troubleshooting, makes customization of FPM workers and other settings easer
and allows for easier uninstallation.
Also renames any previously-existing `www.conf` pool config so it doesn't conflict with Valet nor run unnecessary additional processes.
This PR changes Valet's default config process to empower this feature, which makes installation less intrusive, and easier to identify and remove valet-specific customizations.
This will make for easier troubleshooting
... and easier customizing (such as dropping in a custom logging config, additional TLDs, alternate DNS resolvers, etc)
Also removes old dnsmasq configs used by prior Valet versions
These larger buffer sizes accommodate larger requests that are often complained about in Valet support issues.
These updates are inspired by common configs in Homestead.
I've been using these in my local Valet config for 4+ months, without any negative side-effects.
Edit: commented-out several, and made consistent with Forge defaults
A long-requested adjustment to Valet is to bypass the logging of robots.txt and favicon.ico hits. Particularly when keeping an Ngrok session alive.
This update is consistent with default logging settings in Forge.
Fixes#772
I've been using this config change since Aug 17, 2019, without any negative side-effects.
All Valet services continue to work properly, and Valet Share still works just as expected.
If someone were to have a challenge with it, there's an easy downgrade: just remove the `127.0.0.1:` from these files, and run `valet tld test` to rebuild the individual site configs. Or just manually edit the `~/.config/valet/Nginx` site file manually.
Since the current TCP port 88 clashes with Kerberos, changing it to port 60 which IANA shows as unassigned, and other databases show as not being used in general practice.
Several alternates were researched, but show (although limited use, nevertheless possible) clashes with other systems, including ports 47, 81-90, 8080-8090, and 100. Various sources were referenced, and the overall conclusion is that 60 seems to be the safest and least likely to conflict.
Tested against a few limited firewall configs without issue.
Tested with both fresh new valet installs and an older install upgraded from 2.0.x.
Defaulting to having `ssi on;` in the `http` block will allow those of us doing Nginx Server Side Includes to use Valet in local development.
A longer explanation of SSI, why we want it, and the impact is here: https://github.com/laravel/valet/issues/513
Signed-off-by: Andrew Welch <andrew@nystudio107.com>
client_max_body_size does not propagate down from the http context into
the server context.
See this stack overflow for further details on the issue:
https://stackoverflow.com/questions/2056124/nginx-client-max-body-size-has-no-effect
This fix ensures that the max client body size is always the default
128mb as specified in nginx.conf.
