[SMF 1.1.5] PHP4 compatability issue.

[Nathaniel]

Hello all,

I have noticed that there seems to be an issue with the loading of the Subs-Compat.php file for SMF 1.1.5 or SMF 1.1.4, which doesn't appear in SMF 2 Beta 3.1.

This is how the index.php loads the file on line 61 for SMF 1.1.5.

Code Select Expand


// Using an old version of PHP?
if (@version_compare(PHP_VERSION, '4.2.3') != 1)
require_once($sourcedir . '/Subs-Compat.php');


This is how the index.php loads the file on line 65 for SMF 2 Beta 3.1

Code Select Expand


// Using an pre-PHP5 version?
if (@version_compare(PHP_VERSION, '5') == -1)
require_once($sourcedir . '/Subs-Compat.php');


When using SMF 1.1.5 with PHP 4.4.2 the Subs-Compat.php file doesn't even seem to load.

I only noticed this error because I have created and tested a Mod (Site Integration Mod) which adds the scandir() function to the Sub-Compat.php file. When using SMF 2 Beta 3.1 and PHP 4.4.2 this works correctly, however when I use SMF 1.1.5 and PHP 4.4.2, SMF gives me these nasty errors.

Fatal error: Call to undefined function: scandir() in ****/index.php on line 354

I *know* that this is not caused by my mod because when I remove the php version checking for the Subs-Compat.php include, it works perfectly. 

So unless I was meant to do some weird voodoo when I added the function to the Subs-Compat.php file then this is something that is wrong with SMF. My first guess would be that SMF 1.1.5 only tries to support a single version of PHP 4 (PHP v4.2.3, which seems kind of pointless) and that this issue was realised and fixed in the Beta but not in SMF 1.1.5.   

[SleePy]

In the 1.1.5 install change that code to this:

Code Select Expand

// Using an old version of PHP?
if (@version_compare(PHP_VERSION, '4.2.3') == -1)
require_once($sourcedir . '/Subs-Compat.php');

Does it function properly now?

[Nathaniel]

No that doesn't make it work, but if I replace it with the SMF 2 beta code it works fine.

Code Select Expand

// Using an pre-PHP5 version?
if (@version_compare(PHP_VERSION, '5') == -1)
require_once($sourcedir . '/Subs-Compat.php');

But a mod should really not have to do this, this should be standard for SMF shouldn't it?

[karlbenson]

As far as I understand it, it is because your using the Subs-Compat for a version other than was intended.

The Subs-Compat in 1.1.5 is ONLY meant to provide for functions that don't exist prior to 4.2.3.

However your trying to use the Subs-Compat to provide for a PHP5 function in PHP4.
So whats happening here is
Less than PHP 4.2.3 your function is provided for
PHP5 and above already has the function.
So your 4.4.2 falls in the missing gap in between.

SMF 1.1.5 DOES include some PHP4 compatible functions to provide the functionality of php5. Including stripos for example. They are NOT done in Subs-Compat, but in Subs.php (Search for stripos).

So this is not a bug in SMF.  You shouldn't really use the 2.x version (it may cause intended consequences for the other functions in the file.  Instead you should put the function in Subs.php
And declare the function like SMF has done for stripos (so if you using a php that does have that function, it won't try to redeclare it.

Code Select Expand


if (!function_exists('stripos'))
{
function stripos($haystack, $needle, $offset = 0)
{
return strpos(strtolower($haystack), strtolower($needle), $offset);
}
}


[SleePy]

It could also be put in the site intergration mod source file that uses it. So you don't have to modify another source file.

[karlbenson]

Indeed it could.

[Nathaniel]

Okay, Thank you everyone for the clarification.

I will put it into the Subs.php file for SMF 1.1.5. I was trying to put it into the Subs-Compat.php File only because I was told that I could do that by the member of the customization team that responded to my Mod application.

I will leave the function in the Subs-Compat.php file for the SMF beta version, please post and tell me if this is a problem.

Thank you again, I will fix this problem with my Mod.

[SleePy]

Its fine for SMF 2.0
The combat file just provides back port functionality for users who are not using that php version or higher.
In SMF 2.0 it was raised to php 5 and before that it was 4.2.3

[karlbenson]

Indeed its shifted up a notch for 2.x.

I'm sure by the time its ?smf 3? that it will be shifted up again to PHP6?

[SleePy]

I don't think so. I think at the most maybe 5.2..

But it will go up as php versions just get to old to provide support for.

[karlbenson]

I admit i haven't fully looked at the roadmap for php6 yet.

[SleePy]

Its going to be great
If su_php supported it (I haven't tested to see if it does though) I thought about using it concurrently on my live site.

It removes magic quotes, safe mode, register globals, and other PITA functions that have plagued developers to fix things.
Safe mode is going to make things interesting for hosts that use it, I am thinking though some idiot is going to come out with a module for php6 that adds it back in and hosts will continue to use it.
Even the register globals isn't going to be nice as there is still a work around for register globals. Which happens to be this nice little function: http://php.net/import-request-variables

Oh, and the best feature about php6 is its supposed to be full unique compatible So no more work arounds needed to get things working properly for UTF-8.

[rsw686]

If su_php supported it (I haven't tested to see if it does though) I thought about using it concurrently on my live site.

You should look at using suexec with fast-cgi. This does use more memory, but provides much faster page load times as it is not starting php processes each time. I use both for my virtual hosts depending on the load on the site.