Continuous integration/Phan


 * For the security plugin used as part of Wikimedia's Phan configuration, see Phan-taint-check-plugin.

We perform static analysis, including security vulnerability analysis of MediaWiki's PHP code base using Phan. MediaWiki core configuration for Phan is in the  directory. All MediaWiki core and Wikimedia-deployed extension and skin patches are analyzed by Phan as part of the CI infrastructure. Non-Wikimedia production code is encouraged to use Phan as well.

Installing Phan
Phan requires PHP >= 7.2 to run. This is because Phan analyzes the AST that was added to PHP in version 7. The php-ast extension is also strongly recommended. You can use Phan without it (as long as you pass the  option), but it could be slower.

Getting Phan
We pull Phan via composer. If your repo already requires, all you have to do is run   to install Phan. Otherwise, you should run  first.

Running Phan
Simply use


 * tells it to analyze the current directory
 * tells it to output a progress bar. Alternatively, you may use  to get a progress bar more suitable for e.g. CI logs.

Web demo
A Web demo is available. Note, however, that it's usually useful only if you want to analyze a small piece of code.

Upstream Documentation

 * Annotating Your Source Code
 * About Union Types
 * Issue Types Caught by Phan
 * Typing Parameters

Interpreting Results
Results are in the following structure, one per line.

Suppressing Issues
Sometimes phan gets it wrong. Or the code is just so hopeless that a large refactor is needed to make the analysis line up. In these cases errors from individual lines can be suppressed with the following format:

Multiple issues can be suppressed from the same line by comma separating them:

See the upstream documentation.

Or you can suppress particular error types from an entire repo by modifying the  array in your phan config.php file:

Known Problems

 * Phan cannot read  annotations in the middle of functions. This is a limitation of the PHP AST, and it likely won't change in the near future. Current workarounds include:
 * You can specify @var annotations in the method doc block.
 * You can also use the ugly-but-it-works string literal version:  see line 302 in this commit for an example.