# WP-CLI in Site Shell emits PHP warnings **URL:** \ **Category:** Bugs\ **Tags:** mac, wp-cli, site-shell\ **Created:** [February 2, 2022, 12:21am UTC](https://community.localwp.com/t/wp-cli-in-site-shell-emits-php-warnings/30125 "2022-02-02T00:21:03Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![weston](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/weston/32/15212_2.png) [@weston](https://community.localwp.com/u/weston)\ **Post date:** [February 2, 2022, 12:21am UTC](https://community.localwp.com/t/wp-cli-in-site-shell-emits-php-warnings/30125/1 "2022-02-02T00:21:03Z")
# 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: ```auto 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: ```auto 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. ---
**Author:** ![jtsternberg](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/jtsternberg/32/4837_2.png) [@jtsternberg](https://community.localwp.com/u/jtsternberg)\ **Post date:** [February 24, 2023, 3:22am UTC](https://community.localwp.com/t/wp-cli-in-site-shell-emits-php-warnings/30125/2 "2023-02-24T03:22:23Z")
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](http://community.localwp.com/t/wp-cli-errors-failed-loading-opcache-so-xdebug-so-and-warning-php-startup-unable-to-load-dynamic-library-imagick-so-code-unsigned/22719/29) - [Local Lightning PHP 8 "Open Site Shell" does not work on ZSH](http://community.localwp.com/t/local-lightning-php-8-open-site-shell-does-not-work-on-zsh/30510/) - [How do I run wp-cli without clicking Open Site Shell? - #2 by alexclst](http://community.localwp.com/t/how-do-i-run-wp-cli-without-clicking-open-site-shell/33087/2) - [Site shell not using LocalWP's PHP](http://community.localwp.com/t/site-shell-not-using-localwps-php/35202) 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](https://github.com/jtsternberg/Dot-Files/blob/master/bin/wplocal) (and [Dot-Files/\_wplocalgenerate at master · jtsternberg/Dot-Files · GitHub](https://github.com/jtsternberg/Dot-Files/blob/master/bin/_wplocalgenerate)) LocalWP team, when will this be addressed? ---
**Author:** ![austinwendt](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/austinwendt/32/13912_2.png) [@austinwendt](https://community.localwp.com/u/austinwendt)\ **Post date:** [February 24, 2023, 3:07pm UTC](https://community.localwp.com/t/wp-cli-in-site-shell-emits-php-warnings/30125/3 "2023-02-24T15:07:50Z")
@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](http://community.localwp.com/t/wp-cli-errors-failed-loading-opcache-so-xdebug-so-and-warning-php-startup-unable-to-load-dynamic-library-imagick-so-code-unsigned/22719/31) - 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? ---
**Author:** ![ben.turner](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/ben.turner/32/5366_2.png) [@ben.turner](https://community.localwp.com/u/ben.turner)\ **Post date:** [February 24, 2023, 3:51pm UTC](https://community.localwp.com/t/wp-cli-in-site-shell-emits-php-warnings/30125/4 "2023-02-24T15:51:28Z")
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](https://localwp.com/releases/) 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: ![Image 2023-02-24 at 7.43.22 AM](https://us1.discourse-cdn.com/flex019/uploads/lwpforums/original/3X/b/9/b949bf1832a1ea5da3114200a7fb8a412b11b778.jpeg) @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? ```auto which php echo $PATH | tr ':' '\n' ``` Here’s what that looks like on my system: ![Image 2023-02-24 at 7.50.30 AM](https://us1.discourse-cdn.com/flex019/uploads/lwpforums/original/3X/3/8/388226e9fc3bda09561361522ca167d352c6054c.jpeg) ---
**Author:** ![jtsternberg](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/jtsternberg/32/4837_2.png) [@jtsternberg](https://community.localwp.com/u/jtsternberg)\ **Post date:** [February 24, 2023, 4:20pm UTC](https://community.localwp.com/t/wp-cli-in-site-shell-emits-php-warnings/30125/5 "2023-02-24T16:20:51Z")
> 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. ```auto # 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”: ![Markup 2023-02-24 at 11.06.08](https://us1.discourse-cdn.com/flex019/uploads/lwpforums/original/3X/6/a/6a6700d3c7070a7876ec1e6bb076baf15760b6dd.png) 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`](https://github.com/jtsternberg/Dot-Files/blob/master/bin/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: ![Markup 2023-02-24 at 11.11.05](https://us1.discourse-cdn.com/flex019/uploads/lwpforums/original/3X/5/5/5513625522e7c0dcb7e1fc601cc89c4f6f26bbe3.png) The way I see it, localwp should be more resilient to user’s specific PATH setups. Here is my php/path output: ![image](https://us1.discourse-cdn.com/flex019/uploads/lwpforums/original/3X/4/f/4ffa0bb6177f768d62bd3e896dd6849a42e528f9.jpeg) > 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 > ![image](https://us1.discourse-cdn.com/flex019/uploads/lwpforums/original/3X/c/2/c2f192235295d1e4282e00aa1a1effd843646d8a.png) > 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? ---
**Author:** ![ben.turner](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/ben.turner/32/5366_2.png) [@ben.turner](https://community.localwp.com/u/ben.turner)\ **Post date:** [February 24, 2023, 6:16pm UTC](https://community.localwp.com/t/wp-cli-in-site-shell-emits-php-warnings/30125/6 "2023-02-24T18:16:00Z")
> [@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: ```auto # Set PATH, MANPATH, etc., for Homebrew. eval "$(/opt/homebrew/bin/brew shellenv)" ``` ![Image 2023-02-24 at 8.45.47 AM](https://us1.discourse-cdn.com/flex019/uploads/lwpforums/original/3X/4/7/4704dec85fff0481093174180b9e0a5fa27f7fb9.jpeg) 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) ```auto ...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](https://localwp.com/releases/) ? - 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 ![Image 2023-02-24 at 10.11.51 AM](https://us1.discourse-cdn.com/flex019/uploads/lwpforums/original/3X/a/9/a9c711e6cb8676f573f93f1ec7b701a3a3afad03.jpeg) ---
**Author:** ![jtsternberg](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/jtsternberg/32/4837_2.png) [@jtsternberg](https://community.localwp.com/u/jtsternberg)\ **Post date:** [February 24, 2023, 7:17pm UTC](https://community.localwp.com/t/wp-cli-in-site-shell-emits-php-warnings/30125/7 "2023-02-24T19:17:47Z")
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](https://localwp.com/releases/) ? No, the app was installed via the migration wizard from my intel machine. I reinstalled the Apple Silicon version. 1. > 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. 1. > 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: ```auto 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: ```auto 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: ![Markup 2023-02-24 at 13.53.25](https://us1.discourse-cdn.com/flex019/uploads/lwpforums/original/3X/d/2/d21121b1d9a054d507ab12ea8a910937b9915f6f.png) those errors: ```auto 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… ![image](https://us1.discourse-cdn.com/flex019/uploads/lwpforums/original/3X/4/2/4276c9329f5bd5a6ab80bc8052e5a3292e3b1ddf.jpeg) ## When I do number 3 above, then things work as expected: ![Markup on 2023-02-24 at 13:59:15](https://us1.discourse-cdn.com/flex019/uploads/lwpforums/original/3X/6/7/67419d275bc0e703ded0144f899a842f724f6554.jpeg) * * * 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. ---
**Author:** ![jtsternberg](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/jtsternberg/32/4837_2.png) [@jtsternberg](https://community.localwp.com/u/jtsternberg)\ **Post date:** [February 24, 2023, 7:21pm UTC](https://community.localwp.com/t/wp-cli-in-site-shell-emits-php-warnings/30125/8 "2023-02-24T19:21:54Z")
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. ---
**Author:** ![afragen](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/afragen/32/31_2.png) [@afragen](https://community.localwp.com/u/afragen)\ **Post date:** [February 24, 2023, 7:30pm UTC](https://community.localwp.com/t/wp-cli-in-site-shell-emits-php-warnings/30125/9 "2023-02-24T19:30:30Z")
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. ---
**Author:** ![ben.turner](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/ben.turner/32/5366_2.png) [@ben.turner](https://community.localwp.com/u/ben.turner)\ **Post date:** [February 27, 2023, 3:28pm UTC](https://community.localwp.com/t/wp-cli-in-site-shell-emits-php-warnings/30125/10 "2023-02-27T15:28:25Z")
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: ![Image 2023-02-27 at 7.11.05 AM](https://us1.discourse-cdn.com/flex019/uploads/lwpforums/original/3X/b/0/b0a2bcf6155c8f1fc5ec1aab8df7811658d425ee.jpeg) 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: ![Image 2023-02-27 at 7.24.23 AM](https://us1.discourse-cdn.com/flex019/uploads/lwpforums/original/3X/4/1/41fd7596205177036f884d5bbe2e5f1a70af0101.jpeg) ---
**Author:** ![figureone](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/figureone/32/18501_2.png) [@figureone](https://community.localwp.com/u/figureone)\ **Post date:** [June 2, 2023, 11:44pm UTC](https://community.localwp.com/t/wp-cli-in-site-shell-emits-php-warnings/30125/11 "2023-06-02T23:44:16Z")
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. ---
**Author:** ![sebastian](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/sebastian/32/9095_2.png) [@sebastian](https://community.localwp.com/u/sebastian)\ **Post date:** [October 4, 2023, 11:04pm UTC](https://community.localwp.com/t/wp-cli-in-site-shell-emits-php-warnings/30125/12 "2023-10-04T23:04:09Z")
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… ---
**Author:** ![system](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/system/32/1_2.png) [@system](https://community.localwp.com/u/system)\ **Post date:** [February 2, 2024, 12:21am UTC](https://community.localwp.com/t/wp-cli-in-site-shell-emits-php-warnings/30125/13 "2024-02-02T00:21:49Z")
This topic was automatically closed after 730 days. New replies are no longer allowed.