When it is time to deploy your Satchmo store to your server, you’ll need to set up your store to automatically start on server boot.

To do this, you’ll need to set up an /etc/init.d/storename script. I’ve provided examples of my redhat and debian setup scripts here. Unpack them, and select the appropriate variant, debian or redhat. I suggest you put the “etc” tree into source control for your store, and then just symlink them into place on your server.

Many stores require that you formally accept their terms and conditions of sale before checking out. How do you pull this off in Satchmo?

It is easy, dead easy, and requires just three lines of code and absolutely no hacking of the Satchmo core. It is all done through the magic of Django Signals.

In my DjangoCon presentation, I claimed that signals and templatetags were the key to extending Satchmo without having to build everything into the base store code. This is an example of doing just that.

One of the most common questions on the Satchmo-Users mailing list is “what layout should I use for my project files?”

Since Satchmo is so flexible, it can be installed in many ways, so there is no one perfect answer to this question. However, in my experience, 9 out of 10 new stores will benefit significantly in flexibility and upgradability by adopting the layout I’ll suggest in this article.

This is based on my real-world experience as a professional Satchmo developer. Every time I’ve been hired to come to the rescue of a site which can’t launch because it just isn’t working right, the problem has boiled down to an inflexible installation. In other words, this layout will save you time, frustration, and money.

Using the excellent graph_models command from the Django Extensions app, I’ve created a set of graphs of the Satchmo models.

At DjangoCon 2008, Chris Moffitt and I gave a fairly technical introduction to Satchmo to a full room. Since it was at Google, it was recorded and is now available at YouTube.

Chris has also posted the presentation we made for the talk.

DjangoCon 2008 wrapped up yesterday, and it was a great weekend for Django and for Django’s leading e-commerce system, Satchmo.

Chris Moffitt and I made a technical presentation (view as a PDF) about Satchmo to a group of 50-70 developers on Saturday. It was videotaped for upload to YouTube, but doesn’t that the Google staff have uploaded it yet. I’ll be sure to make a post when that happens.

First Core Meeting

For the first time ever, the Satchmo core development team actually met face-to-face. The panels and discussions at DjangoCon made it completely worth my time and money to attend the convention, but even had they not been so useful, the trip would have been worth it just for the chance to meet and hang out with my fellow core developers.

We decided on our “Road to 0.8 release” strategy. We’re going to clean up the code & docs, closing as many tickets as possible in the next two or three weeks. In the meantime, Jag is going to be testing his shiny new Order Admin screens. When he’s ready, we’ll release!

The 0.8 release will be pinned to Django 1.0, making it much easier for us to tell people what version of Django to use. It is getting quite old to have to repeatedly specify “rev such-and-such” to new users on the Satchmo-Users list.

Initial 1.0 Discussion

Following 0.8, we’re going to work on a six-month release cycle, trying to fairly closely follow the Django Project’s newly announced intention to start doing timed releases.

We came up with quite a list of new or modified functionality we’d like to see in 1.0, but the primary driving force is going to be a very thorough and exciting refactor of the Product Model. Our intention is to make it much easier to allow store owners and developers to create products which exactly fit the specific needs of their store.

[tags]djangocon,satchmo[/tags]

I’ve finally committed the single most requested feature for Satchmo. “Multi-Shop” allows one installation of Satchmo to serve many shops on different domains.

In Satchmo versions before 0.7, sometimes administrators accidentally set a category as its own parent. This causes an infinite loop and hangs the site. So then they can’t even use Django to fix the error.