php-src: the C source behind the PHP interpreter

TL;DR: php-src is the interpreter itself, not a framework or a library you install. Everything PHP runs on lives in one C repository: the Zend execution engine, the extension tree, the server APIs and the test suite. It sits at 41,192 stars under a BSD-3-Clause license, which makes it the place to read when you want to know how PHP actually behaves.

What it is

The repository description is short: “The PHP Interpreter”. The owner is the php organization and the homepage is php.net, so this is the canonical upstream source for the language runtime rather than a third-party reimplementation or a fork.

Two numbers frame the scale. The repository has 41,192 stars and 8,316 forks, and it was created on 2011-06-16, yet it has been pushed to as recently as today. That combination, an old repository with daily commits, is what you expect from infrastructure that a large share of the web still depends on.

The implementation language is C, and that choice drives everything else about the project. A runtime that has to start fast, run on many platforms and behave predictably under load is a different kind of codebase from one written in a garbage collected language, and it is why the tree still looks the way it does.

What lives in the tree

The top level of the repository is the quickest way to understand the layout, and it divides into a few clear groups:

Path	What it holds
Zend/	The Zend engine, the part that executes your PHP code
ext/	Bundled extensions, one directory per extension
main/	The interpreter core, including request handling
sapi/	Server APIs, so one interpreter can sit behind different web servers
tests/	The test suite driven by run-tests.php
benchmark/	Performance measurement harnesses
win32/	Windows-specific build support

Around those sit the build system (buildconf, configure.ac, build/) and the contributor-facing documents. The repository carries CONTRIBUTING.md, CODING_STANDARDS.md, SECURITY.md and AGENTS.md at the root, plus UPGRADING and UPGRADING.INTERNALS for anyone tracking behaviour changes between versions.

Two sample configuration files ship at the root, php.ini-development and php.ini-production. They are worth knowing about, because the gap between a sane development setup and a sane production setup is mostly about which of those two files you start from.

How to build it

Building from source is the usual path when you need a version newer than your distribution ships, when you want to patch the interpreter, or when you are testing an extension against a specific build.

git clone https://github.com/php/php-src.git
cd php-src
./buildconf --force
./configure --prefix=/usr/local/php
make -j"$(nproc)"
sudo make install

After the install, two commands tell you what you actually got:

php -v
php -m

php -m lists the compiled-in modules, which is the fastest way to confirm that the extensions you care about made it into the build rather than being skipped.

When reading the source pays off

Reach for the source when you need ground truth about behaviour. A bug that only reproduces on one version, a request that hangs under a specific server API, or an extension that will not compile against a new release all end up in the same place: reading the implementation, or reading tests/ to see how the project pins down expected behaviour.

The test suite is the part outsiders underuse. run-tests.php at the root is the runner, and the repository ships with it as the reference implementation of what correct behaviour looks like for every bundled extension. When you write an extension, those tests double as a specification you can copy.

The contributor documents also shorten the learning curve. CODING_STANDARDS.md holds the style rules that live alongside CONTRIBUTING.md, and both assume you are about to touch code that other people maintain.

When to skip it

If you are building an application, this repository is the wrong place to start. PHP applications depend on the runtime, not on its source, and the language documentation and community extensions cover the day to day work. The same goes for comparing web frameworks, where the runtime is a given rather than a variable.

Reading this tree only pays off when the interpreter itself is your subject. One caveat worth flagging: the codebase is large and old in places, so expect to spend real time orienting yourself before the first useful edit.

Source and Accuracy Notes

• Project page: https://github.com/php/php-src
• Source repository: php/php-src (verified via GitHub API html_url)
• License: BSD-3-Clause (verified via GitHub API license.spdx_id)
• Stars at time of writing: 41192