Nginx Configuration With include Directive For WordPress

Specially for HSTS WordPress configuration, the configuration file which is, by default /etc/nginx/sites-available/default gets quite bigger. Nginx Configuration With include Directive Can Make the default of nginx.conf file less bloated specially for WordPress W3C like plugins. There are some stuffs to keep in mind for this work.

 

What To Remember For Using Nginx Configuration With include Directive

 

Too much include can make the front end slower. It becomes like, go and read from /etc/nginx/sites-available/default, then go to /etc/nginx/w3c.conf (example); if file ownership and permission is right, then read it, else print error. It is very minute, sometimes invisible change for using too many includes, but logically it can happen when the memory is at margin or server load is higher.

In other words, we will ONLY use the include directive for adding the extras. There is other advantage specially for WordPress W3C Plugin. If we place the W3C settings specific file at location which is readable and writable to W3C, if the location of configuration is corrected from W3C Plugin’s dashboard, it becomes “automatic” for the changes. Same goes for WordPress SEO like common plugins.

We can not include the major directions like :

The nginx.conf file by default includes /etc/nginx/conf.d/ directory. If we place the conf files there, we actually need no separate addition of one line on /etc/nginx/sites-available/default but it probably will be not writeable by PHP (or rather WordPress plugins) in a secured setup.

It is not a great idea to place files in /usr/share/nginx/html (default public root location) or equivalent publicly accessible location.

 

Nginx Configuration With include Directive

 

We have a NGINX configuration as example in GitHub. If you see the default file there, it is hugely big. It is difficult to find a line and manage. Line number 209 to 342 is of WordPress W3C Plugin. You can see this gist here.

We could name it as w3c instead of w3c.conf. If we put that file in /etc/nginx/conf.d/ location, nginx.conf will pick it up without doing anything :

In other words, in that case of placing in /etc/nginx/conf.d/ location, we have no work with /etc/nginx/nginx.conf or /etc/nginx/sites-available/default like file. Simply running the config test ( nginx -t ) and restarting nginx should work fine.

BUT, that can get loaded prior to a direction we wanted. Instead, exactly like the SSL certs, we will create a separate directory and chown, chmod it for reading :

Now, in our example, we are picking up the lines from /etc/nginx/sites-available/default file counting number 209 to 342. We have to vanish the lines first there. Then on line number 209, we will add :

If it throws error after running the config test ( nginx -t ), we will comment the line and add the line within active server block :

 

Nginx Configuration With include Directive Throwing Errors

 

There can never be any error if you follow this method. Nginx is not a herbal product that there will be no logic, most common reason of getting error is too many commented out lines. Nano is a dangerous text editor, if you do not know vim at all, we will suggest to learn vi a bit.

One day I casually opened a XML file of a git (of our company’s one software under development) with nano and nano added line breaks on each line. If it was nginx, the situation became :

Now, obviously nginx will read the empty include first and throw error. It is not very easy to locate such line break on server from SSH and use sed and/or tr to remove the line breaks. Always, when a thing is working, take multiple backups in multiple ways first.