Just patched this forum to 2.0.18, forum is fine but ssi.php include on website homepage is causing wsod.
<?
include_once('/home/mrennhack/public_html/forum/SSI.php');
$_SESSION['login_url'] = 'https://www.nukeworker.com/forum/';
if (!isset($context['session_var']))
$context['session_var'] = $_SESSION['session_var'];
$context['session_id'] = $_SESSION['session_value'];
?>
Page loads if include is commented out.
Try adding
ini_set("display_errors",1);
Before and after the include.
SSI seems to load on that site.
Wasn't working, then it was, now it's back to wsod. There's a mod edit in SSI.php, will try removing it, see what happens.
Tried this, nothing -
<?
ini_set("display_errors",1);
include_once('/home/mrennhack/public_html/forum/SSI.php');
$_SESSION['login_url'] = 'https://www.nukeworker.com/forum/';
if (!isset($context['session_var']))
$context['session_var'] = $_SESSION['session_var'];
$context['session_id'] = $_SESSION['session_value'];
ini_set("display_errors",1);
?>
Only difference in SSI.php is .18 core code contains this -
global $auth_secret, $cookie_no_auth_secret;
If I replace it with clean file, it loads once, but goes back to wsod. Remove include, homepage loads. Is there anything wrong with include code?
Uninstalled 2.0.18 patch, no good. Uninstalled mod that was conflicting with patch in ManageSettings.php, no help. Reinstalled .18 patch (no errors), I have it working now with SSI.php from 2.0.17 backup (attached). Looks like it's all core except for bad behavior mod include. Something in .18 patch is apparently causing the problem.
Version Information:
Forum version: SMF 2.0.18 (more detailed)
Current SMF version: SMF 2.0.18
GD version: bundled (2.1.0 compatible)
Database Server: MariaDB
MySQL version: 10.0.38-MariaDB
PHP: 7.1.33
Server version: Apache
just checked... SSI works fine on my systems. Running 2.0.18 with SSI functions being used on 3 sites.
The good news is that there haven't been a lot of changes...
The file you provided has a mix of 2.0.18 & 2.0.17 code in it, & is missing some 2.0.17/2.0.18. It looks like changes have been manually applied at some point. It is actually closer to 2.0.18 than it is to .17.
The file you provided is missing some auth_secret globals that are in both 2.0.17 & 2.0.18.
The only other real change is the magic_quotes_runtime check. It won't go there if you are at 7.4 or greater.
Not quite sure what your issue is, but the first thing I'd do is see if adding the globals back reintroduces the issue. If so, then there is an authentication problem of some sort. I'd make sure your auth_secret settings make sense.
The bad behavior change looks very minor. The next thing I'd try would be manually applying the BB change to a vanilla 2.0.18 file instead of this tweaked one. If that works, you're done.
It's inconsistent. Worked for a while with .17 SSI.php backup, uploaded clean .18 file, broke it, reuploaded .17 backup, still broken. Only thing that works consistently is removing include from website index.php. Beginning to think it's a server caching issue, then I get this today -
Quote from: NukeWorker.com on February 18, 2021, 06:39:41 AM
It's still not working when people use an "incognito" mode, which forced it to use fresh resources. OR some one they doesn't come to the site daily, and needs fresh resources.
For people like you and i that have files cashed, it works...
Server is logging a lot of these -
[Thu Feb 18 16:31:31.064071 2021] [core:crit] [pid 7481:tid 47674761463552] (13)Permission denied: [client 185.191.171.14:57604] AH00529: /home/mrennhack/public_html/404/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/home/mrennhack/public_html/404/' is executable
[Thu Feb 18 16:30:43.765814 2021] [core:crit] [pid 23791:tid 47674795083520] (13)Permission denied: [client 95.163.255.96:34068] AH00529: /home/mrennhack/public_html/404/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/home/mrennhack/public_html/404/' is executable
[Thu Feb 18 16:30:37.593116 2021] [core:crit] [pid 7481:tid 47674750957312] (13)Permission denied: [client 41.169.79.166:44186] AH00529: /home/mrennhack/public_html/404/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/home/mrennhack/public_html/404/' is executable
[Thu Feb 18 16:29:52.729338 2021] [core:crit] [pid 7481:tid 47674788779776] (13)Permission denied: [client 209.133.111.211:52392] AH00529: /home/mrennhack/public_html/404/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/home/mrennhack/public_html/404/' is executableRemoving .htaccess has no effect.
If I rename SSI.php to ssi.php, and change filename to match in ssi include, it works.
What does this mean? ???
That means you're on unix, which is case sensitive.
Odd that works, though. I would search all code for all references to "ssi.php" and "SSI.php" and make sure they are consistent. If your custom code has a lower-case version somewhere, that likely explains it.
I know it's case sensitive, that's why I changed it. The include seems to be loading a bad SSI.php from somewhere else, possibly server cache. When file is renamed, include loads it correctly from forum and it works. Rename it back to SSI.php, wsod. I can rename all occurences of SSI.php in forum code (not that many), that may fix the problem but will probably bork future updates.
The problem apparently started here (https://www.simplemachines.org/community/index.php?topic=576679.msg4081306#msg4081306), this was before I got involved. Upgrade to 2.1 failed, host restored 2.0.17 backup. I upped him to .18, down to .17, back to .18. Same thing either way. I have him checking with host re: server caching.
Yes, I would leave them at SSI.php, but consistent.
The code uses an 'include'? Normally we use a 'require' - I would be tempted to change it to 'require' & see if any behavior changes. Maybe a require_once...
Thought of that but didn't try it. He's been running that code long time. Will give it a shot, but it appears the SSI.php that it's loading is a damaged file, where it's coming from is a mystery.
Does it use relative or absolute path? The httpd can be configured to allow cross domain sharing on a shared server include/require, but man, is that dangerous....
There is another httpd setting that finds broken links, too... though I don't recall it's name. Premise is if an include/require doesn't find the file it searches other directories for that file and uses it if it finds one... another bad juju on a shared host but sometimes handy on a dedicated... not that I would use it... but... its available.