mirror of
https://github.com/sigmasternchen/php-doc-en
synced 2025-03-15 16:38:54 +00:00
The content of this file was moved to general.xml,
installation.xml and using.xml as the questions were ones that should be there, so this file is not needed anymore git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@59915 c90b9560-bf6c-de11-be94-00142212c4b1
This commit is contained in:
Gabor Hojtsy
parent
0bbc4cfc79
commit
3a4c28b464
1 changed files with 0 additions and 165 deletions
165
faq/common.xml
165
faq/common.xml
|
|
@ -1,165 +0,0 @@
|
|||
<?xml encoding="iso-8859-1"?>
|
||||
<!-- $Revision: 1.7 $ -->
|
||||
<chapter id="faq.common">
|
||||
<title>Common Problems</title>
|
||||
<titleabbrev>Common Problems</titleabbrev>
|
||||
|
||||
<para>
|
||||
Here is a bunch of common problems, met every
|
||||
day with PHP, and solved the easy way!
|
||||
</para>
|
||||
|
||||
<qandaset>
|
||||
<qandaentry id="faq.common.nodata">
|
||||
<question>
|
||||
<para>
|
||||
I installed PHP, but every time I load a document, I get the
|
||||
message 'Document Contains No Data'! What's going on here?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
This probably means that PHP is having some sort of problem
|
||||
and is core-dumping. Look in your server error log to see if
|
||||
this is the case, and then try to reproduce the problem with
|
||||
a small test case. If you know how to use 'gdb', it is very
|
||||
helpful when you can provide a backtrace with your bug report
|
||||
to help the developers pinpoint the problem. If you are using
|
||||
PHP as an Apache module try something like:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Stop your httpd processes
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
gdb httpd
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Stop your httpd processes
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
> run -X -f /path/to/httpd.conf
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Then fetch the URL causing the problem with your browser
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
> run -X -f /path/to/httpd.conf
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If you are getting a core dump, gdb should inform you of this now
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
type: bt
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
You should include your backtrace in your bug report. This should be submitted to
|
||||
<ulink url="&faqurl.php.bugs;">&faqurl.php.bugs;</ulink>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
<para>
|
||||
If your script uses the regular expression functions
|
||||
(<function>ereg</function> and friends), you should make sure
|
||||
that you compiled PHP and Apache with the same regular
|
||||
expression package. This should happen automatically with
|
||||
PHP and Apache 1.3.x
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.common.cgi-vars">
|
||||
<question>
|
||||
<para>
|
||||
I'm trying to access one of the standard CGI
|
||||
variables (such as $DOCUMENT_ROOT or $HTTP_REFERER) in a user-defined
|
||||
function, and it can't seem to find it. What's wrong?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
Environment variables are normal global variables, so you must
|
||||
either declare them as global variables in your function (by using
|
||||
"<literal>global $DOCUMENT_ROOT;</literal>", for example) or by using
|
||||
the global variable array (ie, "<literal>$GLOBALS["DOCUMENT_ROOT"]</literal>".
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.common.incompatible">
|
||||
<question>
|
||||
<para>
|
||||
I patched Apache with the FrontPage extensions patch, and suddenly PHP stopped
|
||||
working. Is PHP incompatible with the Apache FrontPage extensions?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
No, PHP works fine with the FrontPage extensions.
|
||||
The problem is that the FrontPage patch modifies several Apache structures,
|
||||
that PHP relies on.
|
||||
Recompiling PHP (using 'make clean ; make') after the FP patch is applied
|
||||
would solve the problem.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.common.bug">
|
||||
<question>
|
||||
<para>
|
||||
I think I found a bug! Who should I tell?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
You should go to the PHP Bug Database and make sure the bug
|
||||
isn't a known bug. If you don't see it in the database, use
|
||||
the reporting form to report the bug. It is important to use
|
||||
the bug database instead of just sending an email to one of the
|
||||
mailing lists because the bug will have a tracking number assigned
|
||||
and it will then be possible for you to go back later and check
|
||||
on the status of the bug. The bug database can be found at
|
||||
<ulink url="&faqurl.php.bugs;">&faqurl.php.bugs;</ulink>.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
</qandaset>
|
||||
</chapter>
|
||||
|
||||
<!-- Keep this comment at the end of the file
|
||||
Local variables:
|
||||
mode: sgml
|
||||
sgml-omittag:t
|
||||
sgml-shorttag:t
|
||||
sgml-minimize-attributes:nil
|
||||
sgml-always-quote-attributes:t
|
||||
sgml-indent-step:1
|
||||
sgml-indent-data:t
|
||||
sgml-parent-document:nil
|
||||
sgml-default-dtd-file:"../../manual.ced"
|
||||
sgml-exposed-tags:nil
|
||||
sgml-local-catalogs:nil
|
||||
sgml-local-ecat-files:nil
|
||||
End:
|
||||
vim600: syn=xml fen fdm=syntax fdl=2 si
|
||||
vim: et tw=78 syn=sgml
|
||||
vi: ts=1 sw=1
|
||||
-->
|
||||
Loading…
Reference in a new issue