Posted on

PHP imagecolorallocation producing incorrect color?

A problem with a simple explanation and fix that’s surprising hard to find an answer for on google. In php, when working with certain images imagecolorallocate() will not return the color you want, and instead return any old color. It’s a rather frustrating problem on the surface, as your code is correct and the result the server ives you is not. but after a little troubleshoot the answer hit me in one of those moments of clarity you hear alcoholics talk about. It’s all a problem of the images color allocation table.

See, the problem is that an image in certain formats (GIF and PNG (8 bit) and there are probable other, less common formats that are susceptible) Store every color in the image in a table. This is what the command imagecolorallocate modifies to give you your color. Specifically it ads one to the end of the table and return it back to you. This is the root of the problem. See, if the image is full color (relative to the limited number of colors they can have) imagecolorallocate can’t add a new color to the images color allocation table, and instead returns a random color (which I’m sure is not random, it’s probably just the last color in the table). So thats the problem, whats the solution?

Simple, remove a color from the color table. Not I suggest doing this prom Photoshops “Save for Web and Devices..” feature as it will be able to re-jigger the color table to still look good, randomly pulling a specific color and turning it black (which can be done entirely from PHP) runs the risk of ruining the image. You can over-ride the Photoshop palet size option simple by typing in the box next to it, 255 will leave you one more color to fill, if you want to use multiple colors then you need to adjust you images pallet size accordingly.

Posted on

PHP-Lively Refresh Fix

PHP-Lively is a php/javascript/ajax live chat script that allows users to chat with vistors on their site. It’s like that feature that nearly all large business sites have but not quite as fully fledged and somewhat buggy. It’s also free, not $99 a month like the most common chat service is.

I was installing PHP-lively into a site after testing it on my personal server and noticed it was not automatically refreshing the view. So if someone typed the other user would have know way of knowing unless they hit the “Envair” (enter, yes the scripting is in… spanish?). This of course was not the point of a live chat so I dug through the code (formatted in some strange language to me) to fix the problem.

Snipplr: http://snipplr.com/view/45224/phplively-auto-refresh-fix/

The code goes towards the end of the code.js document (located at master/js/chat.js), specifically at the end of the UpdateTimer() function.

What the code does is register a submission as if you entered text, but sends a blank set of data, wich tells the script to update without posting. This is very much a hack and should only be used if your on a server that will not allow the automatic refreshing of the script as written.

Posted on

PHP absolutely relative links

After there were some issues importing a WordPress site from a live server to a local server so we could work on it without fear of it breaking (it needs some pretty extensive back-end reorganization) I decided to solve the problem of mixed absolute and relative links my simply making them all relative. This works great in theory but in practice has some problems, for instance some of the classes call, and are called, from multiple location in the directory tree. PHP can handle this but when your trying to include an HTML image or javascript that can be a problem. Lets see if I can explain this problem a little better.

You have a class with a function that generates a form, it is stored on the root level as forms.class.php. You call this form from multiple locations, on the signup page also on the root directory located at signup.php and on the account modification page located at /account/index.php. The function uses a javascript file that is located at /js/form.js. If you call that file in the forms.class.php function via js/form.js it will work great on your signup.php file on the root of your server, but on /account/index.php it will 404, not being able to find it. Thats what this bit of code handles.

Snipplr: http://snipplr.com/view/44647/php-absolutely-relative-root/

Place this on the top of the file thats displaying and then you can use the PHP definition ROOT in the class for the javascript file. On the root level of the server ROOT will be blank, and the link will still work just fine, but in the account/index.php page ROOT will be ../ which will tell the browser to look back one directory and then it will be able to find the file.

This is still a pretty sparsely tested little clip (just around a few folder in a test server) and there’s probably a better way to do it, but until I get a chance to sit down with the WordPress installation at work and test it out it is what it is. There are other improvements that can be done (like making it a function so your not locked into the current value making it not always go back to root) but for now it’s doing what I wanted it to do. I’ll make some improvements to it and update the snippet here and and snipplr accordingly.

Also, I’m sure theres a better way to do this, this is just the first solution that came to mind and I decided to roll with it. If there is a simpler method (not involving /htaccess or anything link that, simple PHP) that I find to do this then I’ll update accordingly