Laravel Valet not picking up php.ini changes, a fix

If you have Laravel Valet not picking up php.ini changes, try this:

Upgrade to PHP 7.4 with Homebrew on Mac

Brent has done a writeup on how to upgrade your Homebrew-installed PHP version to PHP 7.4. Since the php formula now contains that 7.4 version (instead of 7.3 before), all you need to do is make sure brew is up-to-date and then upgrade the php formula itself:

# make sure brew is up-to-date
brew update

# upgrade the php formula to its latest version
brew upgrade php

Upgrade to PHP 7.4 with Homebrew on Mac →

💁‍♂️ Don’t forget to upgrade Valet too, while you’re at it:

# stop current valet
valet stop

# update global packages
composer global update

# Make Valet do its housekeeping
valet install

Laravel Valet Environment Variables

To set/override Environment Variables in Laravel Valet, one had to manually edit the Nginx config files and restart Nginx after doing so. With the release of Laravel Valet 2.1.6 this is no longer needed: Valet 2.1.6 contains a merged PR that provides built-in support for an specific file named .valet-env.php in which you can set your environment variables.

🕸 Running an older version of Valet? Run these on the CLI to update:

# update package
composer global update

# Make Valet do its housekeeping
valet install

To set environment variables in Valet 2.1.6 or newer, create a file named .valet-env.php inside the directory where you ran valet link app-name before. Its contents must return an array with the envvars you want to define.

However, you must group these per app-name (e.g. the one you used during the valet link command), or you can use * as the wildcard. Each app-name define contains an array in itself, with the keys representing the names of the environment variable, and the values their respective value.

Here’s a few examples:

<?php

return [
	'*' => [ // Applies to all
		'APP_ENV' => 'dev',
	],
];
<?php

return [
	'app-name' => [ // Only applies to app-name.test
		'APP_ENV' => 'dev',
	],
];

It’s possible to combine * and app-name, their defined envvars will get merged at runtime:

<?php

return [
	'*' => [ // Applies to all
		'APP_ENV' => 'dev',
	],
	'myproject' => [ // Only applies to myproject.test
		'DB_NAME' => 'db_devdata',
	],
	'empty.myproject' => [ // Only applies to empty.myproject.test
		'DB_NAME' => 'db_empty',
	],
];

Here’s to no more fiddling with ~/.config/valet/Nginx/app-name.test files 🍻

Did this help you out? Like what you see?
Thank me with a coffee.

I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!

☕️ Buy me a Coffee (€3)

To stay in the loop you can follow @bramus or follow @bramusblog on Twitter.

Fixing the valet share 301 Redirect Loop

One of the nice things of Laravel Valet is that it includes an easy way to make your local site available publicly. For this it has the aforementioned Ngrok built-in. To use it, just run the valet share command, and your local site will be shared through a *.ngrok.io subdomain.

However, when combining valet share with valet secure (which serves your local site over HTTPS) it won’t work: you’ll end up in a 301 Redirect Loop when visiting your site through the *.ngrok.io domain.

To fix this issue there are two options:

  1. The old way: Manually edit your sites Nginx config file and remove the block that listens on port 80.

    As valet issue#382 details, you can fix this error by manually editing the Nginx configuration for your site.

    Say your site is mysite.test, then its Nginx config file can be found at ~/.config/valet/Nginx/mysite.test.

    💁‍♂️ Can’t find the file at said location?

    Note that Valet versions < 2.1.0 use the ~/.valet folder instead of the ~/.config/valet/ folder

    Inside the ~/.config/valet/Nginx/mysite.test file, look for a block that looks like this:

    server {
        listen 80;
        server_name mysite.test;
        return 301 https://$host$request_uri;
    }

    Now remove that block entirely (or comment it out using the # sign), save it, and restart valet using valet restart.

    When now using valet share it will work fine 🙂

  2. The new way: Upgrade Valet to version 2.1.3 or newer

    It came to my attention through valet issue#148 that valet 2.1.3 got released just three days ago and that it contains an out-of-the-box fix for this bug … yay! 🎉

    To upgrade your Valet install run this:

    # update package
    composer global update
    
    # Make Valet do its housekeeping
    valet install

    When now using valet share it will work fine 🙂

    Note that when coming from Valet < 2.1.0 the ~/.valet folder will have moved to ~/.config/valet/

There ya go 🙂

Did this help you out? Like what you see?
Thank me with a coffee.

I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!

☕️ Buy me a Coffee (€3)

To stay in the loop you can follow @bramus or follow @bramusblog on Twitter.

Missing ~/.valet folder?

Earlier today I updated my Valet installation from version 2.0.x to 2.1.1. To my surprise the ~/.valet/ folder had gone missing, immediately making me think the update process somehow had gone wrong (even though Valet kept on serving sites).

Turns out that the ~/.valet/ folder got moved to ~/.config/valet/ with the release of Valet 2.1.0.

So yes, the valet logs are now located in ~/.config/valet/Log/ instead of ~/.valet/Log.

/me mumbles something about semver and breaking changes and stuff …

Did this help you out? Like what you see?
Thank me with a coffee.

I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!

☕️ Buy me a Coffee (€3)

To stay in the loop you can follow @bramus or follow @bramusblog on Twitter.

Switching PHP versions with Laravel Valet

⚠️ Running Valet 2.x with a PHP version lower than 7.1 won’t work, until this issue is resolved. You can still switch to that version for use on the CLI. You just won’t be able to use it with Valet 2.x

ℹ️ UPDATE 2018.10.23: Freek has developed some handy aliases to easily switch PHP versions.

ℹ️ UPDATE 2019.08.12: With the release of Valet 2.2.0, it is now possible to change PHP versions using the valet command itself:

valet use [email protected]

valet use php

Valet will install the specified PHP version via Brew if it is not already installed.

🎉

For some older projects that I still need to run, I recently started using Valet. As those projects sometimes require different versions of PHP – or when I want to test them with the latest PHP version – I followed this set of instructions by Michael Dyrynda:

With the most recent Homebrew – in which PHP got moved to the core – I had to slightly tweak the commands a bit though:

# Install PHP 7.1 (you only need to do this once)
brew install [email protected]

# Stop latest PHP
brew services stop php
brew unlink php

# Activate PHP 7.1
brew link [email protected] --force
brew services start [email protected]

🔥 Because they are no long supported, PHP versions 5.6 and 7.0 have been removed from homebrew/core. If you still need to install them, you can find them in the exolnet/homebrew-deprecated tap.

# Tap exolnet/homebrew-deprecated
$ brew tap exolnet/homebrew-deprecated

# Installing these old versions will now work
$ brew install [email protected]
$ brew install [email protected]

I noticed that after running these command you – somehow – might still have the “old” php service running as root (you can check with brew services list). In that case force it to stop, and restart the new version service:

sudo brew services stop php
brew services restart [email protected]

After these steps here I (finally) got it working.

Switching PHP versions with Laravel Valet →

(via Freek)

Did this help you out? Like what you see?
Thank me with a coffee.

I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!

☕️ Buy me a Coffee (€3)

To stay in the loop you can follow @bramus or follow @bramusblog on Twitter.