Liveblogging Drupal Commerce Camp Lucerne 2011 / Saturday

The second day of Drupal Commerce Camp is starting rather relaxed with an empty campus on Saturday. We are now split into three tracks (two regular, one training) and so sessions have thinned out somewhat. Off to the talks.

How do I monitor Drupal

The thinning out had the effect that the audience could introduce themselves and their background. Fischer starts off with probably the most important question on why to monitor: "How do you know that your site is currently up and running?"

The usual suspects: Nagios, Munin, Cacti. Interesting other solutions are New Relic (apparently used by Acquia), Groundwork and Zenoss. Surprisingly few complete solutions. Other interesting modules which can come in handy at times but are not really monitoring tools: prod_check, hacked, hosting_stats, variable_changes.

Drupalmonitor.com is a tool with a Drupal focus and not server maintenance or analytics in general, needs one module and the site should be successfully monitored under drupalmonitor.com. Monitoring apparently secured by a hash, looks like sniffing and replay attack might work here, speculating.

An interesting example is the analysis of watchdog here, split by type (i.e. page not found), which shows the development nicely over time, that information is normally hidden behind the tabular log entries report. I want that. Currently in free beta, with a tentative freemium model for monitoring more than one site. D7 release not yet out.

Date based pricing in Drupal Commerce

Phillip is showing his work on decoupling prices and products. The module Commerce Limited time Offers (LTO) creates temporary line items to perform price calculations where rules can be used to then compute. This looks at the two use cases of different prices based on different time unites (i.e. weekend/weekday) or different ranges of dates (i.e. seasonal prices during the summer). Interestingly, also makes it possible to go down to second-base pricing (though you probably only want daily). It also accounts for the fact that caching of a price until a specific time (i.e. midnight) is considered.

Fundraising and Donations with Drupal Commerce

Schmidt is showing the Commerce interactions in regards to donations, coupons and redeeming modules with Drupal 7. Donations are in essence one item per cart but the cart module is used to be able to rely on all the features it offers, while skipping the cart form with rules (/cart as a path is actually available if typed in by hand).

Variable pricing for donations can either be solved by creating unique products for each price entered, or changing the price on the fly of the product. Solved here with Commerce Product Option and rules then changes the product price for the transaction.

Coupons are integrated with Commerce Coupon but the extra case of users not entering more than the coupon value and thus not having to enter payment information has to be considered. Also, coupons should be able to be set by users, e.g. when a large company wants to hand out 1000 coupons and for the users the amount should be given by the coupon code and not by manually entering the amount. The solution was to use taxonomy terms: easy import, redeem status and associated amount per term. This showed really nicely how the workflow of Drupal Commerce was adapted to fit a custom transaction process and isn't limited to the cart-billing-done workflow. Hadn't actually used fields on terms before, that's a neat trick.

Lunch break.

How to sleep without the server-crash-fear

Schmidt talks about how they moved back from the cloud and are now primarily relying on APC, Varnish, MySQL master/slave and memcache on their own resources. The first, APC, is a nice basic PHP cache but as he points out, maxed shared memory has to be set sensibly. Default often 20MB, D7 needs 35MB at a minimum and they use up to 400MB.

An interesting file-system-level strategy is serving Apache webservers with GlusterFS as a distributed file-system. The auto-heal functionality in particular looks quite interesting.

Looking at MySQL, if you are running a master/slave configuration a neat fallback strategy is to declare one slave to be the hot-spare master. This does not switch automatically when the master goes down, though it is possible to configure this in Drupal but they are switching this manually.

Varnish is the reverse proxy which handles those queries which do not involves sessions, cookies and SSL extremely well and fast. Also an interesting point is to use Pressflow for D6 to backport some lazy session handling. Looking for modules which create a session for some reason as a performance problem is something I'll probably have to look into.

Schmidt concludes with their reasoning on why they choose managed hosting at a local hoster over Amazon resources after trying them due to price, performance and an actual person to call when things go pear-shaped. I definitely agree on his argument that Amazon pricing on a 24h basis is not cost-effective, even if it's cool that you can bring instances up and down at will.

Import and synchronize products with Feeds and Commerce

Feeds is a powerful module that allows non-developers a wide array of integration options. It separates into fetcher (grab), parser (we now have arrays) and processor (target entities and assigned to fields) and at each level one can cleanly adapt Feeds to the proper use case. So, Cambra shows us how one can create a product reference importer and how much can be managed right in the Feeds administrative pages and is easily accessible, even to novice Feeds users. Apparently even pulling in images should be possible, what else could a PIM want?

The alternative would be Commerce Migrate, which also makes converting Ubercart to Commerce often possible.

And that's it for day two.