Related

Tool NGINX Config Generator Tool
How to install wordpress on a subdirectory Question Question
having issues with nginx varnish and wordpress Question Question

Question

Nginx with Kirby CMS at web root and WordPress in a subdirectory

Posted March 1, 2017 3.8k views
NginxWordPressUbuntu 16.04

Hey, I’m having some trouble setting up a site that uses Kirby CMS for the main site and WordPress in a subdirectory for a subsite.

I’ve done a lot of trial and error, and while the homepage and WordPress admin panel are working, WordPress inner pages are resulting in the Kirby CMS 404 page. I’ve tried the same configuration in a VM locally that has it working, but I can’t seem to get the subdirectory location block working on DigitalOcean.

I’ve included the server block from the nginx config below.

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name www.domain.com;
    root /home/forge/www.domain.com/public;

    # ssl info...

    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Content-Type-Options "nosniff";

    index index.html index.htm index.php;

    charset utf-8;

    # FORGE CONFIG (DOT NOT REMOVE!)
    include forge-conf/www.domain.com/server/*;

    ##############################
    ## Kirby configuration
    ##############################

    if (!-e $request_filename){
      rewrite ^/panel/(.*) /panel/index.php break;
    }

    if (!-e $request_filename) {
      rewrite ^/(.*)$ /index.php last;
      break;
    }

    location /content {
      rewrite ^/content/(.*)\.(txt|md|mdown)$ /error redirect;
    }

    location /site {
      rewrite ^/site/(.*) /error redirect;
    }

    location /kirby {
      rewrite ^/kirby/(.*) /error redirect;
    }

    location ~* \.(ico|css|js|gif|jpeg|jpg|png|woff|ttf|otf|svg|woff2|eot)$ {
        expires 1M;
        add_header Pragma public;
        add_header Cache-Control "public";
    }

    ##############################
    ## End Kirby CMS configuration
    ##############################

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # Subsite
    location /subdir {
        try_files $uri $uri/ /subdir/index.php?$uri&$args;
    }

    # Kirby panel links
    location /panel {
        try_files \$uri \$uri/ /panel/index.php?\$uri&\$args;
    }

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    access_log off;
    error_log  /var/log/nginx/www.domain.com-error.log error;

    error_page 404 /index.php;

    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php/php7.1-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
    }

    location ~ /\.ht {
        deny all;
    }
}

Any suggestions?

Add a comment
spivi
By:
spivi
Add a comment

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
4 answers
jtittle1 March 2, 2017

@spivi

Normally you’d want to use either root or alias on the location block when you’re referencing where files should be pulled from if they are not located in the web root.

So in the above configuration, you’re specifying that this is your web root:

/home/forge/www.domain.com/public

That means that content will be pulled from:

/home/forge/www.domain.com/public/content

site will be pulled from:

/home/forge/www.domain.com/public/site

kirby will be pulled from:

/home/forge/www.domain.com/public/kirby

subdir will be pulled from:

/home/forge/www.domain.com/public/subdir

and panel will be pulled from:

/home/forge/www.domain.com/public/panel

Is that the intended location for each directory? We should start there as much of your rewrites are targeting those directories and unless you need specific functionality, the blocks with rewrites would be much better off written as:

    location /content {
      alias /path/to/content;
    }

    location /site {
      alias /path/to/site;
    }

    location /kirby {
      alias /path/to/kirby;
    }

I would also remove these blocks:

    if (!-e $request_filename){
      rewrite ^/panel/(.*) /panel/index.php break;
    }

    if (!-e $request_filename) {
      rewrite ^/(.*)$ /index.php last;
      break;
    }
Reply Report
spivi March 2, 2017

Thanks @jtittle! I tried the alias directive for the /subdir location block, but it didn’t change the behavior.

Those rules (content, site, kirby, panel, $request_filename) are for blocking Kirby CMS directories. It’s basically a translation of the .htaccess rules here.

The /subdir directory is the one containing the WordPress installation. The links where a file can be found (domain.com/subdir => /subdir/index.php, domain.com/subdir/wp-admin/ => /subdir/wp-admin/index.php, domain.com/subdir/wp-admin/post.php?post=[postnum]&action=edit, etc) work, but when going to a permalink (domain.com/page-title) it returns a 404. If one goes to the non-permalinked url (domain.com?p=[postnum]) it 301 redirects to the correct permalink, but that url then 404s.

Here’s a little more info about the VM (where the simple try_files directive is working) and the droplet:

VM
nginx 1.11.1
Ubuntu 16.04
PHP 7.0.16

DO droplet
nginx 1.11.9
Ubuntu 16.04.2
PHP 7.1.2

They’re not huge differences, so I’m not sure why it’d be working fine in the VM but not on DO.

Reply Report
  • jtittle1 March 2, 2017

    @spivi

    For the WordPress rewrite, i.e

        location /subdir {
        try_files $uri $uri/ /subdir/index.php?$uri&$args;
    }

    Try changing that to:

        location /subdir {
        try_files $uri $uri/ /subdir/index.php?$args;
    }

    … and then reloading NGINX for the changes to take. I use the same on a dev Droplet as well as many live instances that I work on for various clients and that has always worked.

    Reply Report
    • spivi March 2, 2017

      @jtittle

      That’s correct and is one of the things we tried, but we just fixed this issue and it ended up that the culprit was the $request_filename blocks. Instead of removing them, we added an additional one in the middle so that it becomes:

          if (!-e $request_filename){
      rewrite ^/panel/(.*) /panel/index.php break;
    }

    if (!-e $request_filename){
      rewrite ^/subdir/(.*) /subdir/index.php break;
    }

    if (!-e $request_filename) {
      rewrite ^/(.*)$ /index.php last;
      break;
    }

      …which makes a lot of sense in retrospect. Thanks for your help with this!

      Reply Report
jensfranke May 21, 2017

@spivi It would be really nice to see your final configuration. Thanks in advance

Reply Report
  • spivi May 22, 2017

    Sure, here you go:

    server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name www.domain.com;
    root /home/forge/www.domain.com/public;

    server_tokens off;

    # ssl info...

    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Content-Type-Options "nosniff";

    index index.html index.htm index.php;

    charset utf-8;

    ##############################
    ## Kirby configuration
    ##############################

    if (!-e $request_filename){
      rewrite ^/panel/(.*) /panel/index.php break;
    }

    if (!-e $request_filename){
      rewrite ^/subdir/(.*) /subdir/index.php break;
    }

    if (!-e $request_filename) {
      rewrite ^/(.*)$ /index.php last;
      break;
    }

    location /content {
      rewrite ^/content/(.*)\.(txt|md|mdown)$ /error redirect;
    }

    location /site {
      rewrite ^/site/(.*) /error redirect;
    }

    location /kirby {
      rewrite ^/kirby/(.*) /error redirect;
    }

    location ~* \.(ico|css|js|gif|jpeg|jpg|png|woff|ttf|otf|svg|woff2|eot)$ {
        expires 1M;
        add_header Pragma public;
        add_header Cache-Control "public";
    }

    ##############################
    ## End Kirby CMS configuration
    ##############################

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # Wordpress subsite
    location /subdir {
        try_files $uri $uri/ /subdir/index.php?$args;
    }

    # panel links
    location /panel {
        try_files \$uri \$uri/ /panel/index.php?\$uri&\$args;
    }

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    access_log off;
    error_log  /var/log/nginx/www.domain.com-error.log error;

    error_page 404 /index.php;

    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php/php7.1-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
    }

    location ~ /\.ht {
        deny all;
    }
}
    Reply Report
jensfranke May 28, 2017

I tried to request a Node.js App beside the main kirby installation.

It works if I remove:

if (!-e $request_filename) {
  rewrite ^/(.*)$ /index.php last;
  break;
}

and I see nothing which doesn’t work in kirby. What is the reason for this rule?

Looks like Bastian is also not using this rule: https://gist.github.com/bastianallgeier/c2e1f1e519f5f2943ec4

Reply Report
  • spivi May 30, 2017

    I might have gotten it from here: https://gist.github.com/ramv/9402198

    It looks like it’s not necessary per se, but it’s meant to return the Kirby 404 template for URLs with file extensions where the files don’t actually exist. It’s essentially an Apache -> nginx translation of the following lines in the default Kirby .htaccess file:

    # make panel links work
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^panel/(.*) panel/index.php [L]

# make site links work
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.php [L]
    Reply Report
Submit an Answer

Related

Looking for something else?

Ask a new question Search for more help