com web/bugs: Move simple pages to templates: include/auth.php templates/pages/bugs_getting_valgrind_log.php templat es/pages/how_to_report.php
templates/pages/search_how _to.php www/bugs-getting-valgrind-log.php www/how-to- report.php www/index.php www/search-howto.php
| From: | Peter Kokot | Date: | Wed, 22 May 2019 00:24:29 +0000 |
| Subject: | com web/bugs: Move simple pages to templates: include/auth.php templates/pages/bugs_getting_valgrind_log.php templat es/pages/how_to_report.php templates/pages/search_how _to.php www/bugs-getting-valgrind-log.php www/how-to- report.php www/index.php www/search-howto.php |
||
| Groups: | php.webmaster | ||
| Request: | Send a blank email to php-webmaster+get-28058@lists.php.net to get a copy of this message | ||
Commit: 80d03e3e78f80fd90e4c231accaaa67bb9da37b6
Author: Peter Kokot <peterkokot@gmail.com> Fri, 4 Jan 2019 01:03:29 +0100
Parents: 353abb3d0bbec66f5f4d76f29dd6717d7babb5a9
Branches: master
Link: http://git.php.net/?p=web/bugs.git;a=commitdiff;h=80d03e3e78f80fd90e4c231accaaa67bb9da37b6
Log:
Move simple pages to templates
This is initial patch of the series of patches that moves the most
simple pages to templates.
Changed paths:
A include/auth.php
A templates/pages/bugs_getting_valgrind_log.php
A templates/pages/how_to_report.php
A templates/pages/search_how_to.php
M www/bugs-getting-valgrind-log.php
M www/how-to-report.php
M www/index.php
M www/search-howto.php
diff --git a/include/auth.php b/include/auth.php new file mode 100644 index 0000000..e9d1052 --- /dev/null +++ b/include/auth.php @@ -0,0 +1,31 @@ +<?php + +/** + * Temporary helper placeholder file to overcome the authentication service + * migration. + * + * TODO: Refactor this into a better authentication service. + */ + +// Start session +session_start(); + +// Authenticate +bugs_authenticate($user, $pw, $logged_in, $user_flags); + +if ('developer' === $logged_in) { + $isLoggedIn = true; + $username = $auth_user->handle; +} elseif (!empty($_SESSION['user'])) { + $isLoggedIn = true; + $username = $_SESSION['user']; +} else { + $isLoggedIn = false; + $username = ''; +} + +$template->assign([ + 'authIsLoggedIn' => $isLoggedIn, + 'authUsername' => $username, + 'authRole' => $logged_in, +]); diff --git a/templates/pages/bugs_getting_valgrind_log.php b/templates/pages/bugs_getting_valgrind_log.php new file mode 100644 index 0000000..1bdec34 --- /dev/null +++ b/templates/pages/bugs_getting_valgrind_log.php @@ -0,0 +1,98 @@ +<?php $this->extends('layout.php', ['title' => 'Generating a valgrind log']) ?> + +<?php $this->start('content') ?> + +<h1>Generating a valgrind log</h1> + +<h3>Important!</h3> + +To get a meaningful log you must have PHP configured with <code>--enable-debug</code> +and disable Zend memory manager. + +<h3>Disabling Zend MM</h3> + +<p> +Zend Engine uses its own routines to optimize memory management, but because of +this valgrind cannot see most of the memory issues. You must disable Zend memory +manager before running PHP with valgrind. In order to do this you need to set +USE_ZEND_ALLOC environment variable to 0. +</p> + +<p> + Use + <pre><code>export USE_ZEND_ALLOC=0</code></pre> + or + <pre><code>setenv USE_ZEND_ALLOC 0</code></pre> + (the syntax depends on what your shell supports). +</p> + +<p> +This works since PHP 5.2, in older versions you had to reconfigure PHP with +<code>--disable-zend-memory-manager</code> option. +</p> + +<h3>Using Shared Extensions</h3> + +<p> +To correctly show the stack frames for extensions compiled as shared libraries, set: +<pre><code>export ZEND_DONT_UNLOAD_MODULES=1</code></pre> or +<pre><code>setenv ZEND_DONT_UNLOAD_MODULES 1</code></pre> (the syntax depends on +what your shell supports). +</p> + +<p> +This works from PHP 5.3.11 onwards. +</p> + +<h3>Running PHP CLI, Built-in Web Server or PHP CGI through valgrind</h3> + +<p> +To generate the valgrind log using PHP CLI/CGI, you need to execute the following +command: +</p> + +<pre> + <code> + valgrind --tool=memcheck --num-callers=30 --log-file=php.log /path/to/php-cli script.php + </code> +</pre> + +<p>This should put the log into php.log file in the current working directory.</p> + +<p> +To valgrind the built-in web server, use the appropriate -S and -t options to +the CLI executable. Run your application via a browser and review php.log for +any valgrind errors. +</p> + +<h3>Running PHP Apache module through valgrind</h3> + +<p> If you compiled PHP and Apache statically, make sure the Apache binary is +not stripped after <code>make install</code>, otherwise you lose the required +debug info. To check it, run <code>file /path/to/httpd</code>, it should output +something like this (notice "not stripped"): +</p> + +<pre> + <code> + # file /usr/local/apache2/bin/httpd + /usr/local/apache2/bin/httpd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), not stripped + </code> +</pre> + +<p> +To generate the valgrind log using PHP as Apache module, you need to run the +Apache itself under valgrind: +</p> + +<pre> + <code> + valgrind --tool=memcheck --num-callers=30 --log-file=apache.log /usr/local/apache/bin/httpd -X + </code> +</pre> + +<p> +Run your application via a browser. All the memory errors will be in apache.log. +</p> + +<?php $this->end('content') ?> diff --git a/templates/pages/how_to_report.php b/templates/pages/how_to_report.php new file mode 100644 index 0000000..0445e9d --- /dev/null +++ b/templates/pages/how_to_report.php @@ -0,0 +1,137 @@ +<?php $this->extends('layout.php', ['title' => 'How to Report a Bug']) ?> + +<?php $this->start('content') ?> + +<h1>How to Report a Bug</h1> + +<p>There is a large number of PHP users. There is a much smaller number of people +who actually develop the PHP language and extensions. There is an even smaller +number of people who actively fix bugs reported by users.</p> + +<p>What does this mean for you, an aspiring bug reporter? In order to catch the +eye of one of these few stalwart <b>volunteers</b>, you'll need to take to +heart a few tips on how to report a bug so that they can and will help you.</p> + +<p>Take special note of that word in bold above. The people who are going to +help you with a bug you report are <b>volunteers</b>. Not only are you not +paying them to help you, but nobody else is either. So, to paraphrase the +immortal words of <a href="https://www.imdb.com/title/tt0096928/">Bill and Ted</a>, +<b>"be excellent to them"</b>.</p> + +<p>Beyond that golden rule, what follows are some additional tips on ways to +make your bug report better so that someone will be able to help you.</p> + +<h2>The basics: what you did, what you wanted to happen, and what actually +happened.</h2> + +<p>Those are the three basic elements of a bug report. You need to tell us +exactly what you did (for example, "My script calls +make_happy_meal('hamburger','onion rings')") , what you expected to have happen +(to continue the example, "I expected PHP to serve me a happy meal with a +hamburger and onion rings"), and what actually happened ("It gave me a happy +meal with french fries.").</p> + +<p>Yes, the example is silly. But if your bug report simply said "The +make_happy_meal function doesn't work," we wouldn't be able to say "That's +because you can't have onion rings in a happy meal, you can only have french +fries or curly fries." By telling us what you asked for, what you expected to +get, and what you actually got, we don't have to guess.</p> + +<h2>Always search the bug database first.</h2> + +<p>Advice is so good, we'll repeat it twice. Always <a +href="/search.php">search</a> the bug database first. As we said above, there's +a lot of users of PHP. The odds are good that if you've found a problem, +someone else has found it, too. If you spend a few minutes of your time making +sure that you're not filing a duplicate bug, that's a few more minutes someone +can spend helping to fix that bug rather than sorting out duplicate bug +reports.</p> + +<h2>If you don't understand an error message, ask for help.</h2> + +<p>Don't report an error message you don't understand as a bug. There are <a +href="https://php.net/support.php">a lot of places you can ask for help</a> +in understanding what is going on before you can claim that an error message +you do not understand is a bug.</p> + +<p>(Now, once you've understood the error message, and have a good suggestion +for a way to make the error message more clear, you might consider reporting it +as a feature request.)</p> + +<h2>Be brief, but don't leave any important details out.</h2> + +<p>This is a fine line to walk. But there are some general guidelines:</p> +<ul> + <li> + Remember the three basics: what you did, what you expected to happen, + and what happened. + </li> + <li> + When you provide code that demonstrates the problem, it should almost + never be more than ten lines long. Anything longer probably contains a + lot of code that has nothing to do with the problem, which just increases + the time to figure out the real problem. (But don't forget to make + sure that your code still demonstrates the bug you're reporting and + doesn't have some other problem because you've accidentally trimmed out + something you thought wasn't important but was!) + </li> + <li> + If PHP is crashing, include a backtrace. Instructions for doing this + can be found <a href="/bugs-generating-backtrace.php">here for *NIX users</a> and + <a href="/bugs-generating-backtrace-win32.php">here for Windows users</a>. + </li> + <li> + <a href="http://valgrind.org">Valgrind</a> log can be also very useful. + See <a href="/bugs-getting-valgrind-log.php">instructions how to generate it</a>. + </li> +</ul> + +<h2>Use English.</h2> + +<p>Yes, the PHP user and developer communities are global and include a great +many people who can speak a great many languages. But if you were to report a +bug in a language other than English, many (if not most) of the people who +would otherwise help you won't be able to. If you're worried about your English +skills making it difficult to describe the bug, you might try asking for help +on one of the <a href="https://php.net/support.php#local">non-English +mailing lists</a>.</p> + +<h2>Don't report bugs about old versions.</h2> + +<p>Every time a new version of PHP is released, dozens of bugs are fixed. If +you're using a version of PHP that is more than two revisions older than the +latest version, you should upgrade to the latest version to make sure the bug +you are experiencing still exists.</p> + +<p>Note that PHP branches which are no longer <a +href="https://php.net/supported-versions.php">actively supported</a> will +receive fixes for critical security issues only. So please do not report +non-security related bugs which do not affect any actively supported PHP +branch.</p> + +<h2>Only report one problem in each bug report.</h2> + +<p>If you have encountered two bugs that don't appear to be related, create a +new bug report for each one. This makes it easier for different people to help +with the different bugs.</p> + +<h2>Check out these other resources.</h2> + +<ul> + <li> + Eric Raymond's and Rick Moen's + <a href="http://www.catb.org/~esr/faqs/smart-questions.html">How + To Ask Questions The Smart Way</a> + </li> + <li> + mozilla.org's + <a href="https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines">bug + writing guidelines</a> + </li> + <li> + Simon Tatham's <a href="https://www.chiark.greenend.org.uk/~sgtatham/bugs.html">How + to Report Bugs Effectively</a> + </li> +</ul> + +<?php $this->end('content') ?> diff --git a/templates/pages/search_how_to.php b/templates/pages/search_how_to.php new file mode 100644 index 0000000..fb5189c --- /dev/null +++ b/templates/pages/search_how_to.php @@ -0,0 +1,171 @@ +<?php $this->extends('layout.php', ['title' => 'How to search the bug database']) ?> + +<?php $this->start('content') ?> + +<h1>How to Search</h1> + +<p> +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. +</p> + +<h3>Basic Search</h3> + +<p> +Within every <a href="/"><?= $siteUrl ?></a> webpage header is a search box, +this is the <i>basic</i> 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. +</p> + +<h3>Advanced Search</h3> + +<p> +Some explanations for most of the PHP bugs <a href="/search.php">advanced search</a> +options. +</p> + +<table cellpadding="2" cellspacing="0" border="1" bgcolor="#eeeeee"> + <tr class="headerbottom" align="left"> + <td><strong>Feature</strong></td> + <td><strong>Explanation</strong></td> + <td><strong>Possible reasons for use</strong></td> + </tr> + <tr valign="top"> + <td>Find bugs</td> + <td> + 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: + <ul> + <li><i>all</i> : (default) All search terms are required.</li> + <li><i>any</i> : One or more (any) of the search terms may be present.</li> + <li> + <i>raw</i> : Allows full use of MySQL's + <a href="https://dev.mysql.com/doc/en/fulltext-search.html">FULLTEXT</a> + boolean search operators. + </li> + </ul> + </td> + <td> + For <strong>any</strong>, 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 <strong>all</strong> makes sense if you require every term in your + results, as this can provide precise searching. The <strong>raw</strong> + 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. + </td> + </tr> + <tr valign="top"> + <td>Status</td> + <td> + Each bug has a status, this allows searching for a specific (or all) status type. + Here are a few explanations: + <ul> + <li> + <strong>Open</strong>: This also includes <i>assigned</i>, <i>analyzed</i>, + <i>critical</i>, and <i>verified</i> bugs. (default) + </li> + <li> + <strong>Feedback</strong>: Bugs requesting feedback. Typically a bug that + requests feedback will be marked as <i>No Feedback</i> if no feedback transpires + after 15 days. + </li> + <li><strong>Old feedback</strong>: Bugs that have been requesting feedback for over60 days.</li> + <li> + <strong>Fresh</strong> : Bugs commented on in the last 30 days that are not closed, + duplicates, or not-a-bug. Only developers and the original author can affect this + date as public comments do not. + </li> + <li> + <strong>Stale</strong>: Bugs last commented on at least 30 days ago that are not + closed, duplicates, or not-a-bug. Only developers and the original author can affect + this date as public comments do not count. + </li> + <li> + <strong>Suspended</strong>: Tickets which are waiting on some action + which is outside the scope of the PHP developers. + </li> + </li> + <strong>Wont fix</strong>: Tickets where PHP developers won't fix an issue + (even though it is acknowlegded as such), for reasons to be stated in the + closing comment. + </li> + <li><strong>All</strong>: All types, even not-a-bug.</li> + </ul> + </td> + <td>If you're only interested in critical bugs, or want to see which have been verified, or perhaps just those seeking feedback.</td> + </tr> + <tr valign="top"> + <td>Category</td> + <td> + 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 <i>feature request</i> or <i>any</i> status. + </td> + <td> </td> + </tr> + <tr valign="top"> + <td>OS</td> + <td> + 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: <i>'%$os%'</i>. + </td> + <td>Although not an accurate field, it may be of some use.</td> + </tr> + <tr valign="top"> + <td>Version</td> + <td> + 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: <i>'$version%'</i>. Defaults to both 4 and 5. + </td> + <td> + 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. + </td> + </tr> + <tr valign="top"> + <td>Assigned</td> + <td> + Some bugs get assigned to PHP developers, in which case you may specify by + entering in the PHP username of said developer. + </td> + <td>Example use is limiting the bugs assigned to yourself.</td> + </tr> + <tr valign="top"> + <td>Author email</td> + <td>Takes on an email address of the original author of a bug.</td> + <td>Looking for all bugs that a particular person initiated.</td> + </tr> + <tr valign="top"> + <td>Date</td> + <td> + 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. + </td> + <td> + Looking for recently reported bugs. For example, choosing <i>30 days ago</i> + will limit the search to all bugs reported in the last 30 days. + </td> + </tr> +</table> + +<h1>Bug System Statistics</h1> + +<p> +You can view a variety of statistics about the bugs that have been reported on +our <a href="/stats.php">bug statistics page</a>. +</p> + +<?php $this->end('content') ?> diff --git a/www/bugs-getting-valgrind-log.php b/www/bugs-getting-valgrind-log.php index 3dc9b3e..eca05be 100644 --- a/www/bugs-getting-valgrind-log.php +++ b/www/bugs-getting-valgrind-log.php @@ -1,107 +1,14 @@ <?php -session_start(); +/** + * Valgring log guide page. + */ -require_once '../include/prepend.php'; +// Application bootstrap +require_once __DIR__.'/../include/prepend.php'; -// Authenticate -bugs_authenticate($user, $pw, $logged_in, $user_flags); +// Authentication +require_once __DIR__.'/../include/auth.php'; -response_header('Generating a valgrind log'); -?> - -<h1>Generating a valgrind log</h1> - -<h3>Important!</h3> -To get a meaningful log you must have -PHP configured with <code>--enable-debug</code> -and disable Zend memory manager. - -<h3>Disabling Zend MM</h3> - -<p> - Zend Engine uses its own routines to optimize memory management, - but because of this valgrind cannot see most of the memory issues. - You must disable Zend memory manager before running PHP with valgrind. - In order to do this you need to set USE_ZEND_ALLOC environment - variable to 0. -</p> -<p> - Use - <pre><code>export USE_ZEND_ALLOC=0</code></pre> or - <pre><code>setenv USE_ZEND_ALLOC 0</code></pre> (the syntax depends on - what your shell supports). -</p> -<p> - This works since PHP 5.2, in older versions you had to reconfigure PHP with - <code>--disable-zend-memory-manager</code> option. -</p> - - -<h3>Using Shared Extensions</h3> - -<p> - To correctly show the stack frames for extensions compiled as shared libraries, set: - <pre><code>export ZEND_DONT_UNLOAD_MODULES=1</code></pre> or - <pre><code>setenv ZEND_DONT_UNLOAD_MODULES 1</code></pre> (the syntax depends on - what your shell supports). -</p> - -<p> - This works from PHP 5.3.11 onwards. -</p> - -<h3>Running PHP CLI, Built-in Web Server or PHP CGI through valgrind</h3> - -<p> - To generate the valgrind log using PHP CLI/CGI, - you need to execute the following command: -</p> - -<pre> - <code> - valgrind --tool=memcheck --num-callers=30 --log-file=php.log /path/to/php-cli script.php - </code> -</pre> - -<p> - This should put the log into php.log file in the current working directory. -</p> - -<p> - To valgrind the built-in web server, use the appropriate -S and -t - options to the CLI executable. Run your application via a browser and - review php.log for any valgrind errors. -</p> - -<h3>Running PHP Apache module through valgrind</h3> - -<p> - If you compiled PHP and Apache statically, make sure the Apache binary - is not stripped after <code>make install</code>, otherwise you lose - the required debug info. To check it, run <code>file /path/to/httpd</code>, - it should output something like this (notice "not stripped"): -</p> -<pre> - <code> - # file /usr/local/apache2/bin/httpd - /usr/local/apache2/bin/httpd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), not stripped - </code> -</pre> - -<p> - To generate the valgrind log using PHP as Apache module, - you need to run the Apache itself under valgrind: -</p> - -<pre> - <code> - valgrind --tool=memcheck --num-callers=30 --log-file=apache.log /usr/local/apache/bin/httpd -X - </code> -</pre> - -<p> - Run your application via a browser. All the memory errors will be in apache.log. -</p> - -<?php response_footer(); +// Output template with given template variables. +echo $template->render('pages/bugs_getting_valgrind_log.php'); diff --git a/www/how-to-report.php b/www/how-to-report.php index a0a6b03..cab6305 100644 --- a/www/how-to-report.php +++ b/www/how-to-report.php @@ -1,145 +1,14 @@ <?php -session_start(); +/** + * Page with info how to report a bug. + */ -require_once '../include/prepend.php'; +// Application bootstrap +require_once __DIR__.'/../include/prepend.php'; -// Authenticate -bugs_authenticate($user, $pw, $logged_in, $user_flags); +// Authentication +require_once __DIR__.'/../include/auth.php'; -response_header('How to Report a Bug'); -?> - -<h1>How to Report a Bug</h1> - -<p>There is a large number of PHP users. There is a much smaller number of people -who actually develop the PHP language and extensions. There is an even smaller -number of people who actively fix bugs reported by users.</p> - -<p>What does this mean for you, an aspiring bug reporter? In order to catch the -eye of one of these few stalwart <b>volunteers</b>, you'll need to take to -heart a few tips on how to report a bug so that they can and will help you.</p> - -<p>Take special note of that word in bold above. The people who are going to -help you with a bug you report are <b>volunteers</b>. Not only are you not -paying them to help you, but nobody else is either. So, to paraphrase the -immortal words of <a href="https://www.imdb.com/title/tt0096928/">Bill and Ted</a>, -<b>"be excellent to them"</b>.</p> - -<p>Beyond that golden rule, what follows are some additional tips on ways to -make your bug report better so that someone will be able to help you.</p> - -<h2>The basics: what you did, what you wanted to happen, and what actually -happened.</h2> - -<p>Those are the three basic elements of a bug report. You need to tell us -exactly what you did (for example, "My script calls -make_happy_meal('hamburger','onion rings')") , what you expected to have happen -(to continue the example, "I expected PHP to serve me a happy meal with a -hamburger and onion rings"), and what actually happened ("It gave me a happy -meal with french fries.").</p> - -<p>Yes, the example is silly. But if your bug report simply said "The -make_happy_meal function doesn't work," we wouldn't be able to say "That's -because you can't have onion rings in a happy meal, you can only have french -fries or curly fries." By telling us what you asked for, what you expected to -get, and what you actually got, we don't have to guess.</p> - -<h2>Always search the bug database first.</h2> - -<p>Advice is so good, we'll repeat it twice. Always <a -href="search.php">search</a> the bug database first. As we said above, there's -a lot of users of PHP. The odds are good that if you've found a problem, -someone else has found it, too. If you spend a few minutes of your time making -sure that you're not filing a duplicate bug, that's a few more minutes someone -can spend helping to fix that bug rather than sorting out duplicate bug -reports.</p> - -<h2>If you don't understand an error message, ask for help.</h2> - -<p>Don't report an error message you don't understand as a bug. There are <a -href="https://php.net/support.php">a lot of places you can ask for help</a> -in understanding what is going on before you can claim that an error message -you do not understand is a bug.</p> - -<p>(Now, once you've understood the error message, and have a good suggestion -for a way to make the error message more clear, you might consider reporting it -as a feature request.)</p> - -<h2>Be brief, but don't leave any important details out.</h2> - -<p>This is a fine line to walk. But there are some general guidelines:</p> -<ul> - <li> - Remember the three basics: what you did, what you expected to happen, - and what happened. - </li> - <li> - When you provide code that demonstrates the problem, it should almost - never be more than ten lines long. Anything longer probably contains a - lot of code that has nothing to do with the problem, which just increases - the time to figure out the real problem. (But don't forget to make - sure that your code still demonstrates the bug you're reporting and - doesn't have some other problem because you've accidentally trimmed out - something you thought wasn't important but was!) - </li> - <li> - If PHP is crashing, include a backtrace. Instructions for doing this - can be found <a href="bugs-generating-backtrace.php">here for *NIX users</a> and - <a href="bugs-generating-backtrace-win32.php">here for Windows users</a>. - </li> - <li> - <a href="http://valgrind.org">Valgrind</a> log can be also very useful. - See <a href="bugs-getting-valgrind-log.php">instructions how to generate it</a>. - </li> -</ul> - -<h2>Use English.</h2> - -<p>Yes, the PHP user and developer communities are global and include a great -many people who can speak a great many languages. But if you were to report a -bug in a language other than English, many (if not most) of the people who -would otherwise help you won't be able to. If you're worried about your English -skills making it difficult to describe the bug, you might try asking for help -on one of the <a href="https://php.net/support.php#local">non-English -mailing lists</a>.</p> - -<h2>Don't report bugs about old versions.</h2> - -<p>Every time a new version of PHP is released, dozens of bugs are fixed. If -you're using a version of PHP that is more than two revisions older than the -latest version, you should upgrade to the latest version to make sure the bug -you are experiencing still exists.</p> - -<p>Note that PHP branches which are no longer <a -href="https://php.net/supported-versions.php">actively supported</a> will -receive fixes for critical security issues only. So please do not report -non-security related bugs which do not affect any actively supported PHP -branch.</p> - -<h2>Only report one problem in each bug report.</h2> - -<p>If you have encountered two bugs that don't appear to be related, create a -new bug report for each one. This makes it easier for different people to help -with the different bugs.</p> - -<h2>Check out these other resources.</h2> - -<ul> - <li> - Eric Raymond's and Rick Moen's - <a href="http://www.catb.org/~esr/faqs/smart-questions.html">How - To Ask Questions The Smart Way</a> - </li> - <li> - mozilla.org's - <a href="https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines">bug - writing guidelines</a> - </li> - <li> - Simon Tatham's <a href="https://www.chiark.greenend.org.uk/~sgtatham/bugs.html">How - to Report Bugs Effectively</a> - </li> -</ul> - -<?php response_footer(); +// Output template with given template variables. +echo $template->render('pages/how_to_report.php'); diff --git a/www/index.php b/www/index.php index f53b7b6..c57a9ac 100644 --- a/www/index.php +++ b/www/index.php @@ -8,29 +8,8 @@ use App\Repository\BugRepository; // Application bootstrap require_once __DIR__.'/../include/prepend.php'; -// Start session -session_start(); - -// Authenticate -bugs_authenticate($user, $pw, $logged_in, $user_flags); - -// TODO: Refactor this into a better authentication service -if ('developer' === $logged_in) { - $isLoggedIn = true; - $username = $auth_user->handle; -} elseif (!empty($_SESSION['user'])) { - $isLoggedIn = true; - $username = $_SESSION['user']; -} else { - $isLoggedIn = false; - $username = ''; -} - -$template->assign([ - 'authIsLoggedIn' => $isLoggedIn, - 'authUsername' => $username, - 'authRole' => $logged_in, -]); +// Authentication +require_once __DIR__.'/../include/auth.php'; // If 'id' is passed redirect to the bug page $id = (int) ($_GET['id'] ?? 0); diff --git a/www/search-howto.php b/www/search-howto.php index 6b0edaf..b0d1e85 100644 --- a/www/search-howto.php +++ b/www/search-howto.php @@ -1,177 +1,14 @@ <?php -session_start(); +/** + * Page with search how to guide. + */ -require '../include/prepend.php'; +// Application bootstrap +require __DIR__.'/../include/prepend.php'; -// Authenticate -bugs_authenticate($user, $pw, $logged_in, $user_flags); +// Authentication +require_once __DIR__.'/../include/auth.php'; -response_header("How to search the bug database"); -?> - -<h1>How to Search</h1> - -<p> -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. -</p> - -<h3>Basic Search</h3> - -<p> -Within every <a href="<?php echo $basedir, '/'; ?>"><?php echo $site_url, $basedir; ?>/</a> -webpage header is a search box, this is the <i>basic</i> 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. -</p> - -<h3>Advanced Search</h3> -<p> -Some explanations for most of the PHP bugs <a href="search.php">advanced search</a> -options. -</p> -<table cellpadding="2" cellspacing="0" border="1" bgcolor="#eeeeee"> - <tr class="headerbottom" align="left"> - <td><strong>Feature</strong></td> - <td><strong>Explanation</strong></td> - <td><strong>Possible reasons for use</strong></td> - </tr> - <tr valign="top"> - <td>Find bugs</td> - <td> - 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: - <ul> - <li><i>all</i> : (default) All search terms are required.</li> - <li><i>any</i> : One or more (any) of the search terms may be present.</li> - <li> - <i>raw</i> : Allows full use of MySQL's - <a href="https://dev.mysql.com/doc/en/fulltext-search.html">FULLTEXT</a> - boolean search operators. - </li> - </ul> - </td> - <td> - For <strong>any</strong>, 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 <strong>all</strong> makes sense if you require every term in your - results, as this can provide precise searching. The <strong>raw</strong> - 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. - </td> - </tr> - <tr valign="top"> - <td>Status</td> - <td> - Each bug has a status, this allows searching for a specific (or all) status type. - Here are a few explanations: - <ul> - <li> - <strong>Open</strong>: This also includes <i>assigned</i>, <i>analyzed</i>, - <i>critical</i>, and <i>verified</i> bugs. (default) - </li> - <li> - <strong>Feedback</strong>: Bugs requesting feedback. Typically a bug that - requests feedback will be marked as <i>No Feedback</i> if no feedback transpires - after 15 days. - </li> - <li><strong>Old feedback</strong>: Bugs that have been requesting feedback for over60 days.</li> - <li> - <strong>Fresh</strong> : Bugs commented on in the last 30 days that are not closed, - duplicates, or not-a-bug. Only developers and the original author can affect this - date as public comments do not. - </li> - <li> - <strong>Stale</strong>: Bugs last commented on at least 30 days ago that are not - closed, duplicates, or not-a-bug. Only developers and the original author can affect - this date as public comments do not count. - </li> - <li> - <strong>Suspended</strong>: Tickets which are waiting on some action - which is outside the scope of the PHP developers. - </li> - </li> - <strong>Wont fix</strong>: Tickets where PHP developers won't fix an issue - (even though it is acknowlegded as such), for reasons to be stated in the - closing comment. - </li> - <li><strong>All</strong>: All types, even not-a-bug.</li> - </ul> - </td> - <td>If you're only interested in critical bugs, or want to see which have been verified, or perhaps just those seeking feedback.</td> - </tr> - <tr valign="top"> - <td>Category</td> - <td> - 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 <i>feature request</i> or <i>any</i> status. - </td> - <td> </td> - </tr> - <tr valign="top"> - <td>OS</td> - <td> - 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: <i>'%$os%'</i>. - </td> - <td>Although not an accurate field, it may be of some use.</td> - </tr> - <tr valign="top"> - <td>Version</td> - <td> - 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: <i>'$version%'</i>. Defaults to both 4 and 5. - </td> - <td> - 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. - </td> - </tr> - <tr valign="top"> - <td>Assigned</td> - <td> - Some bugs get assigned to PHP developers, in which case you may specify by - entering in the PHP username of said developer. - </td> - <td>Example use is limiting the bugs assigned to yourself.</td> - </tr> - <tr valign="top"> - <td>Author email</td> - <td>Takes on an email address of the original author of a bug.</td> - <td>Looking for all bugs that a particular person initiated.</td> - </tr> - <tr valign="top"> - <td>Date</td> - <td> - 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. - </td> - <td> - Looking for recently reported bugs. For example, choosing <i>30 days ago</i> - will limit the search to all bugs reported in the last 30 days. - </td> - </tr> -</table> - -<h1>Bug System Statistics</h1> - -<p> -You can view a variety of statistics about the bugs that have been -reported on our <a href="stats.php">bug statistics page</a>. -</p> - -<?php response_footer(); +// Output template with given template variables. +echo $template->render('pages/search_how_to.php');
diff --git a/include/auth.php b/include/auth.php new file mode 100644 index 0000000..e9d1052 --- /dev/null +++ b/include/auth.php @@ -0,0 +1,31 @@ +<?php + +/** + * Temporary helper placeholder file to overcome the authentication service + * migration. + * + * TODO: Refactor this into a better authentication service. + */ + +// Start session +session_start(); + +// Authenticate +bugs_authenticate($user, $pw, $logged_in, $user_flags); + +if ('developer' === $logged_in) { + $isLoggedIn = true; + $username = $auth_user->handle; +} elseif (!empty($_SESSION['user'])) { + $isLoggedIn = true; + $username = $_SESSION['user']; +} else { + $isLoggedIn = false; + $username = ''; +} + +$template->assign([ + 'authIsLoggedIn' => $isLoggedIn, + 'authUsername' => $username, + 'authRole' => $logged_in, +]); diff --git a/templates/pages/bugs_getting_valgrind_log.php b/templates/pages/bugs_getting_valgrind_log.php new file mode 100644 index 0000000..1bdec34 --- /dev/null +++ b/templates/pages/bugs_getting_valgrind_log.php @@ -0,0 +1,98 @@ +<?php $this->extends('layout.php', ['title' => 'Generating a valgrind log']) ?> + +<?php $this->start('content') ?> + +<h1>Generating a valgrind log</h1> + +<h3>Important!</h3> + +To get a meaningful log you must have PHP configured with <code>--enable-debug</code> +and disable Zend memory manager. + +<h3>Disabling Zend MM</h3> + +<p> +Zend Engine uses its own routines to optimize memory management, but because of +this valgrind cannot see most of the memory issues. You must disable Zend memory +manager before running PHP with valgrind. In order to do this you need to set +USE_ZEND_ALLOC environment variable to 0. +</p> + +<p> + Use + <pre><code>export USE_ZEND_ALLOC=0</code></pre> + or + <pre><code>setenv USE_ZEND_ALLOC 0</code></pre> + (the syntax depends on what your shell supports). +</p> + +<p> +This works since PHP 5.2, in older versions you had to reconfigure PHP with +<code>--disable-zend-memory-manager</code> option. +</p> + +<h3>Using Shared Extensions</h3> + +<p> +To correctly show the stack frames for extensions compiled as shared libraries, set: +<pre><code>export ZEND_DONT_UNLOAD_MODULES=1</code></pre> or +<pre><code>setenv ZEND_DONT_UNLOAD_MODULES 1</code></pre> (the syntax depends on +what your shell supports). +</p> + +<p> +This works from PHP 5.3.11 onwards. +</p> + +<h3>Running PHP CLI, Built-in Web Server or PHP CGI through valgrind</h3> + +<p> +To generate the valgrind log using PHP CLI/CGI, you need to execute the following +command: +</p> + +<pre> + <code> + valgrind --tool=memcheck --num-callers=30 --log-file=php.log /path/to/php-cli script.php + </code> +</pre> + +<p>This should put the log into php.log file in the current working directory.</p> + +<p> +To valgrind the built-in web server, use the appropriate -S and -t options to +the CLI executable. Run your application via a browser and review php.log for +any valgrind errors. +</p> + +<h3>Running PHP Apache module through valgrind</h3> + +<p> If you compiled PHP and Apache statically, make sure the Apache binary is +not stripped after <code>make install</code>, otherwise you lose the required +debug info. To check it, run <code>file /path/to/httpd</code>, it should output +something like this (notice "not stripped"): +</p> + +<pre> + <code> + # file /usr/local/apache2/bin/httpd + /usr/local/apache2/bin/httpd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), not stripped + </code> +</pre> + +<p> +To generate the valgrind log using PHP as Apache module, you need to run the +Apache itself under valgrind: +</p> + +<pre> + <code> + valgrind --tool=memcheck --num-callers=30 --log-file=apache.log /usr/local/apache/bin/httpd -X + </code> +</pre> + +<p> +Run your application via a browser. All the memory errors will be in apache.log. +</p> + +<?php $this->end('content') ?> diff --git a/templates/pages/how_to_report.php b/templates/pages/how_to_report.php new file mode 100644 index 0000000..0445e9d --- /dev/null +++ b/templates/pages/how_to_report.php @@ -0,0 +1,137 @@ +<?php $this->extends('layout.php', ['title' => 'How to Report a Bug']) ?> + +<?php $this->start('content') ?> + +<h1>How to Report a Bug</h1> + +<p>There is a large number of PHP users. There is a much smaller number of people +who actually develop the PHP language and extensions. There is an even smaller +number of people who actively fix bugs reported by users.</p> + +<p>What does this mean for you, an aspiring bug reporter? In order to catch the +eye of one of these few stalwart <b>volunteers</b>, you'll need to take to +heart a few tips on how to report a bug so that they can and will help you.</p> + +<p>Take special note of that word in bold above. The people who are going to +help you with a bug you report are <b>volunteers</b>. Not only are you not +paying them to help you, but nobody else is either. So, to paraphrase the +immortal words of <a href="https://www.imdb.com/title/tt0096928/">Bill and Ted</a>, +<b>"be excellent to them"</b>.</p> + +<p>Beyond that golden rule, what follows are some additional tips on ways to +make your bug report better so that someone will be able to help you.</p> + +<h2>The basics: what you did, what you wanted to happen, and what actually +happened.</h2> + +<p>Those are the three basic elements of a bug report. You need to tell us +exactly what you did (for example, "My script calls +make_happy_meal('hamburger','onion rings')") , what you expected to have happen +(to continue the example, "I expected PHP to serve me a happy meal with a +hamburger and onion rings"), and what actually happened ("It gave me a happy +meal with french fries.").</p> + +<p>Yes, the example is silly. But if your bug report simply said "The +make_happy_meal function doesn't work," we wouldn't be able to say "That's +because you can't have onion rings in a happy meal, you can only have french +fries or curly fries." By telling us what you asked for, what you expected to +get, and what you actually got, we don't have to guess.</p> + +<h2>Always search the bug database first.</h2> + +<p>Advice is so good, we'll repeat it twice. Always <a +href="/search.php">search</a> the bug database first. As we said above, there's +a lot of users of PHP. The odds are good that if you've found a problem, +someone else has found it, too. If you spend a few minutes of your time making +sure that you're not filing a duplicate bug, that's a few more minutes someone +can spend helping to fix that bug rather than sorting out duplicate bug +reports.</p> + +<h2>If you don't understand an error message, ask for help.</h2> + +<p>Don't report an error message you don't understand as a bug. There are <a +href="https://php.net/support.php">a lot of places you can ask for help</a> +in understanding what is going on before you can claim that an error message +you do not understand is a bug.</p> + +<p>(Now, once you've understood the error message, and have a good suggestion +for a way to make the error message more clear, you might consider reporting it +as a feature request.)</p> + +<h2>Be brief, but don't leave any important details out.</h2> + +<p>This is a fine line to walk. But there are some general guidelines:</p> +<ul> + <li> + Remember the three basics: what you did, what you expected to happen, + and what happened. + </li> + <li> + When you provide code that demonstrates the problem, it should almost + never be more than ten lines long. Anything longer probably contains a + lot of code that has nothing to do with the problem, which just increases + the time to figure out the real problem. (But don't forget to make + sure that your code still demonstrates the bug you're reporting and + doesn't have some other problem because you've accidentally trimmed out + something you thought wasn't important but was!) + </li> + <li> + If PHP is crashing, include a backtrace. Instructions for doing this + can be found <a href="/bugs-generating-backtrace.php">here for *NIX users</a> and + <a href="/bugs-generating-backtrace-win32.php">here for Windows users</a>. + </li> + <li> + <a href="http://valgrind.org">Valgrind</a> log can be also very useful. + See <a href="/bugs-getting-valgrind-log.php">instructions how to generate it</a>. + </li> +</ul> + +<h2>Use English.</h2> + +<p>Yes, the PHP user and developer communities are global and include a great +many people who can speak a great many languages. But if you were to report a +bug in a language other than English, many (if not most) of the people who +would otherwise help you won't be able to. If you're worried about your English +skills making it difficult to describe the bug, you might try asking for help +on one of the <a href="https://php.net/support.php#local">non-English +mailing lists</a>.</p> + +<h2>Don't report bugs about old versions.</h2> + +<p>Every time a new version of PHP is released, dozens of bugs are fixed. If +you're using a version of PHP that is more than two revisions older than the +latest version, you should upgrade to the latest version to make sure the bug +you are experiencing still exists.</p> + +<p>Note that PHP branches which are no longer <a +href="https://php.net/supported-versions.php">actively supported</a> will +receive fixes for critical security issues only. So please do not report +non-security related bugs which do not affect any actively supported PHP +branch.</p> + +<h2>Only report one problem in each bug report.</h2> + +<p>If you have encountered two bugs that don't appear to be related, create a +new bug report for each one. This makes it easier for different people to help +with the different bugs.</p> + +<h2>Check out these other resources.</h2> + +<ul> + <li> + Eric Raymond's and Rick Moen's + <a href="http://www.catb.org/~esr/faqs/smart-questions.html">How + To Ask Questions The Smart Way</a> + </li> + <li> + mozilla.org's + <a href="https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines">bug + writing guidelines</a> + </li> + <li> + Simon Tatham's <a href="https://www.chiark.greenend.org.uk/~sgtatham/bugs.html">How + to Report Bugs Effectively</a> + </li> +</ul> + +<?php $this->end('content') ?> diff --git a/templates/pages/search_how_to.php b/templates/pages/search_how_to.php new file mode 100644 index 0000000..fb5189c --- /dev/null +++ b/templates/pages/search_how_to.php @@ -0,0 +1,171 @@ +<?php $this->extends('layout.php', ['title' => 'How to search the bug database']) ?> + +<?php $this->start('content') ?> + +<h1>How to Search</h1> + +<p> +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. +</p> + +<h3>Basic Search</h3> + +<p> +Within every <a href="/"><?= $siteUrl ?></a> webpage header is a search box, +this is the <i>basic</i> 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. +</p> + +<h3>Advanced Search</h3> + +<p> +Some explanations for most of the PHP bugs <a href="/search.php">advanced search</a> +options. +</p> + +<table cellpadding="2" cellspacing="0" border="1" bgcolor="#eeeeee"> + <tr class="headerbottom" align="left"> + <td><strong>Feature</strong></td> + <td><strong>Explanation</strong></td> + <td><strong>Possible reasons for use</strong></td> + </tr> + <tr valign="top"> + <td>Find bugs</td> + <td> + 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: + <ul> + <li><i>all</i> : (default) All search terms are required.</li> + <li><i>any</i> : One or more (any) of the search terms may be present.</li> + <li> + <i>raw</i> : Allows full use of MySQL's + <a href="https://dev.mysql.com/doc/en/fulltext-search.html">FULLTEXT</a> + boolean search operators. + </li> + </ul> + </td> + <td> + For <strong>any</strong>, 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 <strong>all</strong> makes sense if you require every term in your + results, as this can provide precise searching. The <strong>raw</strong> + 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. + </td> + </tr> + <tr valign="top"> + <td>Status</td> + <td> + Each bug has a status, this allows searching for a specific (or all) status type. + Here are a few explanations: + <ul> + <li> + <strong>Open</strong>: This also includes <i>assigned</i>, <i>analyzed</i>, + <i>critical</i>, and <i>verified</i> bugs. (default) + </li> + <li> + <strong>Feedback</strong>: Bugs requesting feedback. Typically a bug that + requests feedback will be marked as <i>No Feedback</i> if no feedback transpires + after 15 days. + </li> + <li><strong>Old feedback</strong>: Bugs that have been requesting feedback for over60 days.</li> + <li> + <strong>Fresh</strong> : Bugs commented on in the last 30 days that are not closed, + duplicates, or not-a-bug. Only developers and the original author can affect this + date as public comments do not. + </li> + <li> + <strong>Stale</strong>: Bugs last commented on at least 30 days ago that are not + closed, duplicates, or not-a-bug. Only developers and the original author can affect + this date as public comments do not count. + </li> + <li> + <strong>Suspended</strong>: Tickets which are waiting on some action + which is outside the scope of the PHP developers. + </li> + </li> + <strong>Wont fix</strong>: Tickets where PHP developers won't fix an issue + (even though it is acknowlegded as such), for reasons to be stated in the + closing comment. + </li> + <li><strong>All</strong>: All types, even not-a-bug.</li> + </ul> + </td> + <td>If you're only interested in critical bugs, or want to see which have been verified, or perhaps just those seeking feedback.</td> + </tr> + <tr valign="top"> + <td>Category</td> + <td> + 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 <i>feature request</i> or <i>any</i> status. + </td> + <td> </td> + </tr> + <tr valign="top"> + <td>OS</td> + <td> + 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: <i>'%$os%'</i>. + </td> + <td>Although not an accurate field, it may be of some use.</td> + </tr> + <tr valign="top"> + <td>Version</td> + <td> + 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: <i>'$version%'</i>. Defaults to both 4 and 5. + </td> + <td> + 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. + </td> + </tr> + <tr valign="top"> + <td>Assigned</td> + <td> + Some bugs get assigned to PHP developers, in which case you may specify by + entering in the PHP username of said developer. + </td> + <td>Example use is limiting the bugs assigned to yourself.</td> + </tr> + <tr valign="top"> + <td>Author email</td> + <td>Takes on an email address of the original author of a bug.</td> + <td>Looking for all bugs that a particular person initiated.</td> + </tr> + <tr valign="top"> + <td>Date</td> + <td> + 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. + </td> + <td> + Looking for recently reported bugs. For example, choosing <i>30 days ago</i> + will limit the search to all bugs reported in the last 30 days. + </td> + </tr> +</table> + +<h1>Bug System Statistics</h1> + +<p> +You can view a variety of statistics about the bugs that have been reported on +our <a href="/stats.php">bug statistics page</a>. +</p> + +<?php $this->end('content') ?> diff --git a/www/bugs-getting-valgrind-log.php b/www/bugs-getting-valgrind-log.php index 3dc9b3e..eca05be 100644 --- a/www/bugs-getting-valgrind-log.php +++ b/www/bugs-getting-valgrind-log.php @@ -1,107 +1,14 @@ <?php -session_start(); +/** + * Valgring log guide page. + */ -require_once '../include/prepend.php'; +// Application bootstrap +require_once __DIR__.'/../include/prepend.php'; -// Authenticate -bugs_authenticate($user, $pw, $logged_in, $user_flags); +// Authentication +require_once __DIR__.'/../include/auth.php'; -response_header('Generating a valgrind log'); -?> - -<h1>Generating a valgrind log</h1> - -<h3>Important!</h3> -To get a meaningful log you must have -PHP configured with <code>--enable-debug</code> -and disable Zend memory manager. - -<h3>Disabling Zend MM</h3> - -<p> - Zend Engine uses its own routines to optimize memory management, - but because of this valgrind cannot see most of the memory issues. - You must disable Zend memory manager before running PHP with valgrind. - In order to do this you need to set USE_ZEND_ALLOC environment - variable to 0. -</p> -<p> - Use - <pre><code>export USE_ZEND_ALLOC=0</code></pre> or - <pre><code>setenv USE_ZEND_ALLOC 0</code></pre> (the syntax depends on - what your shell supports). -</p> -<p> - This works since PHP 5.2, in older versions you had to reconfigure PHP with - <code>--disable-zend-memory-manager</code> option. -</p> - - -<h3>Using Shared Extensions</h3> - -<p> - To correctly show the stack frames for extensions compiled as shared libraries, set: - <pre><code>export ZEND_DONT_UNLOAD_MODULES=1</code></pre> or - <pre><code>setenv ZEND_DONT_UNLOAD_MODULES 1</code></pre> (the syntax depends on - what your shell supports). -</p> - -<p> - This works from PHP 5.3.11 onwards. -</p> - -<h3>Running PHP CLI, Built-in Web Server or PHP CGI through valgrind</h3> - -<p> - To generate the valgrind log using PHP CLI/CGI, - you need to execute the following command: -</p> - -<pre> - <code> - valgrind --tool=memcheck --num-callers=30 --log-file=php.log /path/to/php-cli script.php - </code> -</pre> - -<p> - This should put the log into php.log file in the current working directory. -</p> - -<p> - To valgrind the built-in web server, use the appropriate -S and -t - options to the CLI executable. Run your application via a browser and - review php.log for any valgrind errors. -</p> - -<h3>Running PHP Apache module through valgrind</h3> - -<p> - If you compiled PHP and Apache statically, make sure the Apache binary - is not stripped after <code>make install</code>, otherwise you lose - the required debug info. To check it, run <code>file /path/to/httpd</code>, - it should output something like this (notice "not stripped"): -</p> -<pre> - <code> - # file /usr/local/apache2/bin/httpd - /usr/local/apache2/bin/httpd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), not stripped - </code> -</pre> - -<p> - To generate the valgrind log using PHP as Apache module, - you need to run the Apache itself under valgrind: -</p> - -<pre> - <code> - valgrind --tool=memcheck --num-callers=30 --log-file=apache.log /usr/local/apache/bin/httpd -X - </code> -</pre> - -<p> - Run your application via a browser. All the memory errors will be in apache.log. -</p> - -<?php response_footer(); +// Output template with given template variables. +echo $template->render('pages/bugs_getting_valgrind_log.php'); diff --git a/www/how-to-report.php b/www/how-to-report.php index a0a6b03..cab6305 100644 --- a/www/how-to-report.php +++ b/www/how-to-report.php @@ -1,145 +1,14 @@ <?php -session_start(); +/** + * Page with info how to report a bug. + */ -require_once '../include/prepend.php'; +// Application bootstrap +require_once __DIR__.'/../include/prepend.php'; -// Authenticate -bugs_authenticate($user, $pw, $logged_in, $user_flags); +// Authentication +require_once __DIR__.'/../include/auth.php'; -response_header('How to Report a Bug'); -?> - -<h1>How to Report a Bug</h1> - -<p>There is a large number of PHP users. There is a much smaller number of people -who actually develop the PHP language and extensions. There is an even smaller -number of people who actively fix bugs reported by users.</p> - -<p>What does this mean for you, an aspiring bug reporter? In order to catch the -eye of one of these few stalwart <b>volunteers</b>, you'll need to take to -heart a few tips on how to report a bug so that they can and will help you.</p> - -<p>Take special note of that word in bold above. The people who are going to -help you with a bug you report are <b>volunteers</b>. Not only are you not -paying them to help you, but nobody else is either. So, to paraphrase the -immortal words of <a href="https://www.imdb.com/title/tt0096928/">Bill and Ted</a>, -<b>"be excellent to them"</b>.</p> - -<p>Beyond that golden rule, what follows are some additional tips on ways to -make your bug report better so that someone will be able to help you.</p> - -<h2>The basics: what you did, what you wanted to happen, and what actually -happened.</h2> - -<p>Those are the three basic elements of a bug report. You need to tell us -exactly what you did (for example, "My script calls -make_happy_meal('hamburger','onion rings')") , what you expected to have happen -(to continue the example, "I expected PHP to serve me a happy meal with a -hamburger and onion rings"), and what actually happened ("It gave me a happy -meal with french fries.").</p> - -<p>Yes, the example is silly. But if your bug report simply said "The -make_happy_meal function doesn't work," we wouldn't be able to say "That's -because you can't have onion rings in a happy meal, you can only have french -fries or curly fries." By telling us what you asked for, what you expected to -get, and what you actually got, we don't have to guess.</p> - -<h2>Always search the bug database first.</h2> - -<p>Advice is so good, we'll repeat it twice. Always <a -href="search.php">search</a> the bug database first. As we said above, there's -a lot of users of PHP. The odds are good that if you've found a problem, -someone else has found it, too. If you spend a few minutes of your time making -sure that you're not filing a duplicate bug, that's a few more minutes someone -can spend helping to fix that bug rather than sorting out duplicate bug -reports.</p> - -<h2>If you don't understand an error message, ask for help.</h2> - -<p>Don't report an error message you don't understand as a bug. There are <a -href="https://php.net/support.php">a lot of places you can ask for help</a> -in understanding what is going on before you can claim that an error message -you do not understand is a bug.</p> - -<p>(Now, once you've understood the error message, and have a good suggestion -for a way to make the error message more clear, you might consider reporting it -as a feature request.)</p> - -<h2>Be brief, but don't leave any important details out.</h2> - -<p>This is a fine line to walk. But there are some general guidelines:</p> -<ul> - <li> - Remember the three basics: what you did, what you expected to happen, - and what happened. - </li> - <li> - When you provide code that demonstrates the problem, it should almost - never be more than ten lines long. Anything longer probably contains a - lot of code that has nothing to do with the problem, which just increases - the time to figure out the real problem. (But don't forget to make - sure that your code still demonstrates the bug you're reporting and - doesn't have some other problem because you've accidentally trimmed out - something you thought wasn't important but was!) - </li> - <li> - If PHP is crashing, include a backtrace. Instructions for doing this - can be found <a href="bugs-generating-backtrace.php">here for *NIX users</a> and - <a href="bugs-generating-backtrace-win32.php">here for Windows users</a>. - </li> - <li> - <a href="http://valgrind.org">Valgrind</a> log can be also very useful. - See <a href="bugs-getting-valgrind-log.php">instructions how to generate it</a>. - </li> -</ul> - -<h2>Use English.</h2> - -<p>Yes, the PHP user and developer communities are global and include a great -many people who can speak a great many languages. But if you were to report a -bug in a language other than English, many (if not most) of the people who -would otherwise help you won't be able to. If you're worried about your English -skills making it difficult to describe the bug, you might try asking for help -on one of the <a href="https://php.net/support.php#local">non-English -mailing lists</a>.</p> - -<h2>Don't report bugs about old versions.</h2> - -<p>Every time a new version of PHP is released, dozens of bugs are fixed. If -you're using a version of PHP that is more than two revisions older than the -latest version, you should upgrade to the latest version to make sure the bug -you are experiencing still exists.</p> - -<p>Note that PHP branches which are no longer <a -href="https://php.net/supported-versions.php">actively supported</a> will -receive fixes for critical security issues only. So please do not report -non-security related bugs which do not affect any actively supported PHP -branch.</p> - -<h2>Only report one problem in each bug report.</h2> - -<p>If you have encountered two bugs that don't appear to be related, create a -new bug report for each one. This makes it easier for different people to help -with the different bugs.</p> - -<h2>Check out these other resources.</h2> - -<ul> - <li> - Eric Raymond's and Rick Moen's - <a href="http://www.catb.org/~esr/faqs/smart-questions.html">How - To Ask Questions The Smart Way</a> - </li> - <li> - mozilla.org's - <a href="https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines">bug - writing guidelines</a> - </li> - <li> - Simon Tatham's <a href="https://www.chiark.greenend.org.uk/~sgtatham/bugs.html">How - to Report Bugs Effectively</a> - </li> -</ul> - -<?php response_footer(); +// Output template with given template variables. +echo $template->render('pages/how_to_report.php'); diff --git a/www/index.php b/www/index.php index f53b7b6..c57a9ac 100644 --- a/www/index.php +++ b/www/index.php @@ -8,29 +8,8 @@ use App\Repository\BugRepository; // Application bootstrap require_once __DIR__.'/../include/prepend.php'; -// Start session -session_start(); - -// Authenticate -bugs_authenticate($user, $pw, $logged_in, $user_flags); - -// TODO: Refactor this into a better authentication service -if ('developer' === $logged_in) { - $isLoggedIn = true; - $username = $auth_user->handle; -} elseif (!empty($_SESSION['user'])) { - $isLoggedIn = true; - $username = $_SESSION['user']; -} else { - $isLoggedIn = false; - $username = ''; -} - -$template->assign([ - 'authIsLoggedIn' => $isLoggedIn, - 'authUsername' => $username, - 'authRole' => $logged_in, -]); +// Authentication +require_once __DIR__.'/../include/auth.php'; // If 'id' is passed redirect to the bug page $id = (int) ($_GET['id'] ?? 0); diff --git a/www/search-howto.php b/www/search-howto.php index 6b0edaf..b0d1e85 100644 --- a/www/search-howto.php +++ b/www/search-howto.php @@ -1,177 +1,14 @@ <?php -session_start(); +/** + * Page with search how to guide. + */ -require '../include/prepend.php'; +// Application bootstrap +require __DIR__.'/../include/prepend.php'; -// Authenticate -bugs_authenticate($user, $pw, $logged_in, $user_flags); +// Authentication +require_once __DIR__.'/../include/auth.php'; -response_header("How to search the bug database"); -?> - -<h1>How to Search</h1> - -<p> -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. -</p> - -<h3>Basic Search</h3> - -<p> -Within every <a href="<?php echo $basedir, '/'; ?>"><?php echo $site_url, $basedir; ?>/</a> -webpage header is a search box, this is the <i>basic</i> 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. -</p> - -<h3>Advanced Search</h3> -<p> -Some explanations for most of the PHP bugs <a href="search.php">advanced search</a> -options. -</p> -<table cellpadding="2" cellspacing="0" border="1" bgcolor="#eeeeee"> - <tr class="headerbottom" align="left"> - <td><strong>Feature</strong></td> - <td><strong>Explanation</strong></td> - <td><strong>Possible reasons for use</strong></td> - </tr> - <tr valign="top"> - <td>Find bugs</td> - <td> - 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: - <ul> - <li><i>all</i> : (default) All search terms are required.</li> - <li><i>any</i> : One or more (any) of the search terms may be present.</li> - <li> - <i>raw</i> : Allows full use of MySQL's - <a href="https://dev.mysql.com/doc/en/fulltext-search.html">FULLTEXT</a> - boolean search operators. - </li> - </ul> - </td> - <td> - For <strong>any</strong>, 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 <strong>all</strong> makes sense if you require every term in your - results, as this can provide precise searching. The <strong>raw</strong> - 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. - </td> - </tr> - <tr valign="top"> - <td>Status</td> - <td> - Each bug has a status, this allows searching for a specific (or all) status type. - Here are a few explanations: - <ul> - <li> - <strong>Open</strong>: This also includes <i>assigned</i>, <i>analyzed</i>, - <i>critical</i>, and <i>verified</i> bugs. (default) - </li> - <li> - <strong>Feedback</strong>: Bugs requesting feedback. Typically a bug that - requests feedback will be marked as <i>No Feedback</i> if no feedback transpires - after 15 days. - </li> - <li><strong>Old feedback</strong>: Bugs that have been requesting feedback for over60 days.</li> - <li> - <strong>Fresh</strong> : Bugs commented on in the last 30 days that are not closed, - duplicates, or not-a-bug. Only developers and the original author can affect this - date as public comments do not. - </li> - <li> - <strong>Stale</strong>: Bugs last commented on at least 30 days ago that are not - closed, duplicates, or not-a-bug. Only developers and the original author can affect - this date as public comments do not count. - </li> - <li> - <strong>Suspended</strong>: Tickets which are waiting on some action - which is outside the scope of the PHP developers. - </li> - </li> - <strong>Wont fix</strong>: Tickets where PHP developers won't fix an issue - (even though it is acknowlegded as such), for reasons to be stated in the - closing comment. - </li> - <li><strong>All</strong>: All types, even not-a-bug.</li> - </ul> - </td> - <td>If you're only interested in critical bugs, or want to see which have been verified, or perhaps just those seeking feedback.</td> - </tr> - <tr valign="top"> - <td>Category</td> - <td> - 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 <i>feature request</i> or <i>any</i> status. - </td> - <td> </td> - </tr> - <tr valign="top"> - <td>OS</td> - <td> - 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: <i>'%$os%'</i>. - </td> - <td>Although not an accurate field, it may be of some use.</td> - </tr> - <tr valign="top"> - <td>Version</td> - <td> - 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: <i>'$version%'</i>. Defaults to both 4 and 5. - </td> - <td> - 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. - </td> - </tr> - <tr valign="top"> - <td>Assigned</td> - <td> - Some bugs get assigned to PHP developers, in which case you may specify by - entering in the PHP username of said developer. - </td> - <td>Example use is limiting the bugs assigned to yourself.</td> - </tr> - <tr valign="top"> - <td>Author email</td> - <td>Takes on an email address of the original author of a bug.</td> - <td>Looking for all bugs that a particular person initiated.</td> - </tr> - <tr valign="top"> - <td>Date</td> - <td> - 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. - </td> - <td> - Looking for recently reported bugs. For example, choosing <i>30 days ago</i> - will limit the search to all bugs reported in the last 30 days. - </td> - </tr> -</table> - -<h1>Bug System Statistics</h1> - -<p> -You can view a variety of statistics about the bugs that have been -reported on our <a href="stats.php">bug statistics page</a>. -</p> - -<?php response_footer(); +// Output template with given template variables. +echo $template->render('pages/search_how_to.php');