White screen page while viewing as guest but not when logged in as admin

[Randem]

System:
VPS Server
EasyApache 4
Apache 2.4
PHP 8.3.14
AlmaLinux 9
SMF 2.1.4
MySQL 8.3.14

Load.php was looking for a file that did not exist (jquery.sceditor.theme.css) as Guest, but as Admin it was looking for (jquery.sceditor.default.css). It failed with a white screen and no log entry. Debugged and after encountering line 2836 (directly after "// Are we validating the the file exists?"), the code went to sessionwrite and ended with white screen.

This situation did not happen on every page, only on some...

I changed the code to the following and it seems to have corrected the issue when a file does not exist. The pages now show and no white screen. The original code is commented out.

Code Select Expand

    // Is this a local file?
   
    $mtime = 0;
    if (empty($params['external']))
    {
        // Are we validating the the file exists?
        if (!empty($params['validate']) && (file_exists($settings[$themeRef . '_dir'] . '/css/' . $fileName) === false))
        {
            // Maybe the default theme has it?
            if ($themeRef === 'theme' && !$params['force_current'] && (file_exists($settings['default_theme_dir'] . '/css/' . $fileName) !== false))
            {
                $fileUrl = $settings['default_theme_url'] . '/css/' . $fileName;
                $filePath = $settings['default_theme_dir'] . '/css/' . $fileName;
                $mtime = @filemtime($filePath);
            }
            else
            {
                $fileUrl = false;
                $filePath = false;
            }
        }
        else
        {
            $fileUrl = $settings[$themeRef . '_url'] . '/css/' . $fileName;
            $filePath = $settings[$themeRef . '_dir'] . '/css/' . $fileName;
            $mtime = @filemtime($filePath);
        }
    }
/*
    if (empty($params['external']))
    {
        // Are we validating the the file exists?
        if (!empty($params['validate']) && ($mtime = @filemtime($settings[$themeRef . '_dir'] . '/css/' . $fileName)) === false)
        {
            // Maybe the default theme has it?
            if ($themeRef === 'theme' && !$params['force_current'] && ($mtime = @filemtime($settings['default_theme_dir'] . '/css/' . $fileName) !== false))
            {
                $fileUrl = $settings['default_theme_url'] . '/css/' . $fileName;
                $filePath = $settings['default_theme_dir'] . '/css/' . $fileName;
            }
            else
            {
                $fileUrl = false;
                $filePath = false;
            }
        }
        else
        {
            $fileUrl = $settings[$themeRef . '_url'] . '/css/' . $fileName;
            $filePath = $settings[$themeRef . '_dir'] . '/css/' . $fileName;
            $mtime = @filemtime($filePath);
        }
    }
*/


[Aleksi "Lex" Kilpinen]

Firstly, a white screen usually means an error that should have been logged. On the server.
https://wiki.simplemachines.org/smf/What_the_white_screen_of_death_means

Secondly, I think - I'm not 100% sure on this right now - jquery.sceditor.theme.css is not a part of the default theme, and so the default theme should not actually look for it. It is possible to use it to customize the editor for a custom theme. Based on that, I'd ask were your guests and the admin actually using the same theme to begin with?

[Randem]

I am just reporting what happened and the files load.php was looking for. I did not just make up the file names, it was right there in the debugger... Secondly, "My Guest" and the "Admin" are the same person... Me. This is how I test, logged in as well as logged out. This is how I found what the Load.php file was looking for on both cases. This is not imaginary or "what I think"... I also provided the solution.

I know what the white screen of death means, but like everything else in the world there are more ways to achieve everything without the same results. Working as admin but not as guest... also looking for two different files using the default theme, which is the only one installed. You state what you think like there have never been errors in SMF before that may have needed to be corrected or changed...

This is why my results were very detailed and the solution was given which fixes the error no matter how it was achieved. Besides the white screen of death would not just disappear... THERE WAS NO GUESSING INVOLVED!

[Aleksi "Lex" Kilpinen]

Well, sorry but no - a guest and a logged in user are not the same person to SMF, even if they are the same user behind the keyboard. Also, you never mentioned the theme before I brought it up, so asking for confirmation on missing details is pretty standard. Also also, you may reach the same result in a multitude of ways, but without actually knowing why it failed, or how you came to your conclusions, you may have simply addressed the symptoms instead of the actual issue. Trying to find out what the actual issue was, is what we do here.

[Randem]

I know a guest and a admin are not the same person to SMF, That is exactly why I mentioned the different in the workings of the error. Yes, I may have addressed the symptom, but isn't this what this thread is for? To mention something that is happening incorrectly to the SMF developers?

I just provided a solution that works, It is up to the developers of SMF to research and find out the original issue if they so choose. I could have just kept it to my self and gone about my business instead of attempting to help the SMF developers look into a pending issue.

I have a solution that works for me and it seems from your response that I should have just kept it to myself...

[Arantor]

Firstly, a white screen usually means an error that should have been logged. On the server.
https://wiki.simplemachines.org/smf/What_the_white_screen_of_death_means

Secondly, I think - I'm not 100% sure on this right now - jquery.sceditor.theme.css is not a part of the default theme, and so the default theme should not actually look for it. It is possible to use it to customize the editor for a custom theme. Based on that, I'd ask were your guests and the admin actually using the same theme to begin with?

This one is one for @shawnb61

[Aleksi "Lex" Kilpinen]

I have a solution that works for me and it seems from your response that I should have just kept it to myself...

I am simply trying to understand the details of the issue, that is all.

[shawnb61]

For a bug to be logged, we need steps to follow for folks to independently reproduce the bug. 

I suspect this is a broken theme.  If this is all with the default theme, I suspect some custom code causing an issue.  If this were a core issue with loading the default theme, more than one person would have the problem.

As for the different behavior for admin vs a user, if you have multiple themes installed, different users can choose different themes.

Those sceditor files are named a little funky, & it's not as straightforward as it should be for folks customizing themes.  Two files are needed, and custom themes use different file names than the default theme:

- jquery.sceditor.theme.css covers the appearance of the sceditor area.  From the rows of formatting buttons to the bottom of the textarea.
- jquery.sceditor.default.css covers the textarea ONLY, in WYSIWYG mode ONLY.

So if you want a unique appearance of the editor, e.g., buttons & toolbars, etc., update jquery.sceditor.theme.css in your theme folder.  It may help to start with a copy of jquery.sceditor.css from the default theme.

If you want to control WYSIWYG appearance within the editor textarea, update jquery.sceditor.default.css in your theme folder.  It may help to start with a copy of jquery.sceditor.default.css from the default theme.

There are a couple discussions up on GitHub about how this could be made easier & more flexible for theme devs:
https://github.com/SimpleMachines/SMF/issues/7681
https://github.com/SimpleMachines/SMF/issues/8135

[Diego Andrés]

I do find this bug report believable with no customization since the function is supposed to also check if a file exists in order to skip it... Not sure why it would break though.

[Randem]

This issue is with only the default theme loaded and no other users. This is development and testing, not a live system, so there would not be other users or other themes. I have also copied the  jquery.sceditor.default.css file to jquery.sceditor.theme.css and that has also solved the issue without the code change.

It can be possible that the version of Linux, PHP or server that I am using may operate a little different on some errors. All that I can say for sure is that when ($mtime = @filemtime($settings[$themeRef . '_dir'] . '/css/' . $fileName)) === false) fails it goes to the sessionwrite sub-routine then ends with no server or SMF errors. This is why I changed the code to file_exists which does not fail. I would want to believe that the SMF developers would want SMF to operate on most systems and the code I provided would do just that without an error being activated and that is why I reported it.

@shawnb61
Thank you for the explanation as to what these files are for, I now have an understanding of them. However I am doing nothing close to those operations. Everything is the default, no theme or text editor modifications.

@Arantor
Thanks for getting this to the person who has shed some light on the issue.

[shawnb61]

My initial suspicion is that filemtime() was disabled by the host, and that SMF isn't expecting that particular function to be disabled.

The current 2.1 logic here checks that the file exists.  It does so by doing a call to filemtime(), because we also want the timestamp of the last change to key css files.  filemtime() will return false if the file doesn't exist.

The proposed change removes the filemtime() check, and also comments out the subsequent cache checks based on the timestamp, and substitutes a simple file_exists() check instead. 

The problem is that the filemtime() method is tied to SMF's method for detecting & forcing browser cache refreshes upon changes to the primary css files.  So this proposed fix breaks that...  (https://github.com/SimpleMachines/SMF/pull/5363)

For some reason, filemtime() didn't work here.  I would attempt to understand why before disabling SMF's ability to detect & force .css refreshes.

[Randem]

The problem is filemtime works as it is used later in the script, so it breaks nothing as I can see. It's most likely the logic formulation in the line that the server is having issue with, since filemtime is actually still used. Or maybe it is the fact that the file is just not found with filemtime that is the issue. Does the cache update when a file is not found? I don't understand how the changed code breaks anything.

[Randem]

Also look at the documentation for filemtime and it states

Return Values

Returns the time the file was last modified, or false on failure. The time is returned as a Unix timestamp, which is suitable for the date() function.
Errors/Exceptions

Upon failure, an E_WARNING is emitted.

So if the error is not ignored on @filemtime SMF seems to trap the E_WARNING and ventures to sessionwrite. This may be the reason why the documentation uses the following example with file_exists.

Code Select Expand

// outputs e.g.  somefile.txt was last modified: December 29 2002 22:16:23.

$filename = 'somefile.txt';
if (file_exists($filename)) {
    echo "$filename was last modified: " . date ("F d Y H:i:s.", filemtime($filename));
}


[Randem]

I did some testing on filemtime and it behaved just like I reported. In the image you will see 4 different tests. The 4th test is using filemtime with an error handler active. As you see the error handler interrupts the program flow even if the @ sign is prepended to filemtime. This will cause the code to terminate in the error handler and not continue with the code. So, in my conclusion it is better to check if the file exists before using filemtime if an error handler is active. Otherwise you will get the same results as I have reported. I have also attached the code that I used to test with. So the @ has no effect with filemtime when an error handler is active.

Code Select Expand

<?php

    echo 'Randem Systems - ' . date("y-m-d") . '<br>filemtime with file that does not exist:';
    Separate();
    
    test1();
    test2();
    test3();    
    test4();
    test5();
    
function test1() {

    // outputs e.g.  somefile.txt was last modified: December 29 2002 22:16:23.

    echo "Test 1 - With file_exists<br><br>";
    $filename = 'somefile.txt';
    if (file_exists($filename))
        echo "$filename was last modified: " . date ("F d Y H:i:s.", filemtime($filename));
    else
        echo "$filename does not exist";
    Separate();
}

function test2() {

    // outputs e.g.  somefile.txt was last modified: December 29 2002 22:16:23.

    echo "Test 2 - Without @<br><br>";
    $filename = 'somefile.txt';
    $filedata = filemtime($filename);
    echo 'filedata = ' . var_export($filedata) . '<br>';
    echo "$filename was last modified: " . date ("F d Y H:i:s.", $filedata);
    Separate();
}

function test3() {

    // outputs e.g.  somefile.txt was last modified: December 29 2002 22:16:23.
    echo "Test 3 - With @<br><br>";
    $filename = 'somefile.txt';
    $filedata = @filemtime($filename);
    echo 'filedata = ' .  var_export($filedata) . '<br>';
    echo "$filename was last modified: " . date ("F d Y H:i:s.", $filedata);
    Separate();
}

function test4() {

    // outputs e.g.  somefile.txt was last modified: December 29 2002 22:16:23.
    echo "Test 4: With @ and Error Handler<br><br>";
    set_error_handler('TestErrorHandler');
    error_reporting( E_ALL && ~E_NOTICE && ~E_DEPRECATED );
    
    $filename = 'somefile.txt';
    $filedata = @filemtime($filename);
    echo 'filedata = ' . var_export($filedata) . '<br>';
    echo "$filename was last modified: " . date ("F d Y H:i:s.", $filedata);
    TestRestoreErrorHandler();
    Separate();
}

function test5() {

    // outputs e.g.  somefile.txt was last modified: December 29 2002 22:16:23.
    echo "Test 5: With @ and Error Handler & Combo Line<br><br>";
    set_error_handler('TestErrorHandler');
    error_reporting( E_ALL && ~E_NOTICE && ~E_DEPRECATED );

    
    $filename = 'somefile.txt';
    (($mtime = @filemtime($filename)) === false);

    echo 'mtime = ' . $mtime . '<br>';
    echo "$filename was last modified: " . date ("F d Y H:i:s.", $mtime);
    TestRestoreErrorHandler();
    Separate();
}

function TestErrorHandler($errno, $errstr, $errfile, $errline) {

    echo '<br>';
    echo ' **** Error No: ' . $errno . '<br>';
    echo ' **** Error Line: ' . $errline . '<br>';
    echo ' **** Error: ' . $errstr . '<br>';
    echo ' **** Error File: ' . $errfile . '<br>';
    echo '<br>';
    exit;
}

function TestRestoreErrorHandler() {

    restore_error_handler();
}

function Separate() {
    
    echo '<br><br>' . str_repeat('*', 80) . '<br><br>';
}
?>


[shawnb61]

If you really want the devs to look at a proposed code change, the proper way to do so is to submit a PR.

A couple clarifications - yes, warnings suppressed by "@" still go to the error handler.  That's normal.  The SMF error handler deals with those.  And yes, if the file doesn't exist, or other issues are encountered, per the spec quoted above, filemtime will do two things: (1) return false, and also (2) throw a warning.  The warning will be suppressed by the SMF error handler, so the code will resume execution & use the return value of false.

The real question here is why it wasn't suppressed in your case, it appears some form of non-recoverable error was thrown.  A couple searches and it appears that filemtime() will choke hard if there are filespec issues (e.g., improper paths) or permissions issues.  For this reason, folks do suggest calling file_exists prior to checking filemtime as a safety measure.

So your PR may be approved.  Another layer of safety never hurts.

If what you're saying were true, however, it wouldn't work for anybody.  But it works everywhere but in your test environment...  That's why this particular issue still feels to me like a local issue.  If I were diagnosing this further I'd look much closer at paths & permissions in play at the time of failure.