In this latest post to his site Christian Weiske shares three PHP manual viewers he finds useful (besides the actual PHP.net manual) and can be used offline.

The PHP documentation is really good. It covers almost all parts of the language and is filled with examples that help you grasp a function's meaning and usage really fast. And since PHP is a grown language, it's function naming and parameter order are often confusing - requiring you to look up the manual more often.

Chris Jones has a new post today showing you how to use Oracle and PHP together to process data offline via the Oracle Streams Advanced Queuing feature.

Offloading slow batch tasks to an external process is a common method of improving website responsiveness. One great way to initiate such background tasks in PHP is to use Oracle Streams Advanced Queuing in a producer-consumer message passing fashion. [...] The following example simulates an application user registration system where the PHP application queues each new user's street address. An external system monitoring the queue can then fetch and process that address. In real life the external system might initiate a snail-mail welcome letter, or do further, slower automated validation on the address.

He includes the SQL needed to create the database and configure the queue system as well as start it up and get it ready for requests. He shows how to push an address into the queue for processing and how to get the results once it has completed in both the SQL and from the oci_* functions in PHP.

Since you can't always be online when you need to install new libraries you'll need for your PHP work, Lorna Mitchell has posted a quick guide to downloading and installing PEAR packages when you're offline.

As with most tools that work really well, I know very little about PEAR. I mean, I use it all the time, and I love it for getting all the extensions installed that I need for the work I do. [...] However I'm now in a situation where I might need to install PEAR packages with a connection that may or may not be working, and I'm not sure exactly which packages I might need, so I wanted to know whether I could use PEAR as my packaging tool even when I wasn't able to reach the usual channels. And guess what? I can!

The install is a pretty simple two-step process - just download the package(s) you'll need for your development and point the PEAR installer (you'll need this installed first, obviously) at the archive file. It's smart enough to take care of the rest.

Jaisen Mathai has a helpful hint for those that do any offline work with PHP on their own development systems - how to mirror the PHP manual on a local web server.

In addition to [a local copy of your source] being faster to develop, it lets you work without needing to be connected to the Internet. But what about the tools you use while developing? If youâ€™re a PHP developer then the manual at php.net is an invaluable tool. It only make sense to have it available for when youâ€™re not online.

His example follows the official mirroring part of the PHP.net website and uses a slightly modified rsync command to fetch the manual information from the php.net site and drops it in a location locally. He throws in an Apache configuration too for a simple VirtualHost to get it up and running.

In this new post to his blog Sebastian Bergmann looks at how to use Bazaar (a dstributed version control system) in his development the PHPUnit tool.

Last December, when I was in Australia and started to work on the Object_Freezer code, I "dived into" Bazaar (bzr) and learned the value of local commits as they allow me to work offline, e.g. when disconnected during travel. Thanks to bzr-svn, I can now work offline for PHPUnit development as well.

He shares his setup - a local shared repository for branching/trunk work and a linked checkout of PHPUnit between Bazaar and Subversion. This allows him to commit locally with Bazaar and, when he gets back online, issue a "merge" command to make the push back out to Subversion's remote repository.

In the process of debugging one of his scripts, Brian Moon came across a default setting (and problem) in the MySQL extension that didn't seem to make much sense to him:

There are several reasons that PHP could not be able to connect to MySQL. [...] Or, perhaps the entire server is offline.

The mysql.connect_timeout setting in the php.ini is supposed to handle this sort of instance, but the default is set tpo 60 seconds. It's only apparently used when the server is completely offline and, in his opinion, is set way too high. He's proposing a patch to the MySQL extension to change this setting's default to shorten it to something a bit more reasonable.

In the process of debugging one of his scripts, Brian Moon came across a default setting (and problem) in the MySQL extension that didn't seem to make much sense to him:

There are several reasons that PHP could not be able to connect to MySQL. [...] Or, perhaps the entire server is offline.

The mysql.connect_timeout setting in the php.ini is supposed to handle this sort of instance, but the default is set tpo 60 seconds. It's only apparently used when the server is completely offline and, in his opinion, is set way too high. He's proposing a patch to the MySQL extension to change this setting's default to shorten it to something a bit more reasonable.