In a new post to her blog today Lorna Mitchell has a few suggestions for handling database patching when your application starts to outgrow its simple roots.

One problem that seems to need solving too often is how to keep databases in sync across different platforms, different developers working on a project, and deploying database changes along with code changes. There are lots of ways of approaching this, none of them are really excellent however and personally I tend to err on the side of simple being better. Fewer dependencies means a solution more likely to work on every platform (and no additional complications for the live platform). Usually this means patch files of some kind.

She outlines her usual approach - creating a table with metadata and version information, export the structure of the database in push it into a row, creating numbered patch files and keeping it all stashed away in versioned source control for easy access. Check out the comments for some more interesting ideas.

Brandon Savage has written up a look at the Suhosin patch for PHP (a project lead by Stefan Esser), what it can do for your PHP installation and his opinion on the benefits.

Last week, I received an email from someone who told me how the Suhosin patch had created problems for their team, and suggested that I write about it here. I thought this was a great idea, for a number of reasons. Particularly, Suhosin is one of those PHP patches that alters the way PHP operates in a fundamental fashion, yet also is installed by default in many places (for example, Ubuntu compiles this patch in by default on their installation).

He talks about some of the features it includes - disabling eval, not allowing for remote includes, makes it possible to modify the memory limit per script and allows you to set limits on the length of REQUEST arrays. He notes that, while the Suhosin patch is a good thing and can make a real difference in your application, it's by no means a requirement to creating a secure application (and shouldn't be used as a replacement for such).

There's also an interesting comment from Stefan Esser himself on the comments Brandon made in the post.

As mentioned on the Suhosin blog today, the latest patch for the PHP 5.3 edition of PHP (it's a beta) has been released:

Because the new features of Suhosin Patch contains new code and some hacks I release the BETA version of the new Suhosin Patch to the public and hope people will test it in different OS/CPU/... and mail me the results to . The patch can be downloaded here.

Issues considered in this new patch version include the support for environment variables that let you configure how certain parts of the patch work (like memory handing and canary violation handling).

In this quick post to his blog Arnold Daniels points out their patched version of the Suhosin hardening patch for PHP 5.3.

The hardened-php project has yet to release a suhosin patch for PHP 5.3.0. We're already using PHP 5.3, therefore I've modified the 0.9.7 patch for 5.2.10 to work with 5.3.0.

The Suhosin patch, created by the Hardened-PHP project is a protection system aiming to help protect your PHP installation from some of the common (and not so common) flaws in the PHP language itself. It's applied as a patch to the source before compiling and gives you a list of features for the base engine, runtime, session and filtering protection.

Following up on all of the craziness that was caused by the suggestion of including type hinting into the PHP core, Ilia Alshaetsky recently posted some of his thoughts on how things turned out and where he'll go from here.

Unfortunately, while initial outpouring of support for inclusion of type hinting into PHP 5.3 and 6 was substantial, it all kinda petered out once more people started voting. To be specific, there is a large amount of support for the feature in general, but very few people seem to think it should go into 5.3. [...] That said, at work we will transition to 5.3 soon, probably around 5.3.2/3 time, so I do need a type hinting patch. To that effect I've cleaned up and improved the old patch based on comments from various people, notably Stas and Dmitry (thank guys) and made a copy that I intend to use for work.

He talks about how the patch works - no more virtual types and no casting support. Three things have been changed to make it all work: modification to the parser, added a getTypeHint function, properly parse type hints in the code.

Ilia Alshanetsky takes a look at type hinting in PHP (he's made some previous comments on the matter) and some of the community's comments about its suggested inclusion in the language.

There has been a lot of comments both on this blog and the internals list. There seems to be a fairly large group of core developers who like the idea as well as surpassingly large support base on the user level too (wow, didn't think that this many people want type hinting).

Despite some of the nay-sayers who don't think it's a good idea, the majority seems to approve and work has already been done on a new patch you can apply to your systems. He includes the Changelog information as well as links to the patch (txt) and a test suite (bz2).

One of the features included in the PHP 5.x releases is type hinting for validating that you have the right values for your functions and methods coming in. In this new post to his blog Ilia Alshanetshy takes a look at the the feature and gives a patch to add it .

On a general level most people agree it would be a good idea to have, since it is an optional feature and does not introduce any regressions, heck you can even mix type hinted code with the non-type hinted one. The "PROBLEM" has always been combining of PHP's typeless nature with type hinting, which is where the consensus has been difficult (impossible) to reach.

He mentions an example of why its such an issue (technically, both 1 and "1" are valid numbers) and includes a link to a patch that gives a new hint to help with the problem.

Elizabeth Smith has a quick tip for those out there working with PHP 5.3 and its thread-safe mode.

There have been some changes to internal PHP stuff for 5.3, and some don't always show up unless you're looking at your compile logs and testing with thread safety on. Currently Xdebug will crash and burn if you're using it with 5.3 and ZTS on.

Her solution came in the form of a PHP 5.3 only patch for XDebug and threads. If you're on Windows, you can also grab the patched compile to make things all better again.

Christian Stocker has posted about "the next take" on the PHP upload progress meter extension - a new version that plays a bit nicer on Windows than before.

The uploadprogress extension for PHP never really worked on Windows and since I don't have a Windows development environment I could never do a proper analysis of the problem. Until this week, when Tomas Holusa sent me an email telling me about some VCWD_RENAME problems on Windows.

A patch that was submitted a while back confirmed the issue and a new patch was written and submitted to take care of the problem. You can try out the new extension on Windows with either the normal Wind32 build or Win32 nts build.

Ilia Alshanetsky has officially submitted his logging patch for the mail function in PHP:

I've finally got of my ass and committed my mail logging patch I've written almost 2 years ago. This functionality is predominantly aimed at shared hosters that often have a problem identifying people who abuse the mail() function to send an in-ordinate amount of spam or hacked scripts used for the some purpose. The logging functionality is disabled by default but can be enabled on a per-directory or globally via 2 INI settings.

A new directive in your php.ini file (mail.log) lets you specify where the mail log needs to go. You can also use the mail.add_x_header setting to add in a mail header with the name of the script that sent it (and the UID).

It will be included in PHP 5.3 but if you're running PHP 5.2 and want to get a jump on it, here's the patch.