Changing home and siteurl

[mvasin]

I'm transferring my site from http to https, and need to change URL scheme in home and siteurl from http to https.

In WordPress admin panel both "WordPress Address (URL)" shows http://mysite.com/wordpress and is non-editable, "Site Address (URL)" is http://mysite.com and is also grey, wp option get siteurl returns a weird http://:/wordpress string, wp option get home prints http://:.

wp option update home https://mysite.com and wp option update siteurl https://mysite.com/wordpress succeed, but change nothing, wp option get and WordPress admin page display what they did before.

I even tried wp option update home https://: and wp option update siteurl https://:/wordpress with no effect as well.

I wonder how these options are even set? For instance, Bedrock provides WP_HOME and WP_SITEURL environment variables and mentions them in the docs, and in WordPlate docs I found no information about it.

[vinkla]

WordPlate will find your address by default with or without https. This means it should work fine in both. Though, it could be an issue when migrating from http to https because WordPress saves the URLs in the database.

I wonder how these options are even set?

These variables are set in the framework. WordPlate also provide environment variables for WP_HOME and WP_SITEURL which you can add to your .env environment file. I'll add these to the documentation later today.

We would defiantly want this to work out of the box and if you find what caused this we are all ears!

[mvasin]

I have a rather tricky configuration, a request goes through these steps:

1. There is Cloudflare at the very front, serving https to clients and talking to my server via http (they call it a "flexible" mode, it's for those who didn't set up https on their own servers yet).
2. Then I have a reverse-proxy nginx acting as a router, listening on port 80 and routing requests to a particular Docker container depending on the Host http request field.
3. Each WordPress site is represented by a pair of containers, a php-fpm container and an nginx container. nginx container listens and passes requests it receives outside on a non-standard port from the router to per-site nginx instance inside that listens on a standard port 80.
4. This per-site nginx instance serves non-php files directly and fcgi_passes php files to per-site php-fpm container.

So it turns out WordPress thinks it should serve http because it's always addressed from port 80.

There are a bunch of ways to address this, I think I'll handle it.

Regarding WordPlate itself:

• it would be nice to mention in the docs that home and site url WordPress options are set automatically to whatever URL the WordPress installation is addressed by (that's actually VERY convenient, otherwise website URL must be specified twice, once in nginx config and second time in WordPress options),
• mention the env vars available,
• setting wp option update siteurl / wp option update home successfully and seeng nothing's changed later on is confusing. Maybe there is some sort of a callback provided by WP-CLI, so we can raise an error and say that these options are not meant to be changed, it's automatic, but in case you really need it, change the env vars.

[vinkla]

It would be nice to mention in the docs that home and site url WordPress options are set automatically... ...mention the env vars available.

I agree, I'll add them as soon as possible.

---

What do you think about an option to enforce https with an environment variable? We could add an variable and name it WP_SECURE which the user could set to true or false.

[mvasin]

OK, thanks!

"Secure" is a term a bit too broad. WordPress has already got FORCE_SSL_ADMIN constant, so let's call the environment variable in a similar manner, WP_FORCE_SSL. It should force SSL for both admin panel and front end.

[vinkla]

@mvasin yeah, that sounds good!

Would you be up to submit a pull request to add this feature to the wordplate/framework repository?

[mvasin]

Sure, with pleasure.

[mvasin]

@vinkla Being a TDD confessor, I am currently in the process of writing a failing test for WP_FORCE_SSL env var redirection. Only then I plan to tinker with the code so the written test will pass.

I don't see an opportunity to test it without WordPress (maybe you do?), so what I'll come up with will be the first broader test involving WordPress core in wordplate/framework repo.

I use an extra composer.json similar to the one in worplate/wordplate that resides in tests directory, but it fetches wordplate/framework from the directory above (the repo's root directory).

It's getting a bit hairy because it's not possible to target "path" type of a composer repository to the parent path of current (tests) directory (package cannot install inside its source), so I try various workarounds.

And while I mess with it, I need to know what platforms do you target WordPlate for; it's a bit tricky for me to support Windows because I don't use it, but I'll try my best if you need it.

[mvasin]

The less messy and a cross-platform variant is to place the whole composer package into a directory alongside the tests/ directory:

- package
  \_ composer.json
  \_ src/
- tests
  \_ ApplicationTest.php
  \_ composer.json
  ...

@vinkla Don't you mind if I rearrange into such a directory structure?

[vinkla]

@vinkla Don't you mind if I rearrange into such a directory structure?

Thanks for the suggestion but I would like to keep the current structure.

Please open an WIP (work in progress) pull request on the wordplate/framework repository and then we could continue the discussion there. It will be easier to discuss when we can look at the code.

[mvasin]

OK, I'll leave the directory structure as is and open a WIP PR as soon as I can.

Please close this issue when you'll update the docs.

[vinkla]

I've updated the documentation in: wordplate/wordplate.github.io@4fa03da