One such example is the register_globals setting in PHP which finally managed to get deprecated in PHP 5.3 (and, the way things are going, may never disappear altogether) after much fighting and gnawing of teeth. [...] The existence of register_globals is problematic in many ways, but it is consistent: as long as you have a version of PHP that supports it installed, you will have the opportunity to use it1. When it is discarded, it ceases to exist, so that rewriting your code becomes a prerequisite to upgrading to a new version of PHP.

He also relates it to a <blink> tag - something that really shouldn't be used any more but, because someone decided it was a good idea in the past, several browsers have included support for it. The moral of the story? Well-planned standards are a good thing.

With the web and web sites open to everyone -- including malicious hackers -- the security of web applications sits at the top of the list of issues on any web developer's mind. In this eight-part series, we will look at the security concerns of PHP developers, and what they can do to make their web applications more secure.

They talk about the importance of having a security plan from the start and look at a few simple steps to get started with in enhancing your application's security - the proper use of register globals, using error reporting to correctly catch problems and how to minimize the code exposure of your app.

PHP's next edition, V6, includes new features and syntax improvements that will make it easier to use from an object-oriented standpoint. Other important features, such as Unicode support in many of the core functions, mean that PHP V6 is positioned for better international support and robustness.

New features he mentions include namespace support, improvements to the native Unicode support as well as a few of the things that will be permanently retired like the php.ini settings for magic_quotes and register_globals.

If you want to make use of PHP 6 when it comes, you're going to have to write your new scripts so they are compatible, and possibly change some of your existing scripts. To start making your scripts PHP 6 compatible, I've compiled a list of tips to follow when scripting.

There's only five things in his list (like "stop using magic_quotes" and "don't register long arrays") but the comments provide many more additional gotchas to look out for and new features that will be included.

Matt brings up some good points. What might be limiting PHP 5 adoption, could just be the lack of interest in developers. [...] Up until reading his rant, I've lived in a box where everyone I've talked to, used and enjoyed PHP 5 and its vast extensions. Developing in PHP 5.0 was uneventfully, but you learn to appreciate PHP 5 with the core inclusion of PDO with PHP 5.1. PHP 5 is not without annoyances. In the core developers attempts to "better" the language, they made changes that broke code that previously worked.

He looks at a few of the items for debate surrounding the move from PHP4 to PHP5 including the extensions that come bundled with PHP5, solving the register_globals issue, and a brief mention of the Standard PHP Library.

It's been a long road and exactly five years (35 releases) since the much discussed and highly controversial PHP directive register_globals has been disabled by default in PHP. After sifting through the mailing list archives, the following set of information has been compiled. Feel free to make additions, corrections, and report register_globals memories!

His list includes some recent "tidbits" about the directive (including the fact that there's still lots of code in the PHP CVS repository that requires register_globals to be on). Following that, there's his brief timeline of the directive's progression - from its infancy as gpc_globals all the way up to more recent events - like its removal from the PHP 6 HEAD CVS versions. With the release of this next major version of PHP, "the beast" can finally be laid to rest.

I am aware that there are some things so shocking that you are not supposed to say them in polite company [...] so confronting that they are best kept to yourself regardless of how strongly you believe them. I have a similarly shocking sentiment that I feel I have to share.

I really like register_globals in PHP.

He reminicies about the days gone by of being able to assume that register_globals is turned on, the days of simpler, lighter code that's even easier for the newbies to get into. Anyone for a tshirt?

The PHP development team would like to announce the immediate availability of PHP 4.4.6. The main issue that this release addresses is a crash problem that was introduced in PHP 4.4.5. The problem occurs when session variables are used while register_globals is enabled. Details about the PHP 4.4.6 release can be found in the release announcement for 4.4.6, the full list of changes is available in the ChangeLog for PHP 4.

Head on over to your local downloads page to get this new release in either:

• tar.bz2 format
• tar.gz format
• Windows binaries

As per Derick:

Because of this I'd like to release a 4.4.6 soon with this fixes. As there is also an upgrade to pcre 7.0 we'd need at least one RC, which I plan to release on Thursday.

Users of the PHP 4.4.x series should keep watch for this new update to correct the issue quickly.

Security in a scripting language such as PHP is more developer-dependent than language-dependent. In other words, although the language offers you the tools to create secure code, it cannot prevent insecure code. Thus, the degree to which code is secure almost entirely depends on how security conscious a developer is.

The article looks at three security-related topics:

• Register globals
• error reporting
• code exposure