About once a day, a user asks me which Zip version they should use: the bundled version (PHP 4 or in 5.2+) or always rely on PECL. There are different cases, and all of them are good except one.

I strongly recommend to not use the bundled Zip extension in PHP 4.x (which is the PECL version 1.0). The later versions (1.1.0 or later in PECL, and bundled in PHP from 5.2.0 and later) is 100% backward compatible. For example, the version 1.8.7 fixes a leak in the old API.

PHP 5.2.0 includes Zip, and all the fixes available in PECL. The only difference between PECL’s Zip and the bundled version is the release cadences. I try to release to PECL on a monthly basis, either a development version (new features, improvements) or a bug fixes, or even both when there are enough supporters . The PHP security policy may hide a problem or two in various changelogs, but be sure that both the PECL releases, and the PHP releases, will have the latest issues fixed.

Summary:

• 5.2.x, bug fixes only or minor improvements
• PECL Zip 1.8.x, bug fixes only or minor improvements
• PECL Zip 1.9.x, development branch, the current improvements include good stuff like pattern based additions or extractions and iterators. The improvements will be available in a PHP only after the first stable PECL release

And a new bug fixes release has been released today, see the complete changelog here.

• Zip Homepage
• Zip Changelog

During my upgrade to dotclear2, I noticed some notices about ""Indirect modification of overloaded property" and thought they are minor (notices…) and can be somehow ignored, bad idea

It seems that the known issues with setter/getters with array are more serious than I thought, being not really a fan of these magic methods, especially not for arrays or other non scalar data, I did not really "care", selber schuld

In the case of dotclear, the workaround is relatively easy:

<br />
class context<br />
{
  public $stack = array();</p>
 
  public function __set($name,$var)
  {
    $this->stack[$name] = $var;
  }
 
  public function __get($name)
  {
    if (!isset($this->stack[$name])) {
      return null;
    }
    return $this->stack[$name];
  }
}
 
	<p>$ctx = new context;<br />
$ctx->comment_preview = array();<br />
$ctx->comment_preview[&#8216;content&#8217;] = &#8216;&#8217;;<br />
$ctx->comment_preview[&#8216;rawcontent&#8217;] = &#8216;&#8217;;<br />
$ctx->comment_preview[&#8216;name&#8217;] = &#8216;&#8217;;<br />
$ctx->comment_preview[&#8216;mail&#8217;] = &#8216;&#8217;;<br />
$ctx->comment_preview[&#8216;site&#8217;] = &#8216;&#8217;;<br />
$ctx->comment_preview[&#8216;preview&#8217;] = false;<br />
$ctx->comment_preview[&#8216;remember&#8217;] = false;<br />
var_dump($ctx);</p>
 
	<p>$comment_preview = array();<br />
$comment_preview[&#8216;content&#8217;] = &#8216;&#8217;;<br />
$comment_preview[&#8216;rawcontent&#8217;] = &#8216;&#8217;;<br />
$comment_preview[&#8216;name&#8217;] = &#8216;&#8217;;<br />
$comment_preview[&#8216;mail&#8217;] = &#8216;&#8217;;<br />
$comment_preview[&#8216;site&#8217;] = &#8216;&#8217;;<br />
$comment_preview[&#8216;preview&#8217;] = false;<br />
$comment_preview[&#8216;remember&#8217;] = false;<br />
$ctx->comment_preview = $comment_preview;<br />
var_dump($ctx);<br />
 

The first initialiation will raise notices and fails (do not assign anything, as the error message says), the second works like a charm. This bug just confirms what I think about all these magic methods, don’t use them for non scalar unless someone put a gun on you.

The issue is known (thanks tony for the info). It is certainly due to the read/write access required by the array element change, but I do not know exactly how userland getter/setter work. I reopen an old bug (#36214), let see what will come out of it.