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.
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.*
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`
While `valet trust` enables (creates) sudoers entries, there was no cleanup/removal option for this, apart from complete forced uninstall of Valet.
This adds `valet trust --off` so that the sudoers entries can be removed from Valet CLI.
After running `valet directory-listing on` if a URI points to a directory that exists, but the requested file cannot be found in that directory, a directory listing will be displayed.
A 404 will still happen if the project directory cannot be found.
Running `valet directory-listing off` makes a 404 display (without a listing) if the requested file cannot be found.
Supercedes and closes#349 and closes#587
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.)
