Including the linked resolv.conf helps with troubleshooting situations where dns appears to not be working.
(Mostly the goal is to determine whether a conflicting entry is listed too early, or if the localhost is not listed first when others are present.)
- properly detects if the requested version is already installed, and skips re-installing/re-starting/re-configuring
- allows --force to re-configure anyway
- smarter treatment of 'php' when it's aliased to another specific installed version
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
