.htaccess file is not properly configured for W3 Total Cache

Your .htaccess file is a hidden file. You need to show hidden files in your FTP application in order to see them.

Thanks!

The check/update doesnt look to work very well either; changing a .htaccess to 777 is not done on a suphp system nor needed. A lot of wordpress users are using shared hosting with suphp which does not need any change of file permissions. Checking file permissions to see if you can edit a .htaccess file is a bad way to check.

Whenever I see “chmod 777” on a file I always cringe.
Does .htaccess need to be executable? NO!

I changed it back after install. Worked fine.

I changed it back after install. Worked fine.

Of course that works; but its wrong to need to do so. Not to mention dangerous for those who forget to change it back. Besides if you have over 500 blogs this would mean a lot of extra work to upgrade.

If the developer needs some more understanding or test environments he can contact me.

The developer needs to WRITE to your .htaccess files to apply rules.

The option you’re given is either set it 777 OR make the changes yourself. If you set it 777, it tells you to change settings to something more secure.

It’s a damned situation (damned if you do and if you don’t) because the .htaccess rules are needed.

Once you install, you never change ’em, in my experience.

The option you’re given is either set it 777 OR make the changes yourself. If you set it 777, it tells you to change settings to something more secure

That is not true; in a suphp environment the developer does NOT need to change the rights on the file because PHP does not run under the webserver account but under the users account as it should be from the start anyways. This also means you do not need (nor allowed) to use 777 permissions. 90% of the shared-hosting solutions are using suphp as it also makes it much easier to find which processes are abusing systems as each process runs at the users account.

If you are on a shared-hosting solution NOT using suphp you should be aware of the security implications this has. That said; this thread is about how the error is given by the developer; where the developer did not look to other (much used) options. If the developer likes to learn more he is more as welcome to discuss this with me.

The option you’re given is either set it 777 OR make the changes yourself. If you set it 777, it tells you to change settings to something more secure

That is not true; in a suphp environment the developer does NOT need to change the rights on the file

Sorry. What I meant was the option given by the plugin. Should have been more clear, but I’m not talking about PHP installs or anything more than what the plugin gives you options for.

You can’t assume everyone’s using suphp, though ?? In fact, given the wide variety of WordPress installs on everythign from Linux to Windows to Mac and every variety of server setup, you’d be making a pretty big gaff if you assumed that. 90%? Find me stats that 90% of WordPress users are on suphp ?? I know I don’t run suphp on my server. It’s got a nasty overhead for certain things that I just don’t care for. That said, if someone was running suphp, they could check and see if the plugin magically updates the htaccess without any permission changes.

And if you really want to tell a dev he’s wrong, you could read the FAQ of the plugin and use the contact link. But since you’re posting in the forums, I assumed you wanted to discuss. My bad.

Files only need to be 666 or 664 or in my case 644 (files created by the web server are owned by the web server)…as long as the .htaccess was created this way, it only needs to be 644.

The developer should attempt to write to the file first, then show an error if that doesn’t work for some reason.

I totally agree with the poster above who said on 500 blogs this is a lot of extra work to have to do anything manually.

Also, I suggest you actually put the command in the error message, so if it has to be done manually, it’s a simple copy and paste.

ie: instead of “copy /path/htaccess to /some/path”
use this instead: “cp /path/to/.hatccess /target/path/of/file”

The developer should attempt to write to the file first, then show an error if that doesn’t work for some reason.

Which … It does, if I understand the function in the source code right. It says it can’t write, and then asks for 777 or manual editing. As it should.

You can’t do the cp for .htaccess, btw. So many people have customized theirs, and there are THREE valid WP versions of the base htaccess, and you have to add-to, not copy over.

I am thinking of a different error message wrt “cp” command…ipstenu is correct, you would need to concat/parse the existing .htaccess to add to it.

Excellent thread. Any other questions?

You’d be making a pretty big gaff if you assumed that. 90%? Find me stats that 90% of WordPress users are on suphp

I never said this; i said the developer should look for another way to check the permissions as just assuming that 777 is necessary. Also i never said 90% of wordpress users are using suphp, i said Shared-hosting providers are using is 90% of the time because on a shared environment you frankly do not want anything else, unless you like others to read/adjust your files whenever it pleases them. That there are situations you rather choose not to use it; i of course understand.

The plugin doesn’t assume that the permissions are 777, that’s why there are a series of notifications.