PHP 5.3 and 6.0 issues

[caltuna]

Does anyone you know why PHP is dumping the ereg() command in 6.0 and do they know how much work it will be for people to change code?

Example: ereg($my_pattern, $xxx, $yyy) must be changed to preg_match("/" . $my_pattern. "/", $xxx, $yyy).

You have to surround the pattern with a delimiter ("/").

What in the world are the PHP people thinking? Why can't they keep ereg and come up with a better expression function that people can use if they want? It makes no sense about what they are doing in PHP 6.0.... unless I'm missing something.

I have a large application/web-service we sell on a subscription basis (http://www.jaya123.com) ... which is a small-biz billing/order-entry/reporting system with several hundred thousand lines of code (most I wrote)... with a lot of "ereg" pattern matching functions. It will take weeks of work. Thank you, PHP developers!

Maybe someone will write a utility to help us make the changes... or maybe someone will write the equivalent of the current ereg() functions (as well as the split() function.

(I assume everyone knows by now to change the php.ini file's "error_reporting" entry so as to not see the "deprecated" messages that will pop up in PHP 5.3 (which the latest build of XAMPP has.)

[Wiedmann]

Does anyone you know why PHP is dumping the ereg() command in 6.0

ereg does not work with unicode.
(and of course the other advantages of pcre opposite ereg)

(I assume everyone knows by now to change the php.ini file's "error_reporting" entry so as to not see the "deprecated" messages that will pop up in PHP 5.3

And not forgetting that people can read since ~8 years in the manual to use pcre instead of ereg

[caltuna]

What is "pcre"? Obviously, I don't keep up with PHP since our application was written in PHP 4.x. We did some magic to it for 5.x but until something breaks we don't really follow the point-upgrades.

I read somewhere that you can use "mb-ereg() but I have no idea what that is all about.

Our server (pair.com) company will go to 5.3 later this year and as long as they will change the php.ini error_reporting entry we will be fine until 6.0 is released and tested... so that buys us at least a year I would think... maybe more since Pair Networks is very conservative in making changes (they run FreeBSD on all their managed/dedicated servers.)

Thanks for your help. Any additional info on this "pcre" issue that you can provide is greatly appreciated.

[Wiedmann]

What is "pcre"?

As you can see in the PHP manual, the function "preg_match" is provided by the pcre extension (available since PHP 4.0.4).

[caltuna]

I'm going to have to go into php.net and see what is happening (more often!) I have no idea what "extensions" are. The ereg() functions are used in a number of library-utility routines that we got open source and we have not changed them since they worked in 4.0 and 5.0. They are being used in lots of date verifications. I forget why! We will have to change some 100 or so PHP scripts to preg_match() for 6.0 but it won't be that big a deal so long as we have plenty of time to do it. (grep is your friend!)

[Wiedmann]

I have no idea what "extensions" are.

Only a few functions are part of the PHP core. The most functions are part of individual extensions (which may be enabled in your installation or not).
Simply ask to a programmer from your company. That one can simply explain that.

[MegaChriz]

@caltuna
I don't think it is needed to go through all the files manually to change ereg to preg_match.
The best way would be to write a script that goes through each php-file, and changes ereg($pattern, to preg_match('/'.$pattern.'/',.
I think you can probably make use of the function preg_replace()

Something like this:

Code: Select all

$sFileContent = preg_replace('/ereg\(/','preg_match(\'/\'.', $sFileContent);

This way you will replace the first part of the ereg()-call. You will have to figure out how to replace the second part as well.

Maybe you also want different replace-patterns on those places where the stringpattern itself is placed after ereg( instead of a variable:

Code: Select all

$sFileContent = preg_replace('/ereg\(\'/','preg_match(\'/', $sFileContent);
$sFileContent = preg_replace('/ereg\(\"/','preg_match("/', $sFileContent);

[caltuna]

Thanks for the scripting ideas. It is worth taking a hard look at. Fortunately we have our own server and we don't have to switch to PHP 6 if we don't want to... but at some point in time we will obviously have to.... and by then we will have the code modified. It is only in a hundred or so scripts and is not hard to fix.

What I fail to understand is why the PHP developers actually have to remove a function that is working. They can leave it in there for legacy code or make it php.ini selectable or something like that. I fail to see where ereg() is a security risk. I have no problem with the PHP community wanting us to code with certain functions, but to arbitrarily remove something just because they have something "better" makes no sense.

[Wiedmann]

What I fail to understand is why the PHP developers actually have to remove a function that is working.

ereg is not removed in the current PHP 5.3 and is still working.

[caltuna]

What I fail to understand is why the PHP developers actually have to remove a function that is working.

ereg is not removed in the current PHP 5.3 and is still working.

Yes, but it is going away in 6.0. which is going to cause a lot of needless work to keep legacy programs running.

This is where the open source modal breaks down. A private company might say "Well, we better not remove this function because our customers will be furious and might go to our competition." But open source communities don't have that concern to a large extent.

I fail to understand why they have to delete a function that works and that is not a security threat... and TTBOMK ereg() works fine and while slower than preg_ it does not constitute any kind of security issue.

[Wiedmann]

why they have to delete a function that works

Because this extension does not work anymore with PHP6 (the internal API is too different). Well, this can happen in every release. In PHP5.3 they have (must) also removed 2 extension. But it's not really an issue because it's always the sames step:
- first you can read for years in the manual to use a new extension for this task.
- one release before it will be removed, the extension is marked as depreciated
- and at least the extension is gone

And it's always curious, that also common scripts stop working at this last point. Even the authors knows for years what will be happen (and can use snapshots to test their code). Just see what happens these days if you update a server to PHP5.3. And there are really minor changes compared to PHP5.2. But people still write code as if PHP3 is the current version...

But that happens with all programs and languages, that old functions will be removed at some day. Nothing new for a programmer.

It makes no sense about what they are doing in PHP 6.0....

Or in the current version. e.g. the timezone warning. That's really nonsense.

[caltuna]

If they are going to give us a year before 6.0, that's OK. 5.3 is the first time I've seen a deprecated message. We wrote www.jaya123.com (there is a free demo... no personal info required) in PHP 4 about five years ago. The move to 5.0 caused no problems that I recall. There might have been one script (out of a couple of hundred) that needed a change.

My fear (but not a great fear) is that they will spring PHP 6.0 on us next week, and lots of ISPs will upgrade to it... and there will be chaos! I didn't know that PHP has a procedure for eliminating a widely used function.

We have our own dedicated server and can have the ISP (pair.com) install any version of PHP we want... but we also MUST stay current for major security reasons... so we really don't have the luxury of running 5.x when 6.x comes out because we don't know what exploits have made 5.0 vulnerable. Indeed, the only reason we upgrade is for security, not speed or new "features." When we wrote Jaya123 a lot of the world was still on dial-up so we made it tight and bare-bones, knowing that some of the constructs like classes and OOP would be refined later on and maybe leave us with a lot of re-writing. And besides, compared to something like SugarCRM, our Jaya123 is much smaller (but still almost as complex.)

Thanks for all the good info. If I had my way (and the resources) I'd re-write the entire mess with Ruby/Rails... or use a PHP framework like CodeIgniter... but that is not about to happen in this economy.

[sili]

I assume everyone knows by now to change the php.ini file's "error_reporting" entry so as to not see the "deprecated" messages that will pop up in PHP 5.3 (which the latest build of XAMPP has.

That is a very bad advice and only leads to problems that you have now.

Why don't you just write your own ereg() function?

Code: Select all

<?php
function ereg(..., ..., ...) {
    return preg_match(..., ..., ...);
}
?>

[caltuna]

Why don't you just write your own ereg() function?

The application is 200,000 lines of PHP code (http://www.jaya123.com feel free to try the demo... no personal info required.) I don't have the time to do what you suggest (which by the way is not a bad suggestion) nor do I want to take the risk that I will code it wrong and really screw things up.

Yes... eventually (when 6.0 comes out) I'll have to make some changes, but I'll wait until then. In the meantime not seeing the error messages is the best solution and so far (since January) we've had no problems pop up with doing that. When they release 6.0 perhaps we will re-write the entire application since it was originally done in 4.0!

[Nobbie]

The application is 200,000 lines of PHP code (http://www.jaya123.com feel free to try the demo... no personal info required.) I don't have the time to do what you suggest (which by the way is not a bad suggestion) nor do I want to take the risk that I will code it wrong and really screw things up.

a) anyway, it is the right way and VERY EASY TO IMPLEMENT, even in applications with million of lines

b) if you are not willed to take that risk and if you think you do not have the time for that patch (what takes 5 minutes effectively), then you clearly are the wrong man for that job and you should seriously think about doing different things than programming or administrating.

Yes... eventually (when 6.0 comes out) I'll have to make some changes, but I'll wait until then.

This is really a bad idea. Why dont you simply create a development environment with the current release (simply copy all data and scripts) and implement the desired changes JUST NOW? It is your own lazyness that brings you in calamity without any needs! Stop waiting and blaming others for your own problems, wake up just now!

I am a serious programmer for many many years and this "problem" is a well known standard problem (one of many) of many many projects, i really cannot understand your behaviour in this case. Sorry for the harsh words, but it is as it is.