wo site upgrade removed SSL information from nginx sites-available file?

grl570810

I have just run through an exercise of changing the cache on one of my sites from fast cache to redis cache. I ran the command wo site update <URL> --wpredis. After the command completed successfully I tried to access the site using https:<URL>. I got the browser warning page that the SSL certificate was not valid and it was weirdly using the certificate for a different site on the same server (the site I had updated was a.domain.com.au, the certificate was from b.domain.com.au).
When I looked in the <URL> file under sites-available I could see that the update had completely removed the server {listen 443 SSL;....} section from the file, leaving only a server {listen 80; ...} section that wasn't the same as the one that had been there. In other words it seems the update created a completely new file rather than just changing the one line in the existing file that specified the include for the cache module (i.e. change include common/wpfc-php81.conf; to read include common/redis-php81.conf; ). It was easy enough to re-edit the file to restore the correct listen settings, but I was surprised at the need to do so. I have a lot of sites I wish to put through this change process so it's going to be rather tedious if I have to manually edit each one.
Is this expected behaviour, as if so it seems to me to be quite a serious shortfall in the site update code? Or am I missing something that would allow we to run this update without losing all the other settings in that file?
Also does anyone have an explanation as to why I was presented with the SSL certificate for a different site? I'm guessing that is is a NginX thing rather than anything wo specific; it seems as if when it found no site matching the URL with a listen on port 443 it made a 'best guess' as to which site I was looking for rather than returning an error status to the https: GET?

marty

grl570810 Or am I missing something that would allow we to run this update without losing all the other settings in that file?

There's a wildcard include in the site config (include /var/www/example.com/conf/nginx/*.conf;), so I think the general idea is that any customisations go in that folder.
You can customise configs by creating an empty <filename>.custom version to avoid them being overwritten. I can't recall if this works for the site level config (should do?). Although you'd then have to manually apply changes (compare with <filename>.orig).
So for the other sites you could just edit the site configs and change the 'fastcgi to redis include' manually (if you use wo site edit example.com it also tests the config is valid and reloads nginx settings). Don't forget to update the Nginx Helper plugin settings to purge the right cache.

grl570810 I'm guessing that is is a NginX thing...

Yup.

grl570810

marty
Thanks marty for your response. I'll have a poke around the way *.conf files are used to see if there's a way to set things up so that the standard wo managed bits are in the file under sites-available, and any things I change post install are in a separate file that any wo site update command doesn't touch.
Just as an observation, in getting to grips with WordOps I'm finding there's a lot of functionality under the hood that isn't mentioned anywhere in the documentation (or at least anywhere I can find!).

grl570810

marty
After a bit more experimenting over the weekend I agree that it's far easier to use wo site edit to manually edit the conf file for the simple change of cache, rather than wo site update, so that's what I'll be doing to implement the transition for the rest of my live sites. Thanks for pointing me at that approach. 🙂
It seems site update is more of a "rebuild the conf from a template" action, rather than "update the existing conf" as I (possibly naively) anticipated.
I think an explanatory note to that effect, including highlighting the potential loss of any post-install changes to the conf, would be a worthwhile addition to the documentation. I am happy to make that change in GitHub as my first contribution to WordOps, but I'm not familiar with GitHub having only used MS development tools like VSS & Azure DevOps to date. The section on improving documentation on the 'Contributing' page says "... in markdown (.md) files inside the WordOps GitHub project." but I haven't managed to find any such files so far. Could I please request a pointer as to where I should be looking in order to edit?
TIA, Graham

marty

grl570810 I'm finding there's a lot of functionality under the hood that isn't mentioned anywhere in the documentation (or at least anywhere I can find!).

The docs do need work/volunteers - there's a lot of info in the forums and release notes that hasn't made it into the docs yet.

marty

grl570810 Could I please request a pointer as to where I should be looking in order to edit?

Sure - you can find the docs plus an exaplanation of structure/how to edit here:-
https://github.com/WordOps/docs.wordops.net
(that link should really be in the docs somewhere..! 🙂)

grl570810

marty
Yes, the key fact that the documentation is a separate GitHub project was not obvious to a newbie! LOL
Thanks again for your assistance, I'll get some changes into the pipeline including one to link to the documentation project from the 'how to contribute' page. 🙂

grl570810

After trawling the forums I found this thread which documents the 'correct' way to add custom entries to the NginX configuration for a site. https://community.wordops.net/d/1046-nginx-domainconf-file-location-
This is another subject worthy of transferring into the documentation so I'll add it to my 'to do' list.