On the Liip blog today Christian Stocker has posted about a few common issues developers seem to have with the upload progress meter extension and a few answers to help them out.

After I released uploadprogress 1.0.0 some days ago and finally declared it as stable, it's time to write that blogpost about some of the limitations and caveats one has to know.

The post links to a demo and answers a few different questions on issues such as:

• Running it on other modules than mod_php on Apache ( like fastcgi)
• Checking if files are too big
• The position and content of UPLOAD_IDENTIFIER within the form is important
• Why not use $_SESSION for the info?
• It segfaults, when I don't include UPLOAD_IDENTIFIER

See the PECL page for the extension for more information.

The latest issue of php|architect magazine has been released - October 2008. Articles in this new issue include:

• Alvaro Videla Godoy - The Propel ORM
• John Mertic - Using Mixins with PHP
• Forrest Lyma - Developing Digitalus

As well as the usual columns from Steph Fox, Jeff Moore and Marco Tabini. You can either buy the issue alone or you can subscribe and get a full year of high quality PHP goodness.

The Zend Developer Zone has announced the release of the latest preview of the Zend Framework - the Preview Release for 1.7.

We are excited to announce that the Zend Framework 1.7 Preview Release is now available from the Zend Framework download site! While 1.7PR is not a feature complete release in the 1.7 series, it nevertheless contains some very important features scheduled for the 1.7 production release.

Updates included in this release are things like the Zend_Amf component, an update of the Dojo toolkit, support for the dijit editor, some performance enhancements and other locale and internationalization changes.

You can download this latest release from the Zend Framework download page and be sure to log any problems you find into the issue tracker and help the ZF team make the framework even better.

Even with the release of PHP 5.3 looming closer and closer on the horizon, there's a few things that are still being worked through - one of which is the much touted namespace support. Elizabeth Smith has posted a few of the issues that she's having with how they're being implemented, four and a half of them, to be exact.

The first thing to clarify is that I like the new implementation overall, it's fairly light and although it isn't really namespacing or packaging in any sense of the word, the best way to describe it is aliasing, it does help keep code easy to use. In fact I have a couple of projects and even a PHP extension that's all namespaced code.

Her list of five (four and a half) things are:

• multiple namespaces in a file
• you can't have ANYTHING before the namespace statement but an opening <?php tag
• The autoload and resolution paths
• Functions in namespaces
• No use * and three million use statements (this is the one with the workaround - class_alias)

Michael Kimsal has pointed out a small irritation when using the Symfony framework and models - an issue when using models that have relationships.

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.

On the PHP::Impact blog, there's a new post mentioning some of the problems that he (Federico) has run into when his Zend_Form forms got larger and larger - performance.

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.

On the Ibuildings blog today, Harrie Verveer has posted about an interesting quirk he found when working with objects and references:

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.

If you're a WordPress user and are in the process of an upgrade from PHP4 to PHP5, you might be having a few issues. One problem can be cause by the wp-cache component and this recent post from Shantanu Goel.

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.

Matthew Turland has come across an "interesting bug" in PHP's stream wrappers functionality - some strange 404 or 500 HTTP errors in one of his scripts.

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.

According to this post on the PEAR blog, the first PEAR bug triage is now over:

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).