Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

I have a multisite blog that will soon have an Akamai caching service sitting in front of it, serving cached content to visitors (15 minute TTL).

I want to configure Akamai to exclude any important URLs that should never be cached (i.e., don't want to serve cached login/admin pages). Is there a compilation, or general recommendation, of all important URLs that should never be cached? Here's what I've got so far:

  • /wp-* (This would prevent wp-includes/admins/etc)
  • /xmlrpc.php
  • Any URL with with ?preview=true so that editors can preview

Edit: Additional info below

We are using Akamai edge cache, which is full site caching. Basically, Akamai acts as a reverse proxy server. Our DNS is pointing at Akamai, visitors hit Akamai directly. Akamai only hits us to update pages when TTL expires, or when a page is requested that isn't already cached.

We have the ability to exclude parts of the site from being fully cached, for example URLs matching wp-*, or any urls with the query string preview=true. Exclusions do allow cookies to be passed through; POST requests are also allowed.

With this additional info, the original question still remains -- what WP-specific URLs/paths/etc need to be excluded from the full-site caching to prevent things from breaking? E.g., previews obviously need to be dynamic by nature, so I've excluded that by allowing preview=true query string. What else do I need to exclude? Is anything matching wp-* good enough, or are other things missing, i.e. /xmlrpc.php?

I hope things brings some additional context to the original question.

share|improve this question
    
Honestly, this sounds like an Akamai question, not a WP question ... which would make it off-topic here. –  EAMann Dec 7 '12 at 17:55
3  
@EAMann If you take Akamai out of the equation, and replace it with any caching service/mechanism, the question still remains: what WP-specific things should be excluded from cache? –  Kai Dec 7 '12 at 18:00
    
CDN is not the same as caching, so unless you use akamai in a way I don't know of, your analogy is baseless. For example you don't cache your JS, but you need to CDN it, therefor blindly blocking wp-includes doesn't sound right unless you load your jquery from some other place. –  Mark Kaplun Dec 7 '12 at 18:22
    
@MarkKaplun Yes, we are using Akamai in a way you don't know of. I've added additional info to the original question. –  Kai Dec 8 '12 at 5:21

3 Answers 3

up vote 3 down vote accepted
+50

You should not cache anything in the admin so your examples are correct.

A typical nginx reverse proxy cache is set to ignore wp\-.*\.php|wp\-admin

Another option is to not cache logged in users by checking the wp cookies, but you probably don't have that level of control.

ps. It is highly advisable you test this out before flipping the switch.

tl;dr You should be fine with a vanilla install.

share|improve this answer

I don't believe Akamai actually caches the entire page. Any publicly available static resource is fine to cache and would have no bearing on the functionality of the site -- even if it were on the login page or in the dashboard.

So you don't need to do any blocking.

The same can't be said for something like W3 Total Cache, but that's solved by simply not serving cached files to logged in users or excluding specific theme or plugin files.

share|improve this answer
    
Akamai is more than a simple CDN; we are actually caching the entire page. See updated question above. –  Kai Dec 8 '12 at 5:22

You are using akamai as web caching server so maybe it will help if you look for tips on using squid, which is a popular web caching tool, with wordpress.

The thing with caching is that you don't want an HTML which was tailored for a specific user to be cached, and the proper way to do it when working with standard conforming web caches is to set the http "Cache-Control" header to something like "no-cache, must-revalidate, max-age=0", which is exactly what wordpress is sending when a user is logged in, so you might actually be OK without doing any configuration.

If you have the ability to exclude by cookie then maybe you should add protection and exclude when the log in cookie is set (don't remember the exact name) and the same for the commenter cookie if you have comments enabled so commenters will be able to see their own comments after submitting them.

If after that you still feel like excluding specific files then do it only for php files , as you want the js,css and images under /wp-inculde to be CDNed. Maybe just exclude all php files except for /index.php

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.