Vesta Control Panel - Forum

I'm not new to VestaCP, been running it very happily for close to a year ... but that was with Ubuntu 12.04LTS + Apache2/NGINX + PHP5 setup. Recently I setup a new server with Ubuntu 16.04LTS + PHP7-FPM + NGINX-only + Redis and ... well not having .htaccess sure is an interesting experience ;) I more or less mastered the change of syntax, but what I still do not understand nor can wrap my brain around, are these two scenario's:

1) when I modify my /home/*/conf/web/nginx.conf (with vi) ... and later on make changes through VestaCP on an web/domain level, it totally messes up the file. Both working incorrectly with changes made through the UI, and through the CLI. How can I do it better? As when I rebuild the user I lose all changes made through vi.

2) W3TC caching plugin in WordPress creates a local nginx.conf in /home/*/web/website/public_html/nginx.conf ... which is odd. Thought that wasn't possible? As I when I do the same for a 'static' website (to migrate away from .htaccess and to fix the problem outlined in point 1); I cannot get it to work; which brings me back to point 1.

Thus how can I make nginx.conf changes that won't affect VestaCP on an UI level, without creating a separate template for every single user / web (domain) configuration?

W3TC caching plugin in WordPress creates a local nginx.conf

What do you mean ?

Exactly as it says :) W3TC creates a nginx.conf in public_html of the wordpress domain ... which works great. So I figured that when I do the same for a "default" vestacp package (instead of a package based on wordpress2 template) it would work too. Yet it doesn't.

*edit* While in both templates there's nothing that suggests nginx.conf would work that way, or does it? Hence my confusion.

*edit2* am I glad you asked that question! Turns out -- although the nginx.conf is created --- it isn't used by nginx. Assumption is the mother of all f*ckups; as I was able to just download the nginx.conf file, even though it contains this line:


Well that means the solution could be easy :-) Just have to modify the templates with adding another inclusion file (as mentioned here: https://john-dugan.com/setup-w3tc-nginx/)? *edit3* except when I do so in /home/*/conf/web/nginx.conf by adding this line:


my entire site goes to 404?! Odd. Oh well :-) at least have something to troubleshoot again. *edit4* annnnd FIXED! Turned out to be a conflict with W3TC's Browser Cache. Not sure what exactly, but just disabled it. And now everything works great! Thus I will just modify my /usr/local/vesta/data/templates/web/nginx/php-fpm/ templates accordingly (both wordpress2.tpl as well as default.tpl with an additional include and I will be a happy camper again. Thanks again for allowing me to declutter my thoughts mehargags :D

just for 'howto' purposes. Thus modify wordpress2.tpl (at the prior mentioned location).

Update 2017-NOV-06: AND also the wordpress2.stpl

Like so (for both files):
just before the closing } and run `/usr/local/vesta/bin/v-rebuild-user admin`. Where 'admin' is the default vestacp user of the web/domains (you might need to run it for other users too if you have them). Nice and tidy :-)

Little addendum. Don't forget to upload an empty nginx.conf to your WP dir prior to installing a fresh or reploading an old WP installation with plugins creating a nginx file. As Nginx will crash after creating a new Vesta user of template being unable to find the file otherwise. As I found out ...

okay ... important addendum. It's probably smarter (in line with VestaCP's roadmap and future updates) to not modify default templates and just add new ones. How to go about that in my own specific example? Is like so:
to then make the necessary modifications as priorly outlined.
Thus replace the "}" on the bottom of both new templates with
As the auto update from VestaCP 0.9.8-17 to 0.9.8-18 on the 29th of December 2017 completely wrecked my server farm :-( . Which is something I only found out about after a reboot due to something else, and pretty sure it has something to do with how the template updates were processed during VestaCP upgrade ... and the effect that had on the rest of the update script.

UPDATE: the cause of the problems turned out to be a different issue. See these post: viewtopic.php?f=16&t=15775&p=65339#p65339 or viewtopic.php?f=10&t=16422&p=68104#p68104

Anyhow ... by adding new templates instead of modifying presents ones? Well it's probably better that way ;) And how to utilize these templates? Login to your VestaCP admin backend -> "Web" -> "Edit" a domain (if not creating a new one) -> and in the dropdown box of 4th field "Web Template NGINX" select "wordpress2extra". Scroll down and press "save" button.

Final note: why go through all this hassle and not just stick to normal wordpress2 templates in the 1st place? Well due to how some WP plugins like to handle rewrite conditions.

Based on this topic in a different thread here on the forum (and what I shared above already): F*CK !!! Please help me TROUBLESHOOT public_html/megla.txt - "hacked by megla akash from Team_CC". I already found a possible cause, but didn't fix it yet. So lets close another security loophole. ;) As by default VestaCP only blocks .htaccess and .htpasswd ... which are files which don't work on a LEMP stack, but WP (and its plugins) often create regardless. Turns out it ain't the only hidden file that's created when using WP WAF and other things as outlined priorly and can be downloaded publicly. Thus find this snippet in the stpl file:
and replace it by something like:
source: https://serverfault.com/questions/75566 ... ory/755777

P.S. don't forget to rebuild your VestaCP users so the new configuration applies. How? Scroll up.