If you’re reading the official Shopify instructions for setting up the domain, ignore the A-Record part. All you have to do is add a C-NAME record for the subdomain and in the Shopify Domain Manager, add the subdomain.

For instance, if you want the subdomain store.mydomain.com to connect to your Shopify store at my-store.myshopify.com, add a C-NAME record “store” at the host “my-store.myshopify.com” on the “mydomain.com” domain. On the Shopify domain manager, click “Add a domain you already own” and enter the full subdomain, “store.mydomain.com”.

While it’s a shame that you can’t add your store to a folder on your domain, at least you can add a subdomain. I would imagine that a subdomain would be the way to go if you want to integrate a Shopify store with an existing website.

Oops! An unexpected error has occurred.

That’s it. No line numbers, no filenames, no broken SQL statements, nothing. So like any other FuelPHP developer would do, I turned on profiling–easy fix, right? Well as it turns out, the error broke profiling as well. So after an hour or so of tracing through code, I found the culprit: an SQL insert statement referencing a field that didn’t exist. Apparently, a simple SQL error caused the PHP framework equivalent of a kernel panic. I found problem by adding this debugging echo statement in fuel/core/classes/database/mysql/connection.php on line 209:

// Execute the query
if (($result = mysql_query($sql, $this->_connection)) === false)
{
	if (isset($benchmark))
	{
		// This benchmark is worthless
		Profiler::delete($benchmark);
	}
	echo mysql_error($this->_connection); //Add this line here
	throw new \Database_Exception(mysql_error($this->_connection).' [ '.$sql.' ]', mysql_errno($this->_connection));
}

It’s a bit frustrating that FuelPHP couldn’t detect the cause of the error, but the framework is a work-in-progress (a very good one at that), and all things considered, it’s still an awesome piece of software.

On the first day of the conference, I had the opportunity to give a short presentation on using the SugarCRM REST API. The presentation was based on a simple PHP wrapper class that I built, making it easy to create a SugarCRM client app. As you might expect, the wrapper has basic CRUD functionality (minus the deleting part), as well as support for uploading and downloading attachments for notes. Checkout the code and the presentation to try it out for yourself!

If you happen to be a Ruby on Rails fan, checkout this rails client for the REST API, based on the active record design pattern. Written by Carl Hicks and David Sulc, these guys gave a sweet presentation on the client and alluded to future improvements in the SugarCRM REST API. I’m certainly looking forward to a more robust and functional API. In the meantime, Jon Witcraft suggested a simple way to add your own API calls to your REST interface. The basic idea is, make a new class that extends SugarWebServiceImpl. Add any API call functions to the new class, and the old functions are still usable because the class extends the old SugarWebServiceImpl class.

There’s a ton of other stuff I learned at SugarCon 2011, but if I keep writing I’ll never get to try out all the new ideas. Hope you’re inspired to use the REST API and even make your own API call functions!

$data = array(
	'session' => $session,
	'note' => array('id' => $note),
	'file' => $file,
	'filename' => $filename,
);

As it turns out, I misread the rather confusing documentation on this specific call. In actuality, the API requires a different data array structure like so:

$data = array(
	'session' => $session,
	'note' => array(
		'id'=>$note,
		'file' => $file,
		'filename' => $filename,
		'related_module_name' => 'Cases'
	)
);

All the fields pertaining to the note must be in an array under the ‘note’ index. A very aggravating subtlety that cost me way too much time to figure out.

After my first “Save for Web & Devices” export, I immediately noticed that the colors in the exported image were lighter and more subdued. So my first instinct was to check the export settings, but after some searching around, I finally found the culprit under Edit > Color Settings. My active preset was “North America General Settings 2″, that dirty son-of-a-gun. I switched to “Monitor Settings” and my problem was cured.

If you have the same problem, I hope that solves it. I use an Apple MacBook. I would imagine the problem would be different on a Windows machine. It would be nice if Photoshop could automatically calibrate itself, but hopefully it’s a simple fix on any machine.