WordPress.org

Ready to get started?Download WordPress

Forums

[resolved] .htaccess file is not properly configured for W3 Total Cache (18 posts)

  1. aokijam
    Member
    Posted 3 years ago #

    I encountered a problem using w3 Total Cache. I like to run chmod 777 for .htaccess but i can't seem to find the file in my file manager.
    Below is the following message that I have received:

    You've enabled Browser Cache feature however the .htaccess file is not properly configured. Please run chmod 777 /home/(my username)/public_html/.htaccess, then try again.

    To manually modify these settings use the following code:
    # BEGIN W3TC Browser Cache
    <IfModule mod_deflate.c>
    <IfModule mod_setenvif.c>
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4\.0[678] no-gzip
    BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
    BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
    </IfModule>
    <IfModule mod_headers.c>
    Header append Vary User-Agent env=!dont-vary
    </IfModule>
    AddOutputFilterByType DEFLATE text/css application/x-javascript text/html text/richtext image/svg+xml text/plain text/xsd text/xsl text/xml image/x-icon
    </IfModule>
    <FilesMatch "\.(css|js)$">
    FileETag None
    <IfModule mod_headers.c>
    Header set X-Powered-By "W3 Total Cache/0.9.1.2"
    </IfModule>
    </FilesMatch>
    <FilesMatch "\.(html|htm|rtf|rtx|svg|svgz|txt|xsd|xsl|xml)$">
    FileETag None
    <IfModule mod_headers.c>
    Header set X-Powered-By "W3 Total Cache/0.9.1.2"
    </IfModule>
    </FilesMatch>
    <FilesMatch "\.(asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc|docx|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|mdb|mid|midi|mov|qt|mp3|m4a|mp4|m4v|mpeg|mpg|mpe|mpp|odb|odc|odf|odg|odp|ods|odt|ogg|pdf|png|pot|pps|ppt|pptx|ra|ram|swf|tar|tif|tiff|wav|wma|wri|xla|xls|xlsx|xlt|xlw|zip)$">
    FileETag None
    <IfModule mod_headers.c>
    Header set X-Powered-By "W3 Total Cache/0.9.1.2"
    </IfModule>
    </FilesMatch>
    # END W3TC Browser Cache

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

  3. aokijam
    Member
    Posted 3 years ago #

    Thanks!

  4. 040hosting
    Member
    Posted 3 years ago #

    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.

  5. chovy
    Member
    Posted 3 years ago #

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

  6. I changed it back after install. Worked fine.

  7. 040hosting
    Member
    Posted 3 years ago #

    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.

  8. 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.

  9. 040hosting
    Member
    Posted 3 years ago #

    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.

  10. 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.

  11. chovy
    Member
    Posted 3 years ago #

    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"

  12. 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.

  13. chovy
    Member
    Posted 3 years ago #

    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.

  14. Frederick Townes
    Member
    Posted 3 years ago #

    Excellent thread. Any other questions?

  15. 040hosting
    Member
    Posted 3 years ago #

    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.

  16. Frederick Townes
    Member
    Posted 3 years ago #

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

  17. @040hosting,

    If you are on a shared host with suPHP you should never get the 777 notice unless there are configuration problems with the server because the plugin will be able to write to the file.

    This is the same notification system WordPress uses when it can't write to a file like when you change your permalink settings are use the theme editor.

    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"

    @chovy, The error message fixes and the install instructions all work copy and paste directly in to an ssh command prompt.

  18. Frederick Townes
    Member
    Posted 3 years ago #

    Thanks @c3mdigital

Topic Closed

This topic has been closed to new replies.

About this Topic