After or during writing a project, it’s important to visit your code with a profiler – see how long your code takes to run, and identify potential bottlenecks, and places where you can improve your code.

The profiler I use is Xdebug, a slick PHP debugger, and profiling tool. I use XAMPP for my testing (no running services, turn on Apache and MySQL when I need it), on my machine, and it comes with the xdebug extension by default. I leave xdebug enabled, as it gives great debugging information, including a caller/stack trace. You also need a program called WinCacheGrind, which will allow you to view the profile traces.

To enable Xdebug in your XAMPP config, go to: C:\xampp\apache\bin (I installed it in C:\xampp), and open up your php.ini file, and go down to the “extensions”, and uncomment this line:

;extension=php_xdebug.dll

So it reads:

extension=php_xdebug.dll

And then add this at the bottom of your .ini file (Note: your php.ini file may already have this, just needs to be uncommented)

[XDebug]
;; Only Zend OR (!) XDebug
zend_extension_ts="C:\xampp\php\ext\php_xdebug.dll"
xdebug.remote_enable=true
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.profiler_enable=1
xdebug.profiler_output_dir="C:\xampp\tmp"

This will enable the profiler, as well as the debugging. Restart Apache in the XAMPP control panel, and run a single PHP page (ie, I goto http://localhost/phpvms). Just run it once, and goto your C:\xampp\tmp directory. There will be a file like “cachegrind.out.<number>”. Open this file using WinCacheGrind, and you’ll see something similar to:

I’ve expanded it out, but you can see the time it takes to run each function, load any include()’s, etc. This is a great way to peek into your scripts and see what’s going on in there, and where you can concentrate your optimization efforts. I’ll share some of the things I did to optimize in the future.

I want my page’s background, navigation bar, and and main content to be randomized together on my main phpVMS site. Now, I don’t want to touch any HTML, just do it in CSS. My background is split into three files, spanning 3 divs, even though it’s one image.

My CSS looked like this:

#body {
	background-image: url(images/topbanner.png);
}

So the image has to be random, but it has to be matched up. Sounds like a job for PHP. First thing we do, is create a folder in our /images directory:

/images/bg/1.png, 2.png, etc

Next we create our PHP file to pick out a background image for us. I called it “bgimages.php”, and placed it in the root of my site (one directory up from /images). Next we change out background-image in CSS to the PHP file (remembering that paths in CSS are relative to the CSS file; I placed it with my CSS file):

#body {
	background-image: url(bgimages.php);
}

First we want to setup the total number of images we have, and then the path to our images:

$total = 4;
$basepath = 'images/bg/';

We next randomize:

$num = rand(1, $total);

And then finally show the file:

readfile($basepath.$num.'.png');

readfile() will just throw the entire file out, without processing, which is what we want to do.

Another thing we can do, instead of using the $total and $basepath, is to use the glob() function:

$files = glob('images/bg/*.png');
$num = rand(0, count($files));
readfile($files[$num-1]);

glob() will do a wildcard match in a directory, and return an array of files which match. The above will match any file ending in the .png. glob() is slower though, and since I keep my images in a separate directory, and don’t change much, I decided to go with giving the total number. The downside is whenever I add an image, I have to change the total number of images, but since that’s not that often, it’s okay. It also saves some load on the server from using glob().

The whole script:

<?php
header('Content-type: image/png');
$total = 4;
$basepath = 'images/bg/';
$num = rand(1, $total);
readfile($basepath.$num.'.png');

Not too shabby for 4 lines.

I always read about CSS being great because you could just change your site’s design without touching a single HTML file. I didn’t think it could be done, not without touching at least some HTML, but lo-and-behold… I did it (only after 5+ years of doing this…)! I changed my design across 3 separate apps – phpBB, dokuwiki, and my main site by just changing the images, sizes, and positioning in my main styles.css. Now that was cool. And it worked perfectly. I’m glad I properly went through and did the main styles properly. Now only if it would work flawlessly in IE all the time (Achilles Heel)

Obviously the index page changed, since I’m not going to use Moveable Type anymore, even though I really liked the ability to create multiple blogs with one installation. That’s the one thing I miss with Wordpress. I still have a few sites running under Moveable Type, so I can’t phase it out just yet… maybe soon. It would be a pain to swap things out. It was nice to create one set of users and give them permissions to one blog or another. Made things easy, since it was all in one place, didn’t have too much to keep track of. It also used one database, and stored the content in flat-files. I’ll have to find a Wordpress plugin which does that (which I’m sure there is). I am also going to cross-post phpVMS news here, and have it shown on the phpVMS site based on the category. Hmm…ideas for a new blog post and something to play with there. For now, I’m going to post up some GD code I wrote to create forum signatures, so messing with sizes and manipulating text. I may write that up for next week.

I’m going to be playing with SEO sometime soon, check out some good tricks and ideas to move phpVMS up to the top of search results. It’s really maturing to the point where I want to take over the world. Muahahaha…

I like all the practice I’m getting with command-line scripts. I had to update Wordpress today, which meant…

1. Downloading the latest version
2. Extracting the latest version
3. Backing up older version
4. Uploading newer version

/ol>

So there’s a few ways this could be done through a bash script – wget the latest URL, and then un-zipping or un-tar’ing that into the WP directory. This is a little more involving, since the download URL will change based on the version.

This is similar to the upgrade script I have for phpVMS, and also the upgrade script I’m offering to users to work with for upgrading. So it was good timing that it coincided with the Wordpress update. Two birds with one stone.

So looking through the Wordpress site for a viable upgrade path, I saw they use SVN for their version control – both dev and stable versions. Woohoo! Subversion to the rescue. Since this URL won’t change anytime soon, it’s a reliable source to use for upgrades. They house all of the “final” versions in the /tags directory, one directory per version, which made it even easier. They have a guide on Updating with Subversion, which was helpful on the procedure for the files which need to stay, so I came up with a small script:

#!/bin/bash
#
# Nabeel Shahzad
#  http://www.nsslive.net
#
# This follows the general flow on the following page:
#  http://codex.wordpress.org/Installing/Updating_WordPress_with_Subversion

#
# Variables
#

# Where wordpress lives on our server
WP_DIR="/path/to/wordpress"
# Wordpress stores latest versions under tags directory
SVN_ROOT="http://svn.automattic.com/wordpress/tags/"

# Go!
echo "Retreiving latest version"

LASTVERSION=$(svn list $SVN_ROOT | tail -1)
echo "Found $LASTVERSION"

# Clean out our temp directory
rm -drf wp-temp

# Check it out
svn checkout $SVN_ROOT/$LASTVERSION wp-temp
echo "Copying files"

# Copy our files over
cp -p $WP_DIR/wp-config.php $WP_DIR/.htaccess wp-temp
echo "Copying everything into $WP_DIR"

# Now copy everything backwards into where our live Wordpress lives
cp -rpf wp-temp/* $WP_DIR
echo "Removing temporary directory"

# Clean up the temp directory and delete it
rm -drf wp-temp
echo "Done!"

What I do is list the versions (svn list) in the /tags directory. The last line is the latest version available (ie, 2.5.0/), so I extract this (using tail –1), and then checkout the latest version into a temporary directory. Then according to the Wordpress guide, I copy over some of the essential files (config file, htaccess) into that temporary directory, and then copy all those files into where Wordpress lives.

The only problem is… any files which you have modified that are part of the Wordpress package will be overwritten and not copied over. You can add those files into the “Copy our files over” section, but it’s meant to be “non-destructive”, so it will only touch the Wordpress files. I have it in my public_html root, where there are tons of other files, I don’t have to worry about those getting messed up or overwritten as part of the upgrade.

All that’s left after this is running the updater, which just involves logging into the admin panel and running their upgrade script. 

Cheers!