Read a file into an array
Here's something that puddled me for a while...
$filename = 'file.txt';
$file_handle = fopen($filename, 'r');
$data = '';
while(!feof($file_handle)){
$data .= fgets($file_handle, 1024);
}
Converting XLS to CSV. Simple, eh? Well, sorta.
I hate problems that can be solved really easily. (With a totally different set of tools). I needed to open Excel (XLS) files in PHP. Simple enough you think, IF you are using Windows.
IF I was using Windows, I would have a bunch of options open to me, I could use PHP's COM & .NET functions. Or PHP's ODBC functions. Or a selection of classess from PHP Classes.
file_exists(), is_file() & is_dir() with spaces?
Why won't file_exists(), is_file(), is_dir() return true if the file or directory has a space in it?
I spent a few hours trying all kinds of ways to make this work. I finally settled on using $file->setName("safe"); from PEAR's HTTP_Upload class which makes the uploaded file "safe".
What's safe?
Yellow text?
I stumbled over a strange bug on two systems the other day where the imagettftext() function was always writing the text in yellow. No matter how I set the colour, imagecolorallocate($image, 0, 0, 0);, I would always get yellow. Why yellow?
Both systems are Ubuntu, I don't know if it is a mix up on the libraries from the package, or indeed PHP.
I had to recompile PHP ignoring the --with-ttf option which most docs suggest, and just use the --with-freetype-dir instead. Problem solved.
“Mail option not available!”
I spotted a strange PHP "feature" in the error_log() feature.
PHP checks for sendmail functionality once during ./configure for the mail() and error_log() functions.
Now, you can quite happily pass the sendmail path with the 'additional_parameters' flag to the mail() function, if you added mail support later but error_log() won't take that flag, so it fails with "Mail option not available!"
Rule: Install postfix/qmail/whatever BEFORE installing PHP if you want to use mail as an error_log() option.
Making user inputted data safe
I like to use the PEAR library HTML_Safe to clean up any user input I collect from forms and such before saving to a database. (It is also downloadable seperately from PixelApes).
It strips out any potentially dangerous HTML and code such as;
- opening tag without its closing tag
- closing tag without its opening tag
- any of these tags: “base”, “basefont”, “head”, “html”, “body”, “applet”, “object”,
“iframe”, “frame”, “frameset”, “script”, “layer”, “ilayer”, “embed”, “bgsound”,
“link”, “meta”, “style”, “title”, “blink”, “xml” etc. - any of these attributes: on*, data*, dynsrc
- javascript:/vbscript:/about: etc. protocols
- expression/behavior etc. in styles
- any other active content
It's been stuck at 0.9.9 beta since 2005 but the oldies are the goodies (See qmail, 1 & 2).
Useage, say for example, I want to make the $_GET['show'] variabl, which is passed in the query string safe;
require_once 'HTML/Safe.php';
$safehtml =& new HTML_Safe();
$show_safe = $safehtml->parse($_GET['show']);
For a lazy simple programmer it is simple to use even with ADODb's AutoExecute() function which I am using more and more recently;
$safehtml =& new HTML_Safe();
foreach ($_POST as $foo) {
$_POST[$foo] = $safehtml->parse($foo);
}
$insert_rs = $conn->AutoExecute('SOME_TABLE', $_POST, 'INSERT');
Simple as.
It is also worth looking at HTMLPurifer which seems to be more recently updated.
Cursed by '
' is not a valid HTML entity. So why do people use it in RSS?
Yeah, sure it is a valid XML entity, but in RSS, which will more than likely be displayed as HTML eventually, why use it?