Tag Archives: PHP

PHP Dark Arts: References

Remember the first time you dabbled in C?  Oh, the glorious typing, functions, and structs!  Now do you remember the first time you ran in to a pointer?  ’*', ‘&’, ‘->’ all made your hurt, but eventually you figured it out.  It’s fortunate (depending how you look at it) that we don’t have need to dabble with pointers or references while web programming these days.  However, PHP does allow us to passing things around by reference.  It’s not used often, but when used correctly can be very beneficial to the quality of your code.

What are PHP references?

The first thing you need to know about PHP references is that they are not C references.  You can’t do pointer arithmetic on them because they aren’t actually addresses.  In PHP references are actually symbol table aliases.  This means that you can have 2 variable names sharing the same variable content.

What can you do with references?

There are 3 things that you can do with PHP references.

  • Assign by reference.
  • Pass by reference.
  • Return by reference.
$x =& $y;
$x = 3;
echo "X: $x, Y: $y";

The above code sets $x and $y’s references to the same content area. Therefore, when $x is assigned 3, $y has access to the same data.

function add_item(&$item) {
   	$item++;
}
 
$totalItems = 0;
for($i = 0; $i <; 5; $i++) {
	add_item($totalItems);
}
echo "Total items: $totalItems";

This code allows you to modify a variable’s value without ever returning anything. In this example I made a simple counter, but you can set the value of $item to anything and it should work out just fine.

class Test {
	public $count = 0;
 
	public function &getCount() {
		return $this->count;
	}
}
 
$t = new Test();
$value = &$t->getCount();
$t->count = 25;
echo $value;

This code returns a reference to the public $count variable of the Test class. Generally this isn’t best practice, as it lowers the readability of the code.

Unsetting References

In the event that you want to free a variable from it’s reference to another, you can simply use the unset function.

$x =& $y;
unset($x);

HTML 5 Canvas: Saving to a File with PHP

So you’ve finally discovered the wonder that is the HTML5 Canvas element. Great! If you’re like me, the first thing I wanted to do with it was doodle on it. I eventually worked out how to map touch/mouse events to the canvas and draw lines, but I wanted to save my creations!

As it turns out, the Canvas element has a method called toDataURL(), which base64 encodes the entire Canvas element and returns it as a string. From there, you can just pump it over to a server and handle it from there. Here’s the step-by-step, which assumes you are also running jQuery on your site.

Step 1: Save the canvas and POST the data

var data = document.getElementById("myCanvasID").toDataURL();
$.post("process.php", {
	imageData : data
}, function(data) {
	window.location = data;
});

Step 2: Process the POST data, and save it to a file.

$data = substr($_POST['imageData'], strpos($_POST['imageData'], ",") + 1);
$decodedData = base64_decode($data);
$fp = fopen("canvas.png", 'wb');
fwrite($fp, $decodedData);
fclose();
echo "/canvas.png";

Note: The first line of this script removes the header information that is sent with the encoded data.

Thats all there is to it. You can now easily save your HTML 5 awesomeness.

Caching WordPress Data with the Transients API

If you’re a plugin or theme developer, there may come a time when you need to execute a long running operation. It doesn’t need to be anything complicated, but something as simple as fetching a Twitter feed can take a significant amount of time. When you come across these types of situations, it’s handy to be able to store the data on your own server and then fetch a new copy of it every X hours. This is called caching, and WordPress convieniently comes packages with an excellent caching API called Transients .
Wordpress Transients API

The Transients API is surprisingly simple to use. In fact, it’s very much like using set_option and get_option except with an expiration time. If you aren’t familiar with caching at all, here’s the general workflow:

  1. If the data exists in the cache and isn’t expired, get it.
  2. If the data doesn’t exist in the cache or is expired, perform the necessary actions to get the data.
  3. Store the data in the cache if it doesn’t already exist or is expired.
  4. Continue from here using data.

When attempting to use the Transients API for caching, there are three functions that you need to be aware of: set_transient, get_transient, and delete_transient.

  • set_transient($identifier, $data, $expiration_in_minutes): This function stores your data into the database. The identifier is a string that uniquely identifies your data. Your data can be any sort of complex object, so long as it is serializable. The expiration is how long your want your data to be valid (ex: 12 hours would be 60*60*12).
  • get_transient($identifier): This retrieves your data. If the data doesn’t exist or the expiration time has passed, false is returned. Otherwise, the same data you stored will be returned.
  • delete_transient($identifier): This will delete your data before it’s expiration time. This is handy if you are storing post-dependent data because you can hook it into the save action so that every time you save a post, your cached data is cleared.

Now that we’ve covered the basics, how about a quick example?

if (false === ( $my_data = get_transient('super_expensive_operation_data') ) ) {
     $my_data = do_stuff();
     set_transient('super_expensive_operation_data', $my_data, 60*60*12);
}
 
echo $my_data;
 
function do_stuff() {
     $x = 0;
     for($i = 0; $i != 999999999; $i++) {
          $x = $x * $i;
     }
     return $x;
}

The example is pretty straight forward. We first check to see if there is a cached copy of the data, if not, we fetch the data from the “do_stuff” function, and store it in the database. Simple, right?

One of the benefits of using the Transients API (aside from speeding your site up) is that plugins like WP Super Cache or WP Total Cache will auto-magically cache your data into memcached if you have it set up. For you, this means an even faster site! If you have any questions about caching techniques or the Transients API, leave a comment and I’d be happy to help.

Tracking Email Open Time with PHP

You can download my code for this article here.
Some time ago I had great aspirations of launching a web company that does email tracking and analytics. One of the things that I really wanted to figure out but wasn’t well documented on the web was how to track how long a user had a particular email open. When a company like MailChimp wants to track emails that they are sending out, they put a small image in the email called a “beacon”. When the user opens the email, the beacon image is requested from the server. The server sends the image, but not before it gathers information about the computer requesting it. The works great for checking if an email was opened, or what platform the person is on, but it doesn’t work at all for determining how long the email was open for.

One option that came to mind for checking the open time of an email was long polling.  Long polling (in this case) would use Javascript to contact the server every X seconds after the email was loaded.  Using those requests, it’d be trivial to find out how long it was open for.  Unfortunately, most (if not all) email clients don’t allow the execution of Javascript within emails, so that idea was completely sank.  The only option I had left was to use the beacon image to somehow determine open time.

The only option I could think of for using the image beacon without any Javascript was to redirect the image back to itself.  After much trial and error, I came up with the following.

//Open the file, and send to user.
$fileName = "../img/beacon.gif";
$fp = fopen($fileName, "r");
header("Content-type: image/gif");
while(!feof($fp)) {
    //Do a redirect for the timing.?
    sleep(2);
    if(isset($_GET['clientID'])) {
    	$redirect = $_SERVER['REQUEST_URI'];
    } else {
    	$redirect = $_SERVER['REQUEST_URI'] . "?clientID=" . $clientID;
    }
    header("Location: $redirect");
}

So what’s happening in this code?  First of all, we’re opening a small GIF file that we’re going to pretend to send to the user.  The second step is to send a header for an image file to the user so that their mail client expects one to be delivered.  This step is important because if the header isn’t sent, the browser/mail client will close the connection.  After that, you make the request sleep for a few seconds (as few or as many as you want depending on how granular you want your timing data to be) and then redirect back to the same page.  The “if” statement within the while loop is there so you can identify incoming requests and log the data accordingly.

So there you have it.  If you’ve ever wondered how people track the open time of an email, it’s probably a method very similar to this.  The only caveat to this method is that it relies on the user loading images in an email.  However, if you have a large enough sample you can just take the average open time from the users that did open it and be fairly confident with that.

Note: There has been some discussion over on Stack Overflow about this article. You may find it helpful.

 

If you liked this article, then you may like:

  • PHP Dark Arts: Multi-Processing (Part 1)
  • PHP Dark Arts: Multi-Processing (Part 2)
  • PHP Dark Arts: Shared Memory Segments (IPC)
  • PHP Dark Arts: Semaphores
  • PHP Dark Arts: GUI Programming with GTK
  • PHP Dark Arts: Sockets
  • PHP Dark Arts: Daemonizing a Process
  • WordPress Development as a Team

    At my day job I’m really the only person that knows how to write WordPress plugins, so when I write one it’s usually sand-boxed on my machine where nobody can touch it. However, in a side endeavor I’m part of we have a team of 3 people developing on one plugin. As I’m the most experienced plugin developer amongst our team, I was tasked with coming up with a development style and plugin architecture that would work for us.

    Development Style

    Everyone will be running a local copy of WordPress and making their changes to the plugin locally. The plugin itself will be under version control using Git, and developers will push/pull changes from either a self-hosted Git server or Git Hub. Database schema will be tracked in a file called schema.sql. When someone makes a change to the schema, it goes into that file at the bottom with a comment about why the schema changed. We’ll being jQuery as our Javascript framework of choice, and we’ll be writing all of our Javascript in CoffeeScript (see my previous entries).

    Plugin Architecture

    The more difficult aspect of developing this plugin as a team is the sheer size of the plugin. Realistically this could probably be split into about 6 different plugins by functionality, but we want to keep everything together in one tidy package. To illustrate the architecture, I made a quick drawing.

    The first layer of the plugin is essentially a wrapper. It initializes the ORM that we are using to access the database (we are using a separate database for this plugin’s data), and includes the wrapper class. The wrapper class is where developers drop their sub-plugin include file and instantiate it’s main object. For instance, for each sub plugin there will probably be two classes instantiated in the wrapper. One being admin related functionality, and the other being for front-end display functionality. My thinking with this architecture was that we could all work on separate sub-plugins without crossing paths too frequently. This also allows us to separate the different functionality areas of the plugin in a logical manner. The other benefit to architecting the plugin like this is that it will be very easy to port to a different architecture in the future. I’m well aware that WordPress probably isn’t the best tool for the job, but it is the best tool for the team with the deadline that we have.

    Thoughts

    While thinking about WordPress Plugin Architecture, I cruised the source code of a lot of plugins and it seems that everyone goes about it in a different way. If you’ve ever developed a large-scale plugin with a team, how did you go about doing it? Did you run in to any problems that you didn’t foresee at the beginning of the process?

    Installing Memcache on MAMP

    For the better part of 2 hours I tried and failed to get the Memcache extension installed on MAMP.  I tried following several guides, but everything fell flat on it’s face about 75% of the way through.  I eventually figured it out, and I wanted to share it so that other people don’t have to go through the pain and suffering that I did.  It turns out to be surprisingly easy, but YMMV.

    Step 1: Install XCode

    Step 2: Make the MAMP PHP binary files executable

    sudo chmod +xrw /Applications/MAMP/bin/php5.3/bin/p*

    Step 3: Get the Memcache extension source

    cd ~
    wget http://pecl.php.net/get/memcache-2.2.5.tgz
    tar -zxvf memcache-2.2.5.tgz
    cd memcache-2.2.5

    Step 4: PHPize the Memcache extension files

    /Applications/MAMP/bin/php5.3/bin/phpize

    Step 5: Compile the Memcache extension

    ./configure
    make

    Step 6: Add the extension to the PHP.ini file

    Add the following to the end of your PHP 5.3 ini file via the MAMP file menu.

    extension=memcache.so

    Step 7: Copy the memcache extension to the PHP extension folder

    cp modules/memcache.so /Applications/MAMP/bin/php5.3/lib/php/extensions/no-debug-non-zts-[yourtimestamp]/

    The “[yourtimestamp]” varies per installation, but you should just be able to tab complete that part.

    PHP Alternative Syntax

    Did you know that PHP has an alternative syntax structure?  Up until about two years ago, I didn’t either.  It wasn’t until I started poking around in the WordPress core that I saw it.  Intrigued, I popped over to PHP.net and read an entry on it.  In a nutshell, the alternative syntax can go far in making your PHP code much easier to read.  The control structures if, while, for, foreach, and switch can all be expressed in the alternative syntax form.  In general, I prefer to use the alternative syntax when mixing PHP in with HTML, and the standard syntax when writing pure PHP.

    If Example

    // This....
    if($myString == "foo"):
        echo "bar";
    else:
        echo "no-foo-bar";
    endif;
     
    //...is equal to this.
    if($myString == "food") {
        echo "bar";
    } else {
        echo "no-foo-bar";
    }

    ForEach Example

    $names = array("bob", "tom", "john");
     
    //This....
    foreach($names as $name):
        echo "Your name is: {$name}";
    endforeach;
     
    //...is equal to this.
    foreach($names as $name) {
        echo "Your name is: {$name}";
    }

    Resources

    If you’re looking for more resources on PHP’s alternative syntax, check out the documentation here, or the WordPress source code for examples.

    Creating a Flexible Caching Module

    I work for a great company, I really do.  Sure we have our problems (like just coming out of the developer stone age), but overall I work with smart, friendly people who are passionate about what they do.  One of the things that always bugged me though was the lack of any sort of caching in our CMS.  Most times it’s not needed, but when an operation takes about 100 queries or so to finish, then it’s time to start caching.

    Since I’m a bit of an efficiency freak, I thought I would take a crack at writing a flexible caching module that is easy for our developers to use.  So what do “easy” and “flexible” mean?  To be “easy”, the caching module must be usable by even a novice developer and have a limited number of options.  For instance, I ended up deciding that we really only need two public methods, and one public property.

    • $cache->exists – If “$cache” is a cache object, calling exists checks to see if the cached object already exists in the database.  It also checks to see if it’s expired or not.  If it’s expired or non-existent, it returns false.   It returns true if the cached object exists and is up to date.
    • $cache->put($val) – This is how you store something in cache.  It can be any type of serializable PHP object.  So basically, resource types are off limits but objects, arrays, variables, entire web pages, etc. can be used.
    • $cache->get() – This fetches the object stored  in the cache.  It handles the re-serialization of it as well, so it really makes things pretty idiot proof.

    What about flexible?  Well, by that I mean we need to be able to transparently implement several different types of caching.  Since we’re just crawling out of the dark ages, I opted to implement a fallback caching mechanism.  Here’s how it works.

    • The programmer defines a variable in our settings area to be which caching option he/she wants to use.  Options are memcached, file, mysql.
    • If the setting isn’t defined, we try memcached by default.  This is by far the best caching system to use, so it makes sense to try it first.
    • If memcached fails, we go to a database caching schema.  While not nearly as good as using memcached, it’s possible it could save you tons of queries on your database.
    • If the user chooses file caching, we do that.  It’s a pretty bad idea to use in most cases, but may still have it’s uses.

    So why did it come this?  It’s not that we host terribly high-volume sites, but that our CMS is super slow.  A full-on page will take about 4 seconds to load to your screen completely, and that’s running local on the network.  One of the main problems is that we use output bufferring extensively.  The ENTIRE FRIGGIN PAGE is buffered.  This has 3 side effects:

    1. Slight performance loss due to bufferring.
    2. Apparent page load time sucks because the browser has to wait for the entire page to be generated before getting output.
    3. Development is super easy because you don’t ever have to worry about output being sent before doing a call like “header()”.

    We can’t remove output buffering unfortunately.  It’s at the very core of our CMS and development practices, so it just won’t work.  To get the load time to generate the page as low as possible, I decided that caching was needed.

    So what sort of problems do we run in to with this caching module?  Glad you asked!  Many of the problems aren’t specific to this caching module, but to caching in general.  The quick list:

    • If the original query wasn’t complicated, it’s not worth storing the results.  The number of queries the caching module does in MySQL mode is 3.  If your initial query was less than that, or not a super-complex-mega-join, it’s not worth using.  This caveat goes away in memcached mode.
    • Smart naming and design.  You have to be very careful out what you cache, and when.  Remember, page content and queries probably change when a user is logged in or on a different device.  Just things to keep in mind.
    • Getting developers to use it.  Not everyone likes to learn, let alone change their habits.  The biggest barrier to this is getting people to use it.  Some people don’t care about efficiency either (sad, I know), but at least our system administrator thanks me.

    The caching module seems to work pretty well too.  On one particularly SQL heavy page, I reduced page load time from 14 seconds (ridiculous) to just under 6 seconds (still bad, but getting better).

    That’s it for now.  Any questions or comments are welcome.