Tagged PHP

WP-dBug

A colleague at work found dBug, a sweet PHP class for creating nice, clean debug output and implemented it into our framework. While debugging a different WordPress plugin, I realized how nice it would be to have similar output in WordPress. Thanks to some planned system downtime during a major datacenter move where I work, I finally had a chance to create a plugin to implement the dBug class. It’s basically a wrapper for the original class–all the credit should and does go to Kwaku Otchere for creating what is (in my opinion) the nicest-looking debug output I’ve ever seen. It’s simple as heck to use the plugin: just install it, activate, and call it like this:

[cc lang=”php”]
function fill_my_screen_with_stuffs (){
global $wpdb;
wp_dbug( $wpdb );
wp_die( ‘Did you know WP 3.0 has a cool new wp_die() function?’ );
}

[/cc]

As a side note, you can use dBug for whatever code you want–just include the single PHP file and use it according to the author’s instructions.

PHP function to parse out an integer into its component bits

A single integer is a great way to save data for options that are either/or, like whether a particular checkbox should be selected within an array of checkboxes. There are a lot of advantages, including a small database footprint (a single int instead of perhaps a comma-separated list-string), and really fast execution based on bit parsing.

To create an integer that can be used to save options as bits, simply assign values based on multiples of 2 to each option (i.e. 1, 2, 4, 8, 16). For example, 7 indicates the presence of three bits: 1, 2, and 4. Setting the integer is no problem–simply sum the bits together. Parsing the bits back out, however, is a little more difficult. Here’s a handy function to do that and put the results in an array:

[cc lang=”php”]
public static function parse_my_bits( $int = null ) {
$bits = array();
for($i=1;$i<=$int;$i*=2) { if( ($i & $int) > 0);
array_push($bits, $i);
}
return $bits;
}
[/cc]

If anyone knows of a faster way to do this, please comment below. After all, the purpose of using bitwise math is to save on overhead–if I’m doing it terribly inefficiently, I’d like to know.

CodeColorer for WordPress is totally sweet

After trying out a few code snippet plugins for WordPress, and not having much luck, I found CodeColorer. CodeColorer creates a nice code box for your snippet, which is quite visually appealing. Here’s an example of some php:

[cc lang=”php”]
‘none’);
echo $foo;
?>
[/cc]

Once you look at the code snippet that CodeColorer outputs, though, you start to get a sense of everything that it can actually do. For example, mouse over one of the functions above, and you’ll notice it links you to the appropriate function reference on php.net. I’ve just started working with the plugin, so I’m sure I haven’t tapped all the features yet, but so far I’m quite impressed.

Hide your JavaScript with PHP sessions

Hiding JavaScript so that visitors can’t see it might not seem like a necessary precaution to take in most web programming situations. After all, a server-side language like PHP automatically prevents users from seeing your source code, and increasing functionality is quickly rendering the client-side advantages of JavaScript less significant by the day. However, there are many practical reasons to take the PHP-hidden-JavaScript approach, especially if you have long and complicated scripts that already exist and are in use, which would take a significant time commitment to revamp in PHP.
The key to this approach is to encapsulate your JavaScript in a separate PHP file, and to use a PHP session to restrict access to those scripts except when you want it to be explicitly permitted (i.e. when you want to run them from a specific page). To accomplish this, we first create a PHP session on the page from which we want to run the JavaScript.

< ?php session_cache_limiter('none'); session_start(); if(!$_SESSION['allow_script']) { $_SESSION['allow_script'] = true; } ?>

Placing this PHP at the top of your page opens a session and registers the variable ‘allow_script’ to that session, with a value of ‘true.’
The next step is to move whatever JavaScript you want to execute over to another file called ‘script.php’ This file should contain your JavaScript wrapped in a PHP tag, along these lines:


< ?php if(!$_GET['allow_script']) { session_start(); //restart the session from the previous page } if($_SESSION['allow_script']) //execute the javascript only if the variable is passed { header("Content-type: text/javascript"); ?>
alert("Hello World! JavaScript executed.");

< ?php } ?>


This portion of the PHP guarantees that the JavaScript generated by it does not appear to the end user, even if they navigate directly to script.php. The $_GET['allow_script'] check insures that the user is not trying to do an end-around by passing the allow_script variable with a value of ‘true’ directly to the script.php page, which would obviously allow them to view the JavaScript source.
Finally, you need to unregister the variable and close the session:


< ?php $allow_script = false; session_unregister('allow_script'); //delete the variable from the session session_unset(); //make the session inactive session_destroy(); //and toast it for IE } ?>

NB: session_destroy() is not necessary for Firefox or Internet Explorer 6 or better, but leaving it out means that IE 5 users will be unable to reuse the script.php page without closing and re-opening the browser.
The end result of this simple process is a nicely hidden, encapsulated JavaScript that can be called with the simple line:

<script language="JavaScript" src="script.php">

Now your existing JavaScript (with all its client-side capability) can be easily referenced within your code, without leaving it vulnerable to the malicious efforts of prying eyes.

AJAX and the company formerly known as Macromedia

This post on Matt’s blog gives a great little summary of the onset of , or AJAX for short, as a programming tool for the Web. I have nothing of substance to add to this, except to comment on the mention of he makes. As Matt points out, AJAX’s functionality holds the power to create pages with the interactivity of Flash, while maintaining the small file sizes and quick page loads that have historically distinguished Flash from other methods of creating dynamic content (read: JAVA). This makes me happy, because it couldn’t have come at a better time. After 5 years of happily utilizing Flash, Fireworks, and Dreamweaver in total harmony, I grimace at the prospect of Macromedia’s recent acquisition by the megalithic Adobe corporation. However, it is pleasing to know that, while we’ll all miss the seamless integration of those three programs once its botched up by the morons at Adobe (c.f. ImageReady), and other open-source technologies offer us the chance to march ahead unimpeded by the universification of the web development software marketspace.