WP-CLI in Site Shell emits PHP warnings

[weston]

Bug Summary

When I select PHP 8.0.0 and open Site Shell, running any WP-CLI command results in the following being printed to STDERR:

Cannot load Zend OPcache - it was already loaded

And then the command runs as expected with the output to STDOUT.

Additionally, when I have selected PHP 7 I get a much larger warning:

Failed loading /Applications/Local.app/Contents/Resources/extraResources/lightning-services/php-7.4.1+16/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/opcache.so:  dlopen(/Applications/Local.app/Contents/Resources/extraResources/lightning-services/php-7.4.1+16/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/opcache.so, 9): Symbol not found: _zif_display_disabled_function
  Referenced from: /Applications/Local.app/Contents/Resources/extraResources/lightning-services/php-7.4.1+16/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/opcache.so
  Expected in: flat namespace
 in /Applications/Local.app/Contents/Resources/extraResources/lightning-services/php-7.4.1+16/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/opcache.so
Xdebug requires Zend Engine API version 320190902.
The Zend Engine API version 420200930 which is installed, is newer.
Contact Derick Rethans at https://xdebug.org/docs/faq#api for a later version of Xdebug.

Warning: PHP Startup: imagick: Unable to initialize module
Module compiled with module API=20190902
PHP    compiled with module API=20200930
These options need to match
 in Unknown on line 0 

Again, this is printed to STDERR but then the expected output is going to STDOUT.

This is similarly what is output in PHP 7.3.5.

So the WP-CLI commands are working, but there are troublesome PHP warnings being emitted.

Steps to reproduce

Open Site Shell and run a WP-CLI command.

Environment Info

• MacOS Big Sur 11.6.3
• Nginx
• PHP 7.4.1 and 8.0.0
• Local 6.2.1+5711

Supporting info

The Local log just has messages related to MySQL.

[jtsternberg]

This is definitely still a thing.
Related links:

• WP CLI errors, "Failed loading ... opcache.so" "xdebug.so" and "Warning: PHP Startup: Unable to load dynamic library ... imagick.so" code unsigned - #29 by ipstenu
• Local Lightning PHP 8 "Open Site Shell" does not work on ZSH
• How do I run wp-cli without clicking Open Site Shell? - #2 by alexclst
• Site shell not using LocalWP's PHP

I had to build a crazy hack with a wp alias that runs Local’s variables before every wp cli call. Dot-Files/wplocal at master · jtsternberg/Dot-Files · GitHub (and Dot-Files/_wplocalgenerate at master · jtsternberg/Dot-Files · GitHub)

LocalWP team, when will this be addressed?

[austinwendt]

@jtsternberg Thanks for using Local!

I read through your linked threads just to make sure I’m up to speed. I’m not aware of any recent Local-specific issues or threads on this issue; from my understanding, all of these threads boiled down to machine-specific issues with the shell config (it seems reordering of $PATH variables was the most reliable fix - WP CLI errors, "Failed loading ... opcache.so" "xdebug.so" and "Warning: PHP Startup: Unable to load dynamic library ... imagick.so" code unsigned - #31 by afragen - this post was helpful!).

Have you looked into your shell config or the order of your $PATH variables? Also, what machine/OS and version of Local are you on?

[ben.turner]

As part of the process of modernizing our PHP services those warnings should be gone. I know that this is an old bug report, so I’d love to close it out if we can.

While on the latest version of Local and installing the latest minor version of PHP (the op had 7.4.1, but the latest minor version of that line is 7.4.30) – do you still get errors?

I’ve done that here, and none of my sites are emitting warnings/errors:

@weston @jtsternberg – If you have the latest version of Local and the latest versions of PHP, do you still get warnings?

If do get errors, it’s likely related to one of a couple things:

• Something (plugin/theme) is requiring Imagick, but that is missing. Some services haven’t been bundled with ImageMagick. It depends on the OS and version of PHP, but that’s likely what Warning: PHP Startup: imagick: Unable to initialize module is mentioning. Core WP has fallback code for environments without Imagick, so it is possible that my test in the screenshot above doesn’t cover your specific site’s code.

• Local’s PHP configuration is colliding with a system-installed version. This is likely what’s related to what @austinwendt mentions as having something to do with the $PATH variable, and what binaries have the most precedent.

If you are still having issues, I’d love to get an idea of what’s in your $PATH to see if something is colliding.

Can you run these commands in Local site shell to get us more info?

which php
echo $PATH | tr ':' '\n'

Here’s what that looks like on my system:

[jtsternberg]

all of these threads boiled down to machine-specific issues with the shell config

Yes, my issues are directly related to the below line living in my .zshenv file.

# Set PATH, MANPATH, etc., for Homebrew.
eval "$(/opt/homebrew/bin/brew shellenv)"

Not using homebrew php is not an option for me. I have tried moving that eval line to several places, and no matter where I put it, I get things like this when running wp commands from the “site shell”:

The only way those go away and wp works correctly is A) if I comment out the homebrew shellenv eval line, or B) use my hacked wplocal alias which preloads the localwp script data before each run of the wp command. If you look through the Github links I linked to, hopefully it’s clear.

Maybe what’s required is for localwp to create it’s own wp alias which does this for us, and “guarantees” the right paths with each run.

You can see my alias works, whereas vanilla wp does not:

The way I see it, localwp should be more resilient to user’s specific PATH setups.

Here is my php/path output:

what machine/OS and version of Local are you on?
MBP Apple M2 Max, macOS Ventura 13.2.1 (22D68), and LocalWP 6.6.1+6281

installing the latest minor version of PHP (the op had 7.4.1, but the latest minor version of that line is 7.4.30) – do

For this particular site, PHP is 8.0.22. System version is 8.0.27.
For another site, it’s 7.4.30.
They all produce similar errors.

I’ve done that here, and none of my sites are emitting warnings/errors:

Are you using hombrew and homebrew’s php?

[ben.turner]

@jtsternberg

Are you using hombrew and homebrew’s php?

I do have Homebrew installed, along with PHP, but I’ve never needed to use that line that you mention:

# Set PATH, MANPATH, etc., for Homebrew.
eval "$(/opt/homebrew/bin/brew shellenv)"

What’s curious to me is that even without that ...shellenv command, php gets added to my PATH and I have access to the man pages for brew’s version of PHP.

Looking at the screenshot for which php – it looks like that wasn’t run within a Local site shell – is that right? I say that because I’m not seeing any entries for Local’s php binaries.

Lastly, in the first screenshot, with the errors in a Local site shell, it looks like maybe the Local version of PHP isn’t correct for your machine (ie, you have an M2 mac, but the Local version is for intel mac)

...incompatible architecture ( have 'x86_64', need 'arm64')

I wonder if you need to re-download the PHP lightning service?

Couple of questions –

• Since you mention having an M2 – when you installed Local, did you use the “Apple Silicon MacOS” link on the Releases page ?
• If you do have the arm64 build of Local, can you try re-downloading the PHP lightning service?

Allowing for a quick “re-download PHP” might be an interesting improvement, but until then, to re-download a service, you’ll need to:

• quit Local
• delete the PHP Lightning Service folder
• Start Local
• Access the site in question and re-download PHP

[jtsternberg]

Thanks for continuing to investigate this with me. Some updates:

1. when you installed Local, did you use the “Apple Silicon MacOS” link on the Releases page ?

No, the app was installed via the migration wizard from my intel machine. I reinstalled the Apple Silicon version.

2. If you do have the arm64 build of Local, can you try re-downloading the PHP lightning service?

I went ahead and deleted all the php services in lightning-services. Then I restarted (the newly downloaded version) of Local, and triggered the re-download of each php service I needed from each site.

3. What’s curious to me is that even without that ...shellenv command, php gets added to my PATH and I have access to the man pages for brew’s version of PHP.

I commented out the eval "$(/opt/homebrew/bin/brew shellenv)" line, replaced the following lines:

PATH=$PATH=$(brew --prefix coreutils)/libexec/gnubin
PATH=$PATH:$(brew --prefix)/share/zsh/site-functions
PATH=$PATH:$(brew --prefix)/libexec/gnubin:/usr/local/bin:

with the hard-coded versions:

PATH=$PATH=/opt/homebrew/opt/coreutils/libexec/gnubin
PATH=$PATH:/opt/homebrew/share/zsh/site-functions
PATH=$PATH:/opt/homebrew/libexec/gnubin:/usr/local/bin:

---

---

SO, after updating the app/services (number 1 and 2 above), the errors went away related to the wrong architecture. As long as the Local site was using the same PHP minor version (8.0.X) as my machine (brew), then there were no errors. When I opened site shell for the 7.4.X site, I still got errors:

those errors:

Failed loading /Users/JT/Library/Application Support/Local/lightning-services/php-7.4.30+5/bin/darwin-arm64/lib/php/extensions/no-debug-non-zts-20190902/opcache.so:  dlopen(/Users/JT/Library/Application Support/Local/lightning-services/php-7.4.30+5/bin/darwin-arm64/lib/php/extensions/no-debug-non-zts-20190902/opcache.so, 0x0009): symbol not found in flat namespace '_instanceof_function'
Failed loading /Users/JT/Library/Application Support/Local/lightning-services/php-7.4.30+5/bin/darwin-arm64/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so:  dlopen(/Users/JT/Library/Application Support/Local/lightning-services/php-7.4.30+5/bin/darwin-arm64/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so, 0x0009): symbol not found in flat namespace '_instanceof_function'

My wplocal alias still works though…

When I do number 3 above, then things work as expected:

---

I’m going to roll w/ the eval "$(/opt/homebrew/bin/brew shellenv)" bit commented out for now, see if I run into any issues with my other tools. However, I’m still interested in Local having more resilience against these PATH issues.

[jtsternberg]

Update: I put the eval "$(/opt/homebrew/bin/brew shellenv)" bit in the .zprofile file instead of .zshenv. That seems to address the issue, though I’m still not entirely sure if it’s necessary. After doing so, site shell works as it should.

[afragen]

Just to let y’all know that you can install/update Local or Local Beta via Homebrew.

brew install local
or
brew install local-beta

It will automatically install the correct binary for your machine Intel or ARM.

[ben.turner]

It sounds like you’re closing in on a working solution.

Some observations: In that first screenshot, it looks like the brew version of PHP is being used instead of Local’s:

It’s almost like the shell is using the system version of PHP, but with the configuration and modules for Local’s version of PHP:

My guess is that the wplocal alias works, because the php location in PATH isn’t being overwritten.

Commenting out that block seems to indicate that it’s the code responsible for that behavior. I’m guessing that the reason moving that block of code to .zshenv works is that this file is only evaluated once, when logging into the system, wherase, .zshrc is evaluated every time a terminal is opened.

Why “every time a terminal is opened” is an important thing to note is that if you look in the shell script Local runs (.../ssh-entry/xxxyyyzzz.sh), the last line basically spawns a new sub-shell:

[figureone]

My current workaround for this: comment out exec $SHELL at the bottom of the Local shell script, and then in any terminal session, run source ~/Library/Application\ Support/Local/ssh-entry/xxxyyyzzz.sh (replacing xxxyyyzzz with your site id). This applies everything from the Local shell script after .zshrc which puts the Local PATH values first, before brew php and everything else.

I’m a new Local user so I’m not sure of the motivation for launching the shell script in the current way (via the “Open site shell” link in the GUI), but @ben.turner it might be worth pursuing using this source method in a new terminal session instead of spawning a new shell at the end of the script, to avoid PATH conflicts on varied setups.

[sebastian]

Another to add to the mix. Same error latest updated version (Version 7.2.1+6433) But at least you can now copy the version number of local…