WP_SITEURL/WP_HOME being ignored

  • Unknown's avatar
    unceasingdev · Member ·

    I have a wordpress.com site hosted on https://wp.example.com/, but I want it to be served as if it was hosted on https://example.com/. This is because I am actually putting the service behind a reverse proxy.

    I have (via SSH) edited ~/htdocs/wp-config.php to add the following lines:

    define('WP_SITEURL', 'https://example.com/wordpress');
define('WP_HOME', 'https://example.com');

    but they appear to be being completely ignored – the HTML served still references https://wp.example.com/ everywhere.

    Any suggestions please?

    The blog I need help with is: (visible only to logged in users)

  • Unknown's avatar
    unceasingdev · Member ·

    It transpires that at least part of the problem is that somehow WP_SITEURL and WP_HOME are being defined before wp-config.php is executed, which does not appear to be how WordPress is supposed to work.

    But also, mysteriously, the values that they have somehow been set to are almost the values I actually want (https://example.com) but they are being ignored anyway.

  • Unknown's avatar
    unceasingdev · Member ·

    Getting closer… I’ve used phpMyAdmin to set home and siteurl in the wp_options table, and then added this to the very end of wp_config.php:

    unset($wp_filter['option_siteurl']);
    unset($wp_filter['option_home']);

  • Unknown's avatar
    unceasingdev · Member ·

    This does it mostly, although not for embedded images it seems for some reason:

    At the very start of wp-config.php:

    define('WP_CONTENT_URL', 'https://example.com/wordpress/wp-content');

    and at the very end:

    remove_filter('option_home', '_config_wp_home' );
    remove_filter('option_siteurl', '_config_wp_siteurl' );
    $wp_scripts->base_url = get_option('siteurl');
  • staff-webwizard · Staff ·

    Hi unceasingdev! Could you please share the real URL of the site?

  • Unknown's avatar
    unceasingdev · Member ·

    It’s https://adaaction.com/ although wordpress.com thinks it’s https://wp.adaaction.com/
    The fundamental issue appears to be that wordpress.com is using some hidden mechanism to define() WP_SITEURL and WP_HOME before any of the PHP code even starts executing, and after that of course they can’t be re-defined.

    My bodge seems to mostly work, although as I say not for the embedded images, and I don’t know if any other snags will crop up later. I’ve no idea how wp_get_attachment_url() gives the right result when I call it manually yet is presumably giving the wrong result when the page is rendered.

  • staff-papyrus · Staff ·

    We do set both the siteurl and home values for WordPress.com sites on our end, and these values generally should not be modified as doing so could disrupt the site or its Jetpack connection (which provides vital functionality for all sites hosted here).

    That said, I’m not sure I fully understand your overall end goal here. You originally mentioned you’re working on setting up a reverse proxy – was there a particular reason (e.g. security or performance concerns) that you were looking to set that up? Any details about how or why you’re configuring that reverse proxy would be helpful, and may help us find a more appropriate solution with you.

  • Unknown's avatar
    unceasingdev · Member ·

    I need to use a reverse proxy because some of the URLs on the hostname are served by the wordpress.com server, and some of them are served by a completely different web server running django. And if I set the primary hostname as far as wordpress.com is concerned to the real hostname then wordpress.com can’t get an SSL certificate.

    I suppose it’s possible that if wordpress.com is using letsencrypt’s file-based domain validation then if I reverse-proxy the .well-known subdirectory only on 404 (via IP address) then both servers will manage to successfully get an SSL certificate for the same hostname and it might work that way.

  • staff-papyrus · Staff ·

    Thanks for clarifying for us! While a reverse proxy like this might be possible here, what you’re describing is well beyond the standard use of WordPress.com. As such, it’s not something we can provide support for.

    From my own experience and research, this setup would generally require some amount of custom code and/or the use of external services (such as Cloudflare or Amazon CloudFront) to control the reverse proxy.

    You’re certainly welcome to try this setup with or without external services, but we can’t guarantee whether a particular setup might work as expected and we don’t provide support for this kind of setup.

  • Unknown's avatar
    unceasingdev · Member ·

    Ok well I’ve changed it so that wordpress.com knows the real hostname, so I’ve been able to get rid of the WP_SITEURL / WP_HOME bodges, but I’ve now got the problem that the two servers that are supposed to be serving the site, 192.0.78.133 and 192.0.78.249, are doing so but with only about a 75% chance of serving the correct SSL certificate, e.g.:

    Is this expected? Should I just wait 24 hours for the certificate to propagate to all your servers, or something? (It’s been several hours already.)

    $ openssl s_client -servername adaaction.com -connect 192.0.78.249:443 /dev/null | openssl x509 -noout -dates -issuer -subject -ext subjectAltName
notBefore=May 12 14:36:05 2024 GMT
notAfter=Aug 10 14:36:04 2024 GMT
issuer=C = US, O = Let's Encrypt, CN = R3
subject=CN = tls.automattic.com
X509v3 Subject Alternative Name:
DNS:adaaction.com, DNS:elixar.au, DNS:genderlibrary.co.uk,
...
$ openssl s_client -servername adaaction.com -connect 192.0.78.249:443 /dev/null | openssl x509 -noout -dates -issuer -subject -ext subjectAltName
notBefore=Dec 5 00:00:00 2023 GMT
notAfter=Jan 4 23:59:59 2025 GMT
issuer=C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo ECC Domain Validation Secure Server CA
subject=CN = .wordpress.com X509v3 Subject Alternative Name: DNS:.wordpress.com, DNS:wordpress.com
  • staff-papyrus · Staff ·

    At the moment, I’m consistently seeing the latter SSL certificate when viewing the adaaction.com site, which is consistent with what I see within our system’s records for your site as well. With the current setup, we aren’t able to detect that the domain is using either our name servers or your site’s IP addresses (A records), so we aren’t able to provision an SSL certificate for the domain.

    If you need our SSL certificate installed on your domain (with the Common Name tls.automattic.com), then the domain will need to use either our name servers or resolve to your site’s IPs. Otherwise, with your current setup, an externally-provisioned SSL certificate may function for your site – though again, we aren’t able to provide any support in that regard.

  • Unknown's avatar
    unceasingdev · Member ·

    You have already provisioned an SSL certificate for the domain, you’re just not reliably sending it. It’s a problem with your web servers, nothing else.

    Also, as I mentioned, if you’re using LetsEncrypt’s HTTP-01 challenge method (which presumably you must be) then you should be able to provision new certificates on the domain without issue.

  • staff-papyrus · Staff ·

    I had a chance to discuss this further with someone from our internal domains team, and it does seem like you’re on the right track here. Our internal tooling and my own tests aren’t showing our SSL certificate being used for your domain, though it’s possible the inconsistency you had mentioned earlier is at least in part to blame for that.

    We do use Let’s Encrypt’s HTTP-01 challenge method, but we’re not able to provision new certificates for your domain because the required HTTP URL isn’t currently resolving to our infrastructure – only the HTTPS variant is. Let’s Encrypt and the ACME standard require HTTP for that challenge.

    You’ll need to make sure that http://adaaction.com/.well-known/acme-challenge/* resolves to our infrastructure (even just with a simple redirect to HTTPS on the same path) in order to have SSL provisioned by us.

  • Unknown's avatar
    unceasingdev · Member ·

    You won’t see your SSL certificate unless you override the DNS to ask your web servers directly – the public DNS points to my front-end web server (reverse proxy). The reason I want your web servers to have working SSL certificates is so the traffic between my server and your servers is encrypted and verified.

    I had made https://.../.well-known/acme-challenge/... forward to your servers but you’re right that the http: equivalent wasn’t doing the right thing. I’ve made it redirect to HTTPS which as you say should work with LetsEncrypt, so hopefully this should result in everything being sorted:

    $ curl -iL http://adaaction.com/.well-known/acme-challenge/wp-url
HTTP/1.1 301 Moved Permanently
Server: nginx/1.18.0 (Ubuntu)
Date: Fri, 19 Jul 2024 10:46:48 GMT
Content-Type: text/html
Content-Length: 178
Connection: keep-alive
Location: https://adaaction.com/.well-known/acme-challenge/wp-url

HTTP/2 200
server: nginx/1.18.0 (Ubuntu)
date: Fri, 19 Jul 2024 10:46:48 GMT
content-type: text/plain;charset=utf-8
vary: Accept-Encoding
vary: Cookie
x-ac: 4.dca _dca HIT
alt-svc: h3=":443"; ma=86400

WP.com
  • Unknown's avatar
    unceasingdev · Member ·

    Well this seems to have worked very well, indeed your servers are now presenting a certificate which is unique for this domain, rather than a shared certificate like they normally do. Which is great of course, if a bit surprising! Is this something you’ve done?

    The paths I’m provisionally proxying to wordpress.com are:

    ^/($|.well-known/acme-challenge/|wp-|_static/|comments/|feed/|xmlrpc.php)

    – are there any others you can think of which I should be adding to the list?

  • staff-galakate · Staff ·

    I’m glad to know that the certificate is now working and is coming from our servers. As for other paths, there aren’t any other paths we can think of to add to the list.

  • Unknown's avatar
    unceasingdev · Member ·

    I’d just like to say that you have provided excellent support in this thread. Thank you.

  • staff-galakate · Staff ·

    Thank you so much for your kind words! We’re truly delighted to hear that you found the support helpful. It’s always our goal to provide the best assistance possible. If you have any more questions or need further help, please don’t hesitate to reach out. We’re here for you! 

  • The topic ‘WP_SITEURL/WP_HOME being ignored’ is closed to new replies.