Previously `valet uninstall` would just shutdown the `nginx` service.
This PR also stops `PHP` and gives a number of instructions on how to do a (nearly) clean uninstall of most Valet dependencies.
And also some troubleshooting tips.
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.
When switching to older PHP versions there may be a composer package dependency conflict. This PR adds a note to consider running `composer global update` to update those dependencies. It's only a comment since not all changes in PHP version will require running the update.
Fixes#822
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.
Previously when checking if the Valet version in use was the latest,
you'd have to go to Valet repo on GitHub, find out that all the docs
were on laravel.com, go there, find the upgrade instructions, and then
upgrade.
This can be simplified by giving the user the option to view the link.
If you've previously run `valet trust` to allow valet to run without specifying `sudo` repeatedly or entering your password with various valet commands, recent updates to MacOS may give you a `sudo: sorry, you are not allowed to preserve the environment` response when trying to run those `valet` commands.
The fix is in updating the sudoers entry that `valet trust` creates.
This PR tells valet how to update the sudoers entry so that this message doesn't continue.
YOU WILL NEED TO RE-RUN `valet trust` IF YOU HAD PREVIOUSLY RUN IT, after installing this update, in order for this code change to have any effect.
(Technical explanation: the sudoers protections have become stricter, so we have to be more explicit that we do indeed want environment variables to flow through to the sudo user's environment when using valet via sudoers entries.)