I’m experiencing this issue as well. Clicking on ‘Open Site Shell’ doesn’t do anything, visually at least.
This is the biggest issue I’m having with Big Sur and on Apple Silicon.
Thanks for all the comments and adding your voices to this thread.
The team has been fixing a few other bugs and implementing a few features that should make Local easier to extend so we don’t have a specific ETA for when this issue with opening the site-shell will be fixed. We’ll be sure to update this thread when a fix has been released!
Are there any updates about it?
@ben.turner Are “new features” more important than fixing broken functionality? That seems backwards? There are several large issues that are not being fixed (this issue, macOS database connection, Imagick not installed) to prioritize new functionality, and that’s very disappointing. Please prioritize the fixing of existing yet broken functionality before introducing new features.
Hi @ben.turner and team, are there any updates on this? Anything you need us to help with in order to get a resolution to this issue?
Thanks everyone for your patience with this!
Thanks for offering to help! There’s not anything that can be done except wait a bit more while the team finishes up the fix and does some final QA.
They’re both important!
I know that it feels like there isn’t movement here with the Big Sur terminal issue, but it’s always hard trying to balance priorities of new features against bugs caused by changes to the underlying technology. Part of the issue with the Big Sur update is that it’s a new version of an OS. We’re devs too, and are hesitant to dive into a new OS the day that it’s released in case it breaks things and prevents us from working on Local.
The good news is that we have virtual machines and have the tooling to help work on the various OSes, but it does take time to account for all the different architectures that Local abstracts away.
This Big Sur terminal issue is definitely frustrating – even for me as a heavy terminal user, but there is a workaround for getting access to the sites’ shell. When one compares this issue against other issues that don’t have workarounds, or which affect more users than those running just one version of one OS, the team will likely prioritize the issue that has a larger impact.
An example of those kinds of issues would be one that you mention: not having imagemagik compiled for a specific version of PHP.
All that’s to say that we know the current workaround for opening a site shell in Big Sur sucks, but we have everything we need to fix it, as well as a version that’s almost ready to be released!
Only a few minor edits and this solution is great.
If using Local Beta you will also need to adjust the path to change
Thought I’d add my solution/work around here, I’ve almost always used this method as opposed to the “Open Site Shell” option, even pre-Lightning.
WP CLI allows you to add your own settings while running it, by adding a
wp-cli.local.php file to your WP root directory.
wp-cli.local.yml file add:
require: - wp-cli.local.php
wp-cli.local.php file add:
<?php define( 'DB_HOST', 'localhost:/Users/yourusername/Library/Application Support/Local/run/o-woLHJD_/mysql/mysqld.sock' ); error_reporting( E_ERROR ); define( 'WP_DEBUG', false );
You shouldn’t need to define the
DB_USER or the
DB_PASSWORD since it will inherit them from the
wp-config.php. However, if you do need them, then just copy it from
wp-config.php and define them in this file too.
Also, you don’t HAVE to add the error report or debugging lines, but if you don’t it will constantly squawk at you that the constants are already defined, amongst all other notices, not relevant to WP-CLI, it might kick out.
If you’re using the non-Lightning version, just replace the socket path with the IP and Socket, e.g.
You should then be able to open terminal regularly (not Open Site Shell), path into your WP install and then use WP CLI as you normally would.
Wanted to let this topic know that the latest Local Release should fix the “Open Site Shell” issue under Big Sur:
@ben.turner When will the update show in Local Beta? Currently on 5.9.5 and reports as up to date.
Thank you so much for following up on this thread for so long. This is a very important issue for someone like me, because I really don’t use local for WordPress development, I use it for craft CMS development. Because of that open site shell is a very useful feature for me to install composer and anything else I need on that. This is some thing that I love about Local, it has a very good UI that I’m able to go in and build a great website with a different CMS other than word press but still get the great benefits of local. Thank you so much.
This is one of those unseen “features” that the team has been working on, namely improving the release process so that it doesn’t take someone a full day to package up and release things. There’s possibly a bug or two here, but here’s the general gist:
- Local Stable and Beta versions are released and pushed up to the servers
- Users can manually download and install those versions
- After a bit of time (usually about a week) we release to the “autoupdater” which is basically a place where your version of Local can as “Is there an update?”
The reason that we stagger updating to the autoupdater is so that if there is a very serious bug that was missed in QA, it’s only experienced by users that actively install the latest version.
Still, I’m sure there are areas of improvement in all of this process, so thank you all for caring and helping to report issues like this – it really makes Local better!
Just to report that Open Site Shell now works in Big Sur with Local 5.9.6
This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.