Sorry for the slow response, I only recently learned of your plight. It’s extremely unusual to see httрs://theserenecity.com in settings but in the DB siteurl and home entries contain localhost references. Are you sure you’re looking at the right DB? (Been there, done that, I’ll assume you have the right one) Some sort of filter code is then apparently changing the value. If it does so consistently, then it should be OK, but this arrangement makes site maintenance difficult because the domain is hard-coded in PHP somewhere, such that the DB entry is meaningless.
But it apparently is not consistent because you have missing domains in supporting CSS and JS file references. This means functions like siteurl() are not returning valid values. I don’t know why some code is messing with site URLs, but it’s doing so incorrectly (setting certain constants in wp-config.php will do so correctly).
Not knowing why this scheme is in place to begin with, I’m not sure my solution would be appropriate. If you want to try it anyway, make a full backup of everything just in case I’m off base. My inclination is to isolate whatever code is messing with domains and remove it (or comment it out), placing the proper values in the DB. You can narrow down the source by selectively deactivating modules until the responsible code is isolated. You can do so manually, or use the troubleshooting tab of the health-check plugin.
That should resolve the external links, but there seems to be other issues with the sub-folder location and SSL certificates. I don’t think a SSL cert for one site will be valid for the other even if it is in a sub-folder of the covered site. I don’t think the SSL enforcement mechanism can “see” this arrangement, as far as it’s concerned they are two separate sites. I may be wrong, I’ve never tried such a scheme.
You should consider switching the domain not named on the cert to normal HTTP protocol for a while in order to confirm everything else is working properly. Once you’ve confirmed it’s otherwise working, you can try HTTPS again. If it fails, you probably will need a separate cert for the site.
www-data is frequently the default system user on many Apache installs, but it doesn’t have to be. WP does not get to pick what user it runs under, Apache uses what its configuration tells it to. Check the httpd.conf file or equivalent for the system user. Whatever it is, it should also be the owner of all WP files and folders. Alternate schemes are possible, but this is the most typical.
