We’ve recently started working on a bigger set of changes that require a feature branch. But, these changes also will require WordPress to be upgraded to 3.3, requiring database changes.  Making it impossible to use the same database.

I was able to come up with this nifty technique for determining which DB to use.

$stringfromfile = file('.git/HEAD', FILE_USE_INCLUDE_PATH);
$stringfromfile = $stringfromfile[0]; //get the string from the array
$explodedstring = explode("/", $stringfromfile); //separate out by the "/" in the string
$branchname = trim($explodedstring[2]); //get the one that is always the branch name
 
// ** MySQL settings - You can get this info from your web host ** //
if($branchname == "master")
{
	/** The name of the database for WordPress */
	define('DB_NAME', 'wordpress_local');
}
else
{
	define('DB_NAME', 'wordpress_new');
}

That’s all there is to it. It works flawlessly.

Happy coding.

To make this possible, I used jQuery Marco Polo, a very nice autocomplete plugin available here: https://github.com/jstayton/jquery-marcopolo

I had to modify it to make it work exactly how I wanted, but it does the job.

Basically, jQuery Marco Polo takes input into a search field and runs it against a URL in realtime using AJAX. It expects a JSON response from this URL. It has many options on how to display items and what to do when items are clicked.

The first challenge was getting the results into JSON. To do this, I created a function to intercept requests that match a certain format: /q=?somesearchterm&ajax=true

Pretty basic. Here is the function:

add_action('wp', 'ajax_autocomplete_search', 1000);
 
function ajax_autocomplete_search() {
	if(isset($_GET['q']) && isset($_GET['ajax']) && $_GET['ajax'] == "true" && !empty($_GET['q']))
	{
		$q = $_GET['q'];
		shopp('catalog','search-products',"load=true&search=$q");
 
		if(shopp('category','has-products'))
		{
			global $Shopp;
			$filter_cat = $_GET['category'];
 
			$results = array();
			$count = 0;
			$used_products = array();
 
			while(shopp('category','products'))
			{
				if($count == 3) continue;
 
				$product_id = shopp('product','id','return=true');
 
				shopp('catalog','product',"id=$product_id&load=true");
				require(TEMPLATEPATH.'/name-vars.php');
 
				if(!in_array($first_name, $used_products))
				{
					$used_products[] = $first_name;
 
					ob_start();
					shopp('product', 'coverimage', 'width=60&height=60');
					$image_tag = ob_get_clean();
 
					$summary = shopp('product','summary','return=true');
					$slug = shopp('product','slug','return=true');
 
					if(strlen($summary) > 90)
					{
						$summary = substr($summary,0,strpos($summary,' ',90))."…";
					}
					else
					{
						$summary = $summary;
					}
 
					if(shopp('product','in-category',"name=$filter_cat") || (!isset($filter_cat) || $filter_cat == "Everything"))
					{
						$results[] = array('name' => $first_name, 'summary' => $summary, 'image' => $image_tag, 'slug' => $slug);
					}
					$count++;
				}
			}
 
			if(count($Shopp->Category->products) > 3 && count($results) == 3)
			{
				$results[] = array('name' => 'footer', 'summary' => 'See All Search Results', 'search' => $_GET['s'], 'category' => $_GET['category']);
			}
 
			if(count($results) > 0)
			{
				echo json_encode($results);
			}
		}
		die;
	}
}

Now, you’re going to notice right away that there are a lot of specific things going on here that cater to the specific way I implemented this. For instance, I only show the first 3 results with a “See All Results” footer. This also assumes that you, like me, have implemented a category filtered search as described here. There is also some custom stuff in there based on the way we name things. (that’s the name-vars.php and $first_name stuff…I won’t go into that)

No matter. You should be able to see what I’m doing and modify it as necessary.

So that, with some modification, should throw some nice JSON responses out.

Other than that, I just used the following JavaScript:

jQuery("#category-dropdown").change(function() {
				jQuery('input.search').marcoPolo({
				  url: '/?wp-minify-off=1&category=' + jQuery("#category-dropdown").val() + '&x=0&y=0&ajax=true',
				  param: 'q',
				  formatItem: function (data, $item) {
				  	if(data.name != "footer")
				  	{
				   		return '<h2>' + data.name + '</h2>' + data.image + '<p>' + data.summary + '</p>';
				   	}
				   	else
				   	{
				   		$item.addClass('footer');
				   		return data.summary;
				   	}
				  },
				  onSelect: function (data, $item) {
				  	if(data.name != "footer")
				  	{
				    	window.location = '/shop/' + data.slug;
				    }
				    else
				    {
				    	window.location = '/?s=' + data.search + '&category=' + data.category + '&catalog=true';
				    }
				  },
				  formatNoResults: function (q, $item) {
				  	$item.addClass("mp_selectable");
				  	$item.click(function() {
				  		window.location = '/?s=' + q + '&category=Everything&catalog=true';
				  	});
				  	return '<em>No results for <strong>' + q + '</strong> in ' + jQuery("#category-dropdown").val() + '.<br /><br /> Try your search again in Everything?</em>';
				  }
				});
			});
 
			jQuery("#category-dropdown").change();

Again, not the briefest example. It’s either show all or show nothing. You’re going to have to work around my particular usage of all of these things. I instantiate Marco Polo when the dropdown is changed because the search URL depends on the drop down selection.

I modified Marco Polo to get rid of it’s hijacking of the ENTER key, etc. I just removed all of the key binding because it didn’t support the way I wanted to use it.

You can see this fully working here: Moore and Giles, Inc.

Type in Brompton, for example.

That’s it. Feel free to ask questions.
Clif

It turns out to not be very difficult, once you understand the way Shopp handles searches.

The trick is that the category template (i.e., theme/shopp/category.php) is used to display searches. This allows you to easily jump in and decide how it is displayed, based on your own criteria.

So, you will want to create a copy of your category.php file named something like category-default.php. Then create a separate file named category-search.php. The former file will handle the default category page functionality. The second will handle searches only.

In category.php, do something like this:

if(isset($_GET['s']) && isset($_GET['catalog']))
{
	include_once('category-search.php');
}
else
{
	include_once('category-default.php');
}

Basically, if the URL parameters for a search exist, use the search template, otherwise, stick to the normal game plan.

Then in category-search.php, you’re going to want to use your own loop to exclude every category but the one you’re interested in:

<?php
if(isset($_GET['category']))
{
	$category = $_GET['category'];
}
?>
<?php if (shopp('category','has-products')): ?>
	<?php while(shopp('category','products')): ?>
	 	<?php if(shopp('product','in-category',"name=$category") || (!isset($category) || $category == "Everything")): ?>
		// your code to display in your own html using the product tags (model it after the default category template, for example)
 
		<?php endif; ?>
	<?php endwhile; ?>

Lastly, you’ll want to render the search form yourself instead of using the default widget. For example:

			<form id="search" action="<?php bloginfo('url'); ?>" method="get" accept-charset="utf-8">
				<div class="search-perimeter">
					<input autocomplete="off" class="search" type="text" name="s" value="" id="find" />
					<select size=1 name="category" id="category-dropdown" title="Search in">
						<option value="Category 1 Name">Category 1 Name</option>
						<option value="Category 2 Name">Category 2 Name</option>
						<option value="Everything">Everything</option>
					</select>
					<input type="image" class="search-button" src="<?php bloginfo( 'template_url' ); ?>/images/search.png" />
				</div>
				<input type="hidden" name="catalog" value="true" id="catalog" />
			</form>

That’s about all there is to it. You’ll have to get in deep with the templates, but I think you’ll agree this is conceptually pretty simple.

Lastly, you should note: Category names seem to be case sensitive. “Bags” != “bags”

Good luck,
Clif

I have been frustrated by the vastly different ways e-mails from my company’s site (http://www.mooreandgiles.com) render in different clients.  After some research, I decided the trick to fix this would be inlining all CSS styles, as various clients will haphazardly abort style blocks you include in your e-mails.

Being lazy and wanting to the greatest flexibility for modifying templates in the future, I came up with a way to automatically process e-mails and inline their styles as they leave.   As this hooks into wp_mail, it should work with most plugins that send HTML e-mails.  Some may go around WordPress and use PHP mail…I can’t help you there.

In your theme functions file, add this:

add_filter('wp_mail', 'html_email_prep');
 
function html_email_prep($email) {
	if(strpos($email['headers'], "html") != false )
	{
		$message = $email['message'];
 
		//Grab CSS block
		require_once TEMPLATEPATH.'/css_to_inline_styles.php';
 
		$cssConverter = new CSSToInlineStyles();
		$cssConverter->setCleanup(true);
		$cssConverter->setHTML($message);
		$cssConverter->setUseInlineStylesBlock(true);
 
		$new_html = $cssConverter->convert();
 
		$email['message'] = $new_html;
	}
 
	return $email;
}

And, simply dropp css_to_inline_styles.php in your theme folder. You may download it here: http://blog.verkoyen.eu/blog/p/detail/convert-css-to-inline-styles-with-php

With this in place, it will automatically parse outgoing e-mail messages. It will find the style block and inline each style, automagically. This instantly fixed most of the rendering problems I was having in various clients.

It automatically excludes e-mails that don’t have HTML. I have seen the class bork up one HTML template, but making a minor change to the markup avoided the problem easily. Make sure you test.

It occurs to me that the greatest tribute to Jobs is his work on the iPhone. In four years he revolutionized the way we think about, use, and what we expect from smartphones.

In 2007, the smartphone industry was a horror show of ugly, slow hardware with archaic input. Each phone seemed to have a larger keyboard, antenna, and battery. This was progress. Then came the first iPhone. Critics scoffed at it. No one would want a touch screen only device. It was too expensive. You couldn’t multitask. It didn’t had GPS or 3G. It was laughably expensive. It would fail miserably.

In 2008, the iPhone 3G was too slow. The screen too small. Too low resolution. Android was going to win because it was open.

2009 brought the too minorly improved 3GS. Apple was poised to be left behind, their massive lead would be quickly absorbed.

Then came the iPhone 4. Within a year of its release, my dad bought one. So did 4 of my non-techie friends. Most people I know that don’t have one, no longer say they never will get one. Android has grown, but the iPhone continues to dominate and define the technology.

I scoffed with the scoffers until 2009. Since then, I have converted from full Windows to full Mac. I bought an iPad. Great products create their own demand.

So that’s Steve’s legacy to me. In four years, he made the smartphone a household device. In four years he took a device from a toy for fanatics and nerds, to a cultural phenomenon. And all around the world, salesmen are pitching the competitions’ products as “Just like an iPhone.”

My friend Jeremy noted it should be called the iPhone 4Steve. I think he has a point. There’s no greater tribute to him than his last revolution.

Clif

Sent from my iPad

The script used Imagick to composite two images together on the fly.  It used WordPress for database connectivity by including wp-load.php.

Strangely,  Firefox reported the image to be corrupt.  I downloaded the image being generated and ran Imagick’s “identify” command against it via SSH.   The tool reported the file had “two SOI markers” and “extraneous bytes before marker”.  Exciting stuff.

After wracking my brain and starting the process of opening a StackOverflow post,  a thought occurred to me:  What if the problem is coming from WordPress.  I threw together a quick proof of concept using Imagick and tested it.  Worked fine.  I then included wp-load.php at the beginning…corrupt image again.

At this point, I knew the problem was most likely a plugin. I realized that the only plugin difference between our test and production site was a plugin called WP-Minify that handles JS/CSS/HTML minification.  I tried disabling it and magically the script worked again.

Unwilling to sacrifice the advantages of WP-Minify, I looked through the code.  It turns out you can pass in wp-minify-off=1 as a URL parameter to any page to prevent it from processing.  A very easy solution.

So there you go. That’s my story.   If ImageMagick / Imagick is outputting a corrupt JPEG, and you are using WP-Minify,  now you know how to solve it.

Today, Media Temple tweeted about an article on optimizing WordPress.  While it makes some good points, I feel like there were some omissions that are worthy of sharing.  So, that’s what I intend to do.

A word about caching.
No article on optimizing WordPress is worth anything if it neglects to mention the world of caching plugins.  Such plugins are relied upon by millions and are a great way to achieve large performance increases in just a few steps.   In fact, I have used such plugins to fix constant crashing on high traffic websites. The two I am most familiar with are WP Super Cache and W3 Total Cache.

While these have their place,  there are a couple of reasons I tend to avoid them:  mainly they can break things,  and they try to do everything.

Now, I’m sure I just offended a few people.  You can certainly work around the occasional (and often minor breaks).  And more features isn’t always bad.

My hangup is that when they do break things, it is often difficult to troubleshoot because of the sheer volume of moving parts.  There are so many nuances to the settings and it can be extremely difficult to find the right balance simply because it can be impossible to understand everything the plugin is trying to do on your behalf.

There are also many plugins that simply do not work with caching plugins. So some don’t even have a choice.

The goal here is to provide a list of things that nearly everyone should consider.  These approaches are specific enough to be understood and minimalist enough to implement on a site that’s already established.

Out of control JavaScript (and CSS)
It happens to everyone.   You build a theme or buy one.  You install it. You customize it.  You install some plugins.  And soon, you find that your site is loading 20 complete JavaScript libraries on every single page load.  NextGen Gallery has hijacked your home page.  Contact Form 7 is running it’s validation scripts on your About Us page.

All of this is costly in terms of page load times.   Your goal should be to never load a JavaScript file on a page where it isn’t being used. Ever.

So, open your site in your favorite browser and start going through these files one by one.   I found it helpful to use the YSlow add-on for Firebug in Firefox for this.  Once you do a scan, you can view the components in a list and sort by size.   This can give you a great way to prioritize what scripts you are going to tackle first.

If you are loading a script in header.php that is only used on one page, consider moving that include to a page template or wrap it in a conditional:

<?php if(is_page('your-awesome-page-slug')): ?>
<script src="evilscript.js" type="text/javascript">
<?php endif; ?>

Some will be more challenging.  If you have plugins adding scripts, you’ll have to figure out how to prevent the script from being included where it isn’t wanted.  Often a quick Google search will show other people who have tackled the same issue.  I was able to disable the javascript/css components of several plugins in just a few minutes, relying on other’s expertise.

It is much faster for PHP to selectively unregister a script in functions.php than for your browser to download and process it.

You should notice immediate, tangible improvement as you work down the list.

Combine and minify
Once you have your JavaScript and CSS running at a bare minimum, it’s time to combine and minify.  The more files your browser has to touch while loading a page, the slower.  The goal of combining is to reduce several requests into one.  The goal of minifying is to reduce the total size of a download by removing comments, line breaks, etc.

Now, I know what some of you are thinking “But you can do this with caching plugins!” Which is true.  But, as we’ve already mentioned we’re trying to take a minimalistic approach.

While there are plenty of online services you can submit your CSS and JavaScript files to for minification, this is often highly inconvenient.  It forces you to maintain development and production versions of your files (which may not make sense for the size of your operation), and it can be difficult to troubleshoot if you don’t have a working test environment.

Enter WP Minify.

WP-Minify has the magic ability to do all of this on the fly.   Install. Activate.  Done.  It even minifies your HTML output.

Now, with anything like this, there can be issues so you’ll want to do full regression testing on anything that requires JavaScript once you’re done.  You’ll also want to pay close attention to styling as it can have an inadvertent effect on the order styles are loaded. (That whole “cascading” part of CSS)

If you have a problem with a script (as I did), the easiest thing to do is just add it to the list of exclusions.  This allows you to reap 90% of the benefits while not changing your whole site to fit an optimization technique.

It also does some other little things for you like setting far future expiration dates and enabling gzip. (More on that later)

Alternative PHP Cache
This next tip only applies if you have a dedicated (virtual or physical) server with root access.   PHP, while having many awesome qualities, is not known for being the fastest language in the world.   This is mainly because it compiles and recompiles each script every time it is requested.  Large operations like Facebook get around this by converting their PHP to C before publishing, but that isn’t a very practical solution for most people.

The most reliable way to improve PHP’s processing time is to use an opcode optimizer.  This allows PHP to cache the compiled version of a page and rerun it from RAM on subsequent requests.  This is tons faster than pulling from disk and recompiling! While there are several options in this realm, I think Alternative PHP Cache is the best choice for two simple reasons: 1) It is made by the PHP guys 2) it’s going to be built into PHP 6

Those are pretty strong reasons to get on board in my book.

Installing APC is relatively easy depending on your server config.  There are many guides, often specific to the hosting service so I recommend you do a quick search before you get started.

Tweaking the settings can have a learning curve.  I recommend you accept the defaults and then tweak once you have a chance to watch how it performs.   The basic concept is this:  you have a certain amount of dedicated cache where pages are compiled and stored.  If this cache fills up frequently, it forces APC to flush the cache.  If this happens often, you get what’s called cache churn which can actually hinder performance.   Your goal is to have a large enough cache with a good expiration interval that allows the cache to stay relatively full without actually running out of space.

The nice thing about APC is that just installing it gives you a performance boost.  But, since this is about WordPress, I recommend you install APC Object Cache Backend.  This allows WordPress’s built in caching engine to fully leverage APC’s features.   Read the instructions carefully…this isn’t installed like a normal plugin.  The file actually goes in wp-content/ directly.  Weird, I know.

Optimize those images
In addition to the above, images are often the slowest component of a page.   Make sure you use JPEGs wherever appropriate and stick with PNGs only where lossless is absolutely necessary or where transparency is desired.

For JPEGs, pick a quality level that will satisfy your level of pixel OCD.  The smaller the files, the faster they’ll load.

Once you’re done with that,  you should use a tool that can losslessly optimize your images.  I chose jpegoptim for this.  Because I’m a nerd, I installed this on my server and setup a cron to run it against my images (of which I have many thousands on the install I’m referencing) weekly.

It’s easy to install and easy to run.

Just run this via SSH:

jpegoptim --strip-all /your/awesome/path/*

This will optimize each image, skipping any that will result in a larger size or no change.

(A word of caution, I found that this altered the permissions of my images…so double check the permissions after you’re done.)

In total, I was able to cut down my images sizes 10% with no loss of quality.  That’s pretty cool.

Expiration and Gzip
The fewer times a browser refreshes your static files from cache, the faster your load times will be.  Because of this it’s desirable to have a lengthy expiration date on your JavaScript, CSS, and image files.   This is most easily accomplished with the Apache module mod_expire.  Your server probably already has it installed *crosses fingers* and turning it on/configuring it is rather easy.

Similarly, mod_deflate for Apache can gzip plain text files for faster delivery.  The small cost of server overhead is well worth the advantages of smaller downloads.  Processing time is cheaper than bandwidth (at least in this case).

To set this up, I suggest you look at this guide.

Et Cetera
Beyond this, there are many other things you can do, but I’ve tried to cover only the things I think go most unnoticed and apply to nearly every install. I highly recommend you use the aforementioned YSlow plugin and Google’s Page Speed feature (available in Chrome and Firefox) for more performance tips. (And many of these were inspired by such tools).

In addition to what I’ve recommended, there are literally hundreds (if not thousands) of techniques out there:

1. You can enable a conservative caching plugin like Hypercache (which hopefully plays nicely with the above plugins).
2. You can optimize your MySQL tables (to reclaim free space).
3. You can limit how many revisions WordPress keeps for each post by modifying wp-config.php.
4. You can offload commenting to services like Disqus.
5. You can change your scripts to run asynchronously.
6. Etc. Ad infinitum.

As you can see, it would be fairly easy to waste* a lot of time here. (I once saw this called the “Holy Grail of micro-performance optimizations”) But, that being said, it’s worth diving into these things at least once.   Your users will like it.  Google’s page ranking will like it.  And you’ll like it.  You may even be amazed by the results.  (I know I was!)

*If you see anyone telling you to get rid of references to get_bloginfo() in your templates in favor of hardcoded paths, tell ‘em to take a hike.  That’s a truly pointless change and you won’t see any real performance gains…WordPress is smart enough to handle that stuff inexpensively.

Twitch for Blinksale is the first native iPhone/iOS client for the popular invoicing service Blinksale. With Twitch, you can manage all of your invoicing needs right from your iPhone.

Its clean, professional design highlights the information you need. Updating invoices on-the-go has never been easier.

Invoices Features:

• View, add, update invoices.
• Send invoices to clients with or without payment link.
• Receive payment for invoices.

Client Features:

• View and add clients.
• Add people to clients.
• Contact clients directly from phone (using the iPhone’s phone and mail apps)

More:

• Convenient, “Pull To Refresh” design on invoice and client views makes reloading data a cinch.
• Tested on multiple iPhone devices and OS versions.
• Very stable.
• Secure credential storage in keychain.

Screenshots:

Twitch for Blinksale is available for purchase in the App Store.

We found a situation recently where we had images with different sizes in Shopp, making uniform usage difficult at times. To compensate for this, we exported the images again. Since we use a consistent naming scheme, we didn’t have to worry about names.

We then uploaded these new images over the existing images in the /wp-content/uploads/shopp folder.

In a perfect world, this would be all there was to it, but unfortunately Shopp stores width and height information about an image in the database. This meant each table entry had to be updated. Enter this script.

It automatically scans your uploads directory and looks for images that have a different size than is stored in the database. It then updates the size.

WARNING: This script is DESTRUCTIVE. It can potentially screw up your database so PLEASE make sure you have a full backup. This is provided without any warranty whatsoever. I have only tested this on Shopp 1.1.17 and have no idea how it will work/not work on other versions.

<?php
//Adjust to point to root from where this script is located
require '../wp-load.php';
 
//Edit this path
$path = '/var/www/vhosts/domain/httpdocs/wp-content/uploads/shopp';
 
// END EDITS. You shouldn't have to edit below this line.
 
header("Content-Type: text/plain");
ini_set("auto_detect_line_endings", 1);
$dir_handle = opendir($path);
$row = 1;
$csv_data = array();
while (false !== ($file = readdir($dir_handle)))
{
	if ($file != "." && $file != "..")
	{
		$width_regex = '/((?<=width\";i:)[0-9]{1,4})|((?<=width=\")[0-9]{1,4})/';
		$height_regex = '/((?<=height\";i:)[0-9]{1,4})|((?<=height=\")[0-9]{1,4})/';
		$query = "select value from wp_shopp_meta where value LIKE '%"".$file.""%'";
		$info = getimagesize($path."/".$file);
 
		$existing_properties = $wpdb->get_var($query);
 
		if(strlen($existing_properties) > 10)
		{
			$new_width = $info[0];
			$new_height = $info[1];
 
			preg_match($width_regex, $existing_properties, $old_width);
			preg_match($height_regex, $existing_properties, $old_height);
 
 
			if(($new_width != $old_width[0] || $new_height != $old_height[0]) && !(empty($old_width[0]) || empty($old_height[0])))
			{
				echo "Updating $file. Old width/height: ".$old_width[0]."/".$old_height[0]." New width/height: $new_width/$new_height";
 
				$new_properties = preg_replace($width_regex, $new_width, $existing_properties);
				$new_properties = preg_replace($height_regex, $new_height, $new_properties);
 
				if(strlen($new_properties) > 10)
				{
					$query_update = "update wp_shopp_meta set value = '".mysql_real_escape_string($new_properties)."' where value LIKE '%"".$file.""%'";
 
					//echo "Query update: ".$query_update."n";
 
					$update = $wpdb->query($query_update);
 
					if($update == 0)
					{
						echo " --- FAILED. No rows changed. Didn't update.n";
					}
					else if($update > 1)
					{
						echo " --- POSSIBLE FAILURE. Updated too many rows.($update)n";
					}
					else
					{
						echo " --- SUCCESSn";
					}
				}
				else
				{
					echo "--- FAILED. New properties string suspiciously short.";
				}
			}
		}
	}
}
?>

Hope it helps. Let me know if there are questions.

The advantages for this are obvious, especially when you have 3000 images and your database has bloomed to several hundred MB.

Failing to find one, I decided to write my own. Shopp’s image store rules (at least in 1.0.14) seem to follow this model:

• Check wp_shopp_asset table to see if an image has been stored in the data column.
• If it isn’t there, assume it’s in the filesystem path.

After about an hour, I came up with this solution (WARNING: This script is DESTRUCTIVE. It will delete all of your images from the database so PLEASE make sure you have a full backup. This is provided without any warranty whatsoever. I have only tested this on Shopp 1.0.14 and have no idea how it will work/not work on other versions.):

<?php
// Copyright 2011, Clifton H. Griffin II
// This script is DESTRUCTIVE.  It will delete all images in your database!
// Run at your own risk. It is provided with NO WARRANTY WHATSOEVER.
// Please read carefully and do a full backup before using!
// Test with Shopp 1.0.14
 
//EDIT THIS LINE (this directory must be writeable)
$path = "/var/www/vhosts/domain.com/httpdocs/wp-content/uploads/shopp";
 
//Load WP data objects
require 'wp-load.php';
 
//Get list of rows from shopp
$sql    = "SELECT id FROM wp_shopp_asset";
$results = $wpdb->get_results($sql, "ARRAY_A");
 
//Loop through them, grabbing images
foreach ($results as $row)
{
	$id = $row['id'];
	$therow = $wpdb->get_row("SELECT name, data FROM wp_shopp_asset WHERE id = $id", "ARRAY_A");
	$image = $therow["data"];
	$name = $therow["name"];
 
	echo "File name: ".$path."$name <br />";
	$file = fopen($path."$name","w");
	fwrite($file, $image);
	fclose($file);
 
	//Clear image from DB
	$wpdb->query("UPDATE wp_shopp_asset SET data = null WHERE id = $id");
}
//Optimize the table to clear unused space
$wpdb->query("OPTIMIZE TABLE wp_shopp_asset");
?>

It should be fairly self-explanatory. Use at your own risk. I create a public github repository to host the file, on the off chance others want to add to it: https://github.com/clifgriffin/Shopp-Image-Export

Let me know if it helps you out.