Charles Reace
PHP Musings

Here's a little something I came up with today for dealing with strings being moved from PHP into JavaScript code. The problem is that if you have some sort of textual content in your PHP script (perhaps the result of a "screen-scraping" operation), if you try to directly use it within some JavaScript being output to your page, you'll run into all sorts of headaches due to newlines, quotes, etc. For instance, the following will not work:

<?php
$html = file_get_contents('http://www.charles-reace.com');
echo <<<END
<script type='text/javascript'>
var htmlText="$html";
document.write(htmlText);
</script>
END;
?> 

But, we can urlencode the text on the PHP side, converting all those problematic characters into the encoded form. Then we can decode it in JavaScript via its unescape() function. On the PHP side we need to use rawurlencode rather than just urlencode(), as the latter replaces spaces with "+" characters, but the JavaScript unescape() does not convert them. Now we can change our test script to:

<?php
$html = file_get_contents('http://www.charles-reace.com');
$encoded = rawurlencode($html);
echo <<<END
<script type='text/javascript'>
var htmlText="$encoded";
document.write(unescape(htmlText));
</script>
END;
?> 

Now the page generates no JavaScript errors and outputs the text as expected.

A new PHP feature you might have missed (I know I did until I stumbled onto it recently) is the Data Filtering extension, which made its debut in PHP 5.2.0. This extension provides a set of functions for both validating and filtering of external data, such as users' form inputs.

These functions are each controlled as to what sort of filtering/validating they do by a set of pre-defined constants. See the Data Filtering Introduction page of the manual for a list of the currently available filters. As an example of its potential utility in the simplification of your code, consider the validation of email address formats. Probably the most commonly used technique for this is to use a regular expression comparison. The most thorough implementation of such a function I've encountered is this one I found at iamcal.com:

Read the rest...

This is the first "Beginners' Corner" article, designed to help new PHP programmers in their quest to become veteran PHP programmers. In this initial installment we'll look at a few things which are best avoided, but for various reasons often become habits of new PHP users who do not yet know better. Many of these may become habits simply because there are so many bad examples out there to learn from, often because they are dated and PHP has moved on in a manner which obsoletes them.

<?php Tags

The first bad habit to avoid is using <? instead of <?php or <?= instead of <?php echo. While saving those few keystrokes is a temptation to all of us lazy programmers, it is a potential problem should you need to run the script on a site where the short_open_tag option is disabled. One likely reason to have it disabled is in order to avoid confusion with <?xml tags in XML documents, and as XML is much more prevalent now than it was when PHP was created, you are more likely to find such configurations in use; so just get in the habit of typing those three extra characters and saving yourself a lot of aggravation in the future.

Read the rest...

...at least until PHP6 is released.

As stated in the php.net release notes, "Support for PHP 4 has been discontinued since 2007-12-31. Please consider upgrading to PHP 5.2. The release below is the last PHP 4 release." The news archive also notes, "This release wraps up all the outstanding patches for the PHP 4.4 series, and is therefore the last normal PHP 4.4 release. If necessary, releases to address security issues could be made until 2008-08-08," (my emphasis).

While I've often tried to create general-purpose functions and applications that could port to either PHP4 or PHP5, I've decided to forego any further support of PHP4 with any code I create (unless, of course, someone is paying me to create something for PHP4 for some reason). I would therefore like to encourage my fellow PHP hackers (in the good sense) to join me in encouraging all developers to move on to PHP5, and explain to all clients and hosting services that they should migrate to PHP5 ASAP, if for no other reason than to ensure that they can continue to operate with the most secure version of PHP by keeping up with the latest stable releases.

But this upgrade is also to our benefit, opening up access to the much more thorough class and object support of PHP5, enhanced database interfaces such as MySQLi, and new functions like filter_var(), just to name a few of the benefits. Additionally, we should strive to rid our applications of deprecated features and functions, in particular those that will not be supported at all in PHP6. (We don't want to have to upgrade our scripts again, right?) According to Nathan A. Good in "The Future of PHP", the following features will be completely removed from PHP6:

• magic_quotes
• register_globals
• register_long_arrays
• safe_mode

If your scripts depend upon any of those settings, it's time to wean yourself of them now. Don't wait until someone upgrades a server and all your scripts start crashing.

[2008/07/15: Added this to the "Beginners' Corner" category]

A common problem I see new PHP users running into is having a script output absolutely nothing: the dreaded "blank page" syndrome. This is normally due to a syntax error of some sort generating a fatal parse error. As this error is generated before any of the script is actually executed, none of the file's output ever gets sent to the browser. If the current PHP environment on the server has display_errors turned off, then not even the error message generated by the parser gets displayed. Additionally, since no PHP commands actually get executed when there is a parse error, turning on display_errors within that script via the ini_set() function will make no difference.

The two usual approaches to debugging such problems are to either search the PHP or web server error logs to look for relevant error messages, or else to turn on display_errors, either globally in the php.ini file or at the directory level via a .htaccess file, assuming you are running under Apache and the necessary Apache settings are in effect to allow this. (A third alternative is to use an editor that has PHP syntax checking built in, such as PHPDesigner.)

If for some reason none of those approaches is practical for your situation, a simple way to have any  parse errors be displayed is to create a tiny wrapper script that includes the offending file:

<?php
ini_set('display_errors', 1);
error_reporting(E_ALL | E_STRICT);
include 'path/to/flawed/file.php';
?>

All you have to do is run this script in your browser, et voilà, your parse errors will now be displayed.

Yes, I've decided to join the world of blogging.

The intent of this blog will is to pass along any words of wisdom or wit I may come up with during my continuing journey in the world of web application development, in particular in regards to the use of the PHP programming language. You can find more articles and code samples in the PHP and MySQL section of my web site.

I am a moderator at the PHPBuilder forums (under the user name “NogDog”) and encourage you to visit there if you’d like to learn more.

I am available for freelance work. If interested, please use my “Email Me” page to let me know something about your needs, and we can begin a dialog about how best to attain them.