Monday, 26 October 2009

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.

Monday, 19 October 2009

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);
}

Tuesday, 10 February 2009

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?

Thursday, 5 February 2009

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.

Sunday, 25 January 2009

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.

Sunday, 7 December 2008

IE6: Superscript problems

Another IE6 oddity - a table where each row has one field that uses CSS with the coding:

font-size: 0.7em;
vertical-align: super;
position: relative;
bottom: -0.15em;
display: inline;

It worked fine for all rows but one (which had a different background-colour, but otherwise identical) - and for that row, IE6 would render the text either a few pixels too high (nearly overlapping the previous row) or nearly half-a-screen too high. No time to explore exactly why, but solved by replacing "vertical-align: super" with "vertical-align: 0.3em;"

Saturday, 6 December 2008

Adright - a reserved word ... somewhere

The following page looks fine in IE7 and in FF3 when opened as a file. But when opened on localhost using WAMP, any css classname starting with "adRight" (case sensitive) causes the div to disappear.

I can't work out whether this is an oddity with my particular setup, with Apache or with FF3. But in case anyone hits it, I thought it worth noting.



ONE

TWO

THREE


Postscript 23 December

The problem lies with Adblock Plus - and it is a moving target. replacing "adRight" with "addDateRight" worked for a while - and then suddenly today, that disappeared too. It looks as if any style name beginning "ad" is vulnerable - which is a bit of a nuisance, eg if you have a style called "address".


Suddenly, "addDateLeft" is also falling foul of