Both sites redirect to http://example.com by default. What’s the best way to ensure my site displays as http://www.example.com? And could you also briefly explain the reasoning behind removing the www?
It’s a best practice to choose one or the other and force the redirect. Meaning either non-www or www should be the canonical domain and you should redirect to that one. The choice of non-www was our personal preference.
Solved for development - but still trying to get the www subdomain working on production (DigitalOcean).
In development/wordpress_sites.yml, I added ‘www’ to site_hosts and set www_redirect to false. (I also updated manifest.json). “www” then worked once I ran vagrant reload --provision
I’m trying to get it working on my production domain, as well, with the same steps above. I’m not sure how to re-provision the production server, and wondering if this is a necessary step?
Otherwise, if I have taken all the right steps, it might be a setting in the digitalocean droplet domain that I need to update to get it working.
I’m trying to have the production site keep the www subdomain, but instead it keeps redirecting to the naked domain. I have it enabled in development (see above), but I had to re-provision the local server before it worked. Wondering if I have to do the same with the production server, as well?
Any idea how to re-provision the production server? Locally, I just run vagrant reload --provision, but not sure how run this on production (server is on DigitalOcean).
First of all thanks for sharing Trellis publicly. I’m so grateful for that.
One thing about this project is annoying though. On the link you have shared about www_redirect, there is in fact no proper documentation about www_redirect. To be honest this part of Trellis is poorly documented and that brings these questions in my mind:
After a lot of tests, it seem impossible to redirect all trafic of a domain to www.
If we add the www_redirect = False, both domains are accessible, it doesn’t act like a toggle.
I tried what @ben said in his last post. Is anyone found a solution for this ?
I’m currently trying to rewrite the default wordpress-site.conf so if anyone had a better solution let me know
BTW, Thanks roots team for all the awesome setup !
Thanks @ben for your answers, I really appreciate that.
Without being rude, the thing that I do not understand and confuses me a lot is that why you think that Trellis configures the Nginx server blocks and issues letsencrypt certificates properly for a website which is supposed to be served on WWW. Because it doesn’t.
I have tried this several times with different versions of Trellis (including the last version as of now) and none of them worked properly. I have been waiting for this bug to be solved for a long time. I would have dived into the code to make a pull request much earlier if I knew any python to be honest.
I think I am going to learn a bit of Python to solve this issue now.
I had the same problem two weeks ago. You can solve this problem by yourself and you don’t have to code any line of python. You simply need to edit the wordpress-site.conf file in the wordpress-setup role. You can check my gist for a example. Note that I didn’t test it with multisite.
Trellis has changed much since this post so this may be due to a new version or another factor but:
Using a website that was in a traditional panel host and accessible at “www.”, I was able to achieve this in a move over to trellis simply by setting “www.” as the canonical, and then using the non-www domain as the redirect.
If I had to guess, it would be that having “www.” in the actual wordpress database options table definitely helps, though since so many had a problem I will safely chalk this up to the great devs at roots.