[resolved] nginx + php-fpm + PHP APC + WordPress multisite (subdirectory) + WP Super Cache (59 posts)

  1. bigsite
    Posted 4 years ago #

    @Bowe - To answer your questions:

    1: Is there a reason why you chose Super Cache over W3 Total Cache? I thought the later was better, but if you have a fully working Super Cache setup with Nginx I might go for Super Cache

    We chose WP Super Cache because we were previously using WP Cache 2 upon which WP Super Cache is based. Our setup is fully functional on WP Super Cache. We tried to use W3 Total Cache around the time WP 3.0 came out and ended up White Screening (WSOD) the whole site - that disaster took a whole day to fix. IMO, WP Super Cache is the easier and more stable static caching plugin. They are both comparable in feature set but I'm more familiar and comfortable with WP Cache 2.

    2: How have you set up your CDN? Do you use W3 Total Cache for that, or a different plugin? And does that also need rewrites to work? (since .htaccess does not work on NGinx).

    We don't use a CDN (yet). Still, WP Super Cache should be rewriting the page content to point at the configured CDN prior to caching the page in the file system. From the nginx perspective, this is transparent and therefore no changes to the nginx configuration should be required unless, of course, you host your own CDN.

  2. bigsite
    Posted 4 years ago #

    Cleaned up the Codex with the updated set of configs and tried to make it more general-purpose. Removed the initial "broken" server {} block that was posted since a "try_files $uri =404;" line in a \.php$ location {} block is critical unless the person running nginx knows exactly what they are doing. Also, the correct practice is to use upstream {} blocks for setting up fastcgi servers. Having two configs on the same page was also a bit confusing.

    But, other than those issues, the Codex page looks pretty good to me. We just need W3 Total Cache rules and someone to test out the regular WP rules and someone else to see if subdirectory rules work with subdomain as-is. Looking forward to seeing nginx being used more widely now.

  3. PaBLoX
    Posted 4 years ago #

    Cool, thanks for cleaning it up, I just wanted to create the page, so someone with more experience could see it.

    I was wondering why with your configuration I can see the new sites localhost/site-1, localhost/site-2, but not the main one? (it was working before creating the network), it shows a blank page without throwing any error. Any clues where to look?

  4. bigsite
    Posted 4 years ago #

    @PaBLoX - A WSOD indicates an error probably happened somewhere and PHP stopped processing when it encountered the error. Check your server logs since PHP and other errors will show up there. I can only guess as to the cause at this point.

    Be aware that not all plugins are WP multisite/network-aware. WP 3.0 finally forced the issue onto plugin authors so the situation is improving slightly.

  5. zsiddique
    Posted 4 years ago #

    I have an EC2 Ubuntu I am using for testing purposes of nginx and I am running WordPress Multisite w/subdomains and on top domain mapper plugin. The Codex and recommendation here work flawless in all aspect BUT Super Cache.

    As soon as I enable Super Cache after any posting or uploading of theme will cause the blog to throw 500 error. Worst inspecting error.log for nginx and php5-fpm logs show nothing reported so its like I am in the dark. Also whats really odd is other php scripts that relay on php5-fpm are working correctly like nothing happen. Restarting php5-fpm resolves the issue but its really points to some issue with Super Cache that I cant figure out.

    Now I suspect the issue might be just Super Cache issue with nginx but seeing as others in this thread have gotten it work maybe I am missing a step or setting. Any recommendation or idea where I should start looking? I had this problem before trying the nginx configurations here as I was using my own and was hoping maybe this one would resolve my super cache problems.

    Server info:
    Ubuntu Server 10.10 x64
    PHP 5.3.3-1ubuntu9.3 (fpm-fcgi) (built: Jan 12 2011 16:07:41)
    nginx version: nginx/0.8.54

  6. zsiddique
    Posted 4 years ago #


    So enabled wp_debug I got the following error:

    Fatal error: Internal Zend error - Missing class information for in /var/www/<domain.com>/public/wp-content/plugins/wp-super-cache/wp-cache-base.php on line 5


  7. bigsite
    Posted 4 years ago #

    @zsiddique - Try reinstalling the WP Super Cache plugin. I always use the latest development version instead of whatever the official release is. If you have used another caching plugin in the past with your site, that can cause strange conflicts with WP Super Cache. I had weird issues with upgrading to WP Super Cache from WP Cache 2 until I completely deleted all files related to WP Cache 2.

    Also, you aren't running the latest version of PHP.

  8. zsiddique
    Posted 4 years ago #

    @bigsite - As this is a test site I nuked the whole installation (drop tables and files) and started fresh to troubleshoot the issue. The site is 100% stable without super cache. Enable Super Cache and after some traffic it would start to throw the Zend Error.

    Some googling on the Zend error point to possible PHP - APC issue. I have for now disabled APC to see if this resolves the issue. If you have some recommendation on things to check for APC that would be great.

    PHP 5.3.3 is the lastest that comes built with Ubuntu and I have not found any good Ubuntu PPA that provide a latest build. But 5.3.3 is not *that* out of date and I know some web host that have public PHP builds that are older. But I might try to upgrade PHP if their is a strong reason that it will resolve the issue.

  9. bigsite
    Posted 4 years ago #

    @zsiddique - Build PHP from source. There are lots of examples around on how to build PHP from source for Ubuntu. If you use PHP APC, you want the latest PECL version of PHP APC and the latest version of PHP.

  10. bigsite
    Posted 4 years ago #

    Looks like the latest development version of WP Super Cache now includes differentiation between http and https served content. I've updated the Codex to reflect this significant change.

    Supposedly there is some better mobile theme support (i.e. actual caching for mobile themes instead of the current cache bypass) in the development version of the WP Super Cache plugin as well but is kind of hacky and I'm not seeing any rewrite rule modifications yet.

  11. bigsite
    Posted 4 years ago #

    We just updated to nginx 1.0.0 and it overwrote the SCRIPT_URI addition to the 'fastcgi_params' file. Maybe it wasn't smart to modify that file. Dropped the change into the global/wordpress-ms-subdir.conf file and that resolved the issue (again).

  12. Dan Collis-Puro
    Posted 4 years ago #

    This looks much, much more complicated than the solution we've been running at blogs.law.harvard.edu for a long time now.

    The short version:

    Nginx sits in front of apache, caching based on simple regex patterns: instructions and my (very simple) plugin here.

    Apache runs wordpress essentially unmodified, except it binds to an internal IP or alternate port. It uses mod_rpaf to see client requests transparently, allowing you to apply ip access controls (LDAP is a biggie for us) at the apache / wordpress level. It knows nothing of the cache, really, except that it should tell the upstream nginx cache to not cache authenticated page requests. We use apc and the apc object cache on the backend wordpress apache with 256meg of shared apc RAM.

    That's pretty much it. nginx handles caching and serving from the cache. There's no rewriting trickery, nginx handles compression, cache reaping, flood protection and you can easily mix content from other apps via separate proxy rules.

    Apache is a great app server, easy to tweak, tons of features and when fronted with a lightweight caching proxy like nginx it's a killer combo. Once you've got nginx caching for you, I just can't see where factoring apache out of the equation is going to get you much. In our setup, apache pretty much just stitches dynamic PHP together when needed - it's great at that.

    Ah well, different strokes. I'm a big fan of reducing moving parts, though.

  13. Big fan of nginx here too. Our server barely blips.

  14. bigsite
    Posted 4 years ago #

    @Dan Collis-Puro - Unfortunately it is not possible to do that here. Running Apache would require us to eliminate PHP APC. Also, a number of custom plugins would break. nginx works fine and, really, that part of the setup is a lot simpler than you might think - especially since the creation of the nginx configuration entry in the Codex based heavily on this thread.

  15. Dan Collis-Puro
    Posted 4 years ago #

    @bigsite: you must mean something other than APC, because APC works great with an apache backend and it's a big part of our infrastructure.

    I stand by my "simpler is better" assertion. We host around 5 million page views a month on http://blogs.law.harvard.edu with one app server and one DB server because of our nginx proxy cache.

  16. Dan Collis-Puro
    Posted 4 years ago #

    That sounded like I said it with a sneer - sorry. No offense intended.

  17. bigsite
    Posted 4 years ago #

    @Dan Collis-Puro - I understand that and use that combination on personal servers without any issues. We definitely tried Apache + PHP + PHP APC first, but there were some really bizarre things going on with that combination on our specific setup. Turning off PHP APC resolved the issues, turning it back on resulted in the issues coming back. So, by process of elimination, PHP APC was definitely the cause. Switching to nginx and php-fpm is the only way we've found that allows us to run PHP APC without nearly as many issues on our specific setup. We still get the occasional hiccup but it isn't nearly as bad as it was and we're relatively happy at the moment.

  18. Per Hansson
    Posted 4 years ago #

    Hi, does anyone have an example config where WordPress is located in a subdirectory like /blog?
    I've been scratching my head all night trying to get it to work but I must be doing something wrong...

    This would be for a dedicated server with only one WordPress blog, right now I'm using these IF based rules, I simply call them from my main nginx.conf with a "location /blog/ {include blog.conf}" rule...


    I'm running WP Super Cache v0.9.9.9
    nginx Compatibility Plugin (PHP5) v0.2.5
    nginx v1.0.2 /w php-fpm & php-xcache

  19. Per Hansson
    Posted 4 years ago #

    Ok, I've done some more testing.
    The WP Super Cache files are actually sent properly when guests are visiting the site now.
    But if I try logging in I get a 404 error when trying to view a cached page.

    Here are links to Pastebins of my config (note the changes done because my WP is located under /blog)
    nginx.conf: http://pastebin.com/9yRbkNag
    wordpress-wp-super-cache.conf: http://pastebin.com/pvWrYi7Y

    Here below are two nginx debug logs, the first is the guest visiting a cached page, it works fine then. Cached content is served directly by nginx...

    The second log shows me when I'm logged into WP, I get a 404 visiting the same cached page, it can be seen that I'm getting redirected to a non-existant index.php file, but I don't understand why this is not processed by the WP index.php instead of being sent directly... (I guess I must be missing some argument or something?)

    ------NOT LOGGED IN------
    ACCESS LOG: - - [11/Jun/2011:17:02:46 +0200] "GET /blog/224/slow-system-performance-when-copying-large-files-in-xp-x64-server-2003-x64/ HTTP/1.1" 200 8888 "-" "Mozilla/5.0 (Windows NT 5.2; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.14 Safari/535.1" "-"

    2011/06/11 17:02:46 [notice] 5831#0: *877 "/blog/wp-admin$" does not match "/blog/224/slow-system-performance-when-copying-large-files-in-xp-x64-server-2003-x64/", client:, server: www.techspot.com, request: "GET /blog/224/slow-system-performance-when-copying-large-files-in-xp-x64-server-2003-x64/ HTTP/1.1", host: "www.techspot.com"
    2011/06/11 17:02:46 [notice] 5831#0: *877 "comment_author_|wordpress_logged_in|wp-postpass_" does not match "wp-settings-3=editor%3Dtinymce%26hidetb%3D1%26m0%3Do%26m1%3Do%26m2%3Dc%26m3%3Dc%26m4%3Dc%26m5%3Dc%26m6%3Dc%26m7%3Do%26urlbutton%3Durlfile; wp-settings-time-3=1307791463; wordpress_test_cookie=WP+Cookie+check; __qca=P0-140701392-1307791437086; __utmz=150184883.1307791437.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __csref=http%3A%2F%2Fwww.techspot.com%2Fblog%2F; PHPSESSID=amidaj1ibo8jrtudir3ro2op65; OAID=eea744cbebb14f9b0eafbd910c9ad95d; __utma=150184883.1830416333.1307791437.1307798802.1307804529.3; __utmc=150184883; __utmb=150184883.1.10.1307804529; _chartbeat2=2wtn5ciwhur68ycf; __cst=e8b136d46eff2fb9; __csv=40d5006bb94c8f3d|0; __csnv=866a21ee5c0ec749; __ctl=40d5006bb94c8f3d1", client:, server: www.techspot.com, request: "GET /blog/224/slow-system-performance-when-copying-large-files-in-xp-x64-server-2003-x64/ HTTP/1.1", host: "www.techspot.com"
    2011/06/11 17:02:46 [notice] 5831#0: *877 "^" matches "/blog/224/slow-system-performance-when-copying-large-files-in-xp-x64-server-2003-x64/", client:, server: www.techspot.com, request: "GET /blog/224/slow-system-performance-when-copying-large-files-in-xp-x64-server-2003-x64/ HTTP/1.1", host: "www.techspot.com"
    2011/06/11 17:02:46 [notice] 5831#0: *877 rewritten data: "/blog/wp-content/cache/supercache/www.techspot.com/blog/224/slow-system-performance-when-copying-large-files-in-xp-x64-server-2003-x64/index.html", args: "", client:, server: www.techspot.com, request: "GET /blog/224/slow-system-performance-when-copying-large-files-in-xp-x64-server-2003-x64/ HTTP/1.1", host: "www.techspot.com"
    --------LOGGED IN------
    ACCESS LOG: - - [11/Jun/2011:16:59:11 +0200] "GET /blog/224/slow-system-performance-when-copying-large-files-in-xp-x64-server-2003-x64/ HTTP/1.1" 404 4215 "-" "Mozilla/5.0 (Windows NT 5.2; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.14 Safari/535.1" "-"
    2011/06/11 16:59:11 [notice] 5831#0: *858 "/blog/wp-admin$" does not match "/blog/224/slow-system-performance-when-copying-large-files-in-xp-x64-server-2003-x64/", client:, server: www.techspot.com, request: "GET /blog/224/slow-system-performance-when-copying-large-files-in-xp-x64-server-2003-x64/ HTTP/1.1", host: "www.techspot.com"
    2011/06/11 16:59:11 [notice] 5831#0: *858 "comment_author_|wordpress_logged_in|wp-postpass_" matches "wp-settings-3=editor%3Dtinymce%26hidetb%3D1%26m0%3Do%26m1%3Do%26m2%3Dc%26m3%3Dc%26m4%3Dc%26m5%3Dc%26m6%3Dc%26m7%3Do%26urlbutton%3Durlfile; wp-settings-time-3=1307791463; wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_8e18665c8a3d51ae0c46bce33a7db0f9=Per+Hansson%7C1307973397%7Cd976f9534bac73ff37d767ff5d505749; __qca=P0-140701392-1307791437086; __utmz=150184883.1307791437.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __csref=http%3A%2F%2Fwww.techspot.com%2Fblog%2F; PHPSESSID=amidaj1ibo8jrtudir3ro2op65; OAID=eea744cbebb14f9b0eafbd910c9ad95d; __utma=150184883.1830416333.1307791437.1307791437.1307798802.2; __utmc=150184883; _chartbeat2=2wtn5ciwhur68ycf; __cst=e8b136d46eff2fb9; __csv=40d5006bb94c8f3d|0; __csnv=cd31f2be9e5e17f9", client:, server: www.techspot.com, request: "GET /blog/224/slow-system-performance-when-copying-large-files-in-xp-x64-server-2003-x64/ HTTP/1.1", host: "www.techspot.com"
    2011/06/11 16:59:11 [error] 5831#0: *858 "/var/www/html/blog/224/slow-system-performance-when-copying-large-files-in-xp-x64-server-2003-x64/index.php" is not found (2: No such file or directory), client:, server: www.techspot.com, request: "GET /blog/224/slow-system-performance-when-copying-large-files-in-xp-x64-server-2003-x64/ HTTP/1.1", host: "www.techspot.com"
  20. bigsite
    Posted 4 years ago #

    @Per Hansson - Your configuration is really screwy. Most obvious problem is that you can't have 'try_files' and 'if'/'rewrite' in the same 'location' block. They are two separate modules that can't be mixed. See the official 'IfIsEvil' Nginx documentation, which barely covers this rather critical topic.

  21. @bigsite

    Recently I upgrade WP Super Cache to development version. It has a debug mode in this version so I can see what WP Super Cache does. Then I just found this problem:

    If someone sets his own domain in Domain Mapping, Images uploaded by users won't bypass PHP. Here's the log:

    07:56:36 /files/2011/05/student-work-s2-02.jpg supercache dir: /srv/www/mysite.tld/public_html/wp-content/cache/supercache/customdomain.tld/files/2011/05/student-work-s2-02.jpg/
    07:56:36 /files/2011/05/student-work-s2-02.jpg No wp-cache file exists. Must generate a new one.

    Any good idea?

    UPDATE: #1. Later I went to /srv/www/mysite.tld/public_html/wp-content/cache/supercache/customdomain.tld/, actually no folder named files was created.

    #2. I've enabled Domain Mapping plugins in WP Super Cache Plugin tab.

  22. Donncha O Caoimh
    Posted 3 years ago #

    PHP is used to serve images unfortunately. On my site I added rewrite rules to bypass those and serve the files directly but I had to add one rule per site so it's only useful if you're running a network that doesn't allow users to create new blogs.

  23. @Donncha:

    I got it, I'm running a multisite instance for some of my friends. Could you share your rules? Thanks.

  24. Donncha O Caoimh
    Posted 3 years ago #

    They're mod_rewrite rules, not Nginx ones but they look like this:

    RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
    RewriteRule ^files/(.+) wp-content/blogs.dir/X/files/$1 [L]
  25. Thanks Donncha, I converted it to nginx version:

    if ($http_host ~* domain.tld) {
      rewrite ^/files/(.+) /wp-content/blogs.dir/X/files/$1 break;

    Add this before $cachetest in wp-ms-subdir.conf, it works but I think there should be a better and more effective method.

  26. usera
    Posted 3 years ago #

    anyone using a sitemap plugin for a multisite multidomain nginx config? None that I've tried created the sitemap...

    Thanks for any info.

  27. abrasmelin
    Posted 3 years ago #

    great guide bigsite thank you but i just wonder what is this for?

    # Upstream to abstract backend connection(s) for PHP.
    	upstream php {
            	server unix:/tmp/php-fpm.sock;
    #       	server;

    i am using php-fpm but i have looked at /tmp/ folder and there is no php-fpm.sock in there.

  28. Gonçalo Peres
    Posted 3 years ago #


    Here is my version for the PHP script that generates symbolic links from the names of the blogs to the numeric (ID) representation of each blog.
    Just place this script in the WordPress installation root and run it each time you had a new site/blog to your multisite.

    require_once "wp-load.php";
    @ini_set('display_errors', 'On');
    $blogs = $wpdb->get_results($wpdb->prepare("SELECT blog_id, domain, path FROM " . $wpdb->blogs . " WHERE site_id = %d AND archived = '0' AND mature = '0' AND spam = '0' AND deleted = '0' AND blog_id <> 1 AND last_updated <> '0000-00-00 00:00:00'", $wpdb->siteid));
    if ($blogs)
      // Generate new symbolic links for uploaded files for each blog.
      foreach ($blogs as $blog)
        $path = ABSPATH."wp-content/cache/ms-filemap/" . $blog->domain;
        //if (!is_dir($path))  @mkdir($path, 0777, true);
        $path .= $blog->path;
        $path = substr($path, 0, -1);
        if (!is_dir($path))  symlink(ABSPATH."wp-content/blogs.dir/" . $blog->blog_id . "/", $path);
  29. Gonçalo Peres
    Posted 3 years ago #

    Warning: please don't put "ms-filemap/" inside "cache/" directory. If you use WP Super Cache and press "Delete Cache on All Blogs", all your uploaded images will be deleted. Instead, place "ms-filemap/" inside "wp-content/".
    So, if you are using Bigsite's excellent approach, wherever it says "wp-content/cache/ms-filemap/", replace it with "wp-content/ms-filemap/" and you should be good (including the script in my previous post, right above).


Topic Closed

This topic has been closed to new replies.

About this Topic