Zlib does not work on fresh ubuntu installations...

[wvdploeg]

And maybe the same issue on other Linux installations. The function 'gzopen' has been renamed to 'gzopen64', zo I suggest that in the future the class-pcllib.php should be extended with the following code just before the class declaration :

if (!extension_loaded('zlib'))
    {
      die('Abort '.basename(__FILE__).' : Missing zlib extensions');
    }
    if (!function_exists('gzopen') && function_exists('gzopen64'))
    {
      function gzopen( $filename ,  $mode,  $use_include_path = 0) {
        return gzopen64($filename, $mode, $use_include_path);
      }
    }

Thanks in advance for the update.

Wilko van der Ploeg
WordXPression

[dd32]

As weird as this report sounds, it's actually an actual PHP bug.

​https://bugs.php.net/bug.php?id=53829

When some linux distributions compiled 32bit PHP with large file support, it'd cause the zlib functions to be incorrectly suffixed with 64, a bug which took PHP almost 3 years to fix.

Normally I'd say, wontfix, but given the amount of time that PHP had the issue, maybe we should consider a compat function wrapper.. The affected functions were: gzopen, gzseek, gztell. However, since it's the first report of issue, I'm not entirely sure if we should.

[wvdploeg]

Replying to dd32:

Normally I'd say, wontfix, but given the amount of time that PHP had the issue, maybe we should consider a compat function wrapper.. The affected functions were: gzopen, gzseek, gztell. However, since it's the first report of issue, I'm not entirely sure if we should.

Well, it is the first report of the issue which made it to your bug reports... when you google the Internet you'll find that there is more discussion about this bug, only nobody took the time to report it here. I would seriously suggest to fix it... it's a few lines of code solving a serious problem.

[dd32]

#37029 was marked as a duplicate.

[dd32]

If anyone has some time, Can you please figure out what versions of PHP this affects?

The bug was fixed in 5.5.20, and existed at least as far back as 5.5.11.

Given we've only had 2 reports in 2 years, this isn't a high priority ticket, although it will cause fatals in the event that an affected PHP version is in use and the ZIP extension isn't available. I'm tempted to leave it as-is and suggest that anyone who encounters this should run a more bugfixed version of PHP.. but..

[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 (​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 (​2). So that would seem to be the necessary precondition.

A patch was contributed by Sasha Kettler 08-Feb-2013 (​3), and this was pulled into php-src by Mattaeo Beccati on 12-Nov-2014 as part of PHP 5.5.20 (​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 (​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 (​7).

In WordPress, zlib functions are only encountered along the wp-includes path ("class-wp-http-encoding.php", "SimplePie/File.php", "ID3(1,2)", and "depreciated.php"), and in wp-admin ("load-scripts.php","load-styles.php","includes/ajax-actions.php", and "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 (​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 219, gzopen only turns up for real at lines 2816 and 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
$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;
}
?>

[dd32]

@thefarlilacfield Sorry for the much delayed response, Thanks a bunch for the full background on the issue at play here.

Due to the amount of time that we've survived without working around this issue, that PHP 5.5 is now EOL and 5.6 is in security-fixes-only I'm confident that the majority of servers which would've been affected by this would have moved to a more recent version of PHP (be that 5.5.20+ or otherwise).

I'm marking this as wontfix. In the highly unlikely case we get a lot of reports about this some day, we'll work out how to handle it then.