custom changes to wp-includes/functions.php overwritten by automatic upgrades, breaking Cloudflare or squid frontend

[noexitorescape]

custom changes to wp-includes/functions.php are clobbered whenever there is an upgrade thereby breaking login functions with "too many redirects" error when WordPress is behind squid or cloudflare (or similar https proxy)

I have to re-insert it in wp-includes/functions.php manually every time I have an automatic update done in the background without knowing about it. good for security and good for knowing there was a recent update and to read about it. but I am somewhat nomadic and this may be problematic if I can't get at the CLI to remedy this in the back end. I do not recall encountering this until later versions of 6.x

I categorized this as an enhancement rather than as a bug, and if it is a bug then it is a trivial/minor bug or request if I'm the only one complaining about it. I am aware of how to fix it, it is just that after the 5th or 6th time here I wished to provide some feedback with apologies in advance if you have another recommended way to implement what others have done with this snippet in older versions of WordPress.

<?php
/**
 *  Enable HTTPS behind proxy service
 */

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

thank you

[noexitorescape]

description should read: "II do not recall encountering this until later versions of 5.x."

[SergeyBiryukov]

Hi there, welcome to WordPress Trac!

Thanks for the report, we're already tracking this issue in #31288.

Replying to noexitorescape:

/**
 *  Enable HTTPS behind proxy service
 */

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

You can put this code in wp-config.php before the /* That's all, stop editing! Happy publishing. */ comment, that way it won't be overwritten on updates.

This is something that comes up often, but is not something that can be fixed due to the nature of handling client-provided headers, which is what's needed to address the issue. See comment:17:ticket:31288 for more info.

The long and short of it is that this is a server-level configuration issue with reverse proxy web servers. It's not a WordPress issue, and it's not limited to WordPress. There's no need to modify the is_ssl() function. You just need to add something along the lines of the code above to your wp-config.php file. This simplified version might also work:

$_SERVER['HTTPS'] = 1;

Any proxy configuration is "supported" by WordPress, you just need to remap the $_SERVER['HTTPS'] server variable based the particular proxy configuration you're using.