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.
When we added the `proxy` feature in https://github.com/laravel/valet/pull/913 we inadvertently broke the `tld` command.
It was concatenating old+new tld when searching for existing configs, thus it couldn't find the correct file, which triggered the reported error.
Fixes#984
This PR fixes the lookup by allowing the correct intended lookup tld to be passed in. It also checks that the file exists before trying to read it.
Updated the `proxies` method to return the URL + .tld
as the rendered output wasn't exactly what one would
expect. While not critical, it was not consistent.
Refactored some of the Site class to aid in testing using
a fake instead of relying on a ton of mocking.
The Site fake has support for both using `tests/output`
as well as named fixtures (`tests/fixtures/Proxies`).
Testing for certificate I/O is pretty whack, but this is
the best I could come up with that would still ensure
the certificate stuff was getting called without
actually requiring `sudo` to run phpunit.
Replaced instances referring directly to `VALET_HOME_PATH`
with calls to the new `valetHomePath()`. This method
is taken over in the fake Site implementation so
that everything runs the same using the fake
Site without having to change other
assumptions.
Updated several "path" methods (and many of their usages)
to take the "thing" you are looking for so you can
either get the path to the type of "thing" you
are looking for or the direct path to the
specific "thing" you are looking for.
Examples:
```
// ~/.config/valet/Nginx
$site->nginxPath();
// ~/.config/valet/Nginx/some-site.com.test
$site->nginxPath('some-site.com.test');
```
Made some other tests related to the existence of `Sites`
directory that resulted in updating the mocks for
many of the other tests.
All in all, it should make other aspects of the Site class
handle things more gracefully if `Sites` doesn't exist.
Fixes#756
Previously if `php` was installed as just `php` (the default Homebrew alias), Valet would not detect *which* PHP version was actually installed, and therefore `valet use` might do incorrect or unnecessary installations/links/etc.
NOTE: This does NOT "convert" existing `php` alias to a numbered version. It merely accepts it as-is, but notes its version in an attempt to avoid extra installations.
*NOTE: Specifally tested with PHP 7.4 and 7.3. No promises about old 5.6, etc aliases.*
Thanks to the generosity of Alan at Ngrok, I've been able to do some additional testing with temporary added features.
Turns out #864 was incomplete. This PR now also loops through the default endpoints in order to find a process matching the passed domain.
Ref: #864
Ref: #145
`valet uninstall` only displays information about how to manually uninstall and clean up after Valet.
This PR adds a `--force` parameter, which will forcefully remove Valet and the Homebrew services it installs, as well as clean up the config files and log files.
But for a few post-uninstall composer dependencies, cleanup is very thorough.
This brings idempotency to both `valet install` and `valet uninstall --force`
(There may still be edge cases where other Homebrew or composer packages might create interference with install/uninstall, but this makes things much easier to self-troubleshoot.)
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.
Ngrok Pro plans allow multiple processes, which means you could be serving several sites simultaneously. This PR allows Valet to correctly identify amongst the active ngrok process URLs.
Fixes#145
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
This PR allows passing `--all` to `valet unsecure` to have it remove all certificates from all Valet configs AND from the MacOS Keychain.
This effectively cleans up certificate fragments or broken configs, and can help with troubleshooting.
While it's rare that the dnsmasq won't be started, it feels incomplete to not include the service when starting/restarting valet, since valet depends on it.
While since #268 valet has been checking nginx configs for errors when starting/restarting, the captured errors are never displayed if there is a failure because it's being run using `quietly()`.
This PR causes the errors to pass through to the console so we can more readily understand why nginx may not be starting or not serving properly.
