Making titles look right

A mixed-case title presents problems with vertical alignment: if none of the letters have a "descender" -ie the title does not include any of g j p q y - then you may want to sit the title lower on the page than if it does.

Here is a simple php function to check whether a string includes a descender:
function hasDescender($thisString){
    return (preg_match("/[gjpqy]/", $thisString));
}

Anchor link fires despite "return false"

I wasted a long time wondering why I couldn't stop the link for an anchor tag firing after the onlick Javacsript had run. Was it because I was setting the onclick function using window.onload? 

No - it was because I had errors in the function that I was calling. And because of that, it wasn't getting the the return false at the end (which is what stops the src link being followed by browsers with Javascript working).

Scriptaculous Sortables - this.observer is not a function

Hit errors with the error message "this.observer is not a function" when releasing a dragged object using the excellent Sortables function from scriptaculous.
Much grief before I eventually found the problem: where all the other options settings require the value to be in quotes, the "onUpdate" parameter requires the function name NOT to be quoted
.

So - use onUpdate:showList not onUpdate:'showList'

Mail2Blogger formatting

One of the really neat features in Blogger is the ability to create a blog entry simply by sending an email - then subject line becomes the title, the main body of the email becomes the content.


But looking at the output, I found some annoying formatting issues. Somewhere in the process, line-return characters were being added - resulting in a much narrower column for emailed entries than for normally-created entries.

And whilst the first section of content was delivered as a <div>, subsequent paragraphs were delivered as <p> paragraphs. The solution is to replace the opening <p> tag with two line-returns, and to ignore the closing </p> tag.

If you are using the output in an external page, and have PHP on your server, then for modest overhead, you can do some simple replacement to tidy up the output. Luckily, the line-returns added (at least in my case, from Outlook 2000) are plain <br> tags, whereas deliberately-added line-returns in Blogger are <br /> - so the text can be tidied up in a single pass like this:

$findArray=Array("<br>","<p>","</p>");

$replaceArray=Array(" ","<br /><br />","");

$blogHTML=file_get_contents(filePath("/Members/blog/blog.htm"));

$blogHTML=str_replace($findArray,$replaceArray,$blogHTML);

echo $blogHTML;

An extension of this could take care of fixed-format "signature" text added at the end of your emails (such as "sent from my iPhone") - but it might take a bit more programming to take care of any variable text (such as ads) that may be added by some email services.

Deleting a chosen file with PHP

I wanted a simple way to let users delete files already uploaded - and decided that I could create a form and populate it using PHP : one row per file, with a submit button each. The name of the submit button would be the file name. That way, when the form is submitted, I would get the key for the button pressed (each with value "Delete" so simply look for $_POST['Delete'], and delete that file.

Two snags worth noting:

First, PHP replaces a period OR a space with an underscore in field names submitted. so "abc def.pdf" appears in the $_POST array as "abc_def_pdf". The solution is to rawurlencode() the name and use this as the button name. Then when processing the $_POST field, use rawurldecode() - which still leaves the period as an underscore, so then run a replace function.


Secondly, there are lots of helpful scripts to show how to unlink, but none of them seemed to be clear on when a path is needed.
So if you write:
$handler = opendir($directory);
while ($fileName = readdir($handler)) {
the $filename variable will show just the filename - but when you come to
unlink($fileName);
it won't work - you need:
unlink($path.$fileName);

Example:

function modifyFileName($fileNameWithUnderscore) {
 if (substr_count($fileNameWithUnderscore,"_") > 0) {
   $lastPeriod = strrpos($fileNameWithUnderscore,"_");
   $fileNameWithUnderscore = substr_replace($fileNameWithUnderscore,".",$lastPeriod,1);
 }
 return $fileNameWithUnderscore;
}


$hit=false;
$deletedOK=false;//default
foreach ($_POST as $key=>$value){
 if ($value=="Delete"){
   $encodedFileNameWithUnderscore=$key;
   $hit=true;
 }
}
if ($hit==true){
 // create a handler for the directory
 //$fileNameWithPeriod=modifyFileName($fileNameWithUnderscore);
 $fileNameWithPeriod=modifyFileName(rawurldecode($encodedFileNameWithUnderscore));
 $handler = opendir($directory);
 // keep going until all files in directory have been read

 while ($loopFileName = readdir($handler)) {
  // if $file isn't this directory or its parent,
  // delete it
  if ($loopFileName != '.' && $loopFileName != '..'){
   //echo $file;

   //open and close to make sure it can be deleted
   if ($loopFileName==$fileNameWithPeriod){
    $fh = fopen($fileNameWithPeriod, 'w') or die("can't open file");
    fclose($fh);
    //delete the file
    $deletedOK=unlink($directory.$fileNameWithPeriod);
   }

  } else {

  }
 }
 // tidy up: close the handler
 closedir($handler);
}

Password Woes

A long time wasted due to a really silly cause.

User asks for new password, which is emailed to them. Then they log in with it, only to have the password rejected as invalid.

The problem? In simulating user behaviour, I pasted the password in first, then typed the user name. What was happening was that the Browser was automatically applying the password it had stored for that user name and so overwriting the new password just created and (correctly) entered.

Moral: as a user, always enter user name before password. As a developer - allow for this in design?

focus() not working with "a" tags

Firefox (at least) demands that an "a" tag has an "href=" entry - without it, it silently ignores the instruction to move the focus.

Missing Space in email Subject line - was it SMTP at fault?

A bizarre problem today - logged here just in case it helps anyone else.

Emails generated by PHP and sent via SMTP were losing a space in the subject line. If I wrote "Mailing Labels for John Geddes (1 label)", the last bit would come across as "(1label).

I tested the character string I was sending character by character - no spurious characters. I tried everything, eventually sending the same message seven times in a loop.

The result was clear - but odd. My ISP's spam software gave three of the messages a score of 3.82 - these were fine. Four messages got a score of 3.819 - that extra precision increased the length of the subject line to 69 (including the spam score) at which point it decided to truncate the string, not by lopping off from the end (which would have been obvious) but by removing the final space character.

This cost me an hour and a half - hope the note might just save someone else from wasting as much time.