[cbutler]

The PHP language developers have decided the PERL/preg functions are superior, so the PHP ereg() family is being deprecated in PHP 5.3, and removed in PHP 6.0

That will break every PHP-based website I've developed over the past 5 years, and I suspect I'm not alone.

I'm hoping some TCH gurus are paying attention and will complain loudly on this issue, because TCH gurus can expect total outrage from PHP users like me when the transition to PHP 5.3 or PHP 6.3 occurs.

The solution seems simple. Just tell the PHP language developers to keep the ereg family in the codebase, but state explicitly that no further development or bug fixes will be done on those functions.

Thanks,

Chris Butler

[TCH-Ryan]

As a developer myself, sometimes it is hard to strike a balance between legacy feature support and moving forward with changes that will enhance performance, reliability or security (or all of). Let me be clear, I do develop php code and extensively use ereg in allot of my stuff, however I do think that going forward and given sufficient time people can safely transition to perl regexp functions with minimal effort. The actual transition to php6 is a bit of a ways off in any production environment and likely will resemble transitions of the past in that for a short time, php5 compatible binaries will still be available on servers to allow legacy applications to work without major overhauls in the short term.

Identify where you use ereg functions, start making it habit in new development projects to stop using it and over time back track older code and replace it. At the end the day, php developers are just trying to do what they feel is right for the community at large, which as a matter of preference most agree perl regexp is far superior than maintaining a stand alone regexp implementation.

[OJB]

I'm a PHP developer (note: not someone who works for PHP, but someone who works in PHP) and to be honest I don't think I have used an ereg in about 2 years now. All my PHP regular expressions are written using preg, but in response to cubtler's post even if TCH as a whole objected to deprecating the ereg functions there is nothing they could do about it. A single company complaining to the php developers wouldn't do anything. This sort of thing will continue to happen as PHP matures and develops as a language. I mean think back to when register globals was enabled by default and how many people will have coded relying on that functionality. Then PHP realised it was a security risk and disabled it by default (can't remember which version that was) and I'm pretty sure it will be removed at some point too. Unfortunately as the language evolves so must the developers.

[carbonize]

I stopped using ereg a few years ago as I prefered the power of preg. You can only support old functions for so long until you have to say that's it and turn them off. If we all lived by your philosophy of not changing things we would still be all using $HTTP_GET_VARS instead of just $_GET or we would all still be designing websites that looked right in IE5.5 and Netscape 4.

Oh and please learn what deprecated means. Here's what it says on php.net/ereg

This function has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 6.0.0. Relying on this feature is highly discouraged.

"DEPRECATED as of PHP 5.3.0" not removed. This means they are planning on removing it and so you will get a warning that the function is deprecated if you use it but, and this is the important part, IT WILL STILL WORK. As web developers it is up to us to keep up with the latest functions, changes, ideas and PHP will give you a warning when something has become deprecated so you have time to learn what it has been replaced with or a better way of doing it.

This post has been edited by carbonize: 16 August 2009 - 07:15 AM

[cbutler]

Yes, I know what deprecated means. What in my initial message suggests otherwise?

All my websites have most PHP error reporting options enabled, because I want to know when a problem arises. When 5.3 hits, I suspect I'll have to turn some PHP error reporting bits to keep "deprecated" messages from squirreling client websites. Not a major effort, but it would be nice if 5.3 included a bit or a function to specifically turn off ereg deprecation warnings while leaving other warnings enabled. Fat chance...

When PHP 6.0 hits, I'll have no choice to modify every client website I've ever written in PHP. This isn't a simple typing exercise. I'll have to retest everything I've written -- shopping carts, photo galleries, databased catalogs, etc. Anybody who revises code and doesn't retest it, hasn't been in this business long enough.

I figure two weeks to revise and retest, if everything goes well.

Plan B is simply to leave the ereg stuff in the PHP codebase, tell the world it's no longer being supported, and use it at your own risk. Perl-based regular expressions are more capable, but the ereg functions are more POSIX-compliant. What's wrong with keeping both?

I'm a Unix guy at heart, but I appreciate that Microsoft owns a big chunk of the computing universe because they grok "backward compatability". It's why Cobol is still around, and still arguably the world's most portable language.

Maybe I'm naive, but I suspect TCH support staff will be losing some weekends and evenings soon...

Chris Butler
BS/CS 1980

[carbonize]

Why would TCH lose any time over it? Not their problem what PHP chooses to support or not support. So long as PHP works as it is supposed to then that's their job done.

[cbutler]

Months after my initial post, I'm grateful to the TCH crew for keeping my reseller account (server Philadelphia) below PHP 5.3. My websites still work, and I've had time to prepare for the inevitable.

Some folks may be interested in my conversion efforts, after I upgraded to Snow Leopard, which ships with PHP 5.3:

1) I wrote a set of "acme" wrapper functions for the few ereg functions that I use, which map between ereg and preg. I also wrote a PHP script that changes ereg calls to "acme_ereg" calls. A few regular expressions needed hand-tweaks, but that approach seems to work.

2) My home-grown PHP framework used $namespace as part of my effort to deal with the lack of early namespace support in PHP and CSS. PHP 5.3 confiscated that keyword, so I wrote another script to change all my instances of $namespace to $acme_namespace. Again, that approach worked.

3) Ditto for "split()" (deprecated) and "mysql_list_tables()" (deprecated).

4) PHP 5.3 no longer seems to allow <? as a PHP intro tag, requiring <?php. I wrote yet another PHP script to change my existing code, some of which dates back to 2002, when <? was kosher.

Every modified website had to be tested.

This is a trickier than some might expect, because PHP is a just-in-time interpreter/compiler. The tester must actually hit each code path to test it. If you use a conditional "include", your PHP code may not even get a basic syntax parse.

I'm near a happy ending, and wish everybody else good fortune in their conversion efforts.

But to the PHP developers: dohhhhh! The number one rule of successful software development:

Don't break existing code!

My Intel-based MacBook can still run PowerPC code via Rosetta, and Microsoft still supports the (idiotic) A: B: C: drive-naming convention that dates back to CP/M. (See Unix "mount" for the correct solution.)

Deprecate any code you want and don't waste further development/debugging efforts, but leave it in the code tree.

C code I wrote in 1980 still works. Cobol still works. PHP is the only language I've used that punishes early adopters.

Again, thanks to TCH for being realistic. TCH has always been a reliable partner for me.

Cheers,

Chris

This post has been edited by cbutler: 19 May 2010 - 04:05 PM

[TCH-Ryan]

Thank you for your input cbutler, at this moment we have no intention to push on php 5.3. It is on our agenda for things to explore and we do intend to get there eventually but there is no clear need or demand for it at this time, till that changes or a security issue emerges that compels us otherwise, we will likely remain on the 5.2.x stable tree. When we do upgrade, everyone will be given plenty of notice through the forums along with a road-map of what servers will be upgraded with specific dates, allowing everyone to transition as seamless as possible.

[carbonize]

Just some updates.

PHP 4 is coming to the end of it's life now so there will be no further updates.
PHP 6 in it's present form, has been scrapped due to the complexity of adding unicode support to strings but some of it's features will be back ported to PHP 5.4.

This post has been edited by carbonize: 27 July 2010 - 11:00 AM

[Bob Crabb]

Here is one more item to add to the list of things to check to insure compatibility in PHP 5.3.

Prior to 5.3, it was alright to omit the link identifier when using the mysql_close()function. I have PHP 5.3 installed on the WAMPSERVER on one of my computers, and I just spent a fun filled hour trying to figure out why a script that works fine on the live site ( on a TCH server ) just dies with no errors shown in the Wamp server on that computer.

So, if you use mysql_close(), make sure that you use the link identifier for the connection that you want to close, instead of letting it default to the last link opened.

[carbonize]

Best practice to have included it anyway

Hell at least you used mysql_close unlike some scripts I have seen.