Support » Plugin: W3 Total Cache » W3TC’s php_flag causing 500 Internal Server Error

  • Hello,

    On one of my sites, when I install the latest version of W3TC, I get a 500 Internal Server Error because W3TC adds…

    <IfModule mod_php5.c>
        php_flag session.use_only_cookies off
    <IfModule mod_php7.c>
        php_flag session.use_only_cookies off
    <IfModule mod_suphp.c>
        php_flag session.use_only_cookies off

    These php_flags cause the following error in my logs…

    /public_html/.htaccess: Invalid command 'php_flag', perhaps misspelled or defined by a module not included in the server configuration, referer:

    I believe php_flag isn’t supported by my server. The strange thing is that I have W3TC on several sites on the same server and php_flag isn’t added to the htaccess files for them and no errors are produced. But with this one site, no matter what I do W3TC always adds php_flag and breaks the site.

    How do I stop W3TC from adding php_flag to my htaccess file?


Viewing 6 replies - 1 through 6 (of 6 total)
  • I also have this issue. Its just cropped up in the last few days.

    as a temporary fix I changed my .htaccess permissions to 444 (removing write access from the plugin) then removed the php_flag lines and saved.

    Until there is a fix I will need to remain this way. Does anyone know the actual settings that set the php_flag variables? I’m thinking its on the Browser cache page


    I think I have a solution that will help until a plugin update is done

    Go to your browser cache settings page in w3tc (/wp-admin/admin.php?page=w3tc_browsercache)

    For me I changed the first 3 settings under Security Headers to “leave as is” – they were set to enabled before that.

    This removed the 3 php_flag options that caused my problems.

    Here is a screenshot

    Yup way back last year when w3tc-fixed (the community version of w3tc) was first to implement Security Headers — so before the official W3TC finally inserted their code in v0.9.7 — they discovered this problem of php_flag not being universally compatible with servers so they removed the php_flag setting from htaccess/nginx.conf and made them into @ini_set function calls within php instead which when you think about it makes more sense since these specific ones relate to session cookies:


    And because these sessions cookies are only set prior to caching (via the session_start() function call) it should only be defined when a cache is going to occur not repeatedly on existing cached files.

    disk:enhanced existing cached files dont pass session cookies to visitors (since cookies aren’t cached by it) so having the php_flag in the htaccess is not technically the best place for it; and as you have found has lead to incompatibility issues. Instead, it should be set via @ini_set in BrowserCache_Plugin.php.

    It seems when the author took the Security Headers code from the community build he mistakenly put back php_flag for the official w3tc latest release, not realizing the discussion those folks over there had about the issue, which is why this once fixed problem has now returned. 🙁

    Anyway, to fix this yourself isn’t difficult. Just do the following:

    1. Open “BrowserCache_Environment.php
    2. Go to line 337 and 675. Replace: $sec = ''; with: /*$sec = '';
    3. Go to line 364 and 693. Replace: } with: }*/
    4. Open “BrowserCache_Plugin.php
    5. Go to line 43. There should just be }. Insert a new blank line before it.
    6. Add the following code:
    7. $v = $this->_config->get_string( '' );
      if ( !empty( $v ) ) {
      	@ini_set( 'session.cookie_httponly', $v == 'on' ? '1': '0' );
      $v = $this->_config->get_string( '' );
      if ( !empty( $v ) ) {
      	@ini_set( 'session.cookie_secure', $v == 'on' ? '1': '0' );
      $v = $this->_config->get_string( '' );
      if ( !empty( $v ) ) {
      	@ini_set( 'session.use_only_cookies', $v == 'on' ? '1': '0' );
    8. Save both modified files and upload them back to your host.

    Thanks for the suggestion, @fistfullofcrisco. I remember that problem from the first time I ever installed W3TC and it was the community build I eventually used that fixed the problem. Too bad the official build went and broke things again. The only reason I didn’t go with this patch is I’m afraid the files may get overwritten in the future if the problem still isn’t fixed.

    Thanks also, @timeassistant. I made this recommendation work. Although it was a little tricky as the WP Admin and therefore W3TC settings pages can’t be reached with the 500 error. So I commented (#) out the php_flags in the htaccess file so I could access WP Admin but with every page switch/load W3TC would overwrite my comments so I had to keep commenting out the flags every time. At first I saw the Security Headers were already set to “Leave as is” and didn’t think this would work. I tried switching them to “Disable” which produced even more php_flags, but then tried switching them back to “Leave as is” and this finally removed the flags!

    I hope W3TC fixes this problem. I’d imagine lots of people must be experiencing this.

    Thanks again!


    you are very welcome, although when removing the php_flags and aftersaving the file you should change the file permissions (chmod) on the .htaccess file to 444 removing the write access, that stops w3tc overwriting it until you can try @fistfullofcrisco recommendation or get into the browser cache page to remove the settings.



    I am sorry to hear about the issues that you are facing. Please keep in
    mind that we are always trying to keep the plugin updated and with
    any release we are trying to apply as many fixes as possible. Indeed
    php_flags are not 100 percent compatible with all environments but
    you can add comments in front of those entries or alternatively, you
    can add those values using a php.ini / user.ini depending on your
    hosting company.

    I hope this helps and if there is anything else, please feel free to ask.

    Thank you for using W3 Total Cache.
    Kind regards!
    Bogdan S.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘W3TC’s php_flag causing 500 Internal Server Error’ is closed to new replies.