Gutenberg: wp-env: No longer working on Linux

[ockham]

Describe the bug
For the past couple of days, I haven't been able to run wp-env on my Linux box.

To reproduce
On Linux, in your Gutenberg source directory, run npx wp-env start. It'll fail with the following error:

✖ .IOError: [Errno 13] Permission denied: '~/.wp-env/6ac6b03bd54e5e922f0d180f6d7ff25d/docker-compose.yml'

(I got the same error with npm -g i @wordpress/env && wp-env start.)

Desktop (please complete the following information):

• OS: Linux (Ubuntu 18.04.3 LTS)

Additional context
This _might_ correlate with #20002 being merged, but I'm not sure it's caused by that PR. /cc @noisysocks

Can we harden Gutenberg against issues like this? For the past ten days, of the time I spent working on Gutenberg, an estimated 50% went into trying to get it to run, figuring out that docs were outdated, updating them, and, just as I thought that things were running smoothely, getting stuck again with this new issue. That doesn't feel like a good use of my time :slightly_frowning_face:

[simison]

Sorry to hear about the trouble.

Note that build scripts use wp-scripts so that's what gets run in CI.

Would a good first step be to add simple dummy wp-env run into CI and then start working on migrating package.json scripts to it?

[noahtallen]

This might correlate with #20002 being merged, but I'm not sure it's caused by that PR.

It does sound as if that PR caused the issue. Instead of downloading the required files to cwd /wordpress and then putting a docker-compose override there, the new setup creates the docker-compose file and other dependencies at ~/.wp-env/. It sounds like the Linux issues mostly stem from filesystem permissions.

Can we harden Gutenberg against issues like this

I think yes. :) The wp-env tool is new enough that use cases like your own are still being uncovered. Indeed, your first issue dealing with the @wordpress/scripts env command was essentially the first point that @wordpress/env was really mentioned as the best way to start a local environment, so you're really on the bleeding edge of things here! 😁 I've been fixing other issues I'm finding along the way (#20158, #20157, #20113), and hopefully we can make this a robust tool for local wordpress environment. (It is already working much faster than the old @wordpress/scripts based solution when it works :))

If you like, you could try to fix the issue. I could see it being hard to replicate it since I don't have a linux box. I think the problem happens at these lines:
https://github.com/WordPress/gutenberg/blob/a59a5d9ab761bb2e0ee37eb67aab96d7f3dcf91b/packages/env/lib/env.js#L215-L227

You can run the source code directly while developing (no need to build anything)

$ path/to/gutenberg/packages/env/bin/wp-env start

In the short term (and I hate suggesting this), I wonder if sudo npx wp-env start would work?

[ramonjd]

I could see it being hard to replicate it since I don't have a linux box

I run Ubuntu on Virtual box. It's like wading through slag in a treacle body suit, but it's good enough for testing.

[noisysocks]

Sorry you're running into issues @ockham! Like @noahtallen says, wp-env has just undergone a major rewrite and so there will definitely be some kinks to work out! I intend to continue work on it over the next month or two and make it hard enough for us to migrate completely to wp-env.

I suspect that your user doesn't have write permission for the new environment temporary directory (~/.wp-env). Does running this fix the problem?

sudo chown -R username ~/.wp-env

Replace username with your username. You can find this out by running the whoami command.

We may need to look at using a different directory for wp-env's temporary folder on Linux systems, or allowing the user to specify a different directory using e.g. an environment variable.

[ockham]

Sorry you're running into issues @ockham! Like @noahtallen says, wp-env has just undergone a major rewrite and so there will definitely be some kinks to work out! I intend to continue work on it over the next month or two and make it hard enough for us to migrate completely to wp-env.

I suspect that your user doesn't have write permission for the new environment temporary directory (~/.wp-env). Does running this fix the problem?

sudo chown -R username ~/.wp-env

Replace username with your username. You can find this out by running the whoami command.

I'm afraid that doesn't fix the issue. ~ is my user's home folder -- it's basically the one folder that's guaranteed to have all the necessary permissions for my user :upside_down_face: I've deleted the ~/.wp-env folder in between runs, so it's newly created by the wp-env tool each time. It must be indeed the tool itself that assigns weird permissions to some subdirectory or file.

[ockham]

Possibly related: https://stackoverflow.com/questions/53344380/errno-13-while-running-docker-compose-up

(I'm doing this inside of my home directory tho, so the answer about adding it to some AppArmor config don't seem to apply :thinking: )

[ockham]

AFAICT, the error is happening on this line: https://github.com/WordPress/gutenberg/blob/9d67638709562eeb49f8fa47f5d73fe6d6b619d7/packages/env/lib/env.js#L57

Since docker-compose works fine for me with other projects, my hunch is that the reason for my issue might be somewhere in the docker-compose npm that this tool uses.

Specifically, I think that prior to #20002, dockerCompose.oneUp wasn't used (only dockerCompose.run), so I'm going to look into that command's implementation.

[ockham]

Nah, nothing to do with the docker-compose npm implementation. It's really just about the docker-compose.yml location. The following patch fixes the issue for me:

diff --git a/packages/env/lib/env.js b/packages/env/lib/env.js
index 94421544d2..ace4502a51 100644
--- a/packages/env/lib/env.js
+++ b/packages/env/lib/env.js
@@ -216,6 +216,8 @@ async function initConfig() {
        const configPath = path.resolve( '.wp-env.json' );
        const config = await readConfig( configPath );

+       config.dockerComposeConfigPath = path.resolve( 'docker-compose.yml' );
+
        await fs.mkdir( config.workDirectoryPath, { recursive: true } );

        await fs.writeFile(

[ockham]

There's a chance that the issue I'm seeing is related to the docker Snap package for Ubuntu that I'm using, which might have an impact on how binaries from a given Snap can access files. (The solutions described at https://stackoverflow.com/questions/53344380/errno-13-while-running-docker-compose-up didn't work for me.)

I think this is a rather widespread and recommended way to install Docker on Ubuntu (and other Linux distributions), plus it seems to be overall well-maintained and provides up-to-date versions. I think it's also the simplest way to install Docker on a number of Linux distributions; compare e.g. with these instructions.

In conclusion, it'd be good to make wp-env work with those Snaps :slightly_smiling_face:

[noahtallen]

The following patch fixes the issue for me:

Interesting, so docker cannot run a docker-compose.yml from ~/.wp-env/whateverhash/docker-compose.yml, but it can from your source code 🤔

As I mentioned in #20002, what do you think about having an environment variable to change ~/.wp-env/ to something else? Along with that, I wonder if there is a general directory on linux that could work for this location.

[ockham]

FWIW, I reported the problem (Docker snap being unable to access file in a hidden directory) here: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1863604

[anonymouse64]

The docker snap cannot access directories that start with a "." in the home folder. This is a generic security mechanism for all snaps. I'd recommend moving the directory out of ~/.wp-env to somewhere like ~/wp-env or allow configuring this somehow.

[ockham]

Thanks @anonymouse64!

So @noahtallen I guess it'll be good to proceed with #20253. Is there any chance we can make the default a non-hidden directory, so wp-env works OOTB on Ubuntu? /cc @noisysocks @epiqueras

[epiqueras]

Yes, we need #20253 as an additional measure, but I'd prefer to also remove the . from ~/.wp-env so that this works by default. @noisysocks Do you have any reservations against that? I don't think it's a problem if this folder is not hidden.

[noahtallen]

The only thing I can think is that pretty much all developer dev tool folders like this are hidden by default. Not sure why, but it is the common practice:

@ockham fantastic, I'll update the path in that PR as well. Maybe just on linux to start (if possible), but could also do it overall.

[epiqueras]

Just on Linux would be better. Having it hidden is still nice, if possible.

[noisysocks]

Yes, we need #20253 as an additional measure, but I'd prefer to also remove the . from ~/.wp-env so that this works by default. @noisysocks Do you have any reservations against that? I don't think it's a problem if this folder is not hidden.

Would something like ~/Library/Application Support/wp-env work?

[epiqueras]

Does Linux also have that directory?

[noisysocks]

I searched briefly and it looks like ~/.whatever is the conventional name for a support directory on Linux systems 😅

Oh well. I don't much mind. A hidden directory is preferable since the contents of .wp-env aren't exactly user-friendly (all of the directories inside it have hash names), but gotta do what you gotta do!

[epiqueras]

Let's track https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1863604 and remove it ASAP.

[sainthkh]

https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1863604 is closed with won't fix tag. They said they won't fix it for security.

[epiqueras]

What’s the security concern?

[sainthkh]

@epiqueras Below is the copy of the answer.

The docker snap cannot access directories that start with a "." in the home folder. This is a generic security mechanism for all snaps. I'd recommend moving the directory out of ~/.wp-env to somewhere like ~/wp-env or allow configuring this somehow.

[noahtallen]

I'm also interested to know how private folders are a security vulnerability, but I'm fine working around the limitation

[epiqueras]

@ockham Can you ask them?

[ockham]

Just on Linux would be better. Having it hidden is still nice, if possible.

This sort of inconsistency across OSes can make things harder to debug and document tho (e.g. referring to that directory in a README).

[ockham]

@ockham Can you ask them?

@anonymouse64 is already on this thread, so let's ask him here :slightly_smiling_face:

What’s the security concern [for disallowing Snaps from accessing hidden directories]?

[epiqueras]

This sort of inconsistency across OSes can make things harder to debug and document tho (e.g. referring to that directory in a README).

I don't think that's an issue, see the updated docs.

[anonymouse64]

What’s the security concern [for disallowing Snaps from accessing hidden directories]?

Snaps by default are confined with security sandboxing which restricts what files they access, including the home directory. By default with no interfaces connected, snaps get their own private home directories, which show up as versioned subdirectories like /home/$USER/snap/$SNAP_NAME/$SNAP_REVISION (with a current symlink which points to the currently active revision). However, when connecting the home interface, snaps can then access any files in the user's home directory at /home/$USER, with the above mentioned limitation denying access to hidden directories that start with a .. This is because many apps may store sensitive data inside .config or .gpg folders, and we don't want to provide every snap that wants to just store files inside $HOME like libreoffice or something access to the secrets another app may store in $HOME.

The way that snaps can get around this is by requesting access using the personal-files interface with a specific directory they wish to access, for example the chromium snap uses the personal-files interface like this:

plugs:
  chromium-config:
    interface: personal-files
    read:
    - $HOME/.config/chromium
    - $HOME/.chromium-browser.init

which allows specifically the chromium snap to access read-only /home/$USER/.config/chromium and /home/$USER/.chromium-browser.init when this interface is connected.

It is unlikely that the docker snap maintainers would propose adding a personal-files interface just for the docker snap when used with this project to be able to access ~/.wp-env, but I am not the docker snap maintainer (any more at least).

[noisysocks]

Closing this out as #20253 changes the default path to ~/wp-env on Linux platforms.

[noahtallen]

I think this should still be open since https://github.com/WordPress/gutenberg/pull/20253#issuecomment-586871441 was unfortunately not solved by the PR

[noisysocks]

Ah, I see! Missed that 😄

[ockham]

On top of that, I might be seeing a regression now:

~/src/gutenberg$ npx wp-env start
✖ Error while running docker-compose command.
Starting 6ac6b03bd54e5e922f0d180f6d7ff25d_mysql_1 ... done
Starting 6ac6b03bd54e5e922f0d180f6d7ff25d_wordpress_1 ... done
Error: Could not process the 'wp-config.php' transformation.
Reason: wp-config.php is not writable.

~/src/gutenberg$ ls -al ~/wp-env/6ac6b03bd54e5e922f0d180f6d7ff25d/tests-WordPress/wp-config.php
-rw-rw-rw- 1 bernie bernie 3219 Feb 21 15:40 /home/bernie/wp-env/6ac6b03bd54e5e922f0d180f6d7ff25d/tests-WordPress/wp-config.php

This seems to be happening upon a fresh run of npx wp-env start (after removing ~/wp-env). Currently re-running to confirm (slow internet, waiting for the WP download to finish).

[ockham]

On top of that, I might be seeing a regression now:

~/src/gutenberg$ npx wp-env start
✖ Error while running docker-compose command.
Starting 6ac6b03bd54e5e922f0d180f6d7ff25d_mysql_1 ... done
Starting 6ac6b03bd54e5e922f0d180f6d7ff25d_wordpress_1 ... done
Error: Could not process the 'wp-config.php' transformation.
Reason: wp-config.php is not writable.

~/src/gutenberg$ ls -al ~/wp-env/6ac6b03bd54e5e922f0d180f6d7ff25d/tests-WordPress/wp-config.php
-rw-rw-rw- 1 bernie bernie 3219 Feb 21 15:40 /home/bernie/wp-env/6ac6b03bd54e5e922f0d180f6d7ff25d/tests-WordPress/wp-config.php

This seems to be happening upon a fresh run of npx wp-env start (after removing ~/wp-env). Currently re-running to confirm (slow internet, waiting for the WP download to finish).

Yep, broken.

~/src/gutenberg$ rm -rf ~/wp-env/
~/src/gutenberg$ npx wp-env start
✖ Error while running docker-compose command.
Starting 6ac6b03bd54e5e922f0d180f6d7ff25d_mysql_1 ... done
Starting 6ac6b03bd54e5e922f0d180f6d7ff25d_wordpress_1 ... done
Error: Could not process the 'wp-config.php' transformation.
Reason: wp-config.php is not writable.

[ockham]

Folks, should we maybe reconsider making wp-env the official way to build and run Gutenberg? It's honestly not fun to run into these issues on a weekly basis -- basically whenever I try to get something productive done. FWIW, things seemed much stabler with the 'old' system (about half a year ago).

I think it's fine to experiment with a new build system, but let's maybe keep it labelled as experimental, and not the officially recommended way until it has consolidated a bit.

[ockham]

@sainthkh I managed to get an environment working that allows me to test Gutenberg. My coworkers recommended using the Jetpack repo and follow the instructions there.

Then, assuming that you have the Gutenberg source code checkout out into a /home/me/src/gutenberg, save the following to a gutenberg.yml file:

version: '3.3'
services:
  wordpress:
    volumes:
      - /home/me/src/gutenberg:/var/www/html/wp-content/plugins/gutenberg-dev

Now run npm run dev in your Gutenberg source folder, and yarn docker:compose -f path/to/gutenberg.yml up in your Jetpack folder. You should be able to access your local WordPress install at localhost:80, and to activate Gutenberg in the Plugins section.

@epiqueras I was surprised that the above yaml was all I needed to connect my Jetpack WordPress install to my Gutenberg source. That really doesn't seem to be such a complex syntax compared to wp-env.json :thinking:

[epiqueras]

The "old" system was abruptly replaced with wp-scripts env which broke for pretty much everyone.

This is still an improvement over that.

Yes, that setup will run WP, but it misses a lot of functionality like testing and being able to change the WP version, add themes/plugins, etc.

[epiqueras]

@ockham I added a --debug mode yesterday. Can you try that and paste the output here. It will be helpful to narrow down the cause of your permissions issue.

[noahtallen]

Error: Could not process the 'wp-config.php' transformation. Reason: wp-config.php is not writable.

Honestly, this sounds like it would be caused by the same issue you noted in https://github.com/WordPress/gutenberg/pull/20253#issuecomment-586871441 -- that is, permissions issues for the wp-config.php file. Really sorry you're "wasting" so much time on these bugs :( But hopefully this will make it a much more solid package for everyone else once everything is ironed out!

[noahtallen]

I just pulled the master version of Gutenberg and tried to spin up Docker and am also getting the same error now. (This is after running npm i and npm run build in the Gutenberg repo.)

~/source/wp-calypso/apps/full-site-editing(add/fse-e2e-tests) » ../../../gutenberg/packages/env/bin/wp-env start
✖ Error while running docker-compose command.
Starting 6325cd8721ee529de1906f9d022ec309_mysql_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_wordpress_1 ... done
Error: Could not process the 'wp-config.php' transformation.
Reason: wp-config.php is not writable.

Debug output:

~/source/wp-calypso/apps/full-site-editing(add/fse-e2e-tests) » ../../../gutenberg/packages/env/bin/wp-env start --debug
ℹ Config:
{
    "name": "full-site-editing",
    "configDirectoryPath": "/Users/noah.allen/source/wp-calypso/apps/full-site-editing",
    "workDirectoryPath": "/Users/noah.allen/.wp-env/6325cd8721ee529de1906f9d022ec309",
    "port": 4013,
    "testsPort": 4005,
    "dockerComposeConfigPath": "/Users/noah.allen/.wp-env/6325cd8721ee529de1906f9d022ec309/docker-compose.yml",
    "coreSource": null,
    "pluginSources": [
        {
            "type": "local",
            "path": "/Users/noah.allen/source/wp-calypso/apps/full-site-editing/full-site-editing-plugin",
            "basename": "full-site-editing-plugin"
        },
        {
            "type": "local",
            "path": "/Users/noah.allen/source/gutenberg",
            "basename": "gutenberg"
        }
    ],
    "themeSources": [
        {
            "type": "local",
            "path": "/Users/noah.allen/source/themes/varia",
            "basename": "varia"
        },
        {
            "type": "local",
            "path": "/Users/noah.allen/source/themes/maywood",
            "basename": "maywood"
        }
    ],
    "config": {
        "WP_DEBUG": true,
        "SCRIPT_DEBUG": true
    },
    "debug": true
}

Docker Compose Config:
{
    "version": "3.7",
    "services": {
        "mysql": {
            "image": "mariadb",
            "environment": {
                "MYSQL_ALLOW_EMPTY_PASSWORD": "yes"
            }
        },
        "wordpress": {
            "depends_on": [
                "mysql"
            ],
            "image": "wordpress",
            "ports": [
                "${WP_ENV_PORT:-4013}:80"
            ],
            "environment": {
                "WORDPRESS_DB_NAME": "wordpress"
            },
            "volumes": [
                "wordpress:/var/www/html",
                "/Users/noah.allen/source/wp-calypso/apps/full-site-editing/full-site-editing-plugin:/var/www/html/wp-content/plugins/full-site-editing-plugin",
                "/Users/noah.allen/source/gutenberg:/var/www/html/wp-content/plugins/gutenberg",
                "/Users/noah.allen/source/gutenberg/packages/e2e-tests/plugins:/var/www/html/wp-content/plugins/gutenberg-test-plugins",
                "/Users/noah.allen/source/gutenberg/packages/e2e-tests/mu-plugins:/var/www/html/wp-content/mu-plugins",
                "/Users/noah.allen/source/themes/varia:/var/www/html/wp-content/themes/varia",
                "/Users/noah.allen/source/themes/maywood:/var/www/html/wp-content/themes/maywood"
            ]
        },
        "tests-wordpress": {
            "depends_on": [
                "mysql"
            ],
            "image": "wordpress",
            "ports": [
                "${WP_ENV_TESTS_PORT:-4005}:80"
            ],
            "environment": {
                "WORDPRESS_DB_NAME": "tests-wordpress"
            },
            "volumes": [
                "tests-wordpress:/var/www/html",
                "/Users/noah.allen/source/wp-calypso/apps/full-site-editing/full-site-editing-plugin:/var/www/html/wp-content/plugins/full-site-editing-plugin",
                "/Users/noah.allen/source/gutenberg:/var/www/html/wp-content/plugins/gutenberg",
                "/Users/noah.allen/source/gutenberg/packages/e2e-tests/plugins:/var/www/html/wp-content/plugins/gutenberg-test-plugins",
                "/Users/noah.allen/source/gutenberg/packages/e2e-tests/mu-plugins:/var/www/html/wp-content/mu-plugins",
                "/Users/noah.allen/source/themes/varia:/var/www/html/wp-content/themes/varia",
                "/Users/noah.allen/source/themes/maywood:/var/www/html/wp-content/themes/maywood"
            ]
        },
        "cli": {
            "depends_on": [
                "wordpress"
            ],
            "image": "wordpress:cli",
            "volumes": [
                "wordpress:/var/www/html",
                "/Users/noah.allen/source/wp-calypso/apps/full-site-editing/full-site-editing-plugin:/var/www/html/wp-content/plugins/full-site-editing-plugin",
                "/Users/noah.allen/source/gutenberg:/var/www/html/wp-content/plugins/gutenberg",
                "/Users/noah.allen/source/gutenberg/packages/e2e-tests/plugins:/var/www/html/wp-content/plugins/gutenberg-test-plugins",
                "/Users/noah.allen/source/gutenberg/packages/e2e-tests/mu-plugins:/var/www/html/wp-content/mu-plugins",
                "/Users/noah.allen/source/themes/varia:/var/www/html/wp-content/themes/varia",
                "/Users/noah.allen/source/themes/maywood:/var/www/html/wp-content/themes/maywood"
            ]
        },
        "tests-cli": {
            "depends_on": [
                "wordpress"
            ],
            "image": "wordpress:cli",
            "volumes": [
                "tests-wordpress:/var/www/html",
                "/Users/noah.allen/source/wp-calypso/apps/full-site-editing/full-site-editing-plugin:/var/www/html/wp-content/plugins/full-site-editing-plugin",
                "/Users/noah.allen/source/gutenberg:/var/www/html/wp-content/plugins/gutenberg",
                "/Users/noah.allen/source/gutenberg/packages/e2e-tests/plugins:/var/www/html/wp-content/plugins/gutenberg-test-plugins",
                "/Users/noah.allen/source/gutenberg/packages/e2e-tests/mu-plugins:/var/www/html/wp-content/mu-plugins",
                "/Users/noah.allen/source/themes/varia:/var/www/html/wp-content/themes/varia",
                "/Users/noah.allen/source/themes/maywood:/var/www/html/wp-content/themes/maywood"
            ]
        },
        "composer": {
            "image": "composer",
            "volumes": [
                "/Users/noah.allen/source/wp-calypso/apps/full-site-editing:/app"
            ]
        }
    },
    "volumes": {
        "wordpress": {},
        "tests-wordpress": {}
    }
}
⠼ Downloading WordPress.Creating network "6325cd8721ee529de1906f9d022ec309_default" with the default driver
Creating 6325cd8721ee529de1906f9d022ec309_mysql_1 ... done
⠦ Starting WordPress.6325cd8721ee529de1906f9d022ec309_mysql_1 is up-to-date
Creating 6325cd8721ee529de1906f9d022ec309_wordpress_1       ... done
Creating 6325cd8721ee529de1906f9d022ec309_tests-wordpress_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_mysql_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_wordpress_1 ... done
⠧ Starting WordPress.mysqlcheck: Got error: 2002: Can't connect to MySQL server on 'mysql' (115) when trying to connect
Starting 6325cd8721ee529de1906f9d022ec309_mysql_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_wordpress_1 ... done
⠼ Starting WordPress.mysqlcheck: Got error: 2002: Can't connect to MySQL server on 'mysql' (115) when trying to connect
Starting 6325cd8721ee529de1906f9d022ec309_mysql_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_wordpress_1 ... done
⠹ Starting WordPress.mysqlcheck: Got error: 2002: Can't connect to MySQL server on 'mysql' (115) when trying to connect
Starting 6325cd8721ee529de1906f9d022ec309_mysql_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_wordpress_1 ... done
⠋ Starting WordPress.mysqlcheck: Got error: 2002: Can't connect to MySQL server on 'mysql' (115) when trying to connect
Starting 6325cd8721ee529de1906f9d022ec309_mysql_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_wordpress_1 ... done
⠏ Starting WordPress.mysqlcheck: Got error: 2002: Can't connect to MySQL server on 'mysql' (115) when trying to connect
Starting 6325cd8721ee529de1906f9d022ec309_mysql_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_wordpress_1 ... done
⠧ Starting WordPress.mysqlcheck: Got error: 2002: Can't connect to MySQL server on 'mysql' (115) when trying to connect
Starting 6325cd8721ee529de1906f9d022ec309_mysql_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_wordpress_1 ... done
⠴ Starting WordPress.mysqlcheck: Got error: 2002: Can't connect to MySQL server on 'mysql' (115) when trying to connect
Starting 6325cd8721ee529de1906f9d022ec309_mysql_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_wordpress_1 ... done
⠼ Starting WordPress.Success: Database checked.
Starting 6325cd8721ee529de1906f9d022ec309_mysql_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_mysql_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_wordpress_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_wordpress_1 ... done
⠙ Starting WordPress.Warning: Unable to create directory wp-content/uploads/2020/02. Is its parent directory writable by the server?
Success: WordPress installed successfully.
Warning: Unable to create directory wp-content/uploads/2020/02. Is its parent directory writable by the server?
Success: WordPress installed successfully.
Starting 6325cd8721ee529de1906f9d022ec309_mysql_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_wordpress_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_mysql_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_wordpress_1 ... done
⠋ Starting WordPress.Error: Could not process the 'wp-config.php' transformation.
Reason: wp-config.php is not writable.
Error: Could not process the 'wp-config.php' transformation.
Reason: wp-config.php is not writable.
Starting 6325cd8721ee529de1906f9d022ec309_mysql_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_wordpress_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_mysql_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_wordpress_1 ... done
⠋ Starting WordPress.WordPress is already installed.
⠙ Starting WordPress.WordPress is already installed.
Starting 6325cd8721ee529de1906f9d022ec309_mysql_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_wordpress_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_mysql_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_wordpress_1 ... done
⠏ Starting WordPress.Error: Could not process the 'wp-config.php' transformation.
Reason: wp-config.php is not writable.
Error: Could not process the 'wp-config.php' transformation.
Reason: wp-config.php is not writable.
✖ Error while running docker-compose command.
Starting 6325cd8721ee529de1906f9d022ec309_mysql_1 ... done
Starting 6325cd8721ee529de1906f9d022ec309_wordpress_1 ... done
Error: Could not process the 'wp-config.php' transformation.
Reason: wp-config.php is not writable.

I don't have a lot of time to troubleshoot right now, but it's interesting that we're seeing a similar issue on macOS now.

[noisysocks]

Looks like it's a regression caused by https://github.com/WordPress/gutenberg/pull/20352 and to do with wp config set not being able to write to wp-config.php when "core": null. ~This makes sense because there isn't a writable Docker volume when "core": null.~ (edit: Nope, that wasn't it!)

For stability during day-to-day development, I'd recommend that one installs the latest major version of @wordpress/env using npm install -g @wordpress/[email protected] instead of using the development version of wp-env included in Gutenberg.

[noisysocks]

I've opened https://github.com/WordPress/gutenberg/pull/20403 which should fix the issue @noahtallen ran into above.

[noahtallen]

I'd recommend that one installs the latest major version

Definitely :) I was mostly trying to test wp-env behavior at the time, which is why I used master (from the other plugin that I develop in)

[ockham]

I ran npx wp-env start --debug to track down why wp-env isn't working for me on _second_ try. Here's the log leading up to the error:

ℹ NodeGit: Cloning or getting the repo.
ℹ NodeGit: Repo already exists, get it.
ℹ NodeGit: Fetching the specified ref.
ℹ NodeGit: Checking out the specified ref.
⠦ Downloading WordPress.
  - core: 100/100%Creating network "6ac6b03bd54e5e922f0d180f6d7ff25d_default" with the default driver
✖ EACCES: permission denied, open '/home/me/wp-env/6ac6b03bd54e5e922f0d180f6d7ff25d/tests-WordPress/wp-config.php'
[Error: EACCES: permission denied, open '/home/me/wp-env/6ac6b03bd54e5e922f0d180f6d7ff25d/tests-WordPress/wp-config.php'] {
  errno: -13,
  code: 'EACCES',
  syscall: 'open',
  path: '/home/me/wp-env/6ac6b03bd54e5e922f0d180f6d7ff25d/tests-WordPress/wp-config.php'
}

Not sure that's very useful tho :sweat_smile:

[sainthkh]

After #20648 is merged, I can run the sudo npx wp-env start on Ubuntu.

NOTE: sudo is required here.

For some reason, it fails at the first attempt like below:

sainthkh@sainthkh-All-Series:~/v/gutenberg$ sudo npx wp-env start
[sudo] password for sainthkh: 
✖ Error while running docker-compose command.
Starting aac851dfb8c3a8cb59795ad0b12671c7_mysql_1 ... done
Starting aac851dfb8c3a8cb59795ad0b12671c7_wordpress_1 ... done
mysqlcheck: Got error: 1049: Unknown database 'wordpress' when selecting the database

But after that, it works without any problem:

sainthkh@sainthkh-All-Series:~/v/gutenberg$ sudo npx wp-env start
✔ WordPress started. (in 87s 64ms)
sainthkh@sainthkh-All-Series:~/v/gutenberg$ sudo npx wp-env stop
✔ Stopped WordPress. (in 8s 583ms)

If it's the case for everyone, we might need to close this issue and focus on solving why mysqlcheck: Got error: 1049: Unknown database 'wordpress' when selecting the database doesn't work at the first attempt.

[noahtallen]

Is sudo required just the first time or also on all the subsequent runs?

[sainthkh]

@noahtallen every time.

[ockham]

I realized that the Docker env was working, even though I was still getting

Error: Could not process the 'wp-config.php' transformation.
Reason: wp-config.php is not writable.

The latter has just been fixed by #22682, so I'll close this issue.

(I'm still getting an Error: Stylesheet is missing., but I guess that's unrelated. Media upload is also still impossible. I might file another issue for that.)

[noahtallen]

Error: Stylesheet is missing

wait, what's this error!? 😋

@sainthkh Is the DB connection issue still problematic? Also, regarding sudo, is that normally needed for docker-compose/docker on linux?

[sainthkh]

Actually, things became worse after I upgraded to Ubuntu 20.04. It just fails with the segmentation fault message even with sudo. I don't know what I misconfigured.

Because of that, I'm currently working on Windows.

[noahtallen]

That's too bad. Could you open a new issue with that specific error message?

[sainthkh]

@noahtallen Opened an issue at #22731.

[noahtallen]

Thank you! didn't want to clutter this one up too much more, since it has already covered two or three different issues 😅

[danieliser]

On WSL 2 (Ubuntu 20.04), and ran into this recently.

The sudo chown -R username ~/.wp-env command didn't quite do it, because the folder was actually ~/wp-env. Corrected that and it worked perfectly. Finally I can restart wp-env without destroying and rebuilding.

[danieliser]

@ockham - Was this patched and just not released yet? I'm on the latest release and this is still happening for me. I'm having to do the chown pretty much every time I restart my computer or the VM or stop & start the wp-env again.

[noahtallen]

@danieliser there was another (similar) issue I fixed in #23797. Can you paste the output of the error you see when running wp-env a second time so that we can see if the error is the same?

Was this patched and just not released yet

This specific issue should have been released, but the one I mentioned above has not yet been released :/

[noahtallen]

If you're running wp-env from Gutenberg, though, you should be referencing the local source code (e.g. npx wp-env or npm run wp-env), and shouldn't see issues developing the gutenberg project specifically.

[danieliser]

@noahtallen - Not using it for Gutenberg, just in general plugin development and testing. Hasn't happened today yet, but I will post the error.

It was this same one though:

✖ EACCES: permission denied, open '/home/me/wp-env/6ac6b03bd54e5e922f0d180f6d7ff25d/tests-WordPress/wp-config.php'
[Error: EACCES: permission denied, open '/home/me/wp-env/6ac6b03bd54e5e922f0d180f6d7ff25d/tests-WordPress/wp-config.php'] {
  errno: -13,
  code: 'EACCES',
  syscall: 'open',
  path: '/home/me/wp-env/6ac6b03bd54e5e922f0d180f6d7ff25d/tests-WordPress/wp-config.php'
}

Error: Could not process the 'wp-config.php' transformation.
Reason: wp-config.php is not writable.

[noahtallen]

Does it happen every time you run wp-env start if it is already running?

Btw, this issue should fix this altogether and make filesystem permissions in wp-env work a lot better: #22515. But it needs some eyes and work to make progress

[danieliser]

@noahtallen No it seems to be related to either restarting the host OS (Windows 10) or the rebooting of the WSL vm.

This one came up today after a reboot:

✖ EACCES: permission denied, open '/home/daniel/wp-env/a539d783750b32e7f42cbafde69608aa/tests-wordpress-latest/wp-content/plugins/fill-data.php'
[Error: EACCES: permission denied, open '/home/daniel/wp-env/a539d783750b32e7f42cbafde69608aa/tests-wordpress-latest/wp-content/plugins/fill-data.php'] {
  errno: -13,
  code: 'EACCES',
  syscall: 'open',
  path: '/home/daniel/wp-env/a539d783750b32e7f42cbafde69608aa/tests-wordpress-latest/wp-content/plugins/fill-data.php'
}

After running the command to fix it I still got this:

✖ Error while running docker-compose command.
Starting a539d783750b32e7f42cbafde69608aa_mysql_1 ... done
Starting a539d783750b32e7f42cbafde69608aa_tests-wordpress_1 ... done
Error: Could not process the 'wp-config.php' transformation.
Reason: wp-config.php is not writable.

[noahtallen]

🙃 By the way, do you use sudo to run docker & wp-env commands? I've had to do that myself on ubuntu, and I hear that is normal for docker on linux

[danieliser]

No, I haven't had to do that.