My experience with Satchmo
I have just finished setting up my first site using Satchmo, a framework for building online stores using Django. You can check out the site online: All Natural Bully Sticks (incidentally, do you know what a bully stick is? Gross!).
Getting this site set up was an incredibly frustrating process. The majority of which wasn’t actually Satchmo’s fault. I started out hosting it on Dreamhost but, for the reasons you can read about below, switched to Slicehost when that didn’t work.
Problem One – SSL on Dreamhost
The first main problem I hit was trying to get the site to properly redirect between secure (using SSL) and insecure pages. When a customer finished checking out, instead of redirecting to a ‘success’ page Satchmo would just show a blank page. Looking at the Apache error logs, it kept complaining about ‘NoReverseMatch’. After assuming this was an issue with Satchmo for a week (why is it redirecting to the wrong place?!) I found out that I had mod_security turned on through the Dreamhost admin panel. Turning this off allowed the page to get redirected just fine.
That is until I turned on SSL for the Authorize.net payment gateway. Then instead of showing a blank page, it would show a page that said the customer’s cart was empty. It was empty because they just finished checking out, but that was the wrong page! And to give you all the sordid details, because I was deploying on dreamhost I had to use an older version of Python, Python 2.4. Python 2.4 doesn’t come with the SSL module built-in so you have to use the backport. In order to install the backport you have to have the OpenSSL lib installed. Dreamhost has OpenSSL installed but not its developer libraries. Because I was running on a shared server I didn’t have sudo
access, so I installed the OpenSSL developer libraries into my home directory. Home free now, right? Nope! Not even with a lot of fiddling could I get the SSL backport to properly find the location of OpenSSL. It is literally hard programmed to look in certain directories for OpenSSL (in /usr/
). Well, no worries, I say! I’ll just install Python 2.6 into my home directory but point it at my new OpenSSL install. But still no luck. It can find OpenSSL when installing but not when it was running. It was at this point that I threw in the towell and switched to Slicehost.
Having full root access to a machine is basically the greatest thing ever. Want to install something? No problem!
Problem Two – Email is spam
Getting the site up and running on Slicehost was a breeze. I basically just checked out my code and then installed the dependencies. In the end there was only one problem with this new set up. All of our emails kept getting caught by spam filters. The solution was a little thing called Reverse DNS. DNS is for turning a domain name into an IP Address, and RDNS is just the opposite. By default Slicehost gives you an RDNS entry that is your.ip.address.slicehost.net
. However, email clients use this RDNS entry to check when you send mail as allnaturalbullysticks.com
to see if you actually own that domain. So, you want your RDNS entry to match your DNS entry. Because they didn’t match for us we were getting flagged as spam. Updating the RDNS did the trick!
Thoughts on Satchmo
Those were the major problems I had. Like I said, completely unrelated to Satchmo. However, that doesn’t mean Satchmo gets off scot-free! For the most part I think Satchmo is absolutely great and it is doing the job quite well.
My minor complaints:
- The documentation is lacking. Maybe I’m just used to the great documentation for Django but I felt really unsure about most of the steps I was taking. Maybe some more tutorials would be nice. Here’s a good example (look at the PayPal section. I was planning on using PayPal as a credit card processor. That isn’t possible with Satchmo currently. At least not without writing your own payment module. I didn’t know this until halfway through setting it up).
- The templating system doesn’t appear to be implemented very consistently. Basically the only way to figure out which template a given bit of code is in, is to use the Debug Toolbar and then go searching through every template mentioned. The checkout templates seem particularly convoluted.
- Sometimes templates are rendered through template tags. When they are rendered through template tags, they don’t show up in the Debug Toolbar, thus making them even harder to find.
- The templates don’t seem to have any consistency when it comes to markup. Sometimes they use
<h2>
s for page headers and sometimes<h3>
s, and it goes on from there.I think they should use the simplest markup to get the point across (basically paragraphs, lists and headers) and then supply lots of class names and IDs for CSS hooks and then leave the rest up to the developers. If you need something more complicated, then overwrite the template. I ended up overwriting every single template that you can navigate to on our website. - Why are some settings (like shipping address) configured in
/admin/
and some settings (like shipping modules) in/settings/
? I understand the difference, but I think they need to be merged into one place—put them all in the database in site configuration.
That said, Satchmo is working great for us now; I’d recommend it.