Matthew Turland

Elizabeth Smith managed to pique my interest and maintain the patience of Job long enough for me to successfully build PHP 5.3.0RC1 with PHP-GTK including Cairo support on Ubuntu Jaunty. The process was a bit arduous, as Ubuntu apparently has a rather “interesting” automake package, so I thought I’d document it here for anyone who might be interested in repeating the process.

I’m assuming here that you want to use as many available Ubuntu packages as is feasible, aside from maybe PHP itself, in order to minimize the amount of manual compilation necessary. To that end, there are a number packages you will need to install before getting started that do not come with a standard Jaunty installation.

sudo apt-get install subversion cvs libcairo2-dev libgtk2.0-dev

If you plan to build PHP from source, you will also need a few more packages.

sudo apt-get install build-essential autoconf libxml2-dev

Once you’ve got all the dependencies installed, the first step will be to grab a copy of PHP. You’ve got a few options in that regard.

• Install the stock php5-cli and php5-dev packages available for Ubuntu.
• Download a copy of 5.2.9 or, if you want the new shiny stuff, 5.3.0RC1.
• Download a current snapshot of the 5.2 or 5.3 branches.

Assuming you do a custom build, here’s how I did it.

./configure --with-gettext --disable-cgi --without-pear \
    --prefix=`pwd`/build/php_build
make
make install

Next, use Subversion to check out a copy of Cairo extension. If you did a custom PHP build, you can just place it on the same directory level as that.

svn co svn://whisky.macvicar.net/php-cairo cairo

At the present moment, the easiest way to install the Cairo extension is manually as a PECL extension. So, compile using the phpize utility in your PHP build.

cd cairo
../php-5.3.0RC1/build/php_build/bin/phpize
./configure --prefix=`pwd`/build/php_build \
    --with-php-config=../php-5.3.0RC1/build/php_build/bin/php-config

It’s at this point that Ubuntu’s “interesting” automake package comes into play. The Makefile generated by phpize will be missing a critical flag -DCOMPILE_DL_CAIRO in its CFLAGS setting value. Open the Makefile in any text editor and find the line that looks like this.

CFLAGS = -g -O2

Append the missing flag to the line so it looks like this, then save it.

CFLAGS = -g -O2 -DCOMPILE_DL_CAIRO

At that point, just continue the compilation process for the Cairo extension as normal.

make
make install

Now use CVS to check out a copy of the PHP-GTK extension. Place it on the same directory level as cairo.

export CVSROOT=:pserver:cvsread@cvs.php.net:/repository
cvs -q checkout -P php-gtk

If the phpize utility is not in your PATH, you’ll have to assign it to an environmental variable as those are the only two ways that the buildconf utility you’re about to use will pick it up.

export PHPIZE=../php-5.3.0RC1/build/php_build/bin/phpize

Execute the buildconf utility to generate the configure script, then execute it.

./buildconf
./configure --prefix=`pwd`/build/php_build \
    --with-php-config=../php-5.3.0RC1/build/php_build/bin/php-config

To have the PHP-GTK extension take advantage of the presence of the Cairo extension, you’ll need to add a flag to the CFLAGS setting in its Makefile. Open that, find the line that looks exactly like the original one modified in the Cairo Makefile, and append the flag -DHAVE_CAIRO to it so it looks like this.

CFLAGS = -g -O2 -DHAVE_CAIRO

At that point, continue the compilation process normally just as with the Cairo extension. Once that’s done, since the extensions were compiled as PECL extensions, you’ll need to enable them in your php.ini file.

If you did a custom build of PHP, just copy the php.ini-development file in the root of the extracted tarball directory to lib/php.ini within your build directory as this is where PHP will look for it by default. If you’re using PHP 5.3.0RC1, there is a syntax error around line 581 of that file. A URL should be commented out using a semicolon but isn’t. Note that the extension_dir setting needs to be set and, if you use a relative path, it must be relative to the current working directory from which PHP is invoked (the root PHP build directory in my case).

extension_dir = "lib/php/extensions/no-debug-non-zts-20090115"
extension=cairo.so
extension=php_gtk2.so

At this point, if you execute your php binary with the -m switch, you should get a list of extensions loaded. cairo and php-gtk should be among them and you shouldn’t see any errors before the extension listing. To take this for a test spin, there’s a particular demo file for PHP-GTK with Cairo support in the php-gtk checkout.

cd php-5.3.0RC1/build/php_build
bin/php php-gtk/demos/examples/cairo_support.php

If this works as expected, you should see a nifty little PHP-powered clock widget on your desktop.

Many thanks to Elizabeth for her help in putting this tutorial together and for all the very cool people working on the PHP-GTK project. You can find them in the #php-gtk channel on the Freenode IRC network. At the present time, some of them are in the process of revamping the PHP-GTK docs. In the meantime, you can check out the GTK docs for more current information.

While using cdc recently after having written about it, I ran into an odd issue. While doing a lint check on a code block, a parse error was occurring on a line that contained a comment in the original source file.

The original code block to do this lint check had the line below to do the heavy lifting.

$response = shell_exec('echo ' . escapeshellarg($code) . ' | php -l');

A var_dump() on $code revealed this, where the comment line was the line on which the parse error was occurring.

string(474) "<?php
...
// Matches any of the standard escape sequences \r, \n, or \t
$matches = (preg_match('/\\r|\\n|\\t/', $string) == 1);
...
?>"

Presumably what was happening was, even though the var_dump() call showed that actual newlines were being interpreted correctly, the \r was also being interpreted rather than taken literally. This caused the comma following it to generate the error I was receiving, namely "Parse error: syntax error, unexpected ‘,’." (If you know why this is, I’m very curious to find out.)

Luckily I was able to tag Derick and he pointed me in the direction of an alternative: proc_open, which even has an example for executing a PHP file that works just as well when modified to perform a lint check on a PHP file. You can see the code changes in the related git commit.

As work-related events recently started piling up, we gained a need to keep them organized. So we got a Google Calendar, shared it between us, and all was dandy. I wanted to be able to pull that into my local e-mail client, though. I’m running Ubuntu Ibex and its Thunderbird package.

My friend and colleague Keith Casey pointed out to me that Thunderbird has a Provider for Google Calendar add-on that works with Lightning, which I already had installed. So I install the GCal add-on and restarted Thunderbird. No visible change. I checked the Add-ons area only to find that the entry for the GCal add-on was displaying the message "Requires additional items" with no way to see what said items were. A search prompted me to check the version of the Lightning add-on, which I found to be 0.8 because I’d already installed the Ubuntu package for it and that was the latest version available.

As it turns out, the Ubuntu wiki has instructions for what I figured out on my own the first time around: version 0.9 of the Lightning extension has to be downloaded and installed manually for 64bit builds. After that, the GCal add-on was right as rain. Adding a calendar was as simply as accessing Google Calendar via the web, going to Calendar Settings for an individual calendar, and using the XML link for that calendar when adding the calendar to Lightning using new new Google Calendar option added by the GCal add-on.

I’ve spoken on this blog before about scaling Zend_Form for larger forms by having it use a central set of plugin loaders for all elements contained within a form, rather than allowing each element to implicitly create its own instances. Another way to accomplish the same goal is to have form elements use the same loaders that the form has already created for itself.

<php

class FastloadingForm extends Zend_Form
{
    public function addElement($element, $name = null, $options = null)
    {
        if (!is_array($options)) {
            $options = array();
        }

        // A plugin loader is implicitly created if default decorators are loaded
        $options['disableLoadDefaultDecorators'] = true;

        // Add the element to the form
        parent::addElement($element, $name, $options);

        // Configure the element to use the form's plugin loaders
        $element = $this->getElement($name);
        foreach ($this->_loaders as $type => $loader) {
            if ($type != 'ELEMENT') {
                $element->setPluginLoader($loader, $type);
            }
        }

        // Now load default decorators for the element
        $element->loadDefaultDecorators();

        return $this;
    }
}

However, this approach can cause an issue if subforms are being used because of a bug in Zend_Loader_PluginLoader.

The bug entails Zend_Loader_PluginLoader allowing multiple instances of the same path to be added per prefix. This becomes an issue because of how Zend_Form handles adding subforms: it automatically calls addPrefixPath() on the subform for each path contained in each of the form’s own plugin loaders. If both the form and subform are using the same plugin loaders, the bug causes the same paths to be added multiple times. When plugins are subsequently loaded, the duplicate paths are all searched individually, creating a bottleneck as more subforms are added.

The issue in the JIRA bug tracker for ZF has patches for both the issue itself and the unit test suite for the Zend_Loader_PluginLoader component. Please view the bug report and vote to ensure that the issue receives attention and is fixed in a release in the near future.