If there are relations (an Author has a Book, for example). the generated forms will complain that the generated Models need a __toString() method to be used in the Form/View. In grails, this is the case, but every domain (corresponding to a Symfony 'model') has an implicit toString() method already generated, which return the string ":". For most production work, you'll want to override it with whatever you need the string to read, but for prototyping, it's fine.

He went in and modified the Symfony core to add in a __toString call that would return the object correctly. Several of the commentors agree with his frustration and some of the Symfony developers even chime in with some of the reasoning behind why it's like that.

If you are using Zend_Form and your site increases in complexity and attracts more traffic, you are most likely to run into performance problems. Of course, bigger and more complex projects result in more load on your servers. [...] In this post I'll explain the problems I faced when using Zend_Form and how I managed to optimize it and improve the performance of my application.

He ran a few tests against his code and found out that one of the biggest causes of overhead was the many calls to other components in the framework to handle different parts of the output. His solution was to modify the Zend_Form_Elements component to check for dependencies before the form is executed. Pre-loading like this prevents the high-overhead (and repetitive) dynamic loading later on.

PHP is a loosely typed language. Most of the time this is very useful because you as a programmer don't have to worry about typecasting: it's done for you. However, on some occasions this can cause some unexpected trouble. [...] In this blog I want to point out what can happen if you try to access object properties by reference when the object is not initialized.

His example shows the problem when it tries to grab a value from an array in a non-existent object by reference. It results in a dyanamically created object (of that type) with an empty array inside of it. It only works when you grab it by reference, but he shares a tip or two about how you can prevent hard to track down issues like this.

The issues range from weird page layouts, to some controls not working, to some errors popping up here and there, and probably your blog not even displaying. This occurs because even though WordPress is PHP5 compatible, some of the plugins you are using might not be.

In his case, it was the wp-cache plugin that was causing the problems. Permissions weren't right to allow it to do its job. This resulted in problems rendering content and with the site acting as it normally would. His solution involved disabling and reenabling the plugin after deleting the cache and lock file the plugin uses.

I wrote a small script a while back that's gained a surprising amount of popularity thanks to a plug from the site that it posts to. [...] I learned that this [connection from the script] could be done with streams, I attempted to implement it in that fashion, but ran into strange issues where I would get 404 or 500-level HTTP errors rather than the response I was expected.

He eventually found the bug related to his problem (in the 5.2.x branch) but happily notes that it has been corrected and will be patched in the upcoming 5.3 (and 6) branches.

PEAR's bug tracker hit the 600+ open bugs mark a month ago. [...] So with 600+ open bugs (not including the feature requests), we had to do something. [...] The logical step was to hold our own bug smashing event and see how it works for PEAR.

Back on March 22nd and 23rd (Easter weekend) they hunted for bugs. Several developers showed to help out and many bugs were fixed and they managed to bring the number of open bugs for PEAR down to 547 with the two days of work. There were some milestones reached too:

Thanks to the triage, we are close to reaching two important milestones: Closing bug reports with lower bug ID than 1000 (1 bug left!) and 2000 (5 left).

Every so often I try to use PDO under PHP5, and every time I run in to basic functionality problems with no ability to find out what's going on under the hood.

He includes a few comments supporting his statement including an issue where a prepare() call didn't work, his frustration with not being able to see what's "under the hood" and the lack of documentation to help with these sorts of issues.

There is a new PHP magazine called "Enterprise PHP" available in English, German and French which might even console those missing the apparently ill-fated International PHP Magazine. Back before publication the usual tree of suspects led me to being interviewed for the initial edition published a short while back.

The current issue (which you can get for free after a survey) has articles looking at testing your PHP scripts, how "professional" it is to use PHP and the fact that Java is not PHP (wait, isn't that backwards?)

My work station is WinXp system and my friend where I had to create it for has the new Vista and somewhere over 9000 pictures to be managed. On my system everything worked fine, but on my friends system i always got the error can not open file.

Further testing revealed that it was the OS at fault - Vista wasn't handling the memory usage for the application correctly. When it was run directly from the file explorer (versus in the PHP-GTK console) though, it worked just fine.

It's a pretty good article about database design and I think all PHP developers who are just starting to integrate databases in their applications should read it. However, there are a few things I'd like to add and point out.

The "blurb" for the article mentions MySQL, PostgreSQL, Oracle, Microsoft SQL, SQLite and database schemas. You can find out more about this issue, including how to get your own copy, from the php|architect website.