Capítulo 48_ Installation

By default on UNIX it should be in /usr/local/lib which is <install_path>/lib_ Most people will want to change this at compile_time with the __with_config_file_path flag_ You would, for example, set it with something like:

__with_config_file_path=/etc

And then you would copy php_ini_dist from the distribution to /etc/php_ini and edit it to make any local changes you want_

__with_config_file_scan_dir=PATH

On Windows the default path for the php_ini file is the Windows directory_ If you're using the Apache webserver, php_ini is first searched in the Apaches install directory, e_g_ c:\program files\apache group\apache_ This way you can have different php_ini files for different versions of Apache on the same machine_

See also the chapter about the configuration file_

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:

• Stop your httpd processes

• gdb httpd

• Stop your httpd processes

• > run _X _f /path/to/httpd_conf

• Then fetch the URL causing the problem with your browser

• > run _X _f /path/to/httpd_conf

• If you are getting a core dump, gdb should inform you of this now

• type: bt

• You should include your backtrace in your bug report_ This should be submitted to http://bugs_php_net/

If your script uses the regular expression functions (ereg() 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

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 httpd_conf file:

# 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

And add:

AddType application/x_httpd_php3 _php3 /* for PHP 3 */ AddType application/x_httpd_php _php /* for PHP 4 */

___ to the global properties, or to the properties of the VirtualDomain you want to have PHP support added to_

Due to the way PHP 3 built, it is not easy to build a complete flexible PHP RPM_ This issue is addressed in PHP 4_ For PHP 3, 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 3, read on___

The RPM packagers are setting up the RPMS to install without database support to simplify installations and 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_

This example will explain the process of adding support for the popular MySQL database server, using the mod installation for Apache_

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_

• First remove mod_php3 :

  rpm _e mod_php3

• Then get the source rpm and INSTALL it, NOT __rebuild

  rpm _Uvh mod_php3_3_0_5_2_src_rpm

• Then edit the /usr/src/redhat/SPECS/mod_php3_spec file

  In the %build section add the database support you want, and the path_

  For MySQL you would add

  __with_mysql=/usr \

  The %build section will look something like this:

  _/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

• Once this modification is made then build the binary rpm as follows:

  rpm _bb /usr/src/redhat/SPECS/mod_php3_spec

• Then install the rpm

  rpm _ivh /usr/src/redhat/RPMS/i386/mod_php3_3_0_5_2_i386_rpm

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_

Do a 'view source' in the web browser and you will probably find that you can see the source code of your PHP script_ This means that the web server did not send the script to PHP for interpretation_ Something is wrong with the server configuration _ double check the server configuration against the PHP installation instructions_

Something went wrong when the server tried to run PHP_ To get to see a sensible error message, from the command line, change to the directory containing the PHP executable (php_exe on Windows) and run php _i_ If PHP has any problems running, then a suitable error message will be displayed which will give you a clue as to what needs to be done next_ If you get a screen full of html codes (the output of the phpinfo() function) then PHP is working, and your problem may be related to your server configuration which you should double check_

This has actually nothing to do with PHP, but with the MySQL client libraries_ Some need __with_zlib, others do not_ This is also covered in the MySQL FAQ_

This error message means that PHP failed to output anything at all_ To get to see a sensible error message, from the command line, change to the directory containing the PHP executable (php_exe on Windows) and run php _i_ If PHP has any problems running, then a suitable error message will be displayed which will give you a clue as to what needs to be done next_ If you get a screen full of html codes (the output of the phpinfo() function) then PHP is working_

Once PHP is working at the command line, try accessing the script via the browser again_ If it still fails then it could be one of the following:

• File permissions on your PHP script, php_exe, php4ts_dll, php_ini or any PHP extensions you are trying to load are such that the anonymous internet user ISUR_<machinename> cannot access them_

• The script file does not exist (or possibly isn't where you think it is relative to your web root directory)_ Note that for IIS you can trap this error by ticking the 'check file exists' box when setting up the script mappings in the Internet Services Manager_ If a script file does not exist then the server will return a 404 error instead_ There is also the additional benefit that IIS will do any authentication required for you based on the NTLanMan permissions on your script file_

Make sure any user who needs to run a PHP script has the rights to run php_exe! IIS uses an anonymous user which is added at the time IIS is installed_ This user needs rights to php_exe_ Also, any authenticated user will also need rights to execute php_exe_ And for IIS4 you need to tell it that PHP is a script engine_ Also, you will want to read this faq_

You must set the cgi_force_redirect directive to 0_ It defaults to 1 so be sure the directive isn't commented out (with a ;)_ Like all directives, this is set in php_ini

Because the default is 1, it's critical that you're 100% sure that the correct php_ini file is being read_ Read this faq for details_

To be sure your php_ini is being read by PHP, make a call to phpinfo() and near the top will be a listing called Configuration File (php_ini)_ This will tell you where PHP is looking for php_ini and whether or not it's being read_ If just a directory PATH exists than it's not being read and you should put your php_ini in that directory_ If php_ini is included within the PATH than it is being read_

If php_ini is being read and you're running PHP as a module then be sure to restart PHP after making changes to php_ini