Non standard webroot crashes "open site shell"

I changed the webroot of my local site because i use bedrock with local. There’s a post here in this community explaining how to bring bedrock into local.
So i changed the document root: it’s not longer app/public but app/bedrock/web. With that change the open site shell script is not working correctly anymore: it always tries to change directory into app/public. when i now modify the script behind the open site shell script, it doesn’t work, because it seems, the script is always generated anew, when the button is clicked.

Anyone an idea, how i could make this work again?

Hi @snr - welcome to the Local community! :wave:

Thanks for your question. I read through the thread you shared - did you happen to try the different suggestions in the comments there?

It looks like there’s maybe a few more steps required outside of just changing that document root.

If you have tried those and it still isn’t working, let me know & I’ll bring in more support from the Local team & those experienced with bedrock.



Hi @sammunoz ,
thanks for your hint. I checked the other steps sketched in the thread, but it didn’t change the broken open site shell button.
Thanks in advance for your help,

Hi @snr

Would you like to share some screenshots of your site.conf.hbs, .env file and Local app settings?

Additionally, what OS and Local version are you on?

Hi @Nick-B ,

I’m on MacOS Monterey 12.4, with local 6.6.1+6281

this is my site.conf.hbs

upstream php {
  {{#each fastcgi_servers}}
  server {{this}};

server {
  listen {{port}};
    root "/Users/xxxx/dev/webs/xxxx.local/app/bedrock/web";

    index index.php index.html index.htm;

    # Generic restrictions for things like PHP files in uploads
  include includes/restrictions.conf;

  # Gzip rules
  include includes/gzip.conf;

  # WordPress Rules
    {{#unless site.multiSite}}
    include includes/wordpress-single.conf;
    include includes/wordpress-multi.conf;

  # Fixes the _WP Admin_ link in the Local UI for bedrock
  rewrite ^/(wp-admin.*)$ $scheme://$http_host/wp/$1 permanent;

  # Forward 404's to WordPress
  error_page 404 = @wperror;
  location @wperror {
    rewrite ^/(.*)$ /index.php?q=$1 last;

  # Static file rules
  location ~* \.(?:css|js)$ {
        access_log        off;
        log_not_found     off;
        add_header        Cache-Control "no-cache, public, must-revalidate, proxy-revalidate";

    location ~* \.(?:jpg|jpeg|gif|png|ico|xml)$ {
        access_log        off;
        log_not_found     off;
        expires           5m;
        add_header        Cache-Control "public";

    location ~* \.(?:eot|woff|woff2|ttf|svg|otf) {
        access_log        off;
        log_not_found     off;

        expires           5m;
        add_header        Cache-Control "public";

        # allow CORS requests
        add_header        Access-Control-Allow-Origin *;

    # PHP-FPM
  location ~ \.php$ {
    try_files $uri =404;

    fastcgi_split_path_info ^(.+\.php)(/.+)$;

    fastcgi_param   QUERY_STRING            $query_string;
    fastcgi_param   REQUEST_METHOD          $request_method;
    fastcgi_param   CONTENT_TYPE            $content_type;
    fastcgi_param   CONTENT_LENGTH          $content_length;

    fastcgi_param   SCRIPT_FILENAME         $document_root$fastcgi_script_name;
    fastcgi_param   SCRIPT_NAME             $fastcgi_script_name;
    fastcgi_param   PATH_INFO               $fastcgi_path_info;
    fastcgi_param   PATH_TRANSLATED         $document_root$fastcgi_path_info;
    fastcgi_param   REQUEST_URI             $request_uri;
    fastcgi_param   DOCUMENT_URI            $document_uri;
    fastcgi_param   DOCUMENT_ROOT           $document_root;
    fastcgi_param   SERVER_PROTOCOL         $server_protocol;

    fastcgi_param   GATEWAY_INTERFACE       CGI/1.1;
    fastcgi_param   SERVER_SOFTWARE         nginx/$nginx_version;

    fastcgi_param   REMOTE_ADDR             $remote_addr;
    fastcgi_param   REMOTE_PORT             $remote_port;
    fastcgi_param   SERVER_ADDR             $server_addr;
    fastcgi_param   SERVER_PORT             $server_port;
    fastcgi_param   SERVER_NAME             $host;

    fastcgi_param   HTTPS                   $fastcgi_https;

    fastcgi_param   REDIRECT_STATUS         200;

    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

    fastcgi_pass php;
    fastcgi_buffer_size      64k;
    fastcgi_buffers          32 32k;
    fastcgi_read_timeout   1200s;

    proxy_buffer_size        64k;
    proxy_buffers            32 32k;
    proxy_busy_buffers_size  256k;

This is my .env file


Find the screenshots attached:

Another thing, that breaks with this non-standard webroot is the configuration of the ssl certificates in the php.ini. That breaks the ability to make https requests from any wordpress plugin or theme. The template php.ini.hbs has this line


Which expands to a path including the webroot, but it doesn’t get updated by the configuration change in site.conf.hbs. I can hardcode that, too. But perhaps… is it somehow possible to define the config vars used in the .hbs template files? Such that the templates stay the same and i configure {{root}} and {{wpCabundlePath}} somewhere?

@Nick-B any updates?

Hey @snr - thanks for the bump. I work on our Local engineering team and was chatting about this with Nick and a couple of our engineers this morning.

What you’re describing is “expected” in the sense that Local doesn’t support Bedrock out of the box. That doesn’t mean it isn’t possible to get there, but as you said, the users who have figured it out are using some hacky workarounds.

Shell Script

You’re correct, that script is auto-generated each time the “Open Site Shell” button is clicked. The best option here is to edit the script as you have done, create an alias for running the script that you can call from a plain terminal, and then don’t click that button again. Clicking it would result in overwriting the changes.


You’ll want to restart your site for any changes to the .hbs files to be registered; this will regenerate the site with the changes.
An option for getting it working would be to provide the full path to the certificates that ship with WordPress - this would be the full path to /wp-includes/certificates/ca-bundle.crt.

For a more complete “better Bedrock support for Local” discussion, I created a feature request on the community forums - Support Bedrock in Local. This will allow others to upvote and jump in on ways we can improve this workflow.

1 Like

Hey @snr - thank you for your comment about changing webroot. That has fixed my setup with a non-standard multisite :smiley:

@austinwendt Having support for setting site root would be very helpful. My site is in a subdirectory of public, so I need to append --url=“https://site.local/subdir” to every WP CLI command.

1 Like

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.