Bug: DISALLOW_FILE_EDIT = false has no effect.

nextgenthemes commented 2 years ago

Terms

[X] I have read the guidelines for Contributing to Roots Projects
[X] This request is not a duplicate of an existing issue
[X] I have read the docs and followed them (if applicable)
[X] I have seached the Roots Discourse for answers and followed them (if applicable)
[X] This is not a personal support request that should be posted on the Roots Discourse community

Description

What's wrong?

Is this possibly something that is done on purpose because?

I have checked the constant DISALLOW_FILE_EDIT and it's set to false.

I am using Trellis to setup my sites, and it is working correctly on my actually staging server VPS. But on the local virtual machine it's not working.

Looking for help in how I can debug this, what source file or WP to check ... I assume this has something with the NFS shared folders mechanic the files are shared across the host OS and guest VM.

Host OS is Ubuntu 22.04 and guest is Ubuntu 20.04. I sshed into the VM and ran sudo chmod 777 -Rv /srv/ but trellis already takes care of permissions, so I was not really expecting this to work, and it did not. I have tested that PHP can create files with this code:

function logfile( string $name, $var, string $file ) {
    $msg = $name . var_export( $var, true ) . PHP_EOL; //phpcs:ignore WordPress.PHP.DevelopmentFunctions.error_log_var_export
    error_log( $msg . PHP_EOL, 3, "$file.log" ); //phpcs:ignore WordPress.PHP.DevelopmentFunctions.error_log_error_log
}

logfile( 'nn', 'vr', __FILE__ );

It can create and write to a log file inside my mu-plugins folder and probably everywhere else in the WP installation. But it seems WP makes some checks on being able to write files that fail.

I found the code in the Gutenberg patch I like to try out.

    /**
     * Checks whether the user has permission to edit themes. In classic themes
     * this controls access to Appearance > Theme Editor to edit theme files.
     * In block themes editing theme files via the visual editor is similar.
     *
     * @return WP_Error|bool True if the request has access, or WP_Error object.
     */
    public function permissions_check() {
        if ( current_user_can( 'edit_themes' ) ) {
            return true;
        }

        return new WP_Error(
            'rest_cannot_edit_theme',
            __( 'Sorry, you are not allowed to edit theme templates and template parts.', 'gutenberg' ),
            array( 'status' => rest_authorization_required_code() )
        );
    }

This message is triggered for me, so it seems my user does not have the permission to edit themes. But I do not get why, it's the default admin user that is created by Trellis for one site, for the other I pulled down my live site and that user also 100% has the default admin role with all the permissions.

What have you tried?

What insights have you gained?

It's working as expected on my staging VPS, I see the menu, get the in admin editors ...

Possible solutions

Temporary workarounds

Steps To Reproduce

set Config::define('DISALLOW_FILE_MODS', false); in development.php

Expected Behavior

The Theme and Plugin Editor menus to show up.

Actual Behavior

The Theme and Plugin Editor menus not showing up. Manually navigating to the URLs also said I have no permission, and the permission check in the code seems to indicate my user does not have permissions.

Relevant Log Output

No response

Versions

master

swalkinshaw commented 2 years ago

I'm not sure this is a Trellis bug, but either way I think you'd need to trace within the WP source code where/how the edit_themes permission is set/derived if that's ultimately what's causing that error message.

I'm going to close this for now because I'm skeptical it's caused by Trellis itself, (plus the configuration is actually Bedrock which is setting a WP constant). If you troubleshoot further and think it is Trellis, please comment and I can re-open.

nextgenthemes commented 2 years ago

@swalkinshaw

Well I DO think it's a Trellis bug that and NOT Bedrock even if this setting is set there. Trellis does the setup and the handling of Vagrant, VirtualBox ... and this complicated NFS setup that caused me so many issues b4 that I wasted hours with. Is there not a better, more simple way to share folders?

Just lately I had lots of weird issues that WordPress roles that set the permission/user change to the files were stuck, that I could not manually set permissions for files inside the vm either ...

I recently, updated from 21.10 and 22.04 and deleted the entire VM to be build from scratch and these issues seem to be fixed now, however I do not get the expected permissions to edit the files.

So did you try to reproduce this? Let me guess, you did not. You just close it off for no reason without testing anything, is my guess.

You also disable the new Vagrant versions, just because there is an issue with Mac OS ONLY.

Vagrant.require_version '>= 2.1.0', '< 2.2.19'

This proves you do not care about Linux on client side at all, because you and most users are on Mac, I gueIguess you just ignore Linux. There is no reason so just disable this as this not an issue for Linux users.

I am skeptical of your behavior.

nextgenthemes commented 2 years ago

Also, the constant is correctly set by Bedrock, so why would it be a Bedrock bug? Bedrock works as expected. Pretty obvious that you just seek for an excuse not to deal with it and blame it on something else.

retlehs commented 2 years ago

@nextgenthemes we have zero tolerance for your behavior in your past two comments. scott had no issues re-opening this if it was a valid issue, but you immediately start attacking him?

scott has no responsibility to prove that there is a bug. that responsibility is on you.

take your entitlement elsewhere. if you pop up again and decide to have the same attitude, you will be permanently banned from interacting with the roots org on github.

have a great weekend.

roots / trellis