1 - General

1.1 - How does PHK differ from PHAR ?

The base idea is similar. Here is a list of the main differences :

I don't guarantee the accuracy of my information on PHAR, as it is evolving rapidly, and there is not much documentation available. Updated 14-JAN-2008.

PHAR	PHK
Requires PHP 5.2 or newer.	Requires PHP 5.1 or newer.
A PHAR archive needs the phar extension to be installed in the runtime environment (not clear, seems to be different whether the archive was created by PHP_Archive or by the phar extension).	The runtime code is included in the archive. Nothing to install in the runtime environment. The PHK and Automap extensions optionally allow to accelrate the runtime code but, except for the performance increase, the features remain the same. So, you can distribute your software as a PHK package without requiring your users to install a PECL extension.
AFAIK, no integration with PHP opcode and user caches. PHAR authors are probably working on the subject but, as they  publish almost nothing on their work, I don't know more.	PHK transparently integrates with the PHP caches it finds in the runtime environment. Supported caches : APC, xcache, eaccelerator. The opcode cache integration is still in an experimental state, as it requires modifications both in the PHP core, and in the cache software. So, it is waiting for approval. Please note that opcode caching requires the PECL PHK extension.
AFAIK once again, no persistence of data between requests.	The PHK and Automap extensions use persistent memory to cache the data they use to load packages and automaps. This, combined with PHP cache integration, allows in most cases to load packages and retrieve their files without any physical access to the package files.
Allows to extract the subfiles from an archive to run them as physical source files. So, can also be used as a deployment tool.	In the PHK philosophy, a package is always run as-is. The subfiles can be extracted from the package but it is just a utility feature.
The runtime code includes the write code. The security is provided by a global php.ini setting (ON/protected by default). This setting enables/disables writing for the whole PHP environment.	The runtime and creator code are separate, and the runtime code is 100% read-only. As a consequence, even on a bug in the PHK layer or a misconfiguration in the INI file, it physically cannot write to the file system. More similar to the traditional development architectures, where the runtime environment never contains the build chain.
Provides a virtual file tree, acceded through a stream wrapper. Few, if any, additional features. An MVC controller would be available in the latest version (waiting for the doc...).	Provides a lot of high-level features like the webinfo mode, built-in CLI commands, the autoloader, pseudo-files, meta-packages, integrated unit tests, a plugin system...
No autoload feature	The embedded autoloader (Automap) transparently extracts symbols from the PHP scripts at package creation time. At runtime, the classes and interfaces are automatically loaded when needed. Unlike most PHP autoloaders, Automap really extract the symbols from the code, and is not filename-based. So, it does not impose a specific file hierarchy and also allows to define several classes per source file.
Provides iteration and array access on Phar objects.	I don't see any real use for this feature. If the users want it, it can be added easily. The list of files contained in a package is provided by the PHK::path_list() method.
The 'stub' prolog is provided by the packager. Once again, it seems to depend whether the archive is generated by phar or PHP_Archive.	PHK provides its own bootstrap code, allowing the user to take control at a higher level.
No standard place for 'administrative' information.	Provides standard ways to include a lot of administrative information in the package. Can also embed a logo, some reference URLs, or the package's documentation and/or license !
No built-in 'introspection' mode.	As previously said, the webinfo mode is a standard way to examine a package, its subfiles, administrative information, license, help... From the packager's point of view, the webinfo mode can be configured to display any information that can be displayed in a web browser. Also provides the same information in CLI mode through a set of built-in commands.
No support for PHP extension dependencies.	The packager can give a list of required extensions. When loading the package, PHK will ensure that all these extensions are present. Can also check for a PHP interpreter min and max version.
From what I know, PHAR does not provide such a feature (a sort of 'controller', in MVC terminology). It is possible to use PHAR as a base to develop it but you'll have to write it yourself. Correction: the latest version would provide one, but there is no doc yet...	Provides a 'direct web access' mode, allowing transparent access to a subfile virtual tree, directly from the users' browsers. Also provides an access protection mechanism, allowing the packager to specify which paths can be requested from the web.
The PHAR documentation does not contain anything on meta-packages (packages embedded in another package). So, I assume that they are not supported.	Supports meta-packages, with full autoloading support (the subpackage is automatically mounted when one of its classes is accessed). This feature is used as the basis to embed its unit tests in a package (see the demo packages).
In its documentation, PHAR authors talk about signatures, but they mean md5/sha1 signatures (checksums). A checksum like this protects against unintended package corruption but is not what I call a signature, because it does not authenticate the data you got. Real signatures are based on digital certificates.	A package can be digitally signed (using a digital certificate), allowing users to check the package's source and integrity.
Documentation: one page in the PHP documentation, a pair of blog entries. Coherent with the usual PEAR 'write-it-yourself' documentations .	PHK has a dedicated web site, with user's, builder's, and developer's documentation, a forum, a bug tracker...

So, in my opinion, the main differences are :

• PHAR authors don't publish much documentation. I really consider it as most important because PEAR and PECL are well known for their poor documentation, and PHAR authors still give the same impression.
• When it comes to performance, PHK, with its associated extensions, can now be compared to phar. I don't have any benchmark ready yet.
• PHK provides a number of high-level features, whose goal is to make building packages faster and easier, even for non-expert people. PHAR authors tend to consider that it is restricting the user's freedom, and they prefer providing only basic features, and let their users program the rest by themselves. I suspect them to be too fluent in PHP. Not that I underestimate people's skills; but I think their learning curve is too steep, especially when combined with a lack of documentation. Correction: if the latest PHAR release really contains a default MVC controller, there is still some hope .

You can find more information about PHAR vs PHK in the External Resources section.

More about PHAR at http://www.php.net/phar

1.2 - Why isn't it in PEAR ?

It could, one day. The potential problems to solve are :

• PHK_Creator does not use the PEAR installer.
• The PHK code does not use any of the PEAR base classes.
• The source code is not totally compliant with the PEAR standards, especially regarding the (missing) phpdoc comments.

1.3 - May I freely distribute the PHK packages I create ?

Yes, the PHK Creator software is distributed under the Apache license, Version 2.0. It does not impose any license constraint on the generated packages.

1.4 - How can I help ?

First and most important, if you are using PHK, please drop us a mail or post a user story to say what you're using it for, what you (don't) like in the product, which feature you'd like to see added... Most important because it is boring and even sometimes depressing to work on a project when you don't know if people are really interested. So, with a quick 3-line message, you can help a lot.

Then, you may have a look at the roadmap document.

You can also write articles, tutorials, or just talk to your friends about it. We'll be glad to help for any PHK-related project you may have.

If you really like PHK, I have an Amazon wishlist... I would be quite surprised if somebody bought something there but, who knows ?

2 - Troubleshooting

2.1 - Constant __COMPILER_HALT_OFFSET__ already defined

When including more than one PHK package in turn, you may see a message saying :

This is caused by PHP bug #39903 and is due to the fact that each PHK package contains an __halt_compiler() directive. When it sees this directive, the Zend engine sets the __COMPILER_HALT_OFFSET__ constant to the offset of the directive in the file. Unfortunately, it was not taken into account that the __halt_compiler() directive can be met by the engine more than once during an execution. So, from the second time on, as the constant is already defined, you get the notice message.

This issue is fixed in PHP 5.2.2.

2.2 - Fatal error: __HALT_COMPILER() can only be used once per request

When using PHP 5.2.1, including more than one PHK package in turn aborts with an error saying :

This is a consequence of bug #39903 detailed above. Unfortunately, in order to fix the 'notice message' issue detailed above, somebody wrongly transformed it to a fatal error !

This issue was fixed in PHP 5.2.2.

2.3 - I get a lot of '?' when executing/including a package

This problem is caused by bug #42396. When unicode detection is active (PHP configured with --enable-zend-multibyte option), PHK packages are detected as unicode scripts (because they contain null bytes).

I have submitted a patch. Until it is accepted, and for PHP versions up to and including 5.2.3, the workaround is to add this line to your php.ini file :

2.4 - 'No input file specified'

If you use web direct access through a CGI SAPI, you may experience some error messages saying : 'No input file specified'. This is a well-known problem, and you can find a lot of information on the web about it.

The usual solution is to use mod_rewrite directives in a .htaccess file in the directory where your PHK archives lie. This rewriting uses the fact that, in web direct access mode, PHK provides two ways to specify the subfile's internal path:

• either as a subpath in the original URL, like: http://server/path/to/phk/virtual/path/to/subfile. Your users will always see this kind of URLs in their browsers.
• or in the global variable $_REQUEST|'_PHK_path']. This way, the same URL is rewritten as : http://server/path/to/phk?_PHK_path=/virtual/path/to/subfile. This URL works in CGI mode.

Here, we are using mod_rewrite to translate the first format to the second one.

As mod_rewrite can be quite complex to configure, we will only give, as an example, what we use for the demos on this web site. You will probably need to adapt it. More info on mod_rewrite here :

Last update : Saturday, 24 March 2012

Average user rating

   (0 vote)