extends('layout.php', ['title' => 'How to search the bug database']) ?> start('content') ?>
This HOWTO will allow for a useful experience while scouring the bug database. Do note that a lot of information is entered in by the general public and therefore cannot be fully trusted. Also, the information contained within a bug report is what setup found the bug, so other setups may apply.
Within every = $siteUrl ?> webpage header is a search box, this is the basic search option. You may enter in a numeric bug ID to redirect to that bugs page or enter in a search term to perform a default bug search. Load the advanced search to view the default values.
Some explanations for most of the PHP bugs advanced search options.
Feature | Explanation | Possible reasons for use |
Find bugs |
The main search text box for your search terms with each term being
separated by a space. The searched database fields are: author email,
subject, and description. Minimum term length is three characters.
There are three types of searches:
|
For any, you might search for a function and its alias while not caring which shows up. Or a name that has changed in PHP 5 from PHP 4. Use of all makes sense if you require every term in your results, as this can provide precise searching. The raw option is for custom searches, like you might require one term but also want to disallow another from the result. Also, adding optional terms always affects relevancy/order. |
Status |
Each bug has a status, this allows searching for a specific (or all) status type.
Here are a few explanations:
|
If you're only interested in critical bugs, or want to see which have been verified, or perhaps just those seeking feedback. |
Category | Bugs are categorized although sometimes it might seem like a bug could be in multiple categories. You may choose a specific category or allow any, and also disallow certain categories. If you're unable to locate a bug, consider trying a feature request or any status. | |
OS | Bugs that may be specific to an operating system. This value is entered in by the reporter as the OS they used while finding the bug so this may or may not have meaning. Also, the value isn't regulated so for example Windows may be written as Win32, Win, Windows, Win98, NT, etc. Or perhaps a distribution name rather than simply Linux. The query uses a SQL LIKE statement like so: '%$os%'. | Although not an accurate field, it may be of some use. |
Version | Limit bugs to a specific version of PHP. A one character integer of 3, 4 or 5 is standard. Entering a length greater than one will perform a SQL LIKE statement like so: '$version%'. Defaults to both 4 and 5. | Limit returned bugs to a specific version of PHP. This is fairly reliable as initial version entries are standardized, but on occasion people are known to enter in bogus version information. |
Assigned | Some bugs get assigned to PHP developers, in which case you may specify by entering in the PHP username of said developer. | Example use is limiting the bugs assigned to yourself. |
Author email | Takes on an email address of the original author of a bug. | Looking for all bugs that a particular person initiated. |
Date | Limit bugs that were reported by a specific time period. This is not only the amount of time since a comment or developer remark was last made, but this is the time when the bug was originally reported. | Looking for recently reported bugs. For example, choosing 30 days ago will limit the search to all bugs reported in the last 30 days. |
You can view a variety of statistics about the bugs that have been reported on our bug statistics page.
end('content') ?>