Welcome to the HOWTO on managing PHP bugs via bugs.php.net. PHP is a large project with many
bugs being submitted daily. Bug topics range from the PHP website itself,
various PHP extensions, PEAR, etc. This document is for all PHP developers
using the bug system. Because there are so many members using the system it's
important we act in a consistent manner. This HOWTO is created to solve this.
If you're going to edit a bug be sure that you know the topic. Don't make
assumptions. If you've read the bug carefully and think of a solution or
related questions, post your answer/comments. If you know of the solution,
solve and close the bug.
Acting on a bug
Never change a status if you're not sure. If you close a bug because you
think it's not really a bug and in fact it is, this makes the bug system
useless and doesn't benefit anyone. Never close a bug because it's too old,
unless your name is Jani. If a bug is in "feedback" status it will close
automatically if the bug reporter doesn't answer after two weeks.
If you want to view a bug report, enter the bug id into the url like
so (with 20406 being an example):
Which redirects to:
At that point you'll see a set of options. Because you're a developer you
will choose the developer option which will then put you here:
Automatic answers (quickfix)
There are a set of quickfix options each of which will both insert text into
the bug report and change the bug status. Please understand what text and
status will be used and only choose a quickfix option if an appropriate
quickfix exists. Choosing a quickfix that's not 100% correct will confuse
and sometimes irritate the reporter. The following table lists them (see
If no quickfix is available you will manually choose the new status and
write some feedback. Select the best status that corresponds to the bug.
Here are descriptions for each status:
The bug still exists and you want to comment on it.
It has been fixed. If you choose this please make sure
it's also been documented. Also, explain why it's closed.
This status is deprecated and can no longer be selected during
modifications of bugs. Always use "Not a Bug" instead now. The originial
If this almost the same bug, both bugs are found 'duplicate' later
on and have both useful information. Also mention what bug it's a
duplicate of with a full url to the report this is duplicate of.
Only bugs that affect most/all users and/or are in the engine or
ext/standard. Only Verified and reproduced bugs in the latest
Git revision can be marked critical.
If a specific person, such as yourself, will take of this bug then
assign it. If you know someone else is or will take care of it then assign
it to them but be sure to ask them first.
If you've analyzed why this bug is here and know why the bug exists, you
have just analyzed it. Also, add a comment. If you are unsure why it
exists then use 'verified' instead.
If you're able to reproduce this bug with the information given.
Be sure to test with the latest CVS. Typically you aren't sure why
it exists you just know it does and have confirmed it.
Usually used when there might be a fix in future and/or it relies on
something external to be fixed first.
- Wont fix
- When something is not considered a bug or the bug is not fixable.
- No feedback
If no answer have been given by the reporter after we've asked them
something. Sometimes you will ask for an example script or ask the
reporter to test using CVS or the latest snap.
You're asking the reporter for more information such as please use
Git revision/snap, and/or the smallest possible test script to reproduce the
error, and/or a value for a certain PHP directive.
- Not a Bug (old: Bogus)
This bug is not a bug, support related or just an assumed bug or the
bug already exists in the database. Be 100% it's really "bogus" and
also be sure it's not a documentation bug.
Sometimes you'll also want to reclassify a bug. For example, a reporter
marks a bug as Apache2 related when really it's a MySQL bug. Just change
the category but be 100% sure it's related to the new category. Another
example would be changing the type to a documentation bug. If you're
changing it to a documentation bug it will help the documentation team if you
add specific information that is to be documented including what version the
changes will take place.
Also note that all bugs are sent to various mailing lists with
email@example.com being the default (most go here). Here's a list:
- PHP.net Website
Reclassifying will immediatly change which mailing list is used. If you
reclassify a bug and don't leave a comment then no email is sent to the mailing list.
So, be sure to leave a comment.
Tips and links
Look at the raw bug stats.
Not leaving a comment means no email will be sent to the mailing list.
(all quickfix options leave comments)
If a version involves Git or a snapshot be sure to label it in the form:
5.x.y-dev An example is: 5.6.0-dev.
If you have a question either email the
mailing list or check out the #php.pecl channel in IRC on
If everyone maintains the bug system in a consistent manner then PHP will
be better for it. Also, bug reporters will not get their feelings hurt
through miscommunication (e.g. a wrong quickfix or bogus status) Thank you
for reading this HOWTO and helping make PHP better.