Permission issues using a theme that uses composer

[lajennylove]

Quick summary

I don't know if this is related to the new implementation regarding the PHP selector, but as soon as I tried to use it I found permission issues.

Here's the screenshot:

I tried to do the following to fix the issue:

# check the permissions
ls -l ../../cache/acorn/framework/cache/
total 0
drwxr-xr-x  2 lajennylove  staff  64 Jun 17 20:26 data
----------  1 lajennylove  staff   0 Jun 17 20:26 packages.php

# change change them
chmod -R 755 ../../cache/acorn/framework/cache/

# Then I tried to change the owner but then that wouldn't have access my self, I guess
chown -R www-data:www-data ../../cache/acorn/framework/cache/

Then I though it wouldn't work and I stopped trying.

Steps to reproduce

1. Create a new site on Studio
2. Switch to PHP 8.2
3. Clone this Sage/Vite theme https://github.com/DevArge/sage-vite
4. Before activating it, to do the following:

# Install vendor
composer install
# Install Vite
yarn 
# Build the assets
yarn build

5. Then activate the theme, or even better... Just try to live previewing it to avoid having issues with a broken theme.

What you expected to happen

The theme gets activated with no issues like if you were using any other LAMP environment.

What actually happened

I get the following error and I think it could affect to all the users that require composer's cache packages or related:

Warning: require(/var/www/html/wp-content/cache/acorn/framework/cache/packages.php): Failed to open stream: Permission denied in /var/www/html/wp-content/themes/sage-vite/vendor/illuminate/filesystem/Filesystem.php on line 123

Fatal error: Uncaught Error: Failed opening required '/var/www/html/wp-content/cache/acorn/framework/cache/packages.php' (include_path='.:') in /var/www/html/wp-content/themes/sage-vite/vendor/illuminate/filesystem/Filesystem.php:123 Stack trace: #0 /var/www/html/wp-content/themes/sage-vite/vendor/illuminate/filesystem/Filesystem.php(124): Illuminate\Filesystem\Filesystem::Illuminate\Filesystem\{closure}() #1 /var/www/html/wp-content/themes/sage-vite/vendor/roots/acorn/src/Illuminate/Foundation/PackageManifest.php(111): Illuminate\Filesystem\Filesystem->getRequire('/var/www/html/w...') #2 /var/www/html/wp-content/themes/sage-vite/vendor/roots/acorn/src/Illuminate/Foundation/PackageManifest.php(90): Illuminate\Foundation\PackageManifest->getManifest() #3 /var/www/html/wp-content/themes/sage-vite/vendor/roots/acorn/src/Illuminate/Foundation/PackageManifest.php(79): Illuminate\Foundation\PackageManifest->config('aliases') #4 /var/www/html/wp-content/themes/sage-vite/vendor/roots/acorn/src/Roots/Acorn/Bootstrap/RegisterFacades.php(25): Illuminate\Foundation\PackageManifest->aliases() #5 /var/www/html/wp-content/themes/sage-vite/vendor/roots/acorn/src/Illuminate/Foundation/Application.php(263): Roots\Acorn\Bootstrap\RegisterFacades->bootstrap(Object(Roots\Acorn\Application)) #6 /var/www/html/wp-content/themes/sage-vite/vendor/roots/acorn/src/Illuminate/Foundation/Http/Kernel.php(186): Illuminate\Foundation\Application->bootstrapWith(Array) #7 /var/www/html/wp-content/themes/sage-vite/vendor/roots/acorn/src/Roots/Acorn/Bootloader.php(187): Illuminate\Foundation\Http\Kernel->bootstrap(Object(Illuminate\Http\Request)) #8 /var/www/html/wp-content/themes/sage-vite/vendor/roots/acorn/src/Roots/Acorn/Bootloader.php(103): Roots\Acorn\Bootloader->bootHttp() #9 /var/www/html/wp-content/themes/sage-vite/functions.php(43): Roots\Acorn\Bootloader->boot() #10 /var/www/html/wp-settings.php(663): include('/var/www/html/w...') #11 /var/www/html/wp-config.php(96): require_once('/var/www/html/w...') #12 /var/www/html/wp-load.php(50): require_once('/var/www/html/w...') #13 /var/www/html/wp-admin/admin.php(34): require_once('/var/www/html/w...') #14 /var/www/html/wp-admin/customize.php(13): require_once('/var/www/html/w...') #15 {main} thrown in /var/www/html/wp-content/themes/sage-vite/vendor/illuminate/filesystem/Filesystem.php on line 123

Impact

Most (> 50%)

Available workarounds?

No and the app is unusable

Platform

Mac Silicon

Logs or notes

No response

[mrfoxtalbot]

Gracias, @lajennylove!

@wojtekn can you take a look? Thanks!

[wojtekn]

Thanks for reporting the issue @lajennylove and for including detailed steps.

I tried to reproduce it in Studio 1.0.3 but couldn't, as it failed earlier in the flow:

• I couldn't activate the theme in WP Admin as PHP version was not supported
• I activated the theme using WP CLI and then got the fatal error:

Fatal error: Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 8.2.0". You are running 8.0.30-dev. in /var/www/html/wp-content/themes/sage-vite/vendor/composer/platform_check.php on line 24

I reproduced it with 8.2 and tracked it to the code from https://github.com/illuminate/filesystem/blob/70487deb0aabbf0ac2f79d4f86e1b2c539f0bbfc/Filesystem.php#L225:

        // Fix permissions of tempPath because `tempnam()` creates it with permissions set to 0600...
        if (! is_null($mode)) {
            chmod($tempPath, $mode);
        } else {
            chmod($tempPath, 0777 - umask());
        }

$mode is null, umask() returns 0777, so the file ends up with permissions set to 0.

As a quick workaround, I propose adding umask(022); in wp-config.php before pulling and installing the theme.

@adamziel any thoughts on that? Should we set default umask for PHP-WASM?

[adamziel]

Should we set default umask for PHP-WASM?

I think we should do the same thing as native PHP – is that the default PHP behavior?

[wojtekn]

I think we should do the same thing as native PHP – is that the default PHP behavior?

I think it's more related to the operating system, and not PHP itself. It seems that 022 is a common default value on the UNIX system. Reference:

https://web.deu.edu.tr/doc/oreily/networking/puis/ch05_03.htm#:~:text=2%20Common%20umask%20Values,the%20default%20umask%20is%20022.

[adamziel]

As a quick workaround, I propose adding umask(022); in wp-config.php before pulling and installing the theme.

The workaround seems good. At the Playground platform level, it seems like an Emscripten-level issue:

• Strange default umask value emscripten-core/emscripten#9916
• Default umask 0o777 is too strict emscripten-core/emscripten#17269

We'll need either an Emscripten PR or a Playground-level patch.

[lajennylove]

Hey there guys, is there any update regarding this issue? I've seen a few updates on the Studio App so I've been updating since then and checking if the issue is solved but I guess you are still working on it.

That's pretty much it, I just wanted to keep track on this issue because this is stopping me from start using this app as my local dev environment.

Best regards.

[wojtekn]

@lajennylove we don't have a fix yet, but it's on our radar.

[fluiddot]

Heads up that this issue will be solved via #555.