This is a list of Frequently Asked Questions about PHP3 and
their answers. If you have suggestions or additions, send them to
php3@php.il.eu.org.
From the manual:
Professional Home Pages Version 3.0 is an HTML-embedded scripting language. Much of its syntax is borrowed from C, Java and Perl with a couple of unique PHP-specific features thrown in. The goal of the language is to allow web developers to write dynamically generated pages quickly.
For a complete list of the changes, read the CHANGES file included in the PHP3 distribution. Some highlights:
On Windows 95/NT machines, you can simply use the included ODBC support and the correct ODBC driver.
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 free version of the necessary libraries for Linux systems. For other Unix operating systems, you need to contact Sybase for the correct libraries (which cost money).
Yes. You already have all the tools you need if you are running entirely under Windows 95 or NT, where you can use ODBC and Microsoft's ODBC drivers for Microsoft Access databases. From other platforms, you would need to have a server running Windows NT (or possibly Windows 95) which you connected to using ODBC drivers from your other platform and OpenLink Software's ODBC Agent software, which runs US$4,000.
Some better alternatives are 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 PHP3 (using the built-in drivers), or to use an intermediary file format that Access and PHP3 both understand, such as flat-files or dBase databases.
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).
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 NOT give you an ability to open 'user sessions' on the same SQL link, they do NOT 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 ANY functionality that wasn't possible with their non-persistent brothers.
Why?
This has to do with the way the way Web servers work. We can divide PHP to three main types. First, PHP in its CGI mode. In CGI mode, there's no difference between persistent and non persistent connects. The reason is simple - a CGI binary terminates as soon as the execution of your script ends. Obviously, when it dies, any resource it may have 'owned', including any type of SQL link, dies with it (in practice PHP is nicer and properly closes the SQL link right before it dies, but even if it didn't, the link wouldn't have been reusable).
The second way of running PHP is as a plugin for a *multithreaded* server. Currently, this is only theoratical - Shane has a thread safe ISAPI module in the works, and NSAPI/Win32 will probably follow soon after the ISAPI one works right. Multithreaded servers are a bit different in what they enable developers to do, even though as far as I can tell right now, PHP's behavior would be identical to the one of *multiprocess* servers. See below.
The last, and most popular way of running PHP is as a plugin to the multiprocess server - apache. A quick guide to the way apache (usually) works - apache has one 'parent' process, that doesn't answer to requests. Its job is to coordinate between its children. The children, which are spawned by the parent, are the processes that answer to HTTP requests. The load of the requests is divided among all of the children. That is, two subsequent hits on the same page are likely to be handled by TWO DIFFERENT PROCESSES. This is the key issue here. There are plenty of processes that make the 'Web server', and the load is distributed among them.
What does that have to do with persistent connections? Everything. That explains why there's no added functionality in persistent connections. When you open a persistent connection, you can't do something like beginning a transaction, and hope that the next time the user submits a page you'd just continue the transaction. You can't lock tables and hope that the next hit by the user will unlock the tables. The two requests are most likely to be handled by two different processes!
If persistent connections don't have any added functionality, what are they good for?
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 connects help you. They simply connect only once for the entire lifespan of the httpd child, instead of once per hit that child processes. Make sure you understand - this means that for every child that opened a persistent connection will have its own open persistent connection to the server. That is, if you had 20 different httpd processes that ran a script that included a pconnect(), you'd have 20 different connections to the SQL server, one from each child.
An important summary. pconnects were designed to have 1::1 mapping to regular connects. That means that you should ALWAYS be able to replace persistent connect with a non-persistent connect, and it won't change the way the script behaves. It MAY and probably will change the efficiency of the script, but not its behavior!
Of course! To subscribe, send mail to
php3-subscribe@php.il.eu.org. You don't need to include
anything special in the subject or body of the message.
To unsubscribe, send mail to
php3-unsubscribe@php.il.eu.org.
If you have problems subscribing to or unsubscribing from the PHP3
mailng list, it may be because the mailing list software can't figure
out the correct mailing address to use. If your email address was
joeblow@example.com, you can send your subscription request
to php3-subscribe-joeblow=example.com@php.il.eu.org,
or your unsubscription request to
php3-unsubscribe-joeblow=example.com@php.il.eu.org.
Yes, it's located at http://www.tryc.on.ca/php3.html.
You can download PHP3 from any of the members of the PHP3 network of sites. These can be found at http://www.php.net/. You can also use anonymous CVS to get the absolute latest version of the source. For more information, go to http://www.lerdorf.on.ca/php3.cgi.
Note: Those marked with * are not thread-safe libraries, and should not be used with PHP3 as a server module in the multi-threaded Windows web servers (IIS, Netscape). This does not matter in Unix environments, yet.
You will need to follow instructions provided with the library. Some of these libraries are detected automatically when you run the 'configure' script of PHP3 (such as the GD library), and others you will have to enable using '--with-EXTENSION' options to 'configure'. Run 'configure --help' for a listing of these.
Yes, as long as you're looking for binaries for Windows 95 or NT. They're available in the same place as the source.
First, you will need Microsoft Visual C++ v5 (v4 may do it also, but we do it with v5), and you will need to download Bison and Flex. You will need to put Bison and Flex somewhere in your path, or add their location to your path. Then run the batch file 'makeparser' before compiling with MSVC. You also may need to edit some settings in the project settings. You should be familier enough with MSVC to know what to do ;).
To install PHP3, follow the instructions in the INSTALL file located in the distribution. Windows 95 and NT users should also read the README.WIN32 file.
autoconf in the top-level directory after getting
the sources from the CVS server. (Also, unless you run configure
with the --enable-maintainer-mode 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.
--with-apache=/path/to/apache'
and not '--with-apache=/path/to/apache/src'.
CFLAGS=-I/path/to/include LDFLAGS=-L/path/to/library ./configure
If you're using a csh-variant for your login shell (why?), it would be:
env CFLAGS=-I/path/to/include LDFLAGS=-L/path/to/library ./configure
cp *.o functions" and then
re-running 'make' to see if that helps. If it does, you should really
upgrade to a recent version of GNU make.
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 INSTALL file that comes with the distribution for more information.
Some people have also reported that they had to add '-ldl' immediately following 'libphp3.a' when linking with Apache.
This is actually quite easy. Follow these steps carefully:
If your script uses the regular expression functions (ereg()
and friends), you should make sure that you compiled PHP3 and
Apache with the same regular expression package. (This should
happen automatically with PHP3 and Apache 1.3.)
global $DOCUMENT_ROOT;", for example) or by using
the global variable array (ie, "$GLOBALS["DOCUMENT_ROOT"]".
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 as opposed to just sending an email to one of the mailing lists because by using the database the bug will get an id 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 http://ca.php.net/bugs.php3.
while
(condition); statement. This will cause PHP3 to spin out of
control because it is simply executing an empty body for your while
loop! Change the semi-colon to a colon and it should work correctly.
function printsum($a, $b) {
echo $a + $b;
}
You can also use old-style function declarations by use the 'old_function' designation, like so:
old_function printsum $a, $b (
echo $a + $b;
);
This FAQ was originally written by Jim Winstead. It is currently maintained by the PHP Development Team.
$Id$