The Zend Developer Zone has posted a book review of an Packt book, "Building Websites with Joomla! 1.5" (by Hagen Graf - the book, not the review):

The book is a tutorial guide to Joomla! 1.5 and was already written and published during the development of Joomla! 1.5. This is the final version and it aims for "web developers, designers, webmasters, content editors and marketing professionals" and is suitable for anyone starting out with Joomla! 1.5, for people who upgrade to Joomla 1.5 and for those who just want a good printed guide/manual at hand.

The review steps through the chapters, highlighting points of interest and the wrapup uses terms like "great instructional value", "very passionate about Joomla!" and the fact that the only thing the reviewer sees missing of a chapter about security.

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.

The admins over on the PHP-GTK Community site have announced a new resource PHP-GTK ircers can take advantage of - a new bot that hangs out in the #php-gtk channel over on the Freenode IRC network with an aim to be as helpful as possible.

The PHP-GTK.eu community site is now host to an IRC bot named Gataka (for "GTK"), helping users on the Freenode IRC channel for PHP-GTK, at irc://irc.freenode.net/php-gtk.

Currently is has an API interface (for PHP-GTK elements), user tracking and the ability to learn factoids. They're even starting to look for input regarding new features (log publication, in this case).

On the Making the Web blog, there's this post that talks about looking forward with your code and making it ready for when PHP6 comes around.

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.

Paul Jones presents a problem he was having in a new post to his blog - the issue was with memory leaks in objects in a PHP5 application he was working on.

One of the nice things about using a scripting language is that it automates garbage collection for you. You don't have to worry about releasing memory when you're done with your variables. [...] But there is at least one circumstance in which PHP will not free memory for you when you call unset(). Cf. http://bugs.php.net/bug.php?id=33595.

The problem is that, when trying to unset the parent object in a parent/child relationship, the memory space for the parent reference in the child isn't removed. The problem, left unchecked can cause a script to go over the memory limit pretty easily (especially with larger objects).

He suggests two solutions - one that the user can control (calling a destructor before unsetting the object) or a PHP internals method that involves fixing issues with the reference counts created with the objects.

On his blog today, Alex Netkachov has posted a suggestion of how to combat a common issue facing PHP scripts - their memory usage.

PHP has a build-in garbage collector so you do not need to track the links on the objects, allocate memory for objects and delete them when they are not longer necessary. Things seem so perfect that developers do not even know that their scripts allocate a lot of memory until their server stops processing requests because of the out of memory error.

His example is the processing of a parent/child relationship tree. If not managed correctly, the variables being used could get out of hand quite quickly. Alex recommends the use of a "destructor" at the end of each iteration to help destroy variables and values no longer needed.

The SitePoint PHP blog has a post that asks developers "Which reference sites do you trust?"

While completing the tech edit on the 2nd edition of the PHP Anthology the issue of linking came up; specifically, linking to authoritative reference material on the web. [...] The issue isn't simple one. Regarding PHP, the php.net manual is the authoritative reference site. The various web technology standards are also represented by authority web sites.

So what does he thing makes for a good, trustworthy resource? He includes criteria divided up into three sections - readability, accuracy & trustworthiness and longevity.

In a new post, Derick Rethans talks about circular references (a reference of a memory structure back to itself) and how they relate to PHP.

Circular-references has been a long outstanding issue with PHP. They are caused by the fact that PHP uses a reference counted memory allocation mechanism for its internal variables. This causes problems for longer running scripts (such as an Application Server or the eZ Components test-suite) as the memory is not freed until the end of the request. But not everybody is aware on what exactly the problem is, so here is a small introduction to circular references in PHP.

He starts by explaining what's so bad about circular references - issues not only with referencing the variable but also with freeing up the resources associated with it. He does suggest some solutions to the issue including garbage collection and cyclic tracing.

Stefan Esser has a new post mentioning a new patch that he's created to help correct an issue with the ZVAL Reference Counter that could cause a buffer overflow in an application.

When a PHP application is run in PHP 4 it can overflow the variable reference counter because it is only 16 bit wide. Whenever this happens it will result in a double destruction of the underlying variable. A local attacker can easily create PHP code that uses such a double destruction to execute arbitrary code within the process executing PHP (e.g. webserver process). This allows bypassing restrictions enforced by disable_functions, open_basedir, SAFE_MODE or to launch direct local root exploits against the target system.

The patch [tar.gz] fixes the issue and keeps from breaking anything from the past (backwards compatibility). You can either grab it now and apply it to your distribution (the sooner the better) or wait until it gets merged into the PHP CVS version and released with the next bug fix release.

If you think you know what's going on behind the scenes when you're working with objects in PHP5 - you're wrong. You're even being lied to, according to Sara Golemon's latest entry:

If you're among the crowd who have migrated an OOP based application from PHP4 to PHP5, then I'm sure you've heard the expression "Objects are copied by reference by default in PHP5". Whoever told you that, was lying.

As she explains, the truth is more that they behave that way, not that they are actually like that. She talks about what objects actually are and how things are handled differently from PHP4 to PHP5. She also "lies" a little also about the "copying" part, and explains the internal structure of a variable to show why.

She also includes a bit on why referencing variables when it's not really a must is a bad idea - the main idea of it being a waste of space and memory in the application.