Matthew Turland

At the encouragement of Elizabeth Smith, I went through the process (not-so-recently as of this blog entry) of compiling PHP on Windows. I actually managed to get 5.2.5 and 5.3 both working on Windows XP. Major credit for success in that endeavor goes to Elizabeth herself who helped me through hurdles in the process, her older tutorial on compiling PHP 5.2 on XP using VCE 2005, and Pádraic Brady’s tutorial for compiling PHP 5.3 on Vista using VCE 2008.

First off, there are a few hefty things to download and install. Here’s the laundry list.

• Visual C++ Express 2008
• Microsoft Platform SDK for Windows Server 2003 R2
• .NET Framework 3.5 SDK
• Desired PHP official source release or snapshot tarball
• Edin Kadribašic’s library and header bundle
• Rob Richard’s libxml bundle (5.3 only)

Beyond the slight differences in the software required, the process described in Elizabeth’s tutorial is still fairly accurate. One thing I noticed for 5.2.5 is that there’s an issue with including IPv6 support, which is done by default when you configure your build. When you try to compile, you’ll probably see an error that looks like this.

network.c(897): error C2065: 'in6addr_any': undeclared identifiernetwork.c(897): error C2440: '=' : cannot convert from 'int' to  'IN6_ADDR'

There are two ways to get around this. The first is to include the –disable-ipv6 flag in the configure line. The other is applying the changes in lines 94-96 of a fairly simple patch to your network.c file so that it includes these lines in the proper place.

#if HAVE_IPV6const struct in6_addr in6addr_any = {0}; /* IN6ADDR_ANY_INIT; */#endif

Another issue is that you may receive an error regarding libmysql.dll not being found when you attempt to run nmake test. You must have the directory containing this file either in your PATH or parallel to php5ts.dll, as these are the only places that Windows will look for it. Thanks again to Elizabeth for this tip.

OK, hopefully the Linux people haven’t left yet. (You guys have a slightly more short and sweet segment in this blog entry.) I also did a custom build of 5.3 on Debian recently to use in running Phergie. I wanted to do a minimal local build to optimize performance (5.3 includes the garbage collection patch) as well as to include a few extensions that Phergie uses. One of these was the pspell extension for her Spellcheck plugin. I don’t have root access to the system on which I was going to run her, and since it didn’t have the aspell libraries already installed, I had to compile those from source as well. Here’s how I did it.

First, aspell itself.
wget -c ftp://ftp.gnu.org/gnu/aspell/aspell-0.60.5.tar.gz
tar -zxvf aspell-0.60.5.tar.gz
cd aspell-0.60.5
./configure –prefix=/path/to/aspell-0.60.5/build
make
make install

Next, the English dictionary for aspell.

wget -c ftp://ftp.gnu.org/gnu/aspell/dict/en/aspell6-en-6.0-0.tar.bz2
bunzip2 aspell6-en-6.0-0.tar.bz2
tar -xvf aspell6-en-6.0-0.tar
cd aspell6-en-6.0-0
./configure –vars ASPELL=/path/to/aspell-0.60.5/build/bin/aspell \
PREZIP=/path/to/aspell-0.60.5/build/bin/prezip-bin
make
make install

And finally, PHP with the pspell extension compiled in.

wget -c http://snaps.php.net/php5.3-200803032330.tar.gz
tar -zxvf php5.3-200803032330.tar.gz
./configure –disable-cgi –without-sqlite –enable-pcntl \
–prefix=/path/to/php-5.3/build/php_build \
–with-pspell=/path/to/aspell-0.60.5/build
make
make test
make install

And presto, that’s all there was to it.

One of the tasks I was recently given at my job involved examining issues with a browser-based batch file upload component. The component that was being used, iBULC, required a separate installation of proprietary software on the client-side, had a rather clunky browser interface, and proved difficult to troubleshot. Rather than expending effort to get iBULC to work properly, I went in search of a new solution. That new solution is SWFUpload.

SWFUpload is a small file upload solution that supports selection and uploading of multiple files, all while exposing a flexible event-driven API to allow you to handle events on the client-side in whatever manner suits your needs. It has two components, a Flash file (supports Flash 8 and 9) and a JavaScript include. A little HTML and JavaScript allows you to include these two components in your application and define handler functions to intercepts whatever events might be relevant to your interface. I was amazed at how quickly I was able to get a solution working. The examples and bundled documentation are quite good.

I only experienced two issues with SWFUpload in the process of completing my task. The first was that ampersands were being HTML encoded in the POST request being sent by the SWFUpload Flash component to my PHP script on the server side for intercepting uploaded files. This caused PHP to be unable to parse the POST parameters correctly. Luckily, the issue had already been reported and a quick fix in the JavaScript component resolved the problem.

The other issue was in the Flash component not properly sending cookie values to the PHP script, even with the JavaScript plugin for handling cookies enabled. Apparently this issue is most likely due to a known bug in the Flash player for Firefox. The only method I was able to use to circumvent the issue required including cookie data as POST parameters and checking for them there in the server-side script. Obviously this is a quick-and-dirty solution and I hope I eventually get to apply a more proper solution.

One outside issue unrelated to SWFUpload that I also ran into in the process of completing this task was an odd error in Internet Explorer. Even though the page using SWFUpload ran fine in Firefox, IE consistently returned the error “Internet Explorer cannot open the Internet site, Operation aborted.” For whatever reason, IE apparently doesn’t like it when you try to run JavaScript within <script> tags inside a table if the JavaScript isn’t contained within a function. An obscure bug, but an annoying one nonetheless. Moving the offending JavaScript to its own function appeared to fix the problem.

Outside of those issues, I was quite happy with the results. I was able to put the new solution together within an afternoon, it uses the native OS interface for multiple file selection, and it allows me to respond to the events that occur in the file upload process however might be necessary. I’d definitely recommend that you check SWFUpload out if you’re in need of a similar solution.

So after eventually getting fed up with WordPress, especially after the WYSIWYG editor disappered in the 2.3.3 update, I finally decided to bite the bullet and migrate my blog over to Habari. Once I’d been through the process, I thought I’d write a short blog entry about the experience.

First, there was the matter of content. Though it wasn’t as easy or intuitive as it could have been to track down how to migrate content from WordPress, once I knew how, it was a snap. Simply go to Admin > Plugins, activate the WordPress Importer plugin (which comes bundled with the release), then go to Admin > Import and you’ll have a WordPress Database option. From that point, it’s just a matter of putting in the authentication credentials to point Habari at the WordPress database and it seamlessly imports all your data into the Habari database.

Next came making Habari support my existing URL scheme from WordPress. It turns out that Habari has a database table for rewrite rules, but currently no section of the admin area to manage it. Ergo, the only way to add to or change these is to do it manually. Luckily, there was a blog entry from Michael Harris that detailed all this and even provided the exact INSERT statement needed.

After that came my blog theme. If the Habari developers are ex-WordPress developers as I’ve heard, they must not have liked the WordPress API much, because the two sure are different. This made theme migration look cumbersome enough that I decided to simply retire my old blog theme in favor of a slightly tweaked version of one of the stock themes available for Habari, namely Whitespace.

Finally, there were plugins. I wanted to continue using Akismet to manage content spam, as that had tended to serve me well while I was using WordPress. Luckily, Chris Davis has created an Akismet plugin. I downloaded the archive into /user/plugins, decompressed it, and then had to dig around in the plugin’s PHP file and add in my WordPress API key and blog URL. It would be nice if this was updated to use the configuration API that Habari offers for plugins. I tried the Blogroll plugin and didn’t really care for its interface. In that particular area, I actually liked how WordPress did things.

I experienced two particularly strange things during the process of migrating my blog. One occurred when I tried to swap out directories to make the new Habari-based version of my blog live. When I did that, all plugins mysteriously deactivated. I had to go back into Admin > Plugins and reactive them individually. They all seemed to retain their settings, at least.

The other oddity happened after I activated the TinyMCE plugin so that I could use a browser-based WYSIWYG interface to edit content. The dashboard screen in the admin area (and only that screen, from what I can tell) started throwing an “exception without a stack frame” error. I’ve e-mailed the author on that one, so we’ll see what happens.

Overall, though, I’m very satisfied with Habari and look forward to using it to catch up on the backlog of post ideas I’ve managed to build up over the past few weeks.