PHP 8.1.29 was automatically downloaded but I can’t download PHP 8.2.20 and 8.3.8. I’m running macOS 13.6.7 and Local 9.0.4. Any ideas why it doesn’t work?
3 Likes
Thank you for the heads-up, @emmtre! We’ve discovered what was missing and stitched that up. Things should be up to date soon here. I just quit and restarted and now I’m seeing those options:
i
3 Likes
Great and quickly fixed! Many thanks to the whole team for this new release. I can confirm that it works here as well now.
I’ve updated a whole bunch of websites. I had some issues with the group commands (Start, Restart, Stop X sites) to begin with.
But it seems to work now that I’ve restarted the Local app a few times. So it was probably just some gremlins.
Below are some of the repeated nginx error logs for the sites that didn’t respond to group commands. Probably just something temporary after the php updates as I haven’t experienced this again.
2024/06/26 17:29:25 [emerg] 5692#0: bind() to 0.0.0.0:10039 failed (48: Address already in use)
2024/06/26 17:29:25 [emerg] 5692#0: bind() to 0.0.0.0:10039 failed (48: Address already in use)
2024/06/26 17:29:25 [emerg] 5692#0: bind() to 0.0.0.0:10039 failed (48: Address already in use)
2024/06/26 17:29:25 [emerg] 5692#0: bind() to 0.0.0.0:10039 failed (48: Address already in use)
2024/06/26 17:29:25 [emerg] 5692#0: bind() to 0.0.0.0:10039 failed (48: Address already in use)
2024/06/26 17:29:25 [emerg] 5692#0: still could not bind()
2024/06/26 17:29:35 [emerg] 5735#0: bind() to 0.0.0.0:10054 failed (48: Address already in use)
2024/06/26 17:29:35 [emerg] 5735#0: bind() to 0.0.0.0:10054 failed (48: Address already in use)
2024/06/26 17:29:35 [emerg] 5735#0: bind() to 0.0.0.0:10054 failed (48: Address already in use)
2024/06/26 17:29:35 [emerg] 5735#0: bind() to 0.0.0.0:10054 failed (48: Address already in use)
2024/06/26 17:29:35 [emerg] 5735#0: bind() to 0.0.0.0:10054 failed (48: Address already in use)
2024/06/26 17:29:35 [emerg] 5735#0: still could not bind()
2024/06/26 17:29:43 [emerg] 5768#0: bind() to 0.0.0.0:10059 failed (48: Address already in use)
2024/06/26 17:29:43 [emerg] 5768#0: bind() to 0.0.0.0:10059 failed (48: Address already in use)
2024/06/26 17:29:43 [emerg] 5768#0: bind() to 0.0.0.0:10059 failed (48: Address already in use)
2024/06/26 17:29:43 [emerg] 5768#0: bind() to 0.0.0.0:10059 failed (48: Address already in use)
2024/06/26 17:29:43 [emerg] 5768#0: bind() to 0.0.0.0:10059 failed (48: Address already in use)
2024/06/26 17:29:43 [emerg] 5768#0: still could not bind()
2024/06/26 17:29:49 [emerg] 5784#0: bind() to 0.0.0.0:10069 failed (48: Address already in use)
2024/06/26 17:29:49 [emerg] 5784#0: bind() to 0.0.0.0:10069 failed (48: Address already in use)
2024/06/26 17:29:49 [emerg] 5784#0: bind() to 0.0.0.0:10069 failed (48: Address already in use)
2024/06/26 17:29:49 [emerg] 5784#0: bind() to 0.0.0.0:10069 failed (48: Address already in use)
2024/06/26 17:29:49 [emerg] 5784#0: bind() to 0.0.0.0:10069 failed (48: Address already in use)
2024/06/26 17:29:49 [emerg] 5784#0: still could not bind()
1 Like
Nice! Thanks for taking these for a spin @emmtre !
This was a fun batch of changes because I had never dug too deep into the environment configuration (ImageMagick, Imagick) that powers WP’s media editing functionality.
It’s pretty cool how defensive WP is written such that even when Local’s PHP versions didn’t come compiled with AVIF support, WP still allowed you to upload and use the image, even if you couldn’t edit it.
1 Like
Thanks for reporting! I’ve noticed this too occasionally, though I don’t know yet what the cause is. I have a couple of hunches around where to look, but just need more time!
1 Like
Yeah, I’m still trying to catch up on WordPress 6.5 with AVIF support and learning more and more as I go…
I think I found the cause to my problems. The problematic sites in the group had some stubborn persistent sockets even when stopped. The sockets were all created the first time the group commands didn’t work. I managed to delete them when the sites were stopped and Local not running. No more messages in the nginx error logs and it seems to be working again.
sudo rm -f /Users/xxxxxx/Library/Application\ Support/Local/run/QeMpq8kSm/php/php-fpm.socket
1 Like
Not that you asked, but you seem like a curious person. If you want to get really geeky, here is my ~2min elevator-pitch summary I included on our internal PR to orient other devs around how this extension needs to be compiled into PHP:
- On Feb, 23rd, WordPress included support for the AVIF image format. If a system isn’t compiled with AVIF support, WP has polyfills to allow it to read this image and obtain basic metadata about the image. The allows WP to accept AVIF images for uploads as well as insert them into content. Certain features like cropping and scaling will not work if PHP isn’t compiled with AVIF support.
- AVIF is a newish, open, high compression, image format
- AVIF competes with HEIC, another high-compression format. Adoption of HEIC is hampered (especially in the WP space) because it requires a license and royalty payments
- AVIF support as it relates to WP, means either AVIF showing as supported under the GD extension OR as an accepted format that ImageMagick handles.
- When compiling PHP, the GD extension will support AVIF if libavif is configured on a system
- When compiling Imagick, even if libavif is present on a system, ImageMagick will not pick up AVIF support. Instead, ImageMagick requires libheif and libaom in order to support AVIF images. This is likely due to ImageMagick’s use of heic and how heic already supports interacting with AVIF formats.
You can check for AVIF support within a PHP environment by inspecting the “GD” and “Imagick” sections of PHP info. So either from the command line with php --info or from the “Details” link next to the PHP line of the site overview of Local.
3 Likes
Many thanx for the elevator-pitch summary. I really appreciate the info and I didn’t know ImageMagick uses heic. As mentioned in the WordPress post the Media Handling section in Site Health is also very useful. I’ve had my fair share of problems with some media plugins and web hosts with weird php configs.
1 Like
One other gotcha (at least for me) is that sometimes the cli version of PHP will act differently than php-fpm, which is what Nginx/Apache will typically use on *nix systems. It’s good to remember that there can be different php.ini files as well as slightly different PATH variables.
While doing this work, I was surprised that running wp media regenerate <id> wasn’t working for an avif image, despite the Site Health page indicating that AVIF was supported. It turned out that I wasn’t correctly adding the various ImageMagick libs to the PATH for the php-cli config, but php-fpm was correctly configured out-of-the-box.
Also, your screenshot-fu is strong – those are some perfectly framed images! 
1 Like
Arghhh… Thank you for the reminder. I completely forgot to update symlinks and paths after installing the new php versions.
It’s incredibly easy and fast to make nice screenshots with a screen capturing tool like CleanShot and also to share them. 
1 Like