Wordpress site not formatting correctly

April 27, 2017 2.2k views
WordPress Ubuntu 16.04
denright
By:
denright

Hi,

I’ve been through the process of setting up some LXC containers running NGINX and then went through install of an LEMP stack on one of them, I have HAProxy set up to do TLS termination and have let’s encrypt certs set up so that I have SSL enabled.

I’ve now been through setting up MySQL and then wordpress install, but my wordpress installs don’t look right. For an example see here: https://benefitsofbamboo.com/

Can anyone tell me what is wrong?

Thanks

1 comment
  • davidfavor April 29, 2017

    Start with a simple LAMP + Letsencrypt SSL setup first.

    Get your site working first + then actually speed test it.

    I normally get 5,000+ reqs/sec WAMPL (WordPress on LAMP) for well tuned Ubuntu + LAMP + LXD.

    Also, you said you’re using LXC. Likely best to switch to LXD, since LXC will reach end of life soon.

    If you use Ubuntu + LXD + LAMP + HTTP2 as your starting point, your headaches will be fewer.

    https://benefitsofbamboo.com looks like a fresh WordPress install.

    Clarify what you mean by “WordPress installs don’t look right” + likely someone can assist you.

Log In to Comment
2 Answers
jtittle1 April 27, 2017

@denright

WordPress doesn’t handle proxies all that well, even if you are sending the correct headers over. I ran in to this issue when setting up a cluster for a client just last week.

A simple solution is to force SSL by modifying wp-config.php.

Find:

define('WP_DEBUG', false);

Directly below that, add:

if ( $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https' )
{
    $_SERVER['HTTPS']       = 'on';
    $_SERVER['SERVER_PORT'] = 443;
}

Save wp-config.php and reload the page.

Reply
  • denright April 27, 2017

    Thanks for this suggestion @jtittle, it’s done the trick.

    • jtittle1 April 28, 2017

      @denright

      No problem, happy to help.

      It’s a bit strange, in a way, but I can see why WordPress doesn’t properly handle this out of the box. Given the fact that SSL terminates at the proxy, the endpoint has no knowledge of the SSL Certificate beyond what’s provided by the headers.

      So since it’s relying on the web server, which is listening on port 80, then it’d be impossible for WordPress to sort this in the core without some rather hack-y test cases which would probably be more problematic than it would be beneficial. That, or they add a new constant that allows the user to define that they are using a proxy and that SSL should always be on no matter what the web server is listening on.

      I can see that as an option, but not sure if they’d add something like that when the above code works just the same.

hansen April 27, 2017

Hi @denright

You need to modify your WordPress installation to run over https instead of http.
https://benefitsofbamboo.com/wp-admin/options-general.php

You might need to modify posts and edit links and images to also use https.
Or you could use a plugin like Better Search Replace to do it automatically.
https://wordpress.org/plugins/better-search-replace/

Reply
  • jtittle1 April 27, 2017

    @hansen

    Even when setting the URL’s to use HTTPS and further enforcing it via definition of constants, it seems that WordPress still doesn’t seem to handle proxied connections correctly (and by that, I mean it doesn’t seem to check what’s being sent).

    I ran in to this last week when configuring NGINX as a Load Balancer with a full proxy config. I’d think this should pretty well cover just about anything in most all cases:

            proxy_buffers 16 32k;
        proxy_buffer_size 64k;
        proxy_busy_buffers_size 128k;
        proxy_cache_bypass $http_pragma $http_authorization;
        proxy_connect_timeout 59s;
        proxy_hide_header X-Powered-By;
        proxy_http_version 1.1;
        proxy_ignore_headers Cache-Control Expires;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504 http_404;
        proxy_no_cache $http_pragma $http_authorization;
        proxy_pass_header Set-Cookie;
        proxy_read_timeout 600;
        proxy_redirect off;
        proxy_send_timeout 600;
        proxy_temp_file_write_size 64k;
        proxy_set_header Accept-Encoding '';
        proxy_set_header Cookie $http_cookie;
        proxy_set_header Host $host;
        proxy_set_header Proxy '';
        proxy_set_header Referer $http_referer;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Original-Request $request_uri;

    Unfortunately, it doesn’t. Even though the correct headers are being sent through, WordPress still needs a little modification (using the code I posted above) to get things working properly.

    I’m guessing this is because SSL is terminating on the LB, thus since SSL isn’t enabled on the actual endpoint where the request lands, WordPress continues to identify with Port 80, thus all resources are served over HTTP instead of HTTPS.

    From what I’ve read, they aren’t going to add additional checks as it’s the responsibility of the user or sysadmin to account for these things, even though under normal circumstances, any script should account for them.

    • hansen April 27, 2017

      @jtittle True, WP is not easy when you’re doing advanced proxying, so you need to fiddle with the config like you posted - but you still need to convert all URLs to use https too, otherwise you will continue to get mixed content warnings.

Have another answer? Share your knowledge.

Related