Thanks for checking in. We (Agathon Group) are actually the webhost, and we use an auto_prepend_file
to detect HTTPS requests that terminate in NGINX on our stack. Specifically, NGINX proxies to Apache/PHP and sets a header via this NGINX directive: proxy_set_header X-Forwarded-proto $scheme;
We pass the connection from NGINX to Apache without SSL, as it’s happening over loopback. This saves some CPU cycles.
However, it means that Apache has to know that the original connection (between the client and NGINX) was over HTTPS, or else it redirects to an https:// version of the site URL. The way it does that is to inspect X-Forwarded-proto
, and the way it does that is through an automatically prepended file:
<?php
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') $_SERVER['HTTPS'] = "on";
There are other plugins that write their own prepend file directive into .user.ini
but they properly detect the presence of an existing prepend file. One plugin in particular adds this (redacted) code to the top of their own prepend file:
// This file was the current value of auto_prepend_file during the [plugin] installation (Sun, 27 Jun 2021 23:30:08 +0000)
if (file_exists('/home/[user]/etc/prepend.php')) {
include_once '/home/[user]/etc/prepend.php';
}
It then follows with its own bootstrap instructions. This allows both our (existing) prepend file and the plugin’s (new) prepend file to be executed properly.
Blogvault doesn’t take this approach, and any existing prepend file is both overridden (in .user.ini
) and left unincorporated in Blogvault’s prepend file.
I can give you specific sites, but would rather not have to do so. I’m hoping, instead, that this is more than enough information to adjust the code that writes out your prepend file to test for the presence of an existing prepend and incorporate it, thereby not confounding our hosting stack.
Thanks!
Peter