Any chance there's an error in your config.php file?
Else I wouldn't know where to start looking for this output to be honest.
Admin White Screening
Re: Admin White Screening
Thanks for your replies DrCSS and Velden
Dr CSS - was PHP 7.3.3; toggled it back to PHP5.6 to see if it made any difference - it didn't - same problem there; now back on PHP7.3.3 again
Velden: I've a few things to try to try to narrow it down. currently FTPing the whole file system to my PC so I can try some better searches to find where the spurious "</</" are coming from
Its about time I installed a recent Xampp; I can try running the website from my PC; see if the same error occurs there and that way I can access all error logs
Alternatively I can create a brand new (bare bones) install of 2.2.10 modules in my 1&1 Ionos hosting account - see if it has the "</</" then install each of the modules I'm using; see at what point the "</</" are being introduced
Dr CSS - was PHP 7.3.3; toggled it back to PHP5.6 to see if it made any difference - it didn't - same problem there; now back on PHP7.3.3 again
Velden: I've a few things to try to try to narrow it down. currently FTPing the whole file system to my PC so I can try some better searches to find where the spurious "</</" are coming from
Its about time I installed a recent Xampp; I can try running the website from my PC; see if the same error occurs there and that way I can access all error logs
Alternatively I can create a brand new (bare bones) install of 2.2.10 modules in my 1&1 Ionos hosting account - see if it has the "</</" then install each of the modules I'm using; see at what point the "</</" are being introduced
Re: Admin White Screening
I wouldn't expect this to come from a commonly used module or core. Imagine how many users would face the same issues then, it wouldn't go unnoticed.
Do you have some custom UDTs (User Defined Tags)? Or did you transfer this website using FTP (which may corrupt files)?
I'm also thinking of (corrupt) language files (e.g. admin\lang\ folder) as possible cause.
You could rename module_folders to prevent them from being loaded. That would be a quick way to find out if it's caused by one of the modules.
Do you have some custom UDTs (User Defined Tags)? Or did you transfer this website using FTP (which may corrupt files)?
I'm also thinking of (corrupt) language files (e.g. admin\lang\ folder) as possible cause.
You could rename module_folders to prevent them from being loaded. That would be a quick way to find out if it's caused by one of the modules.
Re: Admin White Screening
these </</ or similar are also happening on the front end of your website. maybe check your FEU forgotten password template for clues, as I get this:
The FEU login has a similar problem, and is also not valid.<h5></</Forgotten Password</h5>
Re: Admin White Screening
Thanks Velden & rotezecke for your replies
I too am starting to strongly suspect that these characters are being displayed from lang files; and perhaps the FEU lang files.
A view source of what the browser receives for the forgotten password page shows the H5 is getting corrupted
And yet compare that to the template The Fieldset Legend and the preceeding H5 are the same field but ones getting corrupted
From having run CMSMS with debug on; on many occasions, many of the modules load when CMSMS loads regardless of whether used so I will start my search in the FEU language files
I did try a brand new CMSMS2.2.10 install and installed all the modules in use - no errors and no "</</" however no content; no pages. I've downloaded the filesystems for both websites and done a full file compare they are identical (i.e. it proves I've not corrupted any of the scripts in the websites that is problematic). However it also suggests the bug exists in both; it just isn't being exposed in the empty website because there aren't any pages causing a particular logic path to be executed. I could try swapping the DBs to prove this
The hunt continues ......
I too am starting to strongly suspect that these characters are being displayed from lang files; and perhaps the FEU lang files.
A view source of what the browser receives for the forgotten password page shows the H5 is getting corrupted
Code: Select all
<h5></</Forgotten Password</h5>
<fieldset id="forgotpassword" class="uk-fieldset">
<legend class="uk-legend">Forgotten Password:</legend>
And yet compare that to the template
Code: Select all
<h5>{$mod->Lang('title_forgotpw')}</h5>
<fieldset id="forgotpassword" class="uk-fieldset">
<legend class="uk-legend">{$mod->Lang('title_forgotpw')}:</legend>
From having run CMSMS with debug on; on many occasions, many of the modules load when CMSMS loads regardless of whether used so I will start my search in the FEU language files
I did try a brand new CMSMS2.2.10 install and installed all the modules in use - no errors and no "</</" however no content; no pages. I've downloaded the filesystems for both websites and done a full file compare they are identical (i.e. it proves I've not corrupted any of the scripts in the websites that is problematic). However it also suggests the bug exists in both; it just isn't being exposed in the empty website because there aren't any pages causing a particular logic path to be executed. I could try swapping the DBs to prove this
The hunt continues ......
Re: Admin White Screening
I also received white page error in admin panel of cmsms.
I resolved the error to increase the memory limit,
Please try after increase the memory limit in config file.
memory_limit = 32M
try to increase 64 or 128 M. May be this resolve your issue.
I resolved the error to increase the memory limit,
Please try after increase the memory limit in config file.
memory_limit = 32M
try to increase 64 or 128 M. May be this resolve your issue.
Re: Admin White Screening
Thanks for the reply rahulu - right back at the start of this issue Digi3 suggested looking at the PHP errors; and because I use a shared hosting system that isn't possible; but I did immediately install a php.ini I commonly use elsewhere which included a memory directive and since then - no more white screening
But the spurious "</</" characters before the <! doctype declaration has been a nightmare but it caused many of the Admin system Ajax functions to fail - which in turn made using admin often problematic. Also an error in the front end, but only "</" (which implied the erroneous characters are getting displayed twice in Admin but only once in the FE.
I had tried building a new CMSMS2.2.10 plus modules and doing a file compare between the problem website and the new install but I coundln't see any red flags.
I also installed the latest Xampp and used Xdebug to trace the scripts.
After an extremely long hunt I narrowed it down to these characters were getting "displayed" sometime after the InitializeAdmin for specifically FEU - after more hunting and debugging I finally found the culprit - and I am embarrassed that it is my own stupid careless mistake - but I'll document it here so that if anyone else ever has this problem and searches for possible AJAX killers they may benefit from this confession
I found that the culprit was the /assets/module_custom/FrontEndUsers/lang/en_US.php which had the following contents which gets {eval} in the password reset process
Ho hum - wish I had thought to check that at the start - thanks all for the suggestions
But the spurious "</</" characters before the <! doctype declaration has been a nightmare but it caused many of the Admin system Ajax functions to fail - which in turn made using admin often problematic. Also an error in the front end, but only "</" (which implied the erroneous characters are getting displayed twice in Admin but only once in the FE.
I had tried building a new CMSMS2.2.10 plus modules and doing a file compare between the problem website and the new install but I coundln't see any red flags.
I also installed the latest Xampp and used Xdebug to trace the scripts.
After an extremely long hunt I narrowed it down to these characters were getting "displayed" sometime after the InitializeAdmin for specifically FEU - after more hunting and debugging I finally found the culprit - and I am embarrassed that it is my own stupid careless mistake - but I'll document it here so that if anyone else ever has this problem and searches for possible AJAX killers they may benefit from this confession
I found that the culprit was the /assets/module_custom/FrontEndUsers/lang/en_US.php which had the following contents
Code: Select all
</<?php
$lang['info_password_reset'] = "Your password has successfully been reset. Please {cms_selflink page='home' text='login'} to continue.";
?>
Ho hum - wish I had thought to check that at the start - thanks all for the suggestions