This leverages the existing `.valet-env.php` file capability, but just adds the Valet Home directory as a first-lookup location.
So, now Valet will check for `.valet-env.php` in:
- `~/.config/valet/`
- then the current project folder
As discussed at https://github.com/laravel/valet/issues/789#issuecomment-565112046Fixes#789
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
This PR allows passing a specific domain name to `valet share` in order to have the app be served for that domain.
Now how it works is this:
- (NEW) if a domain name is passed, it checks whether it matches a link (which would be required for multiple domains served by same app project), and uses that
- if a domain name is NOT passed, it looks up any links for current directory, and uses the first found link
- else falls back to current project foldername
It also still allows passing through custom ngrok parameters if desired (ref: #112), as either the 2nd parameter (no domain name passed) or (NEW) 3rd parameter
Fixes#537
`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
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.
Since we require PHP > 5.6 there's no need to support symfony/process 2.x
However, symfony/process 4.x requires minimum PHP 7.1 so have to retain 3.x for now if we wish to support PHP 7.0 or older without complications.
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
