HookPHP: a C extension shell for hot-pluggable PHP business components

A PHP application shell built around a C extension

HookPHP describes itself as an architecture system built on a C extension, with built-in AI programming support, and the project page it links to is an OSChina article rather than a hosted documentation site. The scope is broad and the wording is compressed: microservice deployment, hot-pluggable business components, an integrated business model and permission model, a UI component library, multiple templates, multiple platforms, multiple domains, multiple terminals, multiple languages, resident memory, front-end and back-end separation, and an API platform.

That is a project description rather than a feature list you can tick off, and it is worth being honest about what the repository itself shows. The top level holds a `Dockerfile`, a `composer.json`, an `app/` directory, `bin/`, `config/`, `doc/`, `log/`, `public/`, `vendor/`, and three files that stand out: `Start`, `apc.php` and `preload.php`.

Those last two are the most informative artefacts in the listing. `preload.php` is the conventional PHP mechanism for loading files before the request cycle starts, and `apc.php` is the configuration file for APC, the user cache that a long-running process would use to keep compiled code and data in memory. Together with a `Start` entry point, they describe a runtime whose goal is to stay resident rather than to be reloaded per request, which is what the resident memory claim amounts to in practice.

The audience is PHP developers working on larger systems. The topic tags name a long list of PHP frameworks and applications, from CakePHP, CodeIgniter, Drupal, Joomla, Kohana, Magento, OpenCart, Phalcon, PrestaShop, Symfony, ThinkPHP, Yii and Zend Cart to Swoole, Workerman and Yaf, which places the project in the same conversation as those tools.

The licence is Apache License 2.0, the package is published on Packagist as `letwang/hookphp`, and the PHP requirement is 8.1 or newer.

Hot-pluggable components as the central design idea

Of the claimed capabilities, the one with a visible counterpart in the repository is hot-plugging. The development section points at three separate directories with distinct roles: the development platform in `app/`, the development modules in `app/admin/modules/`, and the development plugins in `app/admin/hooks/`.

The naming makes the model clear enough to reason about. Modules and plugins are separate concepts, and the plugins live under a directory called `hooks`, which matches the project name. A plugin in this scheme is a business component that can be attached to the running system and detached from it, and the `hooks` directory is where that attachment is described. The `vendor/` directory is described in the README as the core general-purpose class library, and it is called portable, which suggests the intent is that the core stays independent of the business code that gets plugged in.

That is the design that the rest of the feature list hangs on. A UI component library, multiple templates and multiple terminals are useful in a system where the presentation layer is also pluggable. An API platform and front-end and back-end separation fit a system whose business logic can be addressed as services. Multiple domains and multiple platforms fit the same way, since a hot-pluggable component can be exposed differently depending on where it is being served.

The permission model and the business model being integrated are similarly structural rather than cosmetic. In a system assembled from components, a shared authorisation layer and a shared domain model are what stop each plugin from inventing its own.

What the repository does not show is the interface itself. There is no example plugin, no sample hook file and no test suite in the listing, so the contract a plugin must satisfy has to be read from the wiki rather than inferred from the code.

The Docker image assembles the whole backing stack

Rather than a plain application image, the Dockerfile in the repository builds an environment with the services a PHP backend usually needs. The base is Ubuntu focal, with the apt sources pointed at the Aliyun mirror.

The image installs the build and runtime tooling first, and the list is long:

apt-get update -y &&
apt-get upgrade -y &&
apt-get install -y sudo vim git pip zsh curl wget zip htop cmake gnupg lsb-release ca-certificates apt-transport-https software-properties-common libzstd-dev libcurl4-openssl-dev libgraphviz-dev

Then it adds the language and service repositories. PHP comes from the `ppa:ondrej/php` repository, Redis from `ppa:redislabs/redis`, and RabbitMQ from `ppa:rabbitmq/rabbitmq-erlang` with the packagecloud install script piped into `bash`. OpenResty is added from its own apt source and its public key, MySQL from the official `mysql-apt-config` package, and MongoDB 5.0 from the MongoDB apt repository for both `amd64` and `arm64`.

The shape of this tells you the intended deployment. OpenResty in front of PHP is the usual shape for a resident-memory PHP service, because the web server and the application processes are managed separately and the PHP workers stay warm. MySQL for relational data, MongoDB for document data, Redis for cache and RabbitMQ for queues is a conventional multi-service backend, and the microservice claim in the description is what the separate worker processes would be built on.

The image is published on Docker Hub as `letwang/hookphp`, and the README links that environment page as well as the wiki. Note what the image does not decide for you: it assembles the services, but the Dockerfile is a starting point with credentials and hostnames to fill in, not a deployment configuration.

Installation is documented in the wiki, not in the repository

The installation section of the README is a single link to the project's wiki on GitHub. There is no composer install command, no service startup command and no configuration file in the listing to copy.

That is unusual for a project that publishes a Packagist package, and it has consequences for evaluation. Everything a new user needs, from how the C extension is compiled and loaded to how the modules and plugins are registered and how the worker processes are started, lives in the wiki rather than in version control. The wiki can change independently of the code, which means the instructions and the repository can drift apart, and a reader who finds the wiki will not know which revision of it applied to which commit.

The repository does contain a `doc/` directory with images, since the README links to `doc/images/1.png` for a demonstration and `doc/images/architecture.png` for the architecture diagram. The architecture picture is the one to look at first, because the prose description is a single compressed sentence and a diagram carries more of the design in less space than a translation of that sentence can.

For a PHP developer, the practical entry point is therefore Packagist for the package identity and version constraint, the wiki for the actual procedure, and the Docker image for a runnable environment. Anyone evaluating this project should budget time for that reading, because the code alone does not tell you how the pieces are meant to fit together.

The project also asks for contributions through issues, pull requests, documentation and examples, and it lists a LUA oriented community group in its description. That combination of a wiki-first documentation model and a community group is typical of a project maintained by a small number of people for a Chinese-speaking PHP community.

A version 0.0.1 project with pushes in 2026

The maintenance signals here need to be read together rather than separately, because they point in different directions.

The repository is not archived, and the last push was on 2026-04-29. So work has happened on the code recently, and the repository is not a dead archive. The single tagged release, however, is v0.0.1 from 2022-03-17, and there is only one. A version number of 0.0.1 that has not moved in four years, in a project whose push history continues, is the clearest statement the repository makes about its release discipline.

For anyone planning to depend on this, the consequence is specific. There is no upgrade path through tags, so pinning a version tells you very little, and a fork or an internal copy of the relevant part is a more realistic strategy than a dependency declaration. The Packagist entry exists, but the semantics of a 0.0.1 package that continues to receive pushes are ambiguous.

The Apache-2.0 licence is worth noting separately from the version question. It is permissive, with an explicit patent grant, and it imposes no requirement to publish modifications. For a project that is effectively a platform, that matters if you intend to extend the module and plugin model for your own business components and keep those extensions private.

The comparison to a conventional PHP framework is instructive. Laravel, Symfony and the other names in the topic tags come with an ORM, migrations, a routing layer, a templating layer and a documented release process. HookPHP positions itself differently, as a component shell with a hot-plug mechanism, a resident runtime and a preassembled service stack. That is a legitimate choice for a team with an existing business model and permission model to encode, and a poor fit for a team that wants those layers provided.

Editorial conclusion

HookPHP suits a PHP team that wants a component shell with hot-pluggable business modules, a resident-memory runtime and a preassembled Docker stack covering OpenResty, MySQL, MongoDB and RabbitMQ, and that is willing to work from the project wiki and its OSChina article. It does not suit a team expecting a conventional framework with an ORM, migrations and a stable release cadence, because the only tagged release is v0.0.1 from 2022-03-17. Before adopting, read the wiki linked from the repository, check the Docker image on Docker Hub, and confirm that the C extension and PHP 8.1 or newer are available in your target environment.

Frequently asked questions

Official sources

1. letwang/HookPHP on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases