Despite the cold and the holidays, the Denver Drupal users group still met a few days after Christmas to discuss a few general web issues in addition to Drupal specific topics.
Most of the Denver Drupal users have experience in a number of CMS (Content Management Software) systems and some light discussion about current projects transitioned to the technologies and CMSes being used for those projects. Naturally, Wordpress (Drupal's evil arch-nemesis) was discussed! Although Drupal Camp Colorado 2010 featured a session comparing Wordpress to Drupal, as developers, many of us felt the session was good for discussion, but didn't touch on enough of the underlying structures of Drupal and Wordpress that would really help developers choose the right CMS for a particular project. As the benefits of each system were discussed, it became clear that much of the lauded simplicity and ease of Wordpress is in part, because the underlying framework is simple. When trying to do more complex tasks that Drupal could easily handle with CCK or hooks, Wordpress's implementation of content types and use of filters and actions seems limited or immature at this time. While Drupal and Wordpress could both learn from each other, neither is in any jeopardy of being outdone by the other.
Following the relatively calm Wordpress vs. Drupal discussion, we discussed conversion tracking and testing. Many sites use Google Analytics to track users from specific landing pages on their site to a conversion page where they complete a specific task (e.g. purchasing a product). Google also provides website optimizer tools for A-B and multivariate testing. A-B testing allows you to create two different versions of a page, altering the text and design layout of each to determine which is more effective at leading users to a conversion page or task. Multivariate testing applies multiple versions on a finer scale, allowing you to test differences in specific elements on a page. The Google Website Optimizer module allows you to easily integrate the Google code into your Drupal site. You can also forgo Google's tools and do your own multivariate testing with the Multivariate module.
Groupon and other social/group bargain sites are becoming extremely popular and one attendee asked a question about allowing users to purchase coupons through Ubercart. The Ubercart Discount Coupons module can create coupons and email those to customers after a purchase. One of the potential problems is that the created coupon code isn't available in the user's order history. One potential solution that was offered was to use Ubercart's conditional actions to write the coupon code to field for later access. Another solution is to use the order number to predictably generate the coupon code (e.g. by a hash).
Ubercart and many online store systems collect payment information and pass that information to a payment gateway such as Authorize.net or Paypal, which perform the actual payment transaction. Depending on the level of PCI compliance necessary, even simple tasks like passing (but not storing) the payment information through your server could be problematic. Most payment gateway services offer a hosted payment page, so users are directed to their servers for checkout and then back to your site when the transaction is complete. While this solves the compliance problem, it usually presents a branding and user experience problem because the hosted payment page rarely carries the look and feel of your web site. One solution is CyberSource's Silent Order Post which allows you to host a payment form on your site, but send the submitted data directly to their servers for processing. Users are directed to pages on your site based on the success or failure of their transaction . The user experience is seamless as the user is never presented with an actual page from CyberSource. Cybersource payment integration is included in the core ubercart module.
Continuing the discussion on security, one developer noted that Drupal 6 stores user passwords as plain MD5 hashes. That means if you see "5f4dcc3b5aa765d61d8327deb882cf99" in the pass column of your users database table, that user's password is "password". The recent Gawker hack emphasizes how important it is to keep your users' data safe. Although MD5 hashes were designed to be one way (i.e. very difficult to determine the plain text password using only the hash), advances in computing and public rainbow tables have made them easier to crack. A common defense against this is to salt your hash and salting is standard in Drupal 7. To make your site more secure, you can use the Password module, which is a backport of the Drupal 7 code into Drupal 6, or the Salt module.
With all the salty discussion, we ended the meetup slightly early and headed to the Breckinridge brewery for some food and beer.
Information about upcoming meet-ups can be found at the DBUG groups page. And as always, we hope to see you at the next Denver Drupal meetup!