After installing eAccelerator on a CentOS 5.5 server running PHP 5.2.10, a bunch of websites began failing with open_basedir errors like so:

[Fri Jul 16 17:53:50 2010] [error] [client XX.XX.XXX.XXX] PHP Warning: require() [function.require]: open_basedir restriction in effect. File() is not within the allowed path(s): (/home/username/) in /home/username/public_html/wp-settings.php on line 19, referer: http://www.server.com/

After doing some research it turns out that a default option that is compiled into eAccelerator is incompatible with open_basedir. The fix is easy enough, simply re-compile with the --without-eaccelerator-use-inode option like so:

make clean
phpize
./configure --without-eaccelerator-use-inode
make
make install

After re-compiling and installing, make sure you clear out the existing eAccelerator files before restarting Apache:

rm -rf /var/cache/eaccelerator/*
apachectl restart

eAccelerator states that the next version will have this compile option set by default.

Reference:

• http://eaccelerator.net/ticket/414
• http://eaccelerator.net/ticket/104

I've been customizing a WordPress install and have been needing to capture the output of the bloginfo() function, which simply echo's a string. I wanted to capture the echo into a variable without actually echo'ing the string. You can do so by leveraging PHP's output buffering functions. Here's how you do it:

ob_start();
echo 'Hello World';
$myStr = ob_get_contents();
ob_end_clean();

$myStr will now contain 'Hello World' without actually outputting it to the screen.

Reference:

• ob_start()
• ob_get_contents()
• ob_end_clean()

For some reason, FCKEditor automatically wraps any content entered into the textbox with a <p> tag. This can cause for some problems in your layout when you're actually displaying the content. Instead of trying to fix this in your layout with CSS, there is a quick and easy way to turn the auto-wrap off in FCKEditor: Change the FCKConfig.EnterMode setting from 'p' to 'br'. There are a few ways to handle this:

• Edit fckconfig.js:
  Change FCKConfig.EnterMode = 'p'; to FCKConfig.EnterMode = 'br';
• Change the setting programatically when you instantiate the object, like so (in PHP):
  <?php
include_once('fckeditor/fckeditor.php');
$oFCKeditor = new FCKeditor('description');
$oFCKeditor->BasePath = '/fckeditor/';
$oFCKeditor->Value = 'some text';
$oFCKeditor->Config['EnterMode'] = 'br'; // turn off auto <p> tags wrapping content
$oFCKeditor->Create();
?>

I prefer the latter way because you can do it on a page by page basis, and there's no messing with FCK's core JavaScript files.

I received the following in my Apache error_log when attempting to load the ionCube loader in my php.ini file:

PHP Fatal error: [ionCube Loader] The Loader must appear as the first entry in the php.ini file in Unknown on line 0

This is because ionCube must be loaded before any of the Zend extensions are. So if you have the Zend extension/optimizer loaded, your php.ini should look like this to get ionCube to work:

[Zend]
zend_extension=/usr/local/ioncube/ioncube_loader_lin_5.1.so
zen_extension_ts=/usr/local/ioncube/ioncube_loader_lin_5.1_ts.so
zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.3.0
zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-3.3.0
zend_optimizer.version=3.3.0a
zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so
zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so

----------------
Now playing: Tommy McCook & The Aggrovators - A Loving Melody
via FoxyTunes

I ran into trouble when trying to pass a urlencode()'ed plus sign into a web address being processed by mod_rewrite.

$url = 'http://www.server.com/browsealpha/name+has+plus+in+it/';
$url = urlencode($url); // http://www.server.com/browsealpha/name%2Bhas%2Bplus%2Bin%2Bit/

This $url variable gets echo()'d as a link in a page, so once it's clicked and loaded in the browser, I then needed mod_rewrite to translate that to the actual URL, which is:

http://www.server.com/browsealpha.php?name=name%2Bhas%2Bplus%2Bin%2Bit

Here is the RewriteRule I was using to match:

# match any name containing any combination of letters, numbers, and the % sign (to match urlencoded URLs)
RewriteRule ^browsealpha/([%\w]*)/?$ /browsealpha.php?name=$1 [QSA,L]

This rule should match http://www.server.com/browsealpha/name%2Bhas%2Bplus%2Bin%2Bit/ but for some reason it wouldn't work. After hours of frustration, I found a few threads mentioning the need to urlencode() the string twice, like so:

urlencode(urlencode($variable));

IT WORKS!!! Apparently this is because mod_rewrite automatically decodes the urlencoded URL, so if you pass in %2B, PHP sees it as %2B0. If you double encode, mod_rewrite decodes the first one, and PHP receives the second one (which is now %2B, which is what we want).

----------------
Now playing: Autechre - 444
via FoxyTunes

If you're trying to write some text using PHP/GD & the imagettftext() function, you will of course need some TrueType fonts to work with. I've found a great set of fonts available for free: Webcore. Webcore contains all the fonts web designers constantly use, things like Arial, Tahoma, Verdana, Georgia, etc..

To install, simply download to your server and install the RPM (Fedora):
shell> wget http://avi.alkalay.net/software/webcore-fonts/webcore-fonts-3.0-1.noarch.rpm
shell> rpm -i webcore-fonts-3.0-1.noarch.rpm

These fonts will now be available to you in /usr/share/fonts/webcore/.

Make sure you specify the full path when calling imagettftext(), eg:
<?php
 
// Set the content-type
header("Content-type: image/png");
 
// Replace path by your own font path
$font = '/usr/share/fonts/webcore/arial.ttf';
 
// Create the image
$im = imagecreatetruecolor(400, 30);
 
// Create some colors
$white = imagecolorallocate($im, 255, 255, 255);
$black = imagecolorallocate($im, 0, 0, 0);
imagefilledrectangle($im, 0, 0, 399, 29, $white);
 
// The text to draw
$text = 'Hello world!';
 
// Add some text
imagettftext($im, 20, 0, 10, 20, $black, $font, $text);
 
// Using imagepng() results in clearer text compared with imagejpeg()
imagepng($im);
imagedestroy($im);
?>

Your mileage may vary if you are using a different distribution, but the docs state that this RPM should work on other distros.

I've come across a little inconsistency between browsers and the way they handle cookies. Using the examples from PHP's online manual, I was unable to get Safari to remove cookies using setcookie(). All other browsers would clear the cookie with no problems. It turns out that Safari will only delete cookies if both the cookie name AND the cookie path match.

In other words, this won't work:

setcookie('TestCookie', 'somevalue', time()+3600, '/somepath/'); // Set cookie
setcookie('TestCookie', '', time()-3600); // Delete cookie

setcookie('TestCookie', 'somevalue', time()+3600, '/somepath/'); // Set cookie
setcookie('TestCookie', '', time()-3600, '/somepath/'); // Delete cookie

Basically, if you set a cookie using a path, you must also specify the path when deleting the cookie. Safari won't remove the cookie otherwise. This is probably a good thing.

We have an account with a VERY large inbox (over 80,000 emails), and when logging into Squirrelmail the main pane would not load. Instead we'd be prompted by the browser to download a right_main.php file. Accounts with smaller inboxes would load fine, so I figured it had something to do with system resources. This is an easy fix. Open up your php.ini file, and increase the memory_limit value to something larger than the default 8M. Restart Apache and try opening your big-ass inbox again. If it still doesn't work, increase memory_limit again. Repeat until your inbox will load, but be careful if you have little RAM. I was able to load my 80,000+ inbox by setting memory_limit = 32M.

The instructions for doing so (here) seemed straightforward enough, but I ran into a few problems. So here's how I got PDFLib working with my PHP install on Fedora Core 4.

First we need to build PDFlib Lite from Source. Download it from here. Unpack it, then:
./configure
make
make install
Easy enough. Now:
yum install automake
yum install php-devel
pecl install pdflib
(Note: php-devel is required because we need phpize which is used by the pecl command.)

The PECL install will ask you a question: "Path to PDFlib installation?" This is where I ran into problems. You must put /usr/local/ and NOT /usr/local/include because the script is hardcoded to look inside the include directory automatically. Once PECL finds pdflib.h it will continue and finish compiling our shared object, pdf.so. The script will install it for us in /usr/lib/php/modules/
Now we just have to tell PHP to load the SO. Open up php.ini and add the following line:
extension=pdf.so
Save & exit, and restart your Apache with apachectl graceful. Now browse to a file containing the phpinfo() function and check to see if PDFlib is now active. If you see it, you're good to go!

NOTE: I ran into a problem with RPM GPG Keys at the automake install step. I was getting the following error:
warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID db42a60e
public key not available for autoconf-2.59-5.noarch.rpm
Retrieving GPG key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora
The GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora (0x4F2A6FD2)
is already installed but is not the correct key for this package.
Check that this is the correct key for the "Fedora Core 4 - i386 - Base" repository.
To get around this we need to import all the keys by run the following command:
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY*
I found this solution in this thread.

I ran into a few problems trying to install Xdebug into PHP on both FreeBSD 5.2 and FreeBSD 5.4. My research led me to this PHP bug thread and the proper solution. Here's a quick summary to get you going with Xdebug:

Xdebug is installed via phpize, and phpize has some requirements:

• autoconf: 2.13
• automake: 1.4+
• libtool: 1.4.x+ (except 1.4.2)
• bison: 1.28 (preferred), 1.35, or 1.75
• flex: 2.5.4

I was able to get mine up and running with the following versions:

• autoconf: 2.59_2
• automake: 1.9.5
• libtool: 1.5.10_1
• bison: 1.75_2
• flex: 2.5.4

However, the ports packages for autoconf, automake, and libtool that come with FreeBSD are installed into non-standard locations, so phpize is unable to find them. This is easily fixed with symlinks (NOTE: symlinks will vary depending on which versions you have installed):
ln -s /usr/local/bin/aclocal19 /usr/local/bin/aclocal
ln -s /usr/local/bin/automake19 /usr/local/bin/automake
ln -s /usr/local/bin/autoconf259 /usr/local/bin/autoconf
ln -s /usr/local/bin/autoheader259 /usr/local/bin/autoheader
ln -s /usr/local/bin/libtool15 /usr/local/bin/libtool
ln -s /usr/local/bin/libtoolize15 /usr/local/bin/libtoolize
ln -s /usr/local/share/aclocal19/ /usr/local/share/aclocal
ln -s /usr/local/share/aclocal19/libtool15.m4 /usr/local/share/aclocal19/libtool.m4
Now, assuming you have all the correct versions installed and paths present, phpize should be able to find everything and Xdebug should install as expected:
# phpize
# ./configure --enable-xdebug
# make
# cp modules/xdebug.so /usr/local/lib/php/extensions

• Add the following to php.ini:
  zend_extension="/usr/local/lib/php/extensions/xdebug.so"
• Restart your webserver
• Check the output of phpinfo() to make sure Xdebug is properly loaded