The bundled WP-CLI version in Local 7.2.0 is still 2.7.1 but since the preferred PHP version 8.1.22 is copied now to the Application Support folder you can’t update WP-CLI with the shell command wp cli update because of the space in the path.
Can you manually replace the wp-cli.phar in the Local app directory to install WP-CLI version 2.8.1 without breaking the code signing or something else? Any news about the WP-CLI bug and the pull request that was rejected due to problem with esc_cmd()?
Agh. This bug with WP-CLI not taking the space is frustrating. No, no additional feedback from the WP-CLI team other than some additional functional testing we could have added. Based on the convos in their Slack, they are cutting a new release on Monday (18 Sept) and we will incorporate that into Lcoal.
We’ll also have to follow up in their Slack channel to see if we can get some traction/help on pushing that PR across the line. I didn’t think about the impact of moving those PHP files to a new location potentially breaking the wp cli update command, but that is our plan for file structure going forward, so we’ll have to address it.
Sorry for the break here - we’ll test it out with the latest WP CLI release on Monday!
@austinwendt No worries. Sometimes you have to navigate around the obstacles to make some progress. What about moving the WP-CLI folder out of the app to the new location and file structure as well? I guess we have to wait and see what the new WP-CLI update brings next week. I hope we can get some help from the WordsPress community to prioritize and fix this bug. Local and macOS can’t be the only app and platform affected from this bug.
I like that idea - definitely an option. Once we’ve got the new update, I want to verify the issue still exists, and then drop Adam’s PR in the community channel to see if we can get guidance. A single test failed in the test suite but without much detail on what was actually happening… we hadn’t contributed to WP-CLI before, so even more guidance on how to troubleshoot that failure would help us keep moving.
I’ve never seen that on any machine and it’s not in accordance with Apple’s developer guidelines. The symlink must have been created manually or by Homebrew or some similar tool.
Nice! That took them a bit longer than expected - I’ll get this over to the engineers and we can get it bumped ASAP. Then, we can verify the issue with file pathing still exists and get some community help on getting it merged.
Yes, the optional step above to create the symlink in /usr/local/bin/ will make it global. I try to containerize and make it as simple as possible to avoid problems. But you can add the path to your WP-CLI installation to the terminal profile and use whatever version you want. There are many different scenarios depending on your set-up and development tools. I haven’t tried to use the Homebrew version in Local websites shell if even possible.