[wp-trac] [WordPress Trac] #30213: Zlib does not work on fresh ubuntu installations...

[WordPress Trac]

#30213: Zlib does not work on fresh ubuntu installations...
--------------------------------------+------------------------------
 Reporter:  wvdploeg                  |       Owner:
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  General                   |     Version:  4.0
 Severity:  normal                    |  Resolution:
 Keywords:  2nd-opinion dev-feedback  |     Focuses:
--------------------------------------+------------------------------

Comment (by thefarlilacfield):

 =  php/zlib 64-bit bug, a people's history =

 At bugs.php.net, the first record is from 23-Jan-2011 with version 5.3.5
 ([https://bugs.php.net/bug.php?id=53829 1]).  "rilatonal at hotmail dot
 de" reported having compiled PHP with zlib 1.2.5 for the first time.
 Version 1.2.5 of zlib was released 19-Apr-2010
 ([http://www.zlib.net/ChangeLog.txt 2]).  So that would seem to be the
 necessary precondition.

 A patch was contributed by Sasha Kettler 08-Feb-2013
 ([https://bugs.php.net/patch-display.php?bug_id=53829&patch=zlib-
 largefile-function-renaming&revision=1360326291 3]), and this was pulled
 into php-src by Mattaeo Beccati on 12-Nov-2014 as part of PHP 5.5.20
 ([http://git.php.net/?p=php-
 src.git;a=commitdiff;h=65fee904622160781db05b0a469d67b4414cbd7f 5]).  The
 patch notes that 'this only seems to happen on 32bit systems with large
 file support'.

 The issue seems to have been encountered intermittently but steadily
 downstream from PHP, primarily in Ubuntu.  Ubuntu as of 01-Jul-2016 has
 accepted PHP 5.5 into "trusty-proposed", and this is anticipated to close
 the bug ([https://bugs.launchpad.net/php/+bug/1315888/comments/34 6]) .
 Prior to that, the bug was first reported 14-May-2014 by Ville Mattila,
 with various follow-up commentary from people who have traced it as a
 cause in Joomla, phpMyAdmin, DokuWiki, SPIP, GLPI, and the WPStatistics
 Plugin via GeoIP ([https://bugs.launchpad.net/php/+bug/1315888 7]).

 In WordPress, zlib functions are only encountered along the wp-includes
 path ("[https://core.trac.wordpress.org/browser/trunk/src/wp-includes
 /class-wp-http-encoding.php class-wp-http-encoding.php]",
 "[https://core.trac.wordpress.org/browser/trunk/src/wp-
 includes/SimplePie/File.php SimplePie/File.php]",
 "ID3([https://core.trac.wordpress.org/browser/trunk/src/wp-
 includes/ID3/module.audio-video.quicktime.php
 1],[https://core.trac.wordpress.org/browser/trunk/src/wp-
 includes/ID3/module.tag.id3v2.php 2])", and
 "[https://core.trac.wordpress.org/browser/trunk/src/wp-
 includes/deprecated.php depreciated.php]"), and in wp-admin
 ("[https://core.trac.wordpress.org/browser/trunk/src/wp-admin/load-
 scripts.php load-
 scripts.php]","[https://core.trac.wordpress.org/browser/trunk/src/wp-admin
 /load-styles.php load-
 styles.php]","[https://core.trac.wordpress.org/browser/trunk/src/wp-
 admin/includes/ajax-actions.php includes/ajax-actions.php]", and
 "[https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes
 /class-pclzip.php includes/class-pclzip.php]"). As @wvdploeg said, the
 affected zlib functions appear to be gzopen, gzseek, and gztell.  Within
 WordPress proper, the only one of these that is present is gzopen,
 appearing only within class-pclzib.php.

 class-pclzib.php contains PhpConcept Library Zip Module 2.8.2 [current
 afaik] by Vincent Blavet, released Aug-2009
 ([http://www.phpconcept.net/pclzip/ 8]).  So technically this matter
 requires a revision of PclZib.

 However, within class PclZip, despite the use of gzopen within the
 constructor as a test for the presence of zlib on line
 [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes
 /class-pclzip.php#L219 219], gzopen only turns up for real at lines
 [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes
 /class-pclzip.php#L2816 2816] and
 [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes
 /class-pclzip.php#L4008 4008], adding a file to an archive, or extracting
 a file from an archive, respectively, in both instances via an
 intermediary temporary file.  In both cases, it is both error supressed
 and contained within an immediate test for an error return value, which is
 subsequently reported and/or logged.

 Although it would make the root cause of an error harder to detect in
 those two instances, it would permit the use of PclZip in all other
 instances were the gzopen test in the constructor to be replaced by a test
 of any one of the unaffected Zlib functions.  Testing zlib existence is
 clearly indicated as the sole intent of the test at that point.

 Wontfix sounds reasonable to me, but the palliative (not curative) fix is
 extremely easy to implement, and running into the problem and reading
 about it takes each individual WordPress developer who does so a not-
 insignificant amount of time.

 === Path to gzopen in the PclZip class ===
 {{{
 create --> privCreate -> privAddList -> privAddFile ->
 privAddFileUsingTempFile -> gzopen()
 add --> privAdd -/

 extract -> privExtractByRule =-> privExtractFile ->
 privExtractFileUsingTempFile -> gzopen()
 extractByIndex -/
 }}}

 === Test for Zlib function existence ===
 {{{#!php
 <?php
 $zlib = array('gzclose', 'gzcompress', 'gzdecode', 'gzdeflate',
 'gzencode', 'gzeof', 'gzfile', 'gzgetc', 'gzgets', 'gzgetss', 'gzinflate',
 'gzopen', 'gzpassthru', 'gzputs', 'gzread', 'gzrewind', 'gzseek',
 'gztell', 'gzuncompress', 'gzwrite', 'readgzfile', 'zlib_decode',
 'zlib_encode', 'zlib_get_coding_type');

 foreach( $zlib as $fn ){
     if( function_exists($fn) ) continue;
     echo $fn . '() gone';
     if( function_exists($fn . '64') ) echo ', replaced by ' . $fn .
 '64()';
     echo '.' . PHP_EOL;
 }
 ?>
 }}}

--
Ticket URL: <https://core.trac.wordpress.org/ticket/30213#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform