I should really move to lighttpd or nginx one of these days…

I found something interesting in the event log yesterday:

PHP Warning:  [eAccelerator] This build of "eAccelerator" was compiled for PHP version 5.2.9. Rebuild it for your PHP version (5.2.9-2) or download precompiled binaries.

Now that error message makes perfect sense. The reason I didn’t see it the first time around is that PHP logged two messages separately at the same time. If I was reading a flat file log, I would’ve noticed it immediately.

After a few seg-faults, I realized that eAccelerator isn’t thread safe (I was running it under a thread safe server)… It is thread safe… I just wasn’t loading it in thread safe mode (see the manual for details). Whoops.

Following the path of logic, I went to the eAccelerator website in search of the appropriate files. Their Windows section directed me to SiteBuddy, which had a nice collection of binaries for various PHP versions. After determining my PHP version (5.2.9-2), I tried the closest match (5.2.9), and was greeted by the following error in the Windows event log:

Unable to start eAccelerator module in Unknown on line 0.

My initial reaction to the error: what the ****… (UPDATE: See this post for more details) After a quick Google search, I found that PHP modules must be built for the EXACT PHP version you plan to use them on.

Since I have just about every Microsoft C++ compiler, I figured compiling a new eAccellerator module for my version of PHP would be simple. I downloaded the archived PHP files I needed (now I understand why they keep archives), switched to the release configuration, and pressed build.

error C2466: cannot allocate an array of constant size 0

My reaction to this was about the same as the other one. After half an hour, I tracked down and fixed the problem, which was a broken Windows build configuration (which the PHP developers KNEW about, and marked as “Wont Fix”).

The solution was to make the changes suggested by sailormax.

In the end, everything compiled, and you’re reading my post through eAccelerator. I noticed that blog page loads are 2 – 3 times faster.

InDefero has no install wizard (one is in the works though), so all the configuration is manual. Installing the DB tables requires you to run a PHP CLI script. Everything was going smoothly until I tried to install the tables. The script exited with no output every time I ran it.

I tried to debug the script with echo statements, and traced to issue to a require statement that was causing execution to stop. After tinkering with several of the scripts, including the script in the require statement (the config file), and still having the install script fail, the thought occurred to me, why am I not getting any debug info from PHP?

Since the php.ini I was using was setup for production, display_errors was off. After turning it on with a CLI switch, I got a debug message. My config file was messed up. After going to the indicated line, I realized what happened.

The InDefero config file has a secretKey field that you’re supposed to put a random string in. I used PWGen (a neat open source password generator) to generate the random string. The only problem was, I opted to include special characters. In most programming languages, there are special characters that have to be escaped, and PWGen happened to put a few in the string it generated.

After selecting the alpha num character set in PWGen, generating a new string and putting it in the config file, the install script ran successfully.

I was thinking, finally, it’s working. Then, I browsed to the admin project list, and got a nice exception page. After spending a few hours figuring out that it was a database name escape issue, and not a permissions problem, I reported and fixed the bug.

When you’re debugging a problem, remember, read each error message carefully. Read it several times, word for word. Not reading the error properly can cause you to spend a lot of time on something that isn’t related to the error message.

Unfortunately, the SVN browser in InDefero is way too slow. I’m going to have to switch to something else

To fix, find (in uploader.php):

<option value=""><?php _e('N/A',"wp-download_monitor"); ?></option>

Replace with:

<option value="0"><?php _e('N/A',"wp-download_monitor"); ?></option>

Another minor bug is that there was a missing space when using the download short code (link titles looked like VersionNumHere instead of Version NumHere).

To fix, find (in wp-download_monitor.php):

$format = '<a class="downloadlink" href="{url}" title="{version,"'.__("Version","wp-download_monitor").'", ""} '.__("downloaded","wp-download_monitor").' {hits} '.__("times","wp-download_monitor").'" >{title} ({hits})</a>';

Replace with:

$format = '<a class="downloadlink" href="{url}" title="{version,"'.__("Version","wp-download_monitor").' ", ""} '.__("downloaded","wp-download_monitor").' {hits} '.__("times","wp-download_monitor").'" >{title} ({hits})</a>';