fix *extremely* ancient problem where phar_wrapper_stat always returned success indicating the file existed
rename phar_destroy_manifest to phar_destroy_manifest_entry
major improvement of zip/tar-based phar stub execution, now __FILE__ says it is the phar, and not phar/.phar/stub.php,
so that the same stub can be used for phar or tar/zip-based phars
ridiculous speedup of rename() within a phar (something like 1000%)
last of the tar-based phar fixes
new tests for tar-based phars, fix existing tests to use new format of __FILE__
improve phar recognition of tar/zip-based phars in phar_compile_file
fix segfault in Phar::webPhar() with invalid redirect
add Phar->isTar()/isZip()/isPhar() to determine internal file format
fix creation of tar-based phars from filename in some circumstances
fix read of corrupted file contents from a tar if the tar had been opened readonly and then modified
ensure directories are marked with is_dir in tar file format entries
copy fp_refcount logic into phar_tar_flush() from phar_flush()
fix segfault when flushing a tar with a new stub/alias
Phar::mungServer(). This static method takes an array with one of these 4 indices (case-sensitive):
'PHP_SELF', 'SCRIPT_NAME', 'SCRIPT_FILENAME', 'REQUEST_URI'
and removes any reference to the actual path on the server. This allows older apps to function unmodified inside a phar.
the variables are re-registered as PHAR_PHP_SELF and company to allow access from clever script files
[DOC]
Phar->webPhar():
<?php
Phar::webPhar();
__HALT_COMPILER();
With the above stub, the default front controller will kick in. An array of mime type overrides, and another
array mapping phar file entry -> redirected entry can be used to further customize
[DOC]
Currently, an entire phar entry is leaked for no obvious reason, otherwise it works. Sample code:
The phar has to be created using Phar->useFrontController(); and the stub performs actual resolution of which file to load:
<?php
Phar::mapPhar();
include 'phar://' . __FILE__ . '/' . substr($_SERVER['REQUEST_URI'], strlen(basename(__FILE__)));
__HALT_COMPILER();
?>
Phar automatically determines mime type from the file extension and either parses or displays the file. Modification of REQUEST_URI
and other variables should happen in the stub
[DOC]
don't use php_parse_url() at all, and always unixify paths on copied strings.
our modification was modifying the zval original string, so a user would pass in
phar://c:\path\to\blah.phar
and their string would change to phar://c:/path/to/blah.phar - bad.
Now using
include 'phar://' . __FILE__ . '/index.php';
works on both unix and windows seamlessly, as well as $a = new Phar(__FILE__)
for use in the loader stub
1) full path, with \ or / path separator
2) relative path to getcwd()
This should fix the last remaining windows-related quirks as well as similar problems
on unix
when passing in a full path with drive letter to the Phar object, we were
then passing "phar://C:/path/to/blah.phar" to php_parse_url(), which
thinks it is getting a valid url scheme "phar", host "C" path "/path/to/blah.phar"
we now pass "phar:///C:/path/to/blah.phar" to make it fail, and then properly
parse the url inside phar
