On the Working Software blog there's a new post showing a solution to a issue with escaping quotes in XPath queries that's not just an issue in PHP.

I've been working with the Basecamp API to plugin our IRC bot that we use for time tracking and I'm astounded to learn that escaping single and/or double quotes for XPath queries in PHP does not have a well documented, best practices solution. In fact, it seems as though this is not peculiar to PHP. I took a look around and found this excellent article by "Kushal": http://kushalm.com/the-perils-of-xpath-expressions-specifically-escaping-quotes.

He's put together his own (PHP) solution to the problem - running the entire XPath query through a filtering method that splits it up, replaces the quote characters and combines it back down to a single string.

On the Lullabot.com blog there's a recent post from Nate Haug showing how you can set up a single sign on with Drupal even if your user crosses multiple sub-domains on your site. The technique is particularly handy in that it doesn't require any extra modules to be installed to make it work.

With the multitude of single sign-on modules out there for Drupal, it's easy to miss the fact that Drupal has a built-in single sign on mechanism already. No modules, no configuration, just 20 easy lines of PHP in your site's settings.php file. This solution works for a lot of clients, but the set of requirements is pretty specific as to when you can use this approach.

To make it work all sites must be on the same domain (just sub-domains of it), be using MySQL as your backend database and, if you're using clustered hardware, they need to be on the same cluster to be able to make the cross-database queries. Since Drupal can prefix tables so the settings for each site are split out, you can create a "shared table" by making a few changes in your master and slave configuration.

Arnold Daniels has a new post to his blog today dealing with something (usually companies) are looking towards to help deal with the infamous "too many passwords for too many places" issue - a simple single sign-on tool that can be dropped in an used anywhere.

Associated websites often share user information, so a visitor only has to register once and can use that username and password for all sites. A good example for this is Google. [...] There are many single sign-on applications and protocols. Most of these are fairly complex. [...] I've written a simple single sign-on solution (400 lines of code), which works by linking sessions. This solutions works for normal websites as well as AJAX sites.

He compares the flow on a non-single sign-on site (lots of fetching between the client/server) and the first/following visits with his tool in place. You can download the source here (as well as the Ajax broker).

Raphael Stolt, in working on his component for the Zend Framework (based on the PHP_CodeSniffer PEAR package), pulled together all of the information Zend provides about their coding standards into one place.

Before jumping into the development of a Zend Framework coding standard for the PHP_CodeSniffer Pear package, I spent some time revisiting and compiling the available Zend Framework coding standards into a handy one-paged Pdf document.

You can download the file here or, if you want something a bit more "spread out", check out the coding standards on the Zend Framework website.

The mystery has been relealed - the php|architect folks have posted about their secret today - a discount on single issues of 30%.

Seasons greetings everyone! The first of two surprises from us today is a great opportunity to combine our recent drop of all DRM protection on our PDFs with an awesome 30% discount on our single-issue prices to stock up on all your favourite past issues of php|architect.

This means that single issues are priced at (about) $3.49 CAD for a few days - all you need to do is pick your favorites from their archive, even their most recent issue.

Alex Netkachov has posted about the update he's just released to the Jamp! package.

I've updated the Jamp! All packages are updated to the latests stable version available, the "Server" and "Service" commands are added for Tomcat 6.0, Jamp.hta UI is updated

Jamp! is a single-click installer for PHP/Java/Apache/MySQL to make installing them (and getting them working together) simple.

DevShed has posted the second and last part of a series of two articles based around the Composite design pattern - using it to work with strings in PHP5.

Are you a PHP developer who wants to improve your skills in pattern-based programming in PHP? If the answer to this question is a emphatic yes, then you should begin reading this article now! Welcome to the final part of the series "Implementing the composite pattern with PHP 5." Comprised of two instructive tutorials, this series walks you through the basic concepts of this important design pattern, and shows you how to apply it with some educational examples.

They start by defining a simple StringProcessor class as an abstract interface to build from. From there, they create two other classes - the SingleStringProcessor and the MultipleStringProcessor. Each of these takes in either a single file or multiple filenames and spits back out the value of the string and the length of the string.

Continuing their look at design patterns, DevShed has kicked off yet another series today spotlighting the Composite pattern as used in PHP5.

The composite pattern is one of the less commonly used patterns in PHP 5. Nevertheless, in certain situations, it is very helpful. This article, the first one in a two-part series, will introduce you to the basic concepts of the composite pattern.

The composite pattern allows you to define a single or multiple objects that will have identical behavior - basically behaving the same if there's just one or with the multiple instances. They start with the basics, reaching for one of their standard examples - a file information reader - to illustrate their point. They create the two helper classes it needs to work, one for the single file read and another for the multiple file read. The finish by combining them all together for a file-reading fiesta, showing how to get a one shot info dose as well adding files to the list and grabbing their info all together.

Pierre-Alain Joye has posted a quick hit to his blog today about using one php.ini file for both a cli and cgi installation of PHP without it throwing errors for htscanner.

Htscanner reports error during module or request init (returns FAILURE), these errors may be fatal and stop the current executions. This behavior is not desired if you use it in a shell ((if you have only one system php.ini for both cli and cgi or if htscanner is compiled statically). This release brings a new ini settings to solve this problem, stop_on_error.

The solution involves changing the htscanner setting to 0 instead of 1 to return a "SUCCESS" message rather than the errors.

From Vidyut Luther today, there's this new post that asks the question "Where do you 'define' your environment/global settings?"

I was wondering how people handled this situation themselves. I'm personally trying to decide whether my constants be in the class files, or a global configuration file. Right now I have a global.conf.php which contains things like (MySQL login info, include paths, table names).

So, my question is: Is it better to have one big configuration file, or should some things be defined on top of the individual classes ? (CONTACTS_TABLE.. is a clear example). I see pros and cons for both approaches.

He lists out pros and cons for the "one file approach" versus the "multiple specific definitions" method, for example:

• simple editing vs. easier to manage
• a single large file vs. multiple small files
• high memory usage on every page vs. lower memory consumption from loading only what's needed