Liveblogging Drupal Commerce Camp Lucerne 2011 / Sunday

Day three of three has arrived, sadly not with the perfect weather we had the past two days, then again the sessions are indoors anyway.

Writing payment modules for Drupal Commerce

Lorétan from Wunderkraut had worked on payment modules with Ubercart but was less than happy with the overall experience and then looked into Drupal Commerce. First good news: it's not much different. Naturally, security and consistency (process-wise) is vastly more important in the payment area compared to other areas. Paraphrased: If you don't know about security, don't write a payment module. And that's good advice. Also, national and international regulations do affect creating payment modules and have to be considered to some degree.

At the most basic level a manual payment involves entering information, which is validated and then a transaction is created and is pending on the payment gateway, hooks are shown, (in theory) done.

A more complex example is credit card processing via a payment gateway validation and act on answer of the payment gateway. So, in contrast to manual transactions we have local validation and remote validation (which creates an authorization answer) and then create a remoe transaction tied to a local transaction, the latter part is heavily dependent on the payment gateway (i.e. some providers allow you to authorize a card and directly execute the transaction). Commerce Payment does offer helper functions for standard credit card elements which avoid having to redo the obvious tasks of CC number field, expiration, etc., neat! His slides then show examples of how to carry out the transaction, formatting request information for a particular gateway and formatting the output/error codes for the user.

The third option is off-site payment, such as SagePay (or for a Swiss example, Datatrans offers the same). Thus we have enter information, local validation, redirect and the return page is what to act upon.

Tips. Make sure you have a test account, naturally. Have the documentation, error codes can be obtuse; same experience here, incredibly important and not always given. The documentation may also be erroneous and thus have a contact person at the payment provider. Writing tests should be mandatory but is not always possible (also depends on having a test account). Finally, consider what happens after the initial transaction, e.g. reimbursement/refunding/cancelling. The payment gateway can probably do this, but how will this be reflected on your site?

Module migration from D6 to D7

Plüss asks you to clone the module first (if it's in contrib), so your patch can go to upstream later. Obviously change the core version in .info, fix the dependency listing. White screen of death, turn on debugging. Iteratively fix. Kinda waiting on a coder upgrade tutorial.

In the link_node example he uses we now have the module enabled, no errors but a non-working module, his tip is to look for the hooks used, here this is hook_filter() which changed to hook_filter_info(), so check the upgrade guide and API reference.

Audience question on coder upgrade. He hasn't seen it yet, it wasn't ready 3-4 months ago. Damn, I failed at this two weeks ago and the multiple parser dependencies required on my test system.

He recommends submitting even incomplete patches with provide some functionality for D7 so the maintainer has something to work from and consider taking over abandoned modules.

Lunch break.

D7 and XHTML+RDFa

Schaffner starts off by talking about the Google panda update, which does take unique, creative content on the web into account and semantic declarations count. Right now, we have lots and lots of acronyms for standards, microformats and namespaces (OWL, RDF, SPARQL, FOAF, DDC, etc. etc.). D7 integrates RDFa. Some more background infos, still wondering about microdata with schema.org and the Google/Bing/Yahoo announcement a few months ago.

RDF does come to the editor at the level of the content type, where a "RDF Mappings" tab allows setting semantic properties on e.g. type, title, body. To actually do something you apparently need to enable the external RDF vocabulary import module, then you get proposed elements via ajax (e.g. hmedia:Audio).

Interesting other modules to consider are SPARQL Views and VARQL for working with semantic data.Schaffner hasn't yet tried implementing it on taxonomies and terms but he is fairly certain that this is currently not supported. Audience input on possibly using the relation module for this.

And it's over, lots of interesting talks and people to talk to over the last three days. Looking forward to the next event, hopefully something long before Drupalcon Munich 2012  in August.

This is part 3 of 3. See also the commentary on the Friday and Saturday sessions.