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

[ben.turner]

I’m having trouble replicating, but I also noticed some odd things when taking a close look at my own .zshrc as well as @jb510’s .zshrc.

Something about this that feels like a $PATH issue, possibly relating to child-shells.

I’d be curious to know what your $PATH looks like. I used this to change the colons to new lines, which I think makes it easier to read. The top lines have a higher precedent than the lower lines:

echo $PATH | tr ':' "\n"

For me, I would have thought that Local’s config would put the Local site items as a higher precedent than anything else, but in actuality, there are a few items that are “put ahead” of those folders:

I think that the reason that there are repeated items in my PATH is due to the Local shell script using exec $SHELL (ie, creating a subshell) as opposed to just sourceing the file.

@jb510 can you try sourceing the “open shell script” instead of running it as a sub-shell? Specifically do:

1. In Local, click “Open Site Shell”. This will create the shell script.
2. Edit the file that was run using “open site shell”
3. Comment out the last line that says exec $SHELL
4. Save the file
5. In a non-Local shell, (ie, a new one) try running that script and see how that affects the $PATH

Here’s a screenshot to help visualize:

It’s important to note that when you click the “Open Site Shell” button within Local, the shell script is regenerated, so any edits you make to that script will be wiped out if you try to open the shell from Local.

The reason to try these things is to see if the act of creating a subshell (and therefore, reloading all of the zsh config) is causing issues with how things are being loaded.

[jb510]

Thank you @afragen, confirmation it’s not ZSH/OMZ is a big help. Still don’t know what’s causing it, but gives me hope I can find it in configs.

@ben.turner TY for continuing to try to help with this. I too feel it’s path or permission related. I thought @clay might have been on to something with codesigning being involved.

In this screenshot left side is first run. Default with the path echoed for reference.

I then opened up the shell script in VS Code and commented out the last exec. line.

I then opened a new shell (iterm new window, right side of screenshot). I ran the script, checked which php, , checked $PHPRC which appears unset.

I ran through it a second time. New terminal session, Checked exec still commented, ran script, ran ‘export’ and again it’s showing no PHPRC set.

[jb510]

@ben.turner argh, as soon as I hit send on that I realized I didn’t ‘source’ the script I ran it… redoing now.

[jb510]

So… that worked. Notably the path orders are different (as expected??).

[jb510]

Hurray (maybe?). If I comment out source .bash_profile from my .zshrc it works because it’s not prefacing all the paths with things like /usr/bin.

[jb510]

@afragen Does your .zshrc source .bash_profile like mine does? Entirely possible I added that years ago and forgot about it.

If it does, does your .bash_profile include sources like mine? Again, entirely possible I add those years ago and forgot about it… and possible maybe they ‘belonged’ somewhere else like .bashrc.

[afragen]

Here are my paths.

I do not source my old .bash_profile probably because I didn’t copy over that file when I set this M1 MBA.

[ben.turner]

Nice find! I think you’ve zeroed in on what’s wrong. Taking a look through the .bash_profile file, it seems like most of the PATH related configuration is already in the .zshrc file. You can probably hand move any configuration that you need over to the zshrc file and then remove the source ~/.bash_profile line.

[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.