Archive for the ‘PHP’ Category.

First public release of my PHP EXIF Library!

I’ve been working on a new library for PHP which will allow you to edit the EXIF headers found in most JPEG images produced by modern digital cameras. And I’m proud to present the result: PEL.

PEL is a library written in 100% PHP 5, and it can currently parse JPEG files and parse any EXIF headers found within the file. The EXIF headers can be changed at will, and they can be turned back into a byte stream, which can be saved as a valid JPEG image.

As far as I know, then this is the first library besides libexif to feature full read/write support for EXIF. Version 0.1 features most of the intended functionality, but the API is still subject to change. Interested parties should go to the development mailinglist and discuss the API, suggestions are very welcome! Also, remember to use the SourceForge trackers found on the project page to report problems.

PhpShell 1.8 released

This release doesn’t add any significant new functionality, instead it breaks compatibility with versions of [PHP][] earlier than 4.1.0 :-) The only new feature is that the stderr checkbox now remembers it’s state. Thanks goes to Michael Zech for sending me a patch!

Seriously, you or your provider ought to have updated your PHP installation beyond version 4.1.0 by now, considering that it’s almost 18 months since it was released (PHP 4.1.0 was released December 11th, 2001). PHP 4.1.0 was the version that introduced the new superglobal arrays: $_REQUEST, $_SERVER, and so on. I’m using them now in [PHP Shell][] because they’re the future standard and because it’s convenient.

For this release I’ve also fixed the generated [HTML][] so that it has become Strict [XHTML][] 1.0 accompanied by a valid stylesheet.

So, this release is mostly about standards complience, which is pretty important if you ask me, but which doesn’t add much new in itself.

Testing new psychedelic theme at GimpsterDotCom

Christmas is over, so it’s time to remove the red snowy background from GimpsterDotCom. But instead of using the normal blue color, I’m trying something new: a changing background color!

Each page start out with a blue background, but as people visit the page it slowly turns turquoise, green, yellow, red, purple and finally blue again. In other words, the color moves through the color-circle every time the page receives 360 hits. Funky isn’t it? :-)

To make it easy to change the color I made this little function to convert from the HSB (hue, saturation, brightness) color space to RGB (red, green, blue) which is what browsers understand:

function hsb2rgb($hue, $saturation, $brightness) {
    /* 0: minimum, +: rising, -: falling, 1: maximum. */
    $map = array(0 => array('1', '+', '0'),
                 1 => array('-', '1', '0'),
                 2 => array('0', '1', '+'),
                 3 => array('0', '-', '1'),
                 4 => array('+', '0', '1'),
                 5 => array('1', '0', '-'));

    /* Clip hue at 360: */
    $hue = $hue % 360;

    $i = floor($hue/60);
    $rgb = array();

    $min = 255 * $brightness/100 * (100-$saturation)/100;
    $max = 255 * $brightness/100;

    for ($color = 0; $color < 3; $color++) {
        switch($map[$i][$color]) {
        case ‘0′:
            $rgb[$color] = $min;
        case ‘1′:
            $rgb[$color] = $max;
        case ‘+’:
            $rgb[$color] = $min + ($hue % 60)/60 * ($max - $min);
        case ‘-’:
            $rgb[$color] = $max - ($hue % 60)/60 * ($max - $min);

    return $rgb;

I’ve figured out the conversion by looking at the sliders in the Gimp, so it could be wrong. Please correct it if you find a mistake… Credits go to DAIMI:~aveng (Lars Petersen) who got me started with this idea after showing me his nice PHP Imaging Lib.

Yes, I have a PhpWiki:PrettyWiki!

I’ve finally managed to get the PhpWiki:PrettyWiki concept to work here at GimpsterDotCom. The idea is, that the URLs used to access the WikiWikiWeb should look like

instead of

I’ve been playing with the settings in index.php for some time now, but today I made it work. The necessary changes turned out to be:

ini_set('include_path', $_SERVER['DOCUMENT_ROOT'] . ‘/phpwiki’);
if (!defined(’SCRIPT_NAME’)) define(’SCRIPT_NAME’, ‘/wiki’);
if (!defined(’DATA_PATH’)) define(’DATA_PATH’, ‘/phpwiki’);
if (!defined(’PHPWIKI_DIR’)) define(’PHPWIKI_DIR’, $_SERVER['DOCUMENT_ROOT'] . ‘/phpwiki’);

The file /wiki is then a symbolic link to /phpwiki/index.php. If you discover any problems with this new URL-scheme, then please mail me.

Hack to stop warnings

I’ve found a way to stop the warnings that started to appear two weeks ago — see my post on the 18th. The problem was, that file_exists suddenly started to give a warning when you used it on a file that you didn’t have access to, because [PHP][] is running in ”Safe Mode”. This started when NetSite upgraded to PHP 4.2.3.

The fix was simple, I just added a @ infront of file_exists to suppress the warnings. [PhpWiki][] provides all the PEAR files is need, so things still work. Here comes the patched function:

function _search_path ($file) {
    foreach ($this->_path as $dir) {
        // ensure we use the same pathsep
        if ($this->_pathsep != '/') {
            $dir = $this->slashifyPath($dir);
            $file = $this->slashifyPath($file);
            if (file_exists($dir . $this->_pathsep . $file))
                return $dir;
        } elseif (@file_exists("$dir/$file"))
            return $dir;
    return false;

Where exactly do you change this? (What file?)

I found it… pretty obvious since the path to the file is given in the errors… lib/FileFinder.php.