Error displayed if the PHP version is switched to 7.2

[Fat Rat]

I have recently migrated my SMF forum to a new host (hihosting.co.uk), since the migration I have had (too) many problems.

They manifest themselves as either a blank screen when accessing /smf or some other cache related issue.  The host tells me that this is a bug in SMF and the reason I didn't encounter it before is because the previous host (names.co.uk) were running an older version of php. Hihosting are running php 7.2


The host has sent the following;


This was caused by the cache. There looks to be a bug with the SMF-modSettings.php cache file that is generated.
I'd be best to contact SMF about this, as we can't find the bug reported.

This was the error displayed if the PHP version is switched to 7.2:
Parse error: syntax error, unexpected ''a:302:{s:10:"smfVersion";s:6:' (T_ENCAPSED_AND_WHITESPACE) in /home/vstromco/public_html/smf/cache/data_6f24b05f17ee1ca8e806bffee275fa07-SMF-modSettings.php on line 1

And may have been the cause of the blank loading page when running PHP 5.6

Here is the offending line:
<?php if (!defined('SMF')) die; if (1543365912 < time()) $expired = true; else{$expired = false; $value = 'a:302:{s:10:"smfVersion";s:6:"2.0.11";s:

[Kindred]

there will be a whole lot more errors.

SMF 2.0.x does not currently support php 7.2

but, just delete the data_ files in the cache directory

[Arantor]

Firstly, SMF 2.0 does not support PHP 7.2 properly.

That isn't the case of your problem, though. I'd wonder if there is more content in that file we could see?

[Fat Rat]

To confirm, I am running 2.0.15.

The host has previously deleted the cache but the problem comes back fairly quickly

[Kindred]

then it's a problem with the host...    occasionally cache files get corrupted, but if it keeps happening, that indicates a problem on the host side.
You could turn off all caching.
You could also provide the file, as Arantor asked.


but, also, as I said, SMF 2.0.x does not support 7.2 at this time.

[Arantor]

@Kindred, it does not indicate that at all. There is at present one known bug in 2.0.15's file cache system and I want to see the file if I can to see if there is a related problem, or a different problem. I can think of multiple possibilities about this.

[Fat Rat]

Arantor,

Thanks you for your interest and input. The file is attached.

[Fat Rat]

Further details from the host;

Just to add, line 1 of the mod-Settings file:
<?php if (!defined('SMF')) die; if (1543365912 < time()) $expired = true; else{$expired = false; $value = 'a:302:{s:10:"smfVersion";s:6:"2.0.11";s:4:"news";s:576:"Visit our shop for T Shirts and other goodies! www.v-strom.co.uk/shop

States:
"smfVersion";s:6:"2.0.11"

However the SMF version is meant to be 2.0.15

So there could be an issue there. It looks like in part SMF 2.0.11 may still be present?
I've also placed an a zip of the whole cache directory here:


As it may not be the modSettings.php file that was the issue.

We're speculating that it may be, because of the error that's revealed for it when switching to PHP 7.2

However it could be any other cache file that was corrupted or the issue today.

[Arantor]

No, that just means it was originally installed as 2.0.11, not that any of it is still installed.

I will repeat that SMF 2.0 is not completely compatible with PHP 7.2 but that it is not related to your current situation. Unfortunately I can't check the file right now as I'm at work and only have an iPad but I'll look at the file tonight and see what might have caused it, I have a few ideas.

[Fat Rat]

Thank you. Some further clarity on PHP versions.

We are not running PHP 7.2 though. You're now running PHP 5.6 with us, and have been, but switching to PHP 7.2 revealed an error that indicates the blank screen when running PHP 5.6 as you have seen was caused by the cache.

[Arantor]

The change to PHP 7.2 is not related to this. It's just not related. Any apparent relationship is honestly coincidental.

[Fat Rat]

Arantor, have you looked at the files?

[Arantor]

Not yet, I'm still at work but I don't have to look to know what issues PHP 7.2 and SMF 2.0 will have.

[Fat Rat]

Thanks.

[Arantor]

OK, so the error is because the file has been cut part way through for some reason.

Is that the entire file? Did you download it via FTP? (What client did you use if so?)

[Fat Rat]

The entire cache is zipped here https://

[Arantor]

Thanks for that, much appreciated as it answers all my questions - but it reveals one more.

Would you mind also attaching your Sources/Load.php file? I just want to verify one thing about your installation and whether you've just been unlucky or whether there's a symptom I thought we'd fixed that has since reoccurred.

[Fat Rat]

Here it is. I am assuming/hoping that none of these files I am posting here contain anything sensitive relating to my site?

[Arantor]

I didn't think about it before - I was looking at what the symptoms were rather than the content but now that I look, I see that the cache files should all be removed as they do contain some things that could be used in... less than pleasant ways. (Not to directly attack your site, but some of the services you make use of.) You may need to report posts to the moderators to get them to remove the attachments though.

I'm actually more confused than before, though. I was wondering if you'd somehow gotten an older Load.php that didn't upgrade properly but you do have the corrected cache code.

The issue you have is that when SMF wrote a cache file out for your modSettings, it only wrote part of the file. We've seen this before, and we thought it was fixed - but seemingly not.

Question for your host: did they add 'file_put_contents' on the restricted function list? If they say no, then I don't know how this can be fixed short of just turning off caching (or just removing modSettings from being cached). Specifically, the issue is that in the old way of doing things, it would write one chunk of the cache (8192 bytes, usually) and for unknown reasons not write the rest. We switched this some time ago to use file_put_contents which claims to write the entire file but it seems that on some occasions it can end up writing just 1 chunk's worth.

Thing is... if file_put_contents is not on the forbidden list, that would imply there's either something wrong with your host's PHP build or something wrong with their filesystem... neither is a good feeling.

[drewactual]

what happens when httpd or php.ini has output_buffering set lower than the file being written? will it just chunk it or does it drop altogether?