For a long time, PHP followed an unwritten rule that its websites and documentation shouldn't mention outside PHP projects, so the project wouldn't look like it was picking favorites. This RFC from Larry Garfield argues that the rule did real harm, and it replaces the vague custom with a written policy.
The policy text itself lives in a pull request to the php/policies repository, and the RFC links to it rather than repeating it.
What the policy says
It splits PHP's own work into three areas:
- PHP tooling. The code that runs php.net, the docs builder, the wiki and similar sites.
- Documentation. The manual, tutorials and FAQs on php.net.
- Marketing material. Pages that promote PHP.
Each area gets a checklist, and a library can be used or linked only if it passes every item. For example, it needs a stable 1.0 or later release that's at least a year old, an approved free software license, and a place as a common, standard choice for its job. The docs can't link to a library that's just one of many good options, and the wording can't suggest that PHP recommends it over the others.
Full web frameworks and applications are kept out of tooling and the docs. Marketing pages can mention them, as long as the wording doesn't seem to endorse one.
The policy also names libraries that are approved by vote. The list includes Composer, Xdebug, PHPUnit, PHPStan, Psalm, PHP_CodeSniffer, PHP CS Fixer and anything from PHP-FIG. If people disagree about a library, an RFC can settle it, and that RFC needs a two-thirds vote.
What it means for you
Nothing changes in your code. The change is in what php.net can say and use. The RFC gives Composer as the clearest case, and the author says PHP "should use it, we should document it, we should promote it."
The vote
Accepted 24 to 1, clearing the two-thirds majority it needed. The policy pull request was merged into php/policies on November 23, 2024.