Email comes in all shapes and sizes, from complicated nested multi-part structures to simple text bodies. But even messages comprised of just plain text require special preparation to safely and properly display from within a webmail application. For security purposes any HTML within a text message needs to be converted to appropriate entities. Using the CSS "white-space: pre;" setting is effective as well, the CSS equivalent of <pre> tags, but this makes word wrapping the message in such a way as to ensure that the webmail interface remains consistent very tricky. Neither approach is ideal (entities vs pre-formatted), and both suffer from some similar display problems. For example a line containing 200 characters in a row with no spaces, such as a long URL will either spill out from it's containing div or expand the width of the page to force a horizontal scroll bar (yuck). To further complicate the situation we need to be able to create links to both urls and email addresses within the text as well as highlight reply quoted sections, not to mention take into account converting the original character set to UTF-8 for display in the page. For Hastymail 2 I have been working on a new system that preps the text body in such a way as to address all of these concerns and creates a situation in which the text is wrapped by the browser automatically for almost any practical resolution without spilling out of its container and without horizontal scroll bars, and without a user setting that defines the maximum line length, all the while maintaining the intended format of the original message as closely as possible within the constraints of the presentation medium.

    I am not a huge video fan, though watching a video online does have an undeniable coolness factor. I have done some client work involving videos for a site and during the process ran into a few things that might be useful to others trying to handle video. There are quite a few open source and inexpensive tools to help deal with video handling, and combined with some server settings and PHP code it is possible to build some pretty cool video features.

   Years ago while working through the framework of Hastymail, I came across a need to have a simple and fast lightweight encryption routine. At the time the mcrypt module of PHP was not so widely available as it is now, and I wanted something without external dependencies including PHP mods that were not default on most distros. RC4 is an older, lightweight encryption algorithm, by no means uncrackable, but suitable for certain encryption tasks in which limited overhead is required and cipher strength is not a top priority. So I wrote a simple RC4 implementation in PHP based on the by then widely available algorithm. It's a single function that takes two arguments, a string to encrypt/decrypt and a "secret key" that forms the basis of the encryption.

     Clean URLs are nice. And it's nice to be nice. So we always use clean URLs. Most rewrite examples found online look something like this:

RewriteRule ^topic/banana/$ filename.php?topic=banana

This puts an entry in the $_GET array with the name "topic" and the value "banana". Very nice. But it does not scale well.  For a big site with a lot of possible URL combinations the amount of rules can be problematic, and just a pain to keep having to adjust or add to. And unless I am mistaken, the more rules you have the more overhead for mod_rewrite (generally speaking). We have to within a web application or site analyze the URL arguments in PHP anyway, so using a more general type of rewrite regex we can use a nicer approach. The word for today by the way appears to be nice.

      If elephants never forget, then I have mouse memory. As the years go by I strain at times to remember early childhood events. I do recall however a certain Christmas gift I received long ago, and when I consider how much fun I had with it I can't help but wax nostalgic. It was a book of ciphers and codes, and had instructions on how to create a multitude of substitution ciphers of varying difficulty. The excitement I felt when I scrawled an encoded message and rolled it up inside a hollowed out pen was not lessened in anyway by the fact that nobody would ever receive said encoded message, nor would anything happen when some time later the hollowed out pen was eventually fished out from the junk drawer to then be thrown away after the quick conclusion that it was broken. But heck, I was like 9 or something. When you are that age the day after tomorrow may as well be 50 years from now, and the reason for doing things need not make a whole lot of sense. At least when I was 9. As I reread this I can't help but think that my recollection of fond memories is coming out more pathetic than heartwarming, so lets jump to the present and get on with the post.

    Rarely do I post what I would call "opinion pieces" (that is not to say my average post is not littered with opinionated statements), though I occasionally read some while trolling through tech and PHP related news and blogs. While doing so recently I came across an article with a title similar to "40 things bad PHP programmers do".  As I scanned the list I thought the ideas where all valid, if not a bit over zealously stated in an effort to make the point. This and a recent job interview (in which I did not get the job) got me thinking again about something I have pondered for a long time: How does a programmer balance practical limitations with best practices that can be difficult and time consuming to adhere to?

    So I am sitting around very late at night, absolutely should be sleeping but apparently against my better judgement have decided to write about variable variables in PHP. I'm reminded of a great boss I used to have who when presented with a new top priority by the company honchos that none of us had time for would look you straight in the eye and with statue like seriousness mention "I seem to recall you have some free time between midnight and 6".  So why write about variable variables, and what are they and why do you care?

    One thing I love about PHP is that simple things can be done with very little code, but at the same time there are several ways one can achieve a goal, allowing for a more fine tuned solution to the task at hand. Some feel the enormous function reference in PHP is one of it's failings as a programming language. I can see that point of view but for me personally, I appreciate the ability to use one of several different methods to get a job done (and even after years of writing apps in PHP I still sometimes stumble upon a function that is just what I need!). Having both a high level quick-and-dirty method, and a more complicated but more precise method allows for greater flexibility as a programmer. One area however in which PHP has really lacked over the years is handling file uploads, especially large files.

    As a child I was, for a time, fascinated with computers. I even briefly entertained the idea that I would write a game in BASIC. The hours it took me to draw a slightly skewed line across the 16 color monitor of my Atari 800XL dispelled that notion almost as quickly as my prepubescent brain had latched on to it. Fast forward to college and while not a CS major, pursuing a Mathematics degree involved some logic and programming courses. When I say "pursuing" I mean barely attending classes and eventually dropping out completely to instead hitchhike across the continental US with all my belongings on my back and only a vague idea of where I was going. The bits of pascal and logic I did study did not stick with me except as a faint memory. Fast forward 8 years to 1998 and I have a wonderful daughter, a quaint middle management job at a box factory, and a renewed interest in the surging home computer phenomenon going on at the time. So with a brand new Windows 98 machine and a copy of Deitel and Deitel's C++ programming purchased for 10 bucks at a garage sale I set out to learn to write software during lunch breaks and late evening hacking sessions.

    People often ask me, "Jason, oh great PHP master, how can I write secure PHP code?". To this I respond "Climb back down the mountain and return to your home my son, the answers will find you there ... as long as you click over to my blog and wait until I get this post done. Now GO!". Seriously though, about the only thing I am a master of is run on sentences, embellishing, and the sometimes spooky but usually droll ability to raise either of my eyebrows individually. I have however written quite a bit of PHP over the years and have some suggestions to help others avoid some of the mistakes I have made in the past. So without further ado, here is my somewhat short, seemingly solid, sometimes sordidly sarcastic, synopsis of secure scripting suggestions.