The MU forums have moved to WordPress.org

WPMU, WP Super Cache & using virtual conf instead of .htaccess (9 posts)

  1. webmaestro
    Member
    Posted 15 years ago #

    NOTE:
    Cross-posting from [Plugin: WP Super Cache] httpd.conf or .htaccess for Apache Directives?, since the moderator thinks this should stay in MU land... Please forgive the cross-post!

    We've implemented WP Super Cache 0.8.2 in our WordPressMU 2.6.1 install, and are having intermittent success seeing 'cached' pages. I'm not so concerned about LOGGED in users. However, it's imperative that POST pages are cached via WP Super Cache, so we can handle a DIGG or Slashdot event.

    CURRENT CACHING RUN-DOWN:

    LOGGED IN BROWSERS:
    no caching ever, and shows this:

    <!-- Dynamic Page Served (once) in 2.005 seconds -->

    NON-LOGGED IN AND NO COMMENT:
    Not Logged In Safari on HOME page And haven't commented
    http://lansner.freedomblogging.com/

    <!-- Dynamic Page Served (once) in 3.341 seconds -->
    <!-- super cache gz -->

    NOT LOGGED IN In Safari on POST page And haven't commented
    http://lansner.freedomblogging.com/2008/10/06/59-say-economic-depression-likely-do-you-agree/4393

    <!-- Dynamic Page Served (once) in 3.287 seconds -->
    <!-- Cached page served by WP-Cache -->
    <!-- Compression = gzip -->

    NOT LOGGED IN Safari on POST page And just commented
    http://lansner.freedomblogging.com/2008/10/06/59-say-economic-depression-likely-do-you-agree/4393

    <!-- Dynamic Page Served (once) in 8.100 seconds -->
    <!-- Cached page served by WP-Cache -->
    <!-- Compression = gzip -->
  2. webmaestro
    Member
    Posted 15 years ago #

    And here's our httpd virtual conf file:

    <VirtualHost *>
      ServerName http://www.domain.com
      ServerAlias domain.com
      ServerAdmin support@domain.com
      DocumentRoot /path/to/wordpress-mu-X.Y.Z/
    
      LogLevel warn
      ErrorLog /var/apache/logs/wpmu_error_log
      CustomLog /var/apache/logs/wpmu_access_log combined
      RewriteLog "/var/log/apache/rewrite.log"
      RewriteLogLevel 0
    
      <Directory "/path/to/wordpress-mu-X.Y.Z">
        AllowOverride All
        Order Deny,Allow
        Allow from all
    
        RewriteEngine On
    
        FileETag INode MTime Size
        #ExpiresActive On
        #ExpiresDefault "modification plus 30 minutes"
        #<FilesMatch "\\.(html|htm|php|jpg|gif|txt)$">
        #Header set Cache-Control "max-age=1h, only-if-cached"
        #</FilesMatch>  
    
        RewriteBase /
    
        #uploaded files
        RewriteRule ^(.*/)?files/$ index.php [L]
        #RewriteCond %{REQUEST_URI} !.*wp-content/plugins.*
        RewriteRule ^(.*/)?files/(.*) wp-content/blogs.php?file=$2 [L]
    
        # add a trailing slash to /wp-admin
        RewriteCond %{REQUEST_URI} ^.*/wp-admin$
        RewriteRule ^(.+)$ $1/ [R=301,L]
    
        RewriteCond %{REQUEST_FILENAME} -f [OR]
        RewriteCond %{REQUEST_FILENAME} -d
        RewriteRule . - [L]
        RewriteRule  ^([_0-9a-zA-Z-]+/)?(wp-.*) $2 [L]
        RewriteRule  ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
        RewriteRule . index.php [L]
    
        <IfModule mod_security.c>
          <Files async-upload.php>
            SecFilterEngine Off
            SecFilterScanPOST Off
          </Files>
        </IfModule>
    
        # BEGIN WPSuperCache
        RewriteCond %{REQUEST_METHOD} !=POST
        RewriteCond %{QUERY_STRING} !.*=.*
        RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
        RewriteCond %{HTTP:Accept-Encoding} gzip
        RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
        RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L]
    
        RewriteCond %{REQUEST_METHOD} !=POST
        RewriteCond %{QUERY_STRING} !.*=.*
        RewriteCond %{QUERY_STRING} !.*attachment_id=.*
        RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
        RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
        RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L]
    
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule . /index.php [L]
        # END WPSuperCache
      </Directory>
    
      # BEGIN supercache
      <Directory "/path/to/wordpress-mu-X.Y.Z/wp-content/cache">
        <IfModule mod_mime.c>
            AddEncoding x-gzip .gz
            AddType text/html .gz
        </IfModule>
        <IfModule mod_deflate.c>
            SetEnvIfNoCase Request_URI \.gz$ no-gzip
        </IfModule>
        <IfModule mod_headers.c>
            Header set Cache-Control 'max-age=300, must-revalidate'
        </IfModule>
        <IfModule mod_expires.c>
            ExpiresActive On
            ExpiresByType text/html A300
        </IfModule>
      </Directory>
      # END supercache
    
    </VirtualHost>
  3. webmaestro
    Member
    Posted 15 years ago #

    As a quick follow-up... There are a couple of reasons I ended up going the httpd virtual conf route. The first reason, was because I was unsuccessful doing it via the .htaccess method, but was able to get it working by inserting the changes via the httpd virtual conf file. In addition, almost everywhere I look, I am advised not to use .htaccess if at all possible:

    In general, you should never use .htaccess files unless you don't have access to the main server configuration file. There is, for example, a prevailing misconception that user authentication should always be done in .htaccess files. This is simply not the case. You can put user authentication configurations in the main server configuration, and this is, in fact, the preferred way to do things.

    .htaccess files should be used in a case where the content providers need to make configuration changes to the server on a per-directory basis, but do not have root access on the server system. In the event that the server administrator is not willing to make frequent configuration changes, it might be desirable to permit individual users to make these changes in .htaccess files for themselves. This is particularly true, for example, in cases where ISPs are hosting multiple user sites on a single machine, and want their users to be able to alter their configuration.

    Since I have access to the main server configuration files, I would like to be able to make it work (and I believe we'll have greater performance if Apache doesn't have to search for .htaccess files). Your insight has so far proved invaluable, and is much appreciated!

    NOTE: You'll notice I have AllowOverride All enabled, but I wasn't able to get CACHING to work without it enabled. I've also got a file at /path/to/wordpress-mu-X.Y.Z/wp-content/cache/.htaccess, which includes the following content:

    <IfModule mod_mime.c>
          AddEncoding x-gzip .gz
          AddType text/html .gz
        </IfModule>
        <IfModule mod_deflate.c>
          SetEnvIfNoCase Request_URI \.gz$ no-gzip
        </IfModule>
        <IfModule mod_headers.c>
          Header set Cache-Control 'max-age=300, must-revalidate'
        </IfModule>
        <IfModule mod_expires.c>
          ExpiresActive On
          ExpiresByType text/html A300
        </IfModule>
  4. webmaestro
    Member
    Posted 15 years ago #

    I think the issue lies in the RewriteRule directives. Anyone have ideas?

    At present, our servers are processing POST (article) page requests via WP-Cache which is good, but they really need to be handled by Super Cache, so PHP processing is not required for the bulk of the server load.

    Also, I would think there should be an option for using httpd virtual conf (vhost) files instead of .htaccess, but WP Super Cache has an error msg in its config page. Would it be possible to hard-code a value in wp-cache-config.php (or somewhere) that indicates the config is not being handled via .htaccess?

  5. Otto42
    Member
    Posted 15 years ago #

    Like I said on the other forum, move the super-cache rules ABOVE all other rules. It won't work otherwise.

  6. webmaestro
    Member
    Posted 15 years ago #

    D'oh! I had the Super Cache RewriteRules above, but during one of my restarts, I had an error and had to revert to an earlier version (in which the Super Cache RewriteRuleshad not been moved up).

    Thanks for the catch! I'll implement the change, and restart the servers later this morning.

  7. webmaestro
    Member
    Posted 15 years ago #

    This was resolved. Thank you for your help!

  8. famous
    Member
    Posted 15 years ago #

    WordPress MU Detected

    Unfortunately the rewrite rules cannot be updated automatically when running WordPress MU. Please open your .htaccess and add the following mod_rewrite rules above any other rules in that file.
    I have a problem I pasted the part below the above, however it still shows yellow?

    And this shows:
    WARNING! /home/journ19/public_html/ is writable. Please make it readonly after your page is generated as this is a security risk.

    I tried changing it to 750 but the webpage no longer shows?

    Also, is there any way to keep the homepage from using too much resources on the server? Is the above the best solution (super cache)?

  9. Ovidiu
    Member
    Posted 15 years ago #

    @Otto42

    regarding this putting the lines for super cache above all others, I have implemented some of donncha's rules for stopping spammers and I think the best solution is to keep those rules above the super cache rules as the cache is only interesting after the spammers have been stopped. does this work out like that?

About this Topic

  • Started 15 years ago by webmaestro
  • Latest reply from Ovidiu