mirror of
https://github.com/sigmasternchen/php-doc-en
synced 2025-03-15 16:38:54 +00:00
Initial Adding to faq
git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@51892 c90b9560-bf6c-de11-be94-00142212c4b1
This commit is contained in:
parent
eb7d3de0be
commit
5171bc1ea3
10 changed files with 1773 additions and 0 deletions
389
faq/build.xml
Executable file
389
faq/build.xml
Executable file
|
@ -0,0 +1,389 @@
|
|||
<chapter id="faq.build">
|
||||
<title> Build Problems</title>
|
||||
<titleabbrev>Common Problems occuring at build time</titleabbrev>
|
||||
|
||||
<para>
|
||||
This section gathers most common errors that occur at
|
||||
build time.
|
||||
</para>
|
||||
|
||||
<qandaset>
|
||||
<qandaentry id="faq.build.configure">
|
||||
<question>
|
||||
<para>
|
||||
I got the latest version of PHP using the anonymous CVS service,
|
||||
but there's no configure script!
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
You have to have the GNU autoconf package installed so you can
|
||||
generate the configure script from configure.in. Just run
|
||||
<command>./buildconf</command> in the top-level directory after getting
|
||||
the sources from the CVS server. (Also, unless you run configure
|
||||
with the <literal>--enable-maintainer-mode</literal> option, the
|
||||
configure script will not automatically get rebuilt when the
|
||||
configure.in file is updated, so you should make sure to do that
|
||||
manually when you notice configure.in has changed. One symptom
|
||||
of this is finding things like @VARIABLE@ in your Makefile after
|
||||
configure or config.status is run.)
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.build.configuring">
|
||||
<question>
|
||||
<para>
|
||||
I'm having problems configuring PHP to work with Apache.
|
||||
It says it can't find httpd.h, but it's right where I said it is!
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
You need to tell the configure/setup script the location of the
|
||||
top-level of your Apache source tree. This means that
|
||||
you want to specify '<literal>--with-apache=/path/to/apache</literal>'
|
||||
and <emphasis>not</emphasis> '<literal>--with-apache=/path/to/apache/src</literal>'.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.build.not_found">
|
||||
<question>
|
||||
<para>
|
||||
When I run configure, it says that it can't find the
|
||||
include files or library for GD, gdbm, or some other package!
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
You can make the configure script looks for header files and libraries
|
||||
in non-standard locations by specifying additional flags to pass to
|
||||
the C preprocessor and linker, such as:
|
||||
<programlisting>
|
||||
CPPFLAGS=-I/path/to/include LDFLAGS=-L/path/to/library ./configure
|
||||
</programlisting>
|
||||
If you're using a csh-variant for your login shell (why?), it would be:
|
||||
<programlisting>
|
||||
env CPPFLAGS=-I/path/to/include LDFLAGS=-L/path/to/library ./configure
|
||||
</programlisting>
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.build.yytname">
|
||||
<question>
|
||||
<para>
|
||||
When it is compiling the file language-parser.tab.c, it gives me errors
|
||||
that say 'yytname undeclared'.
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
You need to update your version of Bison. You can find the latest version
|
||||
at <ulink url="&faqurl.bison;">&faqurl.bison;</ulink>.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.build.link">
|
||||
<question>
|
||||
<para>
|
||||
When I run 'make', it seems to run fine but then fails when it tries
|
||||
to link the final application complaining that it can't find some files.
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
Some old versions of make that don't correctly put the compiled
|
||||
versions of the files in the functions directory into that same
|
||||
directory. Try running "<command>cp *.o functions</command>" and then
|
||||
re-running '<command>make</command>' to see if that helps. If it does, you should really
|
||||
upgrade to a recent version of GNU make.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.build.undefined">
|
||||
<question>
|
||||
<para>
|
||||
When linking PHP, it complains about a number of undefined references.
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
Take a look at the link line and make sure that all of the appropriate
|
||||
libraries are being included at the end. Common ones that you might have
|
||||
missed are '-ldl' and any libraries required for any database support
|
||||
you included.
|
||||
</para>
|
||||
<para>
|
||||
If you're linking with Apache 1.2.x, did you remember to add the
|
||||
appropriate information to the EXTRA_LIBS line of the Configuration
|
||||
file and re-rerun Apache's Configure script? See the
|
||||
<ulink url="&faqurl.file.installation;">INSTALL</ulink> file that
|
||||
comes with the distribution for more information.
|
||||
</para>
|
||||
<para>
|
||||
Some people have also reported that they had to add '-ldl' immediately
|
||||
following '<filename>libphp3.a</filename>' when linking with Apache.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.build.Apache">
|
||||
<question>
|
||||
<para>
|
||||
I can't figure out how to build PHP with Apache 1.3.
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
This is actually quite easy. Follow these steps carefully:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<simpara>
|
||||
Grab the latest Apache 1.3 distribution from
|
||||
<ulink url="&faqurl.apache;">&faqurl.apache;</ulink>.
|
||||
</simpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<simpara>
|
||||
Ungzip and untar it somewhere, for example
|
||||
<filename>/usr/local/src/apache-1.3</filename>.
|
||||
</simpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<simpara>
|
||||
Compile PHP by first running
|
||||
<command>./configure --with-apache=/<path>/apache-1.3</command>
|
||||
(substitute <path> for the actual path to your apache-1.3 directory.
|
||||
</simpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<simpara>
|
||||
Type '<literal>make</literal>' followed by '<literal>make install</literal>'
|
||||
to build PHP and copy the necessary files to the Apache distribution tree.
|
||||
</simpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<simpara>
|
||||
Change directories into to your <filename>/<path>/apache-1.3/src</filename>
|
||||
directory and edit the <filename>Configuration</filename> file.
|
||||
At the end of the file, add:
|
||||
<literal>AddModule modules/php3/libphp3.a</literal>.
|
||||
</simpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<simpara>
|
||||
Type: '<command>./Configure</command>' followed by '<literal>make</literal>'.
|
||||
</simpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<simpara>
|
||||
You should now have a PHP-enabled httpd binary!
|
||||
</simpara>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
<para>
|
||||
<emphasis>Note:</emphasis> : You can also use the new Apache
|
||||
<literal>./configure</literal> script. See the instructions in
|
||||
the <literal>README.configure</literal> file which is part of
|
||||
your Apache distribution. Also have a look at the <filename>INSTALL</filename>
|
||||
file in the PHP distribution.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.build.not_running">
|
||||
<question>
|
||||
<para>
|
||||
I have followed all the steps to install the Apache module version on
|
||||
UNIX, and my PHP scripts show up in my browser or I am being asked to
|
||||
save the file.
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
This means that the PHP module is not getting invoked for some reason.
|
||||
Three things to check before asking for further help:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<simpara>
|
||||
Make sure that the httpd binary you are running is the actual
|
||||
new httpd binary you just built. To do this, try running:
|
||||
<literal>/path/to/binary/httpd -l</literal>
|
||||
</simpara>
|
||||
<simpara>
|
||||
If you don't see <filename>mod_php3.c</filename> listed then you are
|
||||
not running the right binary. Find and install the correct binary.
|
||||
</simpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<simpara>
|
||||
Make sure you have added the correct Mime Type to one of your
|
||||
<literal>Apache .conf</literal> files. It should be:
|
||||
<literal>AddType application/x-httpd-php3 .php3</literal> (for PHP 3)
|
||||
</simpara>
|
||||
<simpara>
|
||||
or <literal>AddType application/x-httpd-php .php</literal> (for PHP 4)
|
||||
</simpara>
|
||||
<simpara>
|
||||
Also make sure that this AddType line is not hidden away inside a
|
||||
<Virtualhost> or <Directory> block which would
|
||||
prevent it from applying to the location of your test script.
|
||||
</simpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<simpara>
|
||||
Finally, the default location of the Apache configuration files
|
||||
changed between Apache 1.2 and Apache 1.3. You should check to
|
||||
make sure that the configuration file you are adding the AddType
|
||||
line to is actually being read. You can put an obvious syntax error
|
||||
into your httpd.conf file or some other obvious change that will
|
||||
tell you if the file is being read correctly.
|
||||
</simpara>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.build.activate_module">
|
||||
<question>
|
||||
<para>
|
||||
It says to use: <literal>--activate-module=src/modules/php4/libphp4.a</literal>,
|
||||
but that file doesn't exist, so I changed it to
|
||||
<literal>--activate-module=src/modules/php4/libmodphp4.a</literal> and it
|
||||
doesn't work!? What's going on?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
Well, you decided to try to outsmart the people who wrote those nice
|
||||
step-by-step instructions for you and you have now discovered that
|
||||
these people cannot be outsmarted. The libphp4.a file is not supposed to
|
||||
exist. The Apache build process will create it.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.build.ansi">
|
||||
<question>
|
||||
<para>
|
||||
When I try to build Apache with PHP as a static module using
|
||||
<literal>--activate-module=src/modules/php4/libphp4.a</literal>
|
||||
it tells me that my compiler is not ANSI compliant.
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
This is a misleading error message from Apache that has been fixed
|
||||
in more recent versions.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.build.apxs">
|
||||
<question>
|
||||
<para>
|
||||
When I try to build PHP using <literal>--with-apxs</literal>
|
||||
I get strange error messages.
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
There are three things to check here. First, for some reason
|
||||
when Apache builds the apxs Perl script, it sometimes ends up
|
||||
getting built without the proper compiler and flags variables.
|
||||
Edit your apxs (sometimes found in /usr/local/apache/bin/apxs
|
||||
or /usr/sbin/apxs) and check for these lines:
|
||||
<programlisting>
|
||||
my $CFG_CFLAGS_SHLIB = ' '; # substituted via Makefile.tmpl
|
||||
my $CFG_LD_SHLIB = ' '; # substituted via Makefile.tmpl
|
||||
my $CFG_LDFLAGS_SHLIB = ' '; # substituted via Makefile.tmpl
|
||||
</programlisting>
|
||||
If this is what you see, you have found your problem. Change these lines
|
||||
to say:
|
||||
<programlisting>
|
||||
my $CFG_CFLAGS_SHLIB = '-fpic -DSHARED_MODULE'; # substituted via Makefile.tmpl
|
||||
my $CFG_LD_SHLIB = 'gcc'; # substituted via Makefile.tmpl
|
||||
my $CFG_LDFLAGS_SHLIB = q(-shared);# substituted via Makefile.tmpl
|
||||
</programlisting>
|
||||
The second possible problem should only be an issue on RedHat-6.1/6.2.
|
||||
The apxs script RedHat ships is broken. Look for this line:
|
||||
<programlisting>
|
||||
my $CFG_LIBEXECDIR = 'modules'; # substituted via APACI install
|
||||
</programlisting>
|
||||
If you see the above line, change it to this:
|
||||
<programlisting>
|
||||
my $CFG_LIBEXECDIR = '/usr/lib/apache'; # substituted via APACI install
|
||||
</programlisting>
|
||||
Last, if you reconfigure/reinstall Apache, add a 'make clean'
|
||||
to the process after './configure' and before 'make'.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.build.microtime">
|
||||
<question>
|
||||
<para>
|
||||
During 'make', I get errors in microtime, and a lot of 'RUSAGE_' stuff.
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
During the 'make' portion of installation, if you encounter problems
|
||||
that look similar to this:
|
||||
<programlisting>
|
||||
microtime.c: In function `php_if_getrusage':
|
||||
microtime.c:94: storage size of `usg' isn't known
|
||||
microtime.c:97: `RUSAGE_SELF' undeclared (first use in this function)
|
||||
microtime.c:97: (Each undeclared identifier is reported only once
|
||||
microtime.c:97: for each function it appears in.)
|
||||
microtime.c:103: `RUSAGE_CHILDREN' undeclared (first use in this function)
|
||||
make[3]: *** [microtime.lo] Error 1
|
||||
make[3]: Leaving directory `/home/master/php-4.0.1/ext/standard'
|
||||
make[2]: *** [all-recursive] Error 1
|
||||
make[2]: Leaving directory `/home/master/php-4.0.1/ext/standard'
|
||||
make[1]: *** [all-recursive] Error 1
|
||||
make[1]: Leaving directory `/home/master/php-4.0.1/ext'
|
||||
make: *** [all-recursive] Error 1
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
Your system is broken. You need to fix your /usr/include files either
|
||||
by making sure your /usr/include/linux symlink is pointing to the
|
||||
right place in your kernel sources or by installing a glibc-devel
|
||||
package that matches your glibc. This has absolutely nothing
|
||||
to do with PHP. To prove this to yourself, try this simple test:
|
||||
<programlisting>
|
||||
$ cat >test.c <<X
|
||||
#include <sys/resource.h>
|
||||
X
|
||||
$ gcc -E test.c >/dev/null
|
||||
</programlisting>
|
||||
If that spews out errors, you know your include files are messed up.
|
||||
</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:
|
||||
-->
|
159
faq/common.xml
Executable file
159
faq/common.xml
Executable file
|
@ -0,0 +1,159 @@
|
|||
<chapter id="faq.common">
|
||||
<title>Migrating from PHP3 to PHP4</title>
|
||||
<titleabbrev>Migrating from PHP3 to PHP4</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 now 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:
|
||||
-->
|
306
faq/databases.xml
Executable file
306
faq/databases.xml
Executable file
|
@ -0,0 +1,306 @@
|
|||
<chapter id="faq.databases">
|
||||
<title>PHP mailing lists</title>
|
||||
<titleabbrev>PHP mailing lists</titleabbrev>
|
||||
|
||||
<para>
|
||||
This section holds common questions about relation between PHP and
|
||||
databases : Yes, PHP can acces virtually any database available today.
|
||||
</para>
|
||||
|
||||
<qandaset>
|
||||
<qandaentry id="faq.databases.mssql">
|
||||
<question>
|
||||
<para>
|
||||
I heard it's possible to access Microsoft SQL Server from PHP. How?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
On Windows 95/NT machines, you can simply use the included ODBC support
|
||||
and the correct ODBC driver.
|
||||
</para>
|
||||
<para>
|
||||
On Unix machines, you can use the Sybase-CT driver
|
||||
to access Microsoft SQL Servers because they are (at
|
||||
least mostly) protocol-compatible. Sybase has made a
|
||||
<ulink url="&faqurl.sybase;">free version of the necessary libraries for Linux systems</ulink>.
|
||||
For other Unix operating systems,
|
||||
you need to contact Sybase for the correct libraries. Also see
|
||||
the answer to the next question - 4.2.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.databases.access">
|
||||
<question>
|
||||
<para>Can I access Microsoft Access databases?</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
Yes. You already have all the tools you need if you are running
|
||||
entirely under Windows 95/98 or NT, where you can use ODBC and Microsoft's
|
||||
ODBC drivers for Microsoft Access databases.
|
||||
</para>
|
||||
<para>
|
||||
If you are running PHP on a Unix box and want to talk to MS-Access on
|
||||
a Windows box you will need Unix ODBC drivers.
|
||||
<ulink url="&faqurl.openlinksw;">OpenLink Software</ulink> has Unix-based
|
||||
ODBC drivers that can do this. There is a free pilot program where you
|
||||
can download an evaluation copy that doesn't expire and prices start at
|
||||
$675 for the commercial supported version.
|
||||
</para>
|
||||
<para>
|
||||
Another alternative is to use an SQL server that has
|
||||
Windows ODBC drivers and use that to store the data, which you can
|
||||
then access from Microsoft Access (using ODBC) and PHP (using the
|
||||
built-in drivers), or to use an intermediary file format that Access
|
||||
and PHP both understand, such as flat-files or dBase databases.
|
||||
On this point Tim Hayes from OpenLink software writes:
|
||||
<programlisting>
|
||||
Using another database as an intermediary is not a good idea, when you can
|
||||
use ODBC from PHP straight to your database - i.e. with OpenLink's drivers. If
|
||||
you do need to use an intermediary file format, OpenLink have now released
|
||||
Virtuoso (a virtual database engine) for NT, Linux and other unix platforms.
|
||||
Please visit our
|
||||
<ulink url="&faqurl.openlinksw;">website</ulink> for a free download.
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
One option that has proven successful is to use MySQL and its
|
||||
MyODBC drivers on Windows and synchronizing the databases. Steve Lawrence
|
||||
writes:
|
||||
</para>
|
||||
<para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<simpara>
|
||||
Install MySQL on your platform according to instructions with MySQL.
|
||||
Latest available from www.mysql.org (get it from your mirror!). No special
|
||||
configuration required except when you set up a database, and configure the
|
||||
user account, you should put % in the host field, or the host name of the
|
||||
Windows computer you wish to access MySQL with. Make a note of your server
|
||||
name, username, and password.
|
||||
</simpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<simpara>
|
||||
Download the MyODBC for Windows driver from the MySQL site. Latest
|
||||
release is myodbc-2_50_19-win95.zip (NT available too, as well as source
|
||||
code). Install it on your Windows machine. You can test the operation with
|
||||
the utilities included with this program.
|
||||
</simpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<simpara>
|
||||
Create a user or system dsn in your ODBC administrator, located in the
|
||||
control panel. Make up a dsn name, enter your hostname, user name, password,
|
||||
port, etc for you MySQL database configured in step 1.
|
||||
</simpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<simpara>
|
||||
Install Access with a full install, this makes sure you get the proper
|
||||
add-ins.. at the least you will need ODBC support and the linked table
|
||||
manager.
|
||||
</simpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<simpara>
|
||||
Now the fun part! Create a new access database. In the table window right
|
||||
click and select Link Tables, or under the file menu option, select Get
|
||||
External Data and then Link Tables. When the file browser box comes up,
|
||||
select files of type: ODBC. Select System dsn and the name of your dsn
|
||||
created in step 3. Select the table to link, press ok, and presto! you can
|
||||
now open the table and add/delete/edit data on your MySQL server! You can
|
||||
also build queries, import/export tables to MySQL, build forms and reports,
|
||||
etc.
|
||||
</simpara>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
<para>
|
||||
Tips and Tricks:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<simpara>
|
||||
You can construct your tables in access and export them to MySQL, then
|
||||
link them back in. That makes table creation quick.
|
||||
</simpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<simpara>
|
||||
When creating tables in access, you must have a primary key defined in
|
||||
order to have write access to the table in access. Make sure you create a
|
||||
primary key in MySQL before linking in access
|
||||
</simpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<simpara>
|
||||
If you change a table in MySQL, you have to re-link it in access. Go to
|
||||
tools>add-ins>linked table manager, cruise to your ODBC DSN, and select the
|
||||
table to re-link from there. you can also move your dsn source around there,
|
||||
just hit the always prompt for new location checkbox before pressing ok.
|
||||
</simpara>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.databases.persistent">
|
||||
<question>
|
||||
<para>I saw PHP offers persistent database connections. What does that mean?</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
Persistent connections are SQL links that do not close when the
|
||||
execution of your script ends. When a persistent connection is
|
||||
requested, PHP checks if there's already an identical persistent
|
||||
connection (that remained open from earlier) - and if it exists, it
|
||||
uses it. If it does not exist, it creates the link. An 'identical'
|
||||
connection is a connection that was opened to the same host, with
|
||||
the same username and the same password (where applicable).
|
||||
</para>
|
||||
<para>
|
||||
People who aren't thoroughly familiar with the way web servers
|
||||
work and distribute the load may mistake persistent connects for what
|
||||
they're not. In particular, they do <emphasis>not</emphasis> give you an ability
|
||||
to open 'user sessions' on the same SQL link, they do <emphasis>not</emphasis>
|
||||
give you an ability to build up a transaction efficently, and they
|
||||
don't do a whole lot of other things. In fact, to be extremely
|
||||
clear about the subject, persistent connections don't give you <emphasis>any</emphasis>
|
||||
functionality that wasn't possible with their non-persistent brothers.
|
||||
</para>
|
||||
<para>
|
||||
Why?
|
||||
</para>
|
||||
<para>
|
||||
This has to do with the way web servers work. There are three ways
|
||||
in which your web server can utilize PHP to generate web pages.
|
||||
</para>
|
||||
<para>
|
||||
The first method is to use PHP as a CGI "wrapper". When run this
|
||||
way, an instance of the PHP interpreter is created and destroyed for
|
||||
every page request (for a PHP page) to your web server. Because it
|
||||
is destroyed after every request, any resources that it acquires (such
|
||||
as a link to an SQL database server) are closed when it is destroyed.
|
||||
In this case, you do not gain anything from trying to use persistent
|
||||
connections -- they simply don't persist.
|
||||
</para>
|
||||
<para>
|
||||
The second, and most popular, method is to run PHP as a module
|
||||
in a multiprocess web server, which currently only includes
|
||||
Apache. A multiprocess server typically has one process (the parent)
|
||||
which coordinates a set of processes (its children) who actually do
|
||||
the work of serving up web pages. When each request comes in from a a
|
||||
client, it is handed off to one of the children that is not already
|
||||
serving another client. This means that when the same client makes
|
||||
a second request to the server, it may be serviced by a different
|
||||
child process than the first time. What a persistent connection does
|
||||
for you in this case it make it so each child process only needs
|
||||
to connect to your SQL server the first time that it serves a page
|
||||
that makes us of such a connection. When another page then requires
|
||||
a connection to the SQL server, it can reuse the connection that
|
||||
child established earlier.
|
||||
</para>
|
||||
<para>
|
||||
The last method is to use PHP as a plug-in for a multithreaded
|
||||
web server. Currently this is only theoretical -- PHP does not
|
||||
yet work as a plug-in for any multithreaded web servers. Work is
|
||||
progressing on support for ISAPI, WSAPI, and NSAPI (on Windows),
|
||||
which will all allow PHP to be used as a plug-in on multithreaded
|
||||
servers like Netscape FastTrack, Microsoft's Internet Information
|
||||
Server (IIS), and O'Reilly's WebSite Pro. When this happens, the
|
||||
behavior will be essentially the same as for the multiprocess model
|
||||
described before.
|
||||
</para>
|
||||
<para>
|
||||
If persistent connections don't have any added functionality,
|
||||
what are they good for?
|
||||
</para>
|
||||
<para>
|
||||
The answer here is extremely simple -- efficiency. Persistent
|
||||
connections are good if the overhead to create a link to your SQL
|
||||
server is high. Whether or not this overhead is really high depends
|
||||
on many factors. Like, what kind of database it is, whether or
|
||||
not it sits on the same computer on which your web server sits,
|
||||
how loaded the machine the SQL server sits on is and so forth.
|
||||
The bottom line is that if that connection overhead is high,
|
||||
persistent connections help you considerably. They cause the child
|
||||
process to simply connect only once for its entire lifespan, instead
|
||||
of every time it processes a page that requires connecting to the
|
||||
SQL server. This means that for every child that opened a persistent
|
||||
connection will have its own open persistent connection to the server.
|
||||
For example, if you had 20 different child processes that ran a script
|
||||
that made a persistent connection to your SQL server, you'd have 20
|
||||
different connections to the SQL server, one from each child.
|
||||
</para>
|
||||
<para>
|
||||
An important summary. Persistent connections were designed to
|
||||
have one-to-one mapping to regular connections. That means that you
|
||||
should <emphasis>always</emphasis> be able to replace persistent connections with
|
||||
non-persistent connections, and it won't change the way your script
|
||||
behaves. It <emphasis>may</emphasis> (and probably will) change the efficiency
|
||||
of the script, but not its behavior!
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.databases.upgraded">
|
||||
<question>
|
||||
<para>I upgraded to php4, and now mysql keeps telling me "Warning: MySQL: Unable to save result set in ...". What's up?</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
Most likely what has happened is, PHP4 was compiled with the '--with-mysql'
|
||||
option, without specifying the path to mysql. This means PHP is using its
|
||||
built-in mysql client library. If your system is running applications,
|
||||
such as php3 as a concurrent Apache module, or auth-mysql, that use other
|
||||
versions of mysql clients, then there is a conflict between the two
|
||||
differing versions of those clients.
|
||||
</para>
|
||||
<para>
|
||||
Recompiling php4, and adding the path to mysql to the flag,
|
||||
'<link linkend="install.configure.with-mysql">--with-mysql=/your/path/to/mysql</link>'
|
||||
usually solves the problem.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.databases.shared_mysql">
|
||||
<question>
|
||||
<para>
|
||||
After installing shared mysql support, Apache dumps core as soon
|
||||
as libphp4.so is loaded. Can this be fixed?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
If your MySQL libs are linked against pthreads this will happen. Check
|
||||
using ldd. If they are, grab the MySQL tarball and compile from source,
|
||||
or recompile from the source rpm and remove the switch in the spec file
|
||||
that turns on the threaded client code. Either of these suggestions will
|
||||
fix this. Then recompile PHP with the new mysql libs.
|
||||
</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:
|
||||
-->
|
||||
|
65
faq/html.xml
Executable file
65
faq/html.xml
Executable file
|
@ -0,0 +1,65 @@
|
|||
<chapter id="faq.html">
|
||||
<title>PHP and HTML</title>
|
||||
<titleabbrev>PHP and HTML</titleabbrev>
|
||||
|
||||
<para>
|
||||
PHP and HTML interact a lot : PHP generate HTML, and HTML
|
||||
has informations that will be sent to PHP.
|
||||
</para>
|
||||
|
||||
<qandaset>
|
||||
<qandaentry id="faq.html.arrays">
|
||||
<question>
|
||||
<para>How do I create arrays in a HTML <form>?</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
To get your <form> result sent as an array to your PHP script
|
||||
you name the <input>, <select> or <textarea>
|
||||
elements like this:
|
||||
<programlisting>
|
||||
<input name="MyArray[]">
|
||||
<input name="MyArray[]">
|
||||
<input name="MyArray[]">
|
||||
<input name="MyArray[]">
|
||||
</programlisting>
|
||||
Notice the square brackets after the variable name, that's what
|
||||
makes it an array. You can group the elements into different arrays
|
||||
by assigning the same name to different elements:
|
||||
<programlisting>
|
||||
<input name="MyArray[]">
|
||||
<input name="MyArray[]">
|
||||
<input name="MyOtherArray[]">
|
||||
<input name="MyOtherArray[]">
|
||||
</programlisting>
|
||||
This produces two arrays, MyArray and MyOtherArray, that gets sent
|
||||
to the PHP script.
|
||||
</para>
|
||||
<para>
|
||||
<emphasis>Note that you must not use indices with arrays in HTML!</emphasis>
|
||||
The array gets filled in the order the elements appear in the form. For
|
||||
functions you can use to process these arrays once you get them into
|
||||
your scripts, please see the Arrays section in the manual.
|
||||
</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:
|
||||
-->
|
208
faq/installation.xml
Executable file
208
faq/installation.xml
Executable file
|
@ -0,0 +1,208 @@
|
|||
<chapter id="faq.installation">
|
||||
<title>PHP installation</title>
|
||||
<titleabbrev>How to install PHP on your machine</titleabbrev>
|
||||
|
||||
<para>
|
||||
This section holds common questions about the way to install
|
||||
PHP. PHP is available for almost any OS (except may be for
|
||||
MacOS before OSX), and almost any web server.
|
||||
</para>
|
||||
<para>
|
||||
To install PHP, follow the instructions in the
|
||||
<ulink url="&faqurl.file.installation;">INSTALLATION</ulink>
|
||||
file located in the distribution. Windows 95 and NT users should also read the
|
||||
<ulink url="&faqurl.file.readmewin;">README.WIN32</ulink>
|
||||
file. There are also some helpful hints for Windows users
|
||||
<ulink url="&faqurl.php.manual.config.nt;">here</ulink>.
|
||||
</para>
|
||||
<para>
|
||||
If you are trying to install PHP for use with Netscape's web server on
|
||||
Unix see: <ulink url="faqurl.install">&faqurl.install;</ulink>
|
||||
</para>
|
||||
|
||||
<qandaset>
|
||||
<qandaentry id="faq.installation.php3ini">
|
||||
<question>
|
||||
<para>
|
||||
Where should my php3.ini file be located?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
By default on UNIX it should be in <filename>/usr/local/lib</filename>.
|
||||
Most people will want to change this at compile-time with the
|
||||
<link linkend="install.configure.with-config-file-path">--with-config-file-path</link>
|
||||
flag. You would, for example, set it to something like:
|
||||
<programlisting>
|
||||
--with-config-file-path=/etc
|
||||
</programlisting>
|
||||
And then you would copy <filename>php3.ini-dist</filename> from
|
||||
the distribution to <filename>/etc/php3.ini</filename> and
|
||||
edit it to make any local changes you want.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.installation.processing">
|
||||
<question>
|
||||
<para>
|
||||
I installed PHP using RPMS, but Apache isn't processing the
|
||||
PHP pages! What's going on here?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
Assuming you installed both Apache and PHP from RPM packages,
|
||||
you need to uncomment or add some or all of the following lines
|
||||
in your http.conf file:
|
||||
<programlisting>
|
||||
# Extra Modules
|
||||
AddModule mod_php.c
|
||||
AddModule mod_php3.c
|
||||
AddModule mod_perl.c
|
||||
|
||||
# Extra Modules
|
||||
LoadModule php_module modules/mod_php.so
|
||||
LoadModule php3_module modules/libphp3.so /* for PHP 3 */
|
||||
LoadModule php4_module modules/libphp4.so /* for PHP 4 */
|
||||
LoadModule perl_module modules/libperl.so
|
||||
</programlisting>
|
||||
And add:
|
||||
<programlisting>
|
||||
AddType application/x-httpd-php3 .php3 /* for PHP 3 */
|
||||
AddType application/x-httpd-php .php /* for PHP 4 */
|
||||
</programlisting>
|
||||
... to the global properties, or to the properties of the
|
||||
VirtualDomain you want to have PHP support added to.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.installation.compile">
|
||||
<question>
|
||||
<para>
|
||||
I installed PHP using RPMS, but it doesn't compile with the database
|
||||
support I need! What's going on here?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
Due to the way PHP is currently built, it is not easy to build a
|
||||
complete flexible PHP RPM. This issue will be addressed in PHP 4.
|
||||
For PHP, we currently suggest you use the mechanism described in the
|
||||
INSTALL.REDHAT file in the PHP distribution. If you insist on using
|
||||
an RPM version of PHP, read on...
|
||||
</para>
|
||||
<para>
|
||||
Currently the RPM packagers are setting up the RPMS to install
|
||||
without database support to simplify installations <emphasis>and</emphasis>
|
||||
because RPMS use /usr/ instead of the standard /usr/local/ directory for
|
||||
files. You need to tell the RPM spec file which databases to support
|
||||
and the location of the top-level of your database server.
|
||||
</para>
|
||||
<para>
|
||||
This example will explain the process of adding support for the
|
||||
popular MySQL database server, using the mod installation for Apache.
|
||||
</para>
|
||||
<para>
|
||||
Of course all of this information can be adjusted for any database
|
||||
server that PHP supports. We will assume you installed MySQL and Apache
|
||||
completely with RPMS for this example as well.
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
First remove mod_php3 :
|
||||
<programlisting>
|
||||
rpm -e mod_php3
|
||||
</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Then get the source rpm and INSTALL it, NOT --rebuild
|
||||
<programlisting>
|
||||
rpm -Uvh mod_php3-3.0.5-2.src.rpm
|
||||
</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Then edit the <filename>/usr/src/redhat/SPECS/mod_php3.spec</filename> file
|
||||
</para>
|
||||
<para>
|
||||
In the %build section add the database support you want, and the path.
|
||||
</para>
|
||||
<para>
|
||||
For MySQL you would add
|
||||
<programlisting>
|
||||
--with-mysql=/usr \
|
||||
</programlisting>
|
||||
The %build section will look something like this:
|
||||
<programlisting>
|
||||
./configure --prefix=/usr \
|
||||
--with-apxs=/usr/sbin/apxs \
|
||||
--with-config-file-path=/usr/lib \
|
||||
--enable-debug=no \
|
||||
--enable-safe-mode \
|
||||
--with-exec-dir=/usr/bin \
|
||||
--with-mysql=/usr \
|
||||
--with-system-regex
|
||||
</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Once this modification is made then build the binary rpm as follows:
|
||||
<programlisting>
|
||||
rpm -bb /usr/src/redhat/SPECS/mod_php3.spec
|
||||
</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Then install the rpm
|
||||
<programlisting>
|
||||
rpm -ivh /usr/src/redhat/RPMS/i386/mod_php3-3.0.5-2.i386.rpm
|
||||
</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
Make sure you restart Apache, and you now have PHP with MySQL support
|
||||
using RPM's. Note that it is probably much easier to just build
|
||||
from the distribution tarball of PHP and follow the instructions in
|
||||
<filename>INSTALL.REDHAT</filename> found in that distribution.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.installation.libraries">
|
||||
<question>
|
||||
<para>
|
||||
How do I get these libraries to work?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
</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:
|
||||
-->
|
||||
|
116
faq/languages.xml
Executable file
116
faq/languages.xml
Executable file
|
@ -0,0 +1,116 @@
|
|||
<chapter id="faq.languages">
|
||||
<title>PHP and HTML</title>
|
||||
<titleabbrev>PHP and HTML</titleabbrev>
|
||||
|
||||
<para>
|
||||
PHP is the best language for Webbing, but what about
|
||||
other languages?
|
||||
</para>
|
||||
|
||||
<qandaset>
|
||||
<qandaentry id="faq.languages.asp">
|
||||
<question>
|
||||
<para>PHP vs. ASP?</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
ASP is not really a language in itself, it's an acronym for Active
|
||||
Server Pages, the actual language used to program ASP with is a
|
||||
script version of Visual Basic. The biggest drawback of ASP is that
|
||||
it's a proprietary system that is natively used only on Microsoft
|
||||
Internet Information Server (IIS). This limits it's availability to
|
||||
Win32 based servers. There are a couple of projects in the works
|
||||
that allows ASP to run in other environments and webservers;
|
||||
<ulink url="&faqurl.instantasp;">InstantASP</ulink>
|
||||
from <ulink url="&faqurl.halcyon;">Halcyon</ulink> (commercial),
|
||||
<ulink url="&faqurl.chilisoft.asp;">Chili!Soft ASP</ulink> from
|
||||
<ulink url="&faqurl.chilisoft;">Chili!Soft</ulink>
|
||||
(commercial) and <ulink url="&faqurl.openasp;">OpenASP from ActiveScripting.org</ulink>
|
||||
(free). ASP is said to be a slower
|
||||
and more cumbersome language than PHP, less stable as well. Some of
|
||||
the pros of ASP is that since it uses VBScript it's relatively easy
|
||||
to pick up the language if you're already know how to program in
|
||||
Visual Basic. ASP support is also enabled by default in the IIS
|
||||
server making it easy to get up and running.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.languages.aspconverter">
|
||||
<question>
|
||||
<para>Is there an ASP to PHP converter?</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
Yes, <ulink url="&faqurl.asp2php;">asp2php</ulink> is the one most often
|
||||
referred to.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.languages.coldfusion">
|
||||
<question>
|
||||
<para>PHP vs. Cold Fusion?</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
PHP is commonly said to be faster and more efficient for complex
|
||||
programming tasks and trying out new ideas. PHP is generally referred
|
||||
to as more stable and less resource intensive as well. Cold Fusion
|
||||
has better error handling, database abstraction and date parsing
|
||||
although database abstraction is being addressed in PHP 4. Another
|
||||
thing that is listed as one of Cold Fusion's strengths is its excellent
|
||||
search engine, but it has been mentioned that a search engine is not
|
||||
something that should be included in a web scripting language. PHP
|
||||
runs on almost every platform there is; Cold Fusion is only available
|
||||
on Win32, Solaris, Linux and HP/UX. Cold Fusion has a better IDE
|
||||
and is generally easier to get started with, whereas PHP initially
|
||||
requires more programming knowledge.
|
||||
</para>
|
||||
<para>
|
||||
A great summary by Michael J Sheldon on this topic has
|
||||
been posted to the PHP mailing list. A copy can be found
|
||||
<ulink url="&faqurl.coldfusion.summary">here</ulink>.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.languages.perl">
|
||||
<question>
|
||||
<para>PHP vs. Perl?</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
The biggest advantage of PHP over Perl is that PHP was designed for
|
||||
scripting for the web where Perl was designed to do a lot more and can
|
||||
because of this get very complicated. The flexibility / complexity
|
||||
of Perl makes it easier to write code that another author / coder
|
||||
has a hard time reading. PHP has a less confusing and stricter format
|
||||
without losing flexibility. PHP is easier to integrate into existing
|
||||
HTML than Perl. PHP has pretty much all the 'good' functionality of
|
||||
Perl; constructs, syntax and so on, without making it as complicated
|
||||
as Perl can be. Perl is a very tried and true language, it's been
|
||||
around since the late eighties, but PHP is maturing very quickly.
|
||||
</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:
|
||||
-->
|
44
faq/migration.xml
Executable file
44
faq/migration.xml
Executable file
|
@ -0,0 +1,44 @@
|
|||
<chapter id="faq.migration">
|
||||
<title>PHP and HTML</title>
|
||||
<titleabbrev>PHP and HTML</titleabbrev>
|
||||
|
||||
<para>
|
||||
PHP has already a long history behind him :
|
||||
Legendary PHP 1.0, PHP/FI, PHP 3.0 and PHP/Zend 4.0.
|
||||
</para>
|
||||
|
||||
<qandaset>
|
||||
<qandaentry id="faq.migrating.phpfi">
|
||||
<question>
|
||||
<para>
|
||||
Migrating from PHP2 to PHP3?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
PHP/FI 2.0 is no longer supported. Please see
|
||||
<link linkend="migration">the manual</link> for
|
||||
information about migration from PHP/FI 2.0.
|
||||
</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:
|
||||
-->
|
60
faq/migration4.xml
Executable file
60
faq/migration4.xml
Executable file
|
@ -0,0 +1,60 @@
|
|||
<chapter id="faq.migration4">
|
||||
<title>Migrating from PHP3 to PHP4</title>
|
||||
<titleabbrev>Migrating from PHP3 to PHP4</titleabbrev>
|
||||
|
||||
<para>
|
||||
PHP has already a long history behind him :
|
||||
Legendary PHP 1.0, PHP/FI, PHP 3.0 and PHP/Zend 4.0.
|
||||
</para>
|
||||
|
||||
<qandaset>
|
||||
<qandaentry id="faq.migration4.php34">
|
||||
<question>
|
||||
<para>
|
||||
Migrating from PHP3 to PHP4
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
PHP 4 was designed to be as compatible with earlier versions of
|
||||
PHP as possible and very little functionality was broken in the
|
||||
process. If you're really unsure about compatibility you should
|
||||
install PHP 4 in a test environment and run your scripts there.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.migration4.incompatible">
|
||||
<question>
|
||||
<para>
|
||||
Incompatibles functions?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
Since PHP 4 is basically a rewrite of the entire PHP engine there
|
||||
was very few functions that were altered and only then some of
|
||||
the more exotic ones.
|
||||
</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:
|
||||
-->
|
51
faq/misc.xml
Executable file
51
faq/misc.xml
Executable file
|
@ -0,0 +1,51 @@
|
|||
<chapter id="faq.misc">
|
||||
<title>PHP and HTML</title>
|
||||
<titleabbrev>PHP and HTML</titleabbrev>
|
||||
|
||||
<para>
|
||||
PHP and HTML interact a lot : PHP generate HTML, and HTML
|
||||
has informations that will be sent to PHP.
|
||||
</para>
|
||||
|
||||
<qandaset>
|
||||
<qandaentry id="faq.misc.popup">
|
||||
<question>
|
||||
<para>
|
||||
Where did the pop-ups go on the website?
|
||||
Can I have the code for that?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
The yellow pop-up windows on the old site were pretty cool, but
|
||||
were very difficult to maintain (since some companies seem to
|
||||
enjoy changing the way their browsers work with every new release).
|
||||
</para>
|
||||
<para>
|
||||
All the code for previous versions of the website is still available
|
||||
through CVS. Specifically, the last version of shared.inc (that had
|
||||
all the Javascript and DHTML to do the popups) is available
|
||||
<ulink url="&faqurl.popup;">here</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:
|
||||
-->
|
375
faq/using.xml
Executable file
375
faq/using.xml
Executable file
|
@ -0,0 +1,375 @@
|
|||
<chapter id="faq.using">
|
||||
<title> Build Problems</title>
|
||||
<titleabbrev>Common Problems occuring at build time</titleabbrev>
|
||||
|
||||
<para>
|
||||
This section gathers most common errors that occur at
|
||||
build time.
|
||||
</para>
|
||||
|
||||
<qandaset>
|
||||
<qandaentry id="faq.using.anyform">
|
||||
<question>
|
||||
<para>
|
||||
I would like to write a generic PHP script that can handle data coming
|
||||
from any form. How do I know which POST method variables are available?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
Make sure that the track_vars feature is
|
||||
enabled in your php3.ini file. If you compiled PHP with
|
||||
"--enable-track-vars" it will be on by default.
|
||||
Alternatively you can enable it at run-time on a per-script
|
||||
basis by putting <?php_track_vars?> at the top of your file.
|
||||
When track_vars is on, it creates three associative arrays.
|
||||
$HTTP_GET_VARS, $HTTP_POST_VARS and $HTTP_COOKIE_VARS. So, to
|
||||
write a generic script to handle POST method variables you would
|
||||
need something similar to the following:
|
||||
<programlisting>
|
||||
while (list($var, $value) = each($HTTP_POST_VARS)) {
|
||||
echo "$var = $value<br>\n";
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.using.singlequotes">
|
||||
<question>
|
||||
<para>
|
||||
I need to convert all single-quotes (') to a backslash
|
||||
followed by a single-quote. How can I do this with a
|
||||
regular expression?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
First off, take a look at the <function>addslashes()</function>
|
||||
function. It will do exactly what you want. You should also have
|
||||
a look at the <link linkend="ini.magic-quotes-gpc">magic_quotes_gpc</link>
|
||||
directive in your <filename>php.ini</filename> file.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.using.wrong_order">
|
||||
<question>
|
||||
<para>
|
||||
When I do the following, the output is printed in
|
||||
the wrong order:
|
||||
<programlisting>
|
||||
function myfunc($argument) {
|
||||
echo $argument + 10;
|
||||
}
|
||||
$variable = 10;
|
||||
echo "myfunc($variable) = " . myfunc($variable);
|
||||
</programlisting>
|
||||
what's going on?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
To be able to use the results of your function in an expression (such
|
||||
as concatenating it with other strings in the example above), you need
|
||||
to <emphasis>return</emphasis> the value, not <function>echo</function>
|
||||
it.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.using.newlines">
|
||||
<question>
|
||||
<para>
|
||||
Hey, what happened to my newlines?
|
||||
<programlisting>
|
||||
<PRE>
|
||||
1 <?echo $result[1];?>
|
||||
2 <?echo $result[2];?>
|
||||
</programlisting>
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
In PHP, the ending for a block of code is either "?>" or
|
||||
"?>\n" (where \n means a newline). This means that you need to
|
||||
insert an extra newline after each block of PHP code in the above
|
||||
example.
|
||||
</para>
|
||||
<para>
|
||||
Why does PHP do this? Because when formatting normal HTML, this
|
||||
usually makes your life easier because you don't want that newline,
|
||||
but you'd have to create extremely long lines or otherwise make the
|
||||
raw page source unreadable to achieve that effect.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.using.header">
|
||||
<question>
|
||||
<para>
|
||||
I need to access information in the request header directly.
|
||||
How can I do this?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
The <function>getallheaders</function> function will do this if
|
||||
you are running PHP as a module. So, the following bit of code
|
||||
will show you all the request headers:
|
||||
<programlisting>
|
||||
$headers = getallheaders();
|
||||
for(reset($headers); $key = key($headers); next($headers)) {
|
||||
echo "headers[$key] = ".$headers[$key]."<br>\n";
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.using.authentication">
|
||||
<question>
|
||||
<para>
|
||||
When I try to use authentication with IIS I get 'No Input file specified'.
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
The security model of IIS is at fault here. This is a problem
|
||||
common to all CGI programs running under IIS. A workaround is
|
||||
to create a plain HTML file (not parsed by php) as the entry page
|
||||
into an authenticated directory. Then use a META tag to redirect
|
||||
to the PHP page, or have a link to the PHP page. PHP will
|
||||
then recognize the authentication correctly. When the ISAPI
|
||||
module is ready, this will no longer be a problem. This should
|
||||
not effect other NT web servers. For more information, see:
|
||||
<ulink url="&faqurl.iis;">&faqurl.iis;</ulink>.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.using.PHP-IIS">
|
||||
<question>
|
||||
<para>
|
||||
I've followed all the instructions, but still can't
|
||||
get PHP and IIS to work together!
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
Make sure any user who needs to run a PHP script has the rights
|
||||
to run <filename>php.exe</filename>! IIS uses an anonymous user which is added at the
|
||||
time IIS is installed. This user needs rights to <filename>php.exe</filename>.
|
||||
Also, any authenticated user will also need rights to execute
|
||||
<filename>php.exe</filename>. And for IIS4 you need to tell it
|
||||
that PHP is a script engine.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.using.netscape">
|
||||
<question>
|
||||
<para>
|
||||
My PHP script works on IE and Lynx, but on Netscape some of
|
||||
my output is missing. When I do a "View Source" I see the
|
||||
content in IE but not in Netscape.
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
Very good question! ;) This is a tricky little issue and it has come up
|
||||
twice in the past month as of this writing. Both times I ended up
|
||||
spending a good 20 minutes trying to figure out what the heck was going
|
||||
on. The answer is that both IE and Lynx ignore any NULs
|
||||
(<literal>\0</literal>) in the HTML stream. Netscape does not.
|
||||
The best way to check for this is to compile the command-line version
|
||||
of PHP (also known as the CGI version) and run your script from the
|
||||
command line and pipe it through 'od -c' and look for any
|
||||
<literal>\0</literal> characters. (If you are on Windows you need to
|
||||
find an editor or some other program that lets you look at binary files)
|
||||
When Netscape sees a NUL in a file it will typically not output
|
||||
anything else on that line whereas both IE and Lynx will. If this
|
||||
issue has bitten you, congratulations! You are not alone.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.using.mixml">
|
||||
<question>
|
||||
<para>
|
||||
How am I supposed to mix XML and PHP? It complains
|
||||
about my <?xml> tags!
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
You need to turn off the short tags by setting short_tags to 0 in your
|
||||
<filename>php.ini</filename> file, or by using the php3_short_tags Apache
|
||||
directive. (You could even use a <File> section to do this
|
||||
selectively.) You can also disable and re-enable the short tags
|
||||
in your script using the short_tags() function.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.using.editor">
|
||||
<question>
|
||||
<para>
|
||||
How can I use PHP with FrontPage or Dreamweaver or some
|
||||
other HTML editor that insists on moving my code around?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
One of the easiest things to do is to enable using ASP tags in your
|
||||
PHP code. This allows you to use the ASP-style <% and %> code
|
||||
delimiters. Most of the popular HTML editors handle those more
|
||||
intelligently (for now). To enable the ASP-style tags, you need
|
||||
to set the asp_tags <filename>php.ini</filename> variable, or use the
|
||||
<link linkend="ini.asp-tags">asp_tags</link> Apache directive.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.using.variables">
|
||||
<question>
|
||||
<para>
|
||||
Where can I find a complete list of pre-set variables available
|
||||
to me, and why are these not documented in the PHP documentation?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
The best way is to stick a <?phpinfo()?> tag on a page and
|
||||
load it up. This will show you all sorts of information about your
|
||||
PHP setup, including a list of both environment variables and also
|
||||
special variables set by your web server. This list can't really be
|
||||
documented in the PHP documentation because it will change from one
|
||||
server to another.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.using.mysql">
|
||||
<question>
|
||||
<para>
|
||||
Why do I get an error that looks something like this:
|
||||
"Warning: 0 is not a MySQL result index in <file>
|
||||
on line <x>" or "Warning: Supplied argument is not
|
||||
a valid MySQL result resource in <file> on line <x>?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
You are trying to use a result identifier that is 0. The 0 indicates
|
||||
that your query failed for some reason. You need to check for errors
|
||||
after submitting a query and before you attempt to use the returned
|
||||
result identifier. The proper way to do this is with code similar
|
||||
to the following:
|
||||
<programlisting>
|
||||
$result = mysql_query("select * from tables_priv");
|
||||
if(!$result) {
|
||||
echo mysql_error();
|
||||
exit;
|
||||
}
|
||||
</programlisting>
|
||||
or
|
||||
<programlisting>
|
||||
$result = mysql_query("select * from tables_priv")
|
||||
or die("Bad query: ".mysql_error());
|
||||
</programlisting>
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.using.form-image">
|
||||
<question>
|
||||
<para>
|
||||
I'm trying to use an <input type="image"> tag, but
|
||||
the $foo.x and $foo.y variables aren't available.
|
||||
Where are they?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
When submitting a form, it is possible to use an image instead of
|
||||
the standard submit button with a tag like:
|
||||
<programlisting>
|
||||
<input type="image" SRC="image.gif" NAME="foo">
|
||||
</programlisting>
|
||||
When the user clicks somewhere on the image, the accompanying form
|
||||
will be transmitted to the server with two additional variables:
|
||||
foo.x and foo.y.
|
||||
</para>
|
||||
<para>
|
||||
Because $foo.x and $foo.y are invalid variable names in PHP, they are
|
||||
automagically converted to $foo_x and $foo_y. That is, the periods
|
||||
are replaced with underscores.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry id="faq.using.select-multiple">
|
||||
<question>
|
||||
<para>
|
||||
How do I get all the results from a SELECT MULTIPLE HTML tag?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
The SELECT MULTIPLE tag in an HTML construct allows users to select multiple
|
||||
items from a list. These items are then passed to the action handler for the
|
||||
form. The problem is that they are all passed with the same widget name. ie.
|
||||
<programlisting>
|
||||
<SELECT NAME="var" MULTIPLE>
|
||||
</programlisting>
|
||||
Each selected option will arrive at the action handler as:
|
||||
<programlisting>
|
||||
var=option1
|
||||
var=option2
|
||||
var=option3
|
||||
</programlisting>
|
||||
Each option will overwrite the contents of the previous $var variable. The
|
||||
solution is to use PHP's
|
||||
non-indexed array feature. The following should be used:
|
||||
<programlisting>
|
||||
<SELECT NAME="var[]" MULTIPLE>
|
||||
</programlisting>
|
||||
This tells PHP to treat <varname>var</varname> as an array and each assignment of a
|
||||
value to var[] adds an item to the array. The first item becomes
|
||||
<varname>$var[0]</varname>, the next <varname>$var[0]</varname>, etc.
|
||||
The <function>count</function> function can be used to determine how
|
||||
many options were selected, and the <function>sort</function> function can be
|
||||
used to sort the option array if necessary.
|
||||
</para>
|
||||
<para>
|
||||
Note that if you are using JavaScript the <literal>[]</literal> on the element name
|
||||
might cause you problems when you try to refer to the element by name.
|
||||
Use it's numerical form element id instead, or enclose the
|
||||
variable name in single quotes and use that as the index to the
|
||||
elements array, for example:
|
||||
<programlisting>
|
||||
variable = documents.forms[0].elements['var[]'];
|
||||
</programlisting>
|
||||
</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:
|
||||
-->
|
Loading…
Reference in a new issue