Defender - cannot write to htaccess file

Through a process of ilimnation, I can only conclude that defender has made it impossible for me to write to my htacess file, but more worryingly, something has caused my cached files in wp-rocket to change the file permissions to 777 from 755. Pretty sure it isn't wp rocket doing it, hummingbird was installed for a while. Would appreciate some help in correcting anything that defender has done, and hummingbird, and completely removing both plugins. Support access is open.

  • Michael Bissett

    Hey Rich, Michael here!

    Looking at your site via the login details you'd sent in from a prior ticket, I did see that there wasn't a .htaccess file visible in the root of your Multisite for a few minutes, I'm seeing that there's one there now, albeit with a different configuration than what a subdomain Multisite has:

    <Files index.php>
    allow from all
    </Files>
    
    <IfModule mod_rewrite.c>
    RewriteEngine on
    
    # You may need RewriteBase on some servers
    #RewriteBase /min
    
    # rewrite URLs like "/min/f=..." to "/min/?f=..."
    RewriteRule ^([bfg]=.*)  index.php?$1 [L,NE]
    </IfModule>
    <IfModule mod_env.c>
    # In case AddOutputFilterByType has been added
    SetEnv no-gzip
    </IfModule>

    The default subdomain .htaccess code would be this:

    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    
    # add a trailing slash to /wp-admin
    RewriteRule ^wp-admin$ wp-admin/ [R=301,L]
    
    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^ - [L]
    RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
    RewriteRule ^(.*\.php)$ $1 [L]
    RewriteRule . index.php [L]

    As for the cache files, that would actually be an accidental oversight from my prior debugging efforts, as I was trying to debug the permission issues you'd noted in another thread. I thought I'd taken care of reverting all of the folders that had been temporarily adjusted, but it looks like the cache folders were missed, and I do apologize for that. :slight_frown:

    I see that those have been cleared out in the meantime, seems like you're working on the site right now?

    Kind Regards,
    Michael

  • Rich

    Hi Michael

    I was working on my site last night, and by accident deleted my htaccess file. When you had looked at it, I was half way through sorting it. Thanks for sending me the details, although I have only just seen it. It seems I have pretty much managed to get it right as is the same now as you have kindly posted.

    #RewriteCond %{HTTP_HOST} ^www\.eevee\.co\.uk
    #RewriteCond %{HTTPS} on
    #RewriteRule ^(.*)$ https://www.eevee.co.uk/$1 [R,L]

    This is the only thing different. My site has ssl active on every subdomain (unless domain mapping is active). Not sure if the above is relevant.

    Regarding the file permissions on the cache files. This has been a bit of nightmare since the weekend. My cxs scanner on my server was switched off by my server providers because they were getting a barrage of messages of incorrect file permissions specifically on my cache files and minification files within the wp-rocket cache folders. Is this why they have all changed to 777, they need to be 755? All the files are correct, 644. It only got flagged on the weekend, this problem.

    Last night, I completely removed wp-rocket and reinstalled it. All the folders are still using 777 for the new cache files and minification. Any help in resolving this would be greatly appreciated.

  • Michael Bissett

    Hey Rich,

    My cxs scanner on my server was switched off by my server providers because they were getting a barrage of messages of incorrect file permissions specifically on my cache files and minification files within the wp-rocket cache folders. Is this why they have all changed to 777, they need to be 755?

    Like I mentioned before, I'd done some file permission changes, so before your re-install, it seems like they were 777 due to that. From the sounds of it, CXS was alerting them about those directories.

    Unfortunately, the /wp-content folder was also 777, which would explain why the folders were 777 as well, after you did that re-install.

    I've rectified this now by changing all of the folder permissions (for /wp-content folder, as well as the WP Rocket config & cache folders, and Hummingbird's cache folders) to 755, and I've changed all of the file permissions inside of the cache & WP Rocket config folders (including subfolders).

    Kind Regards,
    Michael

  • Rich

    Hi Michael

    Morning here in the UK, so just got up.

    Thank you for your help in rectifying this, it is greatly appreciated.

    Couple of questions.

    Does this mean that any new cache and minification folders for all the mentioned plugins will use the correct file permissions of 755 and 644 from now on?

    Did you find any insight to my wpmudev issues regarding why I am still unable to install any plugins or themes through my dashboard? Are you going to delete my second account registered under my name (it is this account I need to keep for reference). You mentioned you were going to pass this on to someone else at wpmudev to look at?

    In simple lames terms, could you tell me what the below three lines are saying in my htaccess file and tell me if you think they need a # in front of them (or not)?

    #RewriteCond %{HTTP_HOST} ^www\.eevee\.co\.uk
    #RewriteCond %{HTTPS} on
    #RewriteRule ^(.*)$ https://www.eevee.co.uk/$1 [R,L]

    I think they are for any www. url requests to re-direct to https://eevee.co.uk (a guess)?

    As always, your help is greatly appreciated. Whilst the dsahboard issue is not the end of the world, as everything seems to update ok and I can use the traditional install method should I need to install anything new. It would be good to know why this is happening?

    Kind regards,

    Rich

  • Michael Bissett

    Hey Rich, apologies for the delay here!

    Very early morning for me here in the US, let's get cracking on those questions of yours:

    Does this mean that any new cache and minification folders for all the mentioned plugins will use the correct file permissions of 755 and 644 from now on?

    Both new folders and files should use 755, it's what I was able to manage with the access available. The existing files use 644, however (at least, they did when I was last in there).

    Did you find any insight to my wpmudev issues regarding why I am still unable to install any plugins or themes through my dashboard?

    I tried looking into this before, but had flagged it for SLS over on the thread in question:

    https://premium.wpmudev.org/forums/topic/no-plugins-or-themes-will-update-or-install-just-from-wpmudev#post-1058193

    We'll want to keep that discussion over there, and stick on the issue in this one.

    In simple lames terms, could you tell me what the below three lines are saying in my htaccess file and tell me if you think they need a # in front of them (or not)?

    #RewriteCond %{HTTP_HOST} ^www\.eevee\.co\.uk
    #RewriteCond %{HTTPS} on
    #RewriteRule ^(.*)$ https://www.eevee.co.uk/$1 [R,L]

    I think they are for any www. url requests to re-direct to https://eevee.co.uk (a guess)?

    Having the # sign in front disables the rules, but the rules would look to be invalid anyhow. If you're not needing to have SSL forced, then you can remove them.

    For the sake of explanation, though, if they were like this:

    RewriteCond %{HTTP_HOST} ^www\.eevee\.co\.uk
    RewriteCond %{HTTPS} != on
    RewriteRule ^(.*)$ https://eevee.co.uk/$1 [R,L]

    Then, in layman's terms:

    If you're visiting a page on eevee.co.uk, and you're not visiting via https://, redirect the URL to a https:// URL.

    Kind Regards,
    Michael