I’ve been working more with WordPress lately, rather than my usual Drupal development, and in the process, I fell in love with a project called EasyEngine. For those of you who aren’t familiar with it, it’s a set of super scripts that are evoked by remarkably short and easy to learn and rember EE commands. It’s kind of like the best features from Drush and Yeoman and combined into a WP site generation tool that’s breathtakingly fast and intuitive – or so I thought until I migrated this site over to a freshly provisioned Ubuntu 16.04 instance and tried to resolve multiple domains to it. Here’s what I wanted to accomplish:

     

    • Have a single instance of WordPress installed via EasyEngine which multiple domains would resolve to
    • Have automated LetsEncrypt SSL also installed and managed by EasyEngine

     

    To do this, I ran the above script and then pointed the .conf for each each respective domain in the /sites-enabled directory to the root of the active WordPress instance. Seems pretty straight forward, right? I thought so too, but I was terribly wrong about that and suddenly, what started off as a beautiful love affair became hours of pulling hair and trying to figure out why I was getting a dreaded 403 error on all but the domain that was the active root for WordPress. EasyEngine had documentation on virtually every scenario I could think of for creating domains, except one – resolving more than one site to a single WordPress installation. For that there was zero documentation. I tried everything I could think of and nothing worked. No matter what I did, I’d wind up with the dreaded NginX 403 forbidden error. I got desperate enough that I even reached out to a support forum for EasyEngine users. The response was essentially “we’ve never seen anything like this before, it’ll be interesting to see if you can figure it out.”

     

    So I did a bunch of troubleshooting and analyzation of the various configuration files, and at some point, I had an epiphany. I realized the the issue wasn’t how I was pointing to the root domain from the .conf files in the sites-available directory to the active WordPress directory created for the root domain, the issue was HOW I was creating the sites initially. Originally, I had read through the EasyEngine documentation, and felt that creating the site with no specific configuration would be the safest bet. The EE command I was originally running looked like this:

     

    ee site create somesite.com --letsencrypt #to create the site without any peripheral apps and LetsEncrypt

     

    What I found after a number of grueling hours was that ee site create somesite.com and ee site create somesite.com –html actually both do the exact same thing, namely, they both create a site with .conf files configured for an HTML website. I confirmed this by creating a site with ee site create somesite.com, I then added encryption  through the second command and added an index.php file to the root directory for that domain. What I found was that if I pointed my browser to somsite.com I’d get a 403 error, which had been the problem all along. The same thing happened when I pointed directly to the file at somesite.com/index.php. What was different about the direct link to the file was that my browser actually downloaded index.php. A light bulb went off and I tried changing the name of the file to test.html and viola! The 403 error disappeared and the test page loaded. At this  point I felt pretty confident that I knew what the problem was. Knowing that WordPress uses PHP, I realized I just needed to change HOW I was creating the sites with EE.

     

    I went back to the documentation and found what I was looking for. I then deleted the sites and recreated them using this one command:

     

    ee site create somesite --php --letsencrypt

     

    Then, at /etc/nginx/sites-available/somesite.conf, I made the following edit to point to the root directory of the site:

     

    server {
    
        server_name resolvetoactiveroot.co.nz   www.resolvetoactiveroot.co.nz;
    
        access_log /var/log/nginx/resolvetoactiveroot.co.nz.access.log rt_cache; 
        error_log /var/log/nginx/ayrne.co.nz.error.log;
        root /var/www/ACTVIVEROOT.com/htdocs;
        
        index index.php index.html index.htm;
    
        include common/php.conf;      
        
        include common/locations.conf;
        include /var/www/resolvetoactiveroot.co.nz/conf/nginx/*.conf;
    }

     

    And that’s all it took. You essentially just want to make sure that the active WordPress installation root is specified by altering this one line of code: root /var/www/ACTVIVEROOT.com/htdocs;

     

    Now I can go back to writing more awesome articles and enhancing my site with a renewed love for all that is the EasyEngine project. I thought I’d share it in the hopes of saving someone from spending all the time I did trying to figure it out.

    Tags:

    • Show Comments (0)

    Your email address will not be published. Required fields are marked *

    comment *

    • name *

    • email *

    • website *

    Ads

    You May Also Like

    How to Harden NginX Security

    While there are many ways to harden the security on your NginX server with ...

    How to Install Redis Server on Ubuntu 16.04 with WordPress

    The quick easy and totally correct way to setup Redis object cache to work ...