WP CLI errors, "Failed loading ... opcache.so" "xdebug.so" and "Warning: PHP Startup: Unable to load dynamic library ... imagick.so" code unsigned

[ben.turner]

It looks like this may have been due to the shell’s path not giving precedence to Local’s version of PHP.

Can you take a look at the shell configuration files (I’m guessing .zshrc since this is the default on new macs) and see if you can adjust things so that Local’s PHP binary is being used?

[jb510]

Agreed on all accounts.

I think it’s unfortunate to have to rely on path precedence here to use the correct version of PHP. It just seems (is) fragile… but it also seems like it might be necessarily so. The only other thing I can think of would be to alias PHP to the correct version in hopes that would override searching the paths (I haven’t tried this and am not certain that’d work, just an idea I was going to try).

In my case, I definitely don’t need .bash_profile sourced anymore, if ever.

[ben.turner]

@afragen – peeking over your shoulder a bit, I see that on line 101 of .zshrc you have

export XDEBUG_CONFIG="idekey=VSCODE"

What’s that used for? Are you debugging wpcli scripts within VS Code?

[afragen]

I believe I came across this here, https://tighten.co/blog/configure-vscode-to-debug-phpunit-tests-with-xdebug/

I think the preferred method would be the following at present. https://github.com/pixeljar/local-addon-xdebug-vscode/pull/14

[ipstenu]

Sorry about my delay in response. I do not have .bash_profile sourced in my ZSH (which is also OMZ flavoured).

Path is:

» echo $PATH | tr ':' "\n"
/opt/homebrew/bin
/usr/local/sbin
/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin
/opt/X11/bin
/Users/ipstenu/bin

And I see similarly homebrew is at the top when I check SSH’d in to local

/opt/homebrew/bin
/Applications/Local.app/Contents/Resources/extraResources/bin/composer/posix
/Applications/Local.app/Contents/Resources/extraResources/bin/wp-cli/posix
/Users/ipstenu/Library/Application Support/Local/lightning-services/php-7.4.1+14/bin/darwin/bin
/Users/ipstenu/Library/Application Support/Local/lightning-services/mysql-5.7.28+4/bin/darwin/bin
/opt/homebrew/bin
/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin
/opt/X11/bin
/Users/ipstenu/bin
/Users/ipstenu/bin

FWIW, not using HomeBrew isn’t an option for me

[afragen]

Just a little more info on my M1 Mac and why it might work. I have set Terminal.app to run in Rosetta. This installed Homebrew in /usr/local not /opt.

Not sure this makes a difference @ipstenu but it sorta popped out to me.

[ipstenu]

iTerm2 and I did not mess with the install because the Homebrew notes say this:

This script installs Homebrew to its preferred prefix ( /usr/local for macOS Intel, /opt/homebrew for Apple Silicon)

So. I’m on an M1, that means I should use /opt/homebrew.

I’m going to try a full uninstall and reinstall though, and clear out some old casks I don’t need anymore.

[ipstenu]

Okay here’s a review:

1. Uninstalled everything homebrew, wp-cli on Local works
2. Reinstall homebrew (in /opt/homebrew/), wp-cli on Local works
3. Reinstall most packages (excluded PHP and about 4 other casks I’m not actively using, like Ruby), wp-cli on Local works
4. Reinstall homebrew PHP, wp-cli on Local works

So. Something was not happy with Homebrew being there first I guess, which is fine for this fix. But it is rather fragile

[afragen]

I just had to re-install my OS, don’t ask. But when I reinstalled Local I wasn’t getting the Site Shell version of apps. I discovered that my /opt/homebrew/bin was listed first in the $PATH and moving it to last worked.

I had this order set in my ~/.zshrc profile. Now I’m back to working again.

[ipstenu]

Huh, last would make sense as to why an uninstall/reinstall (which moves it to the end) worked. Fragile indeed.

[afragen]

@ipstenu I found that if I did the following

[stuff deleted]

I think what may be safer would be to add

/opt/homebrew/bin
/opt/homebrew/sbin

to /etc/paths

NB: The above seems to work without issues.