Commit: 80d03e3e78f80fd90e4c231accaaa67bb9da37b6
Author: Peter Kokot <[email protected]> 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');
--
PHP Webmaster List Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
