WPEngine is now showing PHP 8.2 as an upgrade option. we need this on local so we can test and fix issues.
1 Like
Also looking for PHP 8.2 inside of Local. @austinwendt any update on this now that we are a week past the holiday? Thanks!
I’d love to get an update on this as well once you guys get a chance. 
Update coming soon on this y’all! Thank you 
6 Likes
PHP 8.2 is also now available on Flywheel, and as of July 11 it is what’s being used as the default for new sites: Flywheel | PHP on Flywheel
It’s really great to see Flywheel adopting 8.2, but it is unfortunate that this is the 2nd time PHP support’s been available in a WP Engine’s hosting platform before it’s available in its testing tool. I’m merely a consumer of a free development tool that is really freaking good, but I’ll be glad when whatever technical barriers inhibiting timely releases of new PHP versions can be overcome.
PHP 8.2 news coming this week! Stay tuned!
3 Likes
PHP 8.2 is out on all operating systems - no update to Local needed! Simply open Local and get to building. It is available in the Custom environment when creating new sites as well as the drop-down for switching PHP versions on existing sites. If you’re not seeing it, you can either refresh the Local window (Cmd+R) or simply close and reopen the app.
All extensions should be present with the exception of Imagick on macOS (Apple Silicon) and Windows - Imagick is configured for the other two operating systems. Those will be coming soon, but it wasn’t worth holding the release any longer!
6 Likes
So I’ve tried to add xdebug.log_level=0 to the php.ini.hbs file for when xdebug is active but the value doesn’t seem to be taking. Any ideas why?
{{#if xdebugEnabled}}
xdebug.mode=debug,develop
xdebug.log_level=0
{{else}}
xdebug.mode=off
{{/if}}
xdebug.client_port=9003
xdebug.start_with_request=yes
xdebug.discover_client_host=yes
It seemed to be an issue with not having current WP-CLI. I wasn’t able to update WP-CLI in 8.2.8, but was in 8.0.22. Now it seems to set the log_level correctly.
Interesting - good find. So the fix was move the site back to PHP 8.0, update WP-CLI (via the update command in the site shell?), and then switch back to PHP 8.2?
Also, which php.ini.hbs file were you editing? There is one at the site level and then one at the Application Support level. Depending on which one, that could explain the behavior.
So I installed PHP 8.2 and got some logged errors that had been mitigated in WP-CLI in 2.8 or so. I opened the site shell ran wp cli update and got errors.
I loaded PHP 8.0, opened site shell and re-ran the command successfully. After updating WP-CLI the mods to php.ini.hbs stuck.
The confit files are in ~Library/Application Support/Local/lightning-services. Or close to that as I’m on mobile.
Upside is now everything seems to function as expected.
1 Like
@austinwendt Is that an official and supported process to update the bundled WP-CLI version (using command wp cli update in site shell for a website)? Where will the updated WP-CLI version be installed? In the regular folder ~/Library/Application Support/Local/ with a symlink to /usr/local/bin/wp or somewhere else?
1 Like
This is great news @austinwendt. Thank you! PHP 8.3 is scheduled for release in November. Can we expect quicker support for 8.3 than 8.2 now with this new process?
1 Like
Interesting! We can repro that wp cli update throws errors for us as well, but we weren’t successful downgrading. We’ll dig in there. Ultimately, switching to PHP 8.0 and back to PHP 8.2 is what made the changes stick as that would force the php.ini to regenerate.
Yes, that is an officially supported process as of Local v6.6. The updated WP-CLI is stored in Local’s package contents, so Applications/Local/Contents/Resources/extraResources/bin/wp-cli. Shoutout to @adamperry (a member of our engineering team) on tracking down the issue - we think it is a bug that was introduced in WP-CLI. In their CLI_Command.php file, there’s this:
$php_binary = Utils\get_php_binary();
$process = Process::create( "{$php_binary} $temp --info {$allow_root}" );
$result = $process->run();
if ( 0 !== $result->return_code || false === stripos( $result->stdout, 'WP-CLI version' ) ) {
$multi_line = explode( PHP_EOL, $result->stderr );
WP_CLI::error_multi_line( $multi_line );
WP_CLI::error( 'The downloaded PHAR is broken, try running wp cli update again.' );
}
$php_binary = Utils\get_php_binary(); needs to be $php_bin = escapeshellarg( Utils\get_php_binary() ); to account for the space in the file path, so we’re going to submit a ticket to WP-CLI.
3 Likes
You’re welcome! Yes, expect PHP 8.3 support to be a quicker turnaround this time. 
5 Likes
@austinwendt Many thanks for the quick response and the detailed information. Maybe I should start reading the release notes a little more closely. 
Ha, no worries! If we’re doing things right, there’s a lot in there to skim through 
We already have a response back from WP-CLI and I think we’ll open a PR to address the issue: Update command doesn't escape php_binary path, update fails when path has spaces · Issue #5815 · wp-cli/wp-cli · GitHub
An update on that wp-cli bug - I’ve opened a PR, it’s been approved, and just waiting on someone to merge it! Hopefully that’ll fix the bug and we’ll be able to update wp-cli from any site regardless of PHP version.
4 Likes
One more update here - new PHP 8.2 binaries are out that include bundled Imagick for:
- macOS (Intel)
- macOS (Apple Silicon)
- Linux
No Imagick for Windows yet - we’re learning that this is a wider WordPress problem, as the community no longer builds Windows binaries for Imagick by default -
It seems like there is some community traction around getting it working, and a few brave souls who said they can get it to work… so we’ll chase it down!
2 Likes