Basil Hendroff

Forum Replies Created

Viewing 15 replies - 1 through 15 (of 35 total)
  • Thread Starter Basil Hendroff

    (@basilh)

    Thanks @bobmatyas. The issue I observed was symptomatic of a much bigger problem. I’ve blogged about it here https://blog.udance.com.au/2021/11/19/wordpress-sites-not-available-externally/

    Thread Starter Basil Hendroff

    (@basilh)

    Thanks, Yui!

    Thread Starter Basil Hendroff

    (@basilh)

    Thanks Yui!

    At the bottom of every WP article there is a section titled Was this article helpful? How could it be improved? with the note:

    Feedback you send to us will go only to the folks who maintain documentation. They may reach out in case there are questions or would like to follow up feedback. But that too will stay behind the scenes.

    I’ve used that to alert the doc team, but now I’m aware of the HelpHub, is it better to raise an issue there instead, or doesn’t it matter?

    PS I’m warming to the idea of the HelpHub. The issue I find with submitting feedback through the WP article is that the feedback disappears into a black hole, whereas with the HelpHub, I can track the issue.

    Thread Starter Basil Hendroff

    (@basilh)

    After lot’s of googling, I’ve started to get my head around this article. I still believe the way the article is written, sections of it are misleading and ambiguous. I suspect that this has occurred because the article has been cobbled together from a variety of sources over a long period of time. This is evident from the inconsistent use of the English language in various sections.

    I’ve identified three areas that could be improved:
    1. Moving a Root install to its own directory
    This section is misleading. What’s impacted is the WordPress Address URL, not the Site Address URL. The site is still accessed at https://example.com. What changes between method I and II is that WordPress is accessed at https://example.com (Method I) or https://example.com/subdir (Method II).
    2. Method II (With URL change)
    Here’s an instance where Google backfires. A search reveals there are many opinions on what constitutes WP core files. The intent of the articles is that core means the whole WP installation. I believe the best way to address this is to remove the word ‘core’ from this section.
    3. .htaccess modification
    The heading level and the placement of this section suggests that it is related to Method II. In fact, it appears to be more closely aligned to Method I.

    Apart from the identified issues, the article is full of spelling and grammatical errors.

    Thread Starter Basil Hendroff

    (@basilh)

    @revgeorge Thanks for responding. I agree, but I’m still confused probably because of the way the article is written. Let me rephrase using your example.

    In Method I, the address in the browser will be unchanged https://example.com, but the rewrite references the WP installation in /blog.

    What’s unclear about Method 2 is that it talks about WP core files being relocated to /blog. Does this suggest that the WP installation is now split into core and non-core (i.e. wp-content) files with the core files being moved to /blog while wp-content remains in root? Or is ‘core’ used loosely and the intent is that the whole WP installation is still moved to /blog?

    If I assume the WP installation is not split, but is moved to /blog, then if I follow the instruction, it appears I login to the site at https://example.com/blog, but visitors still access the site at https://example.com. There’s no visible redirection for visitiors Is this the expected behaviour?

    Forum: Fixing WordPress
    In reply to: mTLS and WordPress
    Thread Starter Basil Hendroff

    (@basilh)

    @fierevere Thanks for responding. A bit of background first.

    1. WordPress + PHP web server, Reverse Proxy – OK
    2. Static file server, mTLS server, Reverse Proxy – OK
    3. WordPress + PHP web server, mTLS server, Reverse Proxy – Not OK

    The points above summarise what was tested in the Caddy forum link referred to in the OP. I’ll briefly go through each of the points above so that, by a process of elimination, we can focus on WordPress and not be overly concerned with the Caddy component, which is providing reverse proxy and mTLS services.

    WordPress + PHP web server, Reverse Proxy

    I’ve had this arrangement working for years. What this tells us is that the PHP web server and reverse proxy server are working. For WordPress and WP-CLI to work in this arrangement, after the opening <?php tag in wp-config.php, I have added the code:

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

    Reference: PHP notice: Undefined index on $_SERVER superglobal

    Note that this is not the same as the code specified in the WordPress guide Using a Reverse Proxy. That guide suggests the following code:

    
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
$_SERVER['HTTPS']='on';

    This doesn’t work for me as it generates an HTTP 500 error.

    Static file server, mTLS server, Reverse Proxy

    In this working arrangement, I have a basic static file server behind an mTLS server and the reverse proxy server from the previous point. The reverse proxy provides automatic HTTPS, and mTLS ensures the backend path between the file server and reverse proxy is encrypted. What this arrangement tells me is that the mTLS server is configured correctly and communicating with both the file server and reverse proxy.

    WordPress + PHP web server, mTLS server, Reverse Proxy

    In this arrangement, I swap out the file server from the previous point and replace it with the working WordPress + PHP web server from the first point. From the previous two points, I can say with a high degree of confidence that all the building blocks i.e. PHP web server, mTLS server and reverse proxy, are working properly.

    The question then becomes ‘What needs to be added to wp-config.php for WordPress to work in this arrangement?’

    I leave in the added code from point 1:

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

    As indicated in the OP (and detailed in the Caddy forum thread linked in the OP), WordPress responds to the mTLS server, but being one step removed from the reverse proxy, can’t find its way back there.

    So, I take out the added code from point 1 and replace it with the suggested code:

    
$_SERVER['HTTPS'] = 'on';

    This time I get an HTTP 500 error.

    Thread Starter Basil Hendroff

    (@basilh)

    All good. I just needed to wait for CDN propagation.

    Thread Starter Basil Hendroff

    (@basilh)

    The issue is resolved with the latest patch. Tested on an iPhone 4s and 6s on FireFox, Chrome and Safari browsers. Thank you!

    The support I’ve received is beyond what I’d expect over this Xmas holiday period. I’ve bought this theme for a client site and will do the same again for each client site that I use this theme on. It is my go-to theme. Apart from arguably being the best of the elite theme offerings (and free to use if you aren’t able to pay for it), the support is what sets it apart from other themes and plugins (even better than the impressive support I receive from Automattic for its offerings).

    Thread Starter Basil Hendroff

    (@basilh)

    I was hopeful the replacement file would fix the issue. Unfortunately, there’s been no change to the end result. Note that I cleared the frontend cache WP Super Cache, the object cache Redis as well as the browser cache. Tested on Firefox, Chrome and Safari browsers on the iPhone 6s.

    Thread Starter Basil Hendroff

    (@basilh)

    @htmlpie, test results…

    A) Please check the landscape mode too, if you haven’t already.

    Problem appears in both portrait and landscape modes. Only way to recover is to refresh the page.

    B) Check with other browsers too, such as Firefox and Chrome.

    Problem is reproducible on Firefox, Chrome and Safari browsers on an iPhone 6s.

    C) If you have any plugins that are installed on both sites, disable them for a bit to see if it makes any difference.

    I went one better and set up a fresh WP install at test.udance.com.au with no plugins, caching and widgets. I also used WP 5.5.3 rather than the latest 5.6. Only the Pen theme was enabled. The problem persists.

    Thread Starter Basil Hendroff

    (@basilh)

    Hi @htmlpie, after disabling both Sticky:Header and Sticky:Mobile Menu, I cleared the local browser cache, cleared the website caches – I use WP Super Cache for the website frontend and Redis for object caching, and retested using both Safari and Chrome on the iPhone 6s with no change to the end result.

    Thread Starter Basil Hendroff

    (@basilh)

    Hi @tmmbecker, thanks for your reply. I’ve cleared cookies and still have the issue. The website also uses WP Super Cache for frontside caching and Redis for object caching. I’ve cleared both, but still see the issue. I’ve reported the problem using the contact form.

    Thread Starter Basil Hendroff

    (@basilh)

    @htmlpie, that’s a good question! I just checked and yes, I get the same result with the hamburger menu on blog.udance.com.au using an iPhone 6s.

    Thread Starter Basil Hendroff

    (@basilh)

    Hi @bruceallen,

    Please refer to the blog post https://blog.udance.com.au/2020/12/22/jetpack-wordpress-com-login-issue/, which clearly demonstrates the issue.

    Thread Starter Basil Hendroff

    (@basilh)

    Hi Jen,
    Thanks for the hint. You’ve jogged my memory. Hmmm… I thought I had unlinked and relink properly (no errors reported), but yes, I have two WordPress accounts. The earlier one uses a standard gmail address; the later a branded email address. I’m trying to migrate to using the latter. Is that possible?

Viewing 15 replies - 1 through 15 (of 35 total)