We had another packed studio at the March Denver Drupal meetup! Thanks to all who attended in person and via the live TV broadcast and online stream.
After kicking off the meeting the the standard round of introductions, Jason donned fuzzy Yeti costume hands to promote DrupalCamp Colorado 2011 which will be held in Denver on June 11 and 12. DrupalCamp Colorado is one of the largest DrupalCamps, with over 300 attendees at last year's camp. This year, DrupalCamp Colorado will feature it's own mascot: The DrupalCamp Colorado Yeti. The Yeti is a perfect match for a mascot, as Yetis are known for their love of the Colorado Rocky Mountains, good beer and Drupal.
In addition to DrupalCamp Colorado, we were excited to announce that DrupalCon 2012 will be held in Denver! The Colorado Drupal community is anxious to host our colleagues from the global Drupal community and to make DrupalCon Denver 2012 a huge success. More information about DrupalCamp Colorado and DrupalCon Denver, including volunteer opportunities can be found at the DBUG group page.
Following the event announcements, Jason and Scott gave a presentation about Drupal.org issue queues. One of Drupal's best features is its active community. But like any community, there are some best practices that should be observed when participating in the community. To demonstrate these best practices, Scott, playing the role of YetiLover5280 installed the DrupalCamp Colorado Yeti module, which creates a Yeti block that counts down the days until the start of DrupalCamp Colorado. YetiLover5280, being an avid IE6 user, noticed that the block did not display properly in Internet Explorer. First, YetiLover5280 searched the project's issue queue to see if there was an existing IE related issue. It's always best to first search for an issue to see if solutions exist and to avoid duplicates when creating new issues. Not finding an existing issue, YetiLover5280 created a new issue, referencing the priority levels and status settings pages as guides. In the demonstration, YetiLover5280 left a bad issue description that it was simply "Broken in IE." It's always best to leave specific details about any problem you encounter, including steps to replicate the problem. If the problem generates an error message, it's also best to include the exact error message.
Jason, as the module maintainer, closed the issue as he didn't have enough information and the module "works as designed," or intentionally didn't work in Internet Explorer. Scott, now playing himself and wearing large Yeti costume feet, submitted a patch and set the issue status to "needs review" which reopened the issue. All community submitted patches should request community review to ensure that they not only work, but also abide by Drupal coding standards.
When submitting patches, the patch file should be named [issue_id]-[description]-[comment_number]-D[drupal_version].patch.
- The issue id can be found in the issue page's URL.
- The description should be short, but clearly reference the problem described by the issue.
- The comment number is simply the number you expect your comment to be. So for example, if there are 4 comments on a particular issue and you're submitting a patch, you can assume a comment number of 5.
- Finally, the Drupal version is the version of Drupal used. In the case of multiple module versions for a single version of Drupal, you could add a dash and the module version. For example, if a module offered versions 1 and 3 for Drupal 6, you could use D6-1.0 or D6-3.2 to describe those module versions and sub-versions.
In the demonstration, YetiLover5280 noted that the patch only fixed the problem in IE9, but not in his beloved IE6. Setting the status to "needs work" and describing the patch's problems, prompted Scott to submit an updated patch and again request "needs review." Finally after YetiLover5280 reviewed the updated patch and verified that it solved the problem, Jason updated the module and marked the issue as "fixed." Often a project maintainer will require multiple members of the community review a patch before committing it, so while contributing patches to the community is helpful, testing and reviewing patches is equally important. To learn more about applying patches, you can reference the drupal.org patch application page.
Following the issue queues presentation, the meetup held an open question and answer time. The first question was regarding single sign on which allows users to login on one site in order to access multiple sites. A common solution for this is to use the Bakery, but Bakery is limited to sites with the same primary domain, but different subdomains. CAS was suggested as an alternate solution.
Another attendee asked about managing members on a drupal site, specifically in regard to purchasing memberships. In Drupal 6, this is easily accomplished with Ubercart, which includes a Roles module in its core set of modules. Roles lets users purchase a Drupal role, which at its most basic will distinguish those users from other users. However, by using roles, you can extend that functionality to give roles access to restricted content or the ability to purchase special products. To limit product purchases, you could either set the product to only be viewable by users with a specific role, or you could use Ubercart's conditional action functionality to check a user's role when adding products to their cart.
While Ubercart is being developed for Drupal 7, there is a large community shift to use Drupal Commerce instead of Ubercart. Both Drupal Commerce and Ubercart for Drupal 7 are still in beta testing and lack many of the extended features of Ubercart for Drupal 6, but both are expected to have full releases soon and extended functionality modules will soon follow.
The status of Drupal Commerce and Ubercart for Drupal 7 led to a follow up question: How do I know if it's safe to upgrade from Drupal 6 to Drupal 7? While the core Drupal 6 to Drupal 7 upgrade process went through thorough testing, there are many modules written for Drupal 6 that have yet to be ported to Drupal 7 and may hinder your upgrade efforts. The Upgrade Status module is a helpful tool which you can install on a Drupal 6 site to determine which modules on the site have corresponding Drupal 7 versions. Similarly, the Hacked! module can be installed on a site to determine which modules have modifications that would be lost during an upgrade.
Good Drupal development means that core files and modules should not be hacked or modified. This prompted a new-to-Drupal attendee to ask the group about the typical Drupal development learning path. Most Denver Drupal developers agreed that using Drupal usually begins by installing, configuring and administrating a Drupal site, and particularly learning about existing Drupal modules and how to configure them in conjunction with other modules in order to accomplish specific tasks. Once you gain a better understanding of what modules and functionality are available, it's easier to know where custom development can extend existing functionality. The learning curve for custom development can be steep, because as mentioned, good development means that you shouldn't modify core or contributed modules. This is because in Drupal, there are hooks that allow you to modify or alter data. For example, the hook_form_alter() allows you to modify forms generated by Drupal core and contributed modules without having to directly modify the core files or module code that originally generated the form. To learn more about hooks and other available functions, api.drupal.org is an indispensable tool. The Examples and Coder are useful to see working examples of Drupal code and verify that your code abides by Drupal coding standards. Finally, Build a Module is an excellent resource to learn about building Drupal modules and other Drupal development.
As always, many thanks to Denver Open Media Foundation for not only providing the meetup space, but also their broadcast and video work. The recorded video for this meetup should be available on the Open Media DBUG page soon. Information about upcoming meetups can be found on the DBUG groups page and we hope to see you at an upcoming meetup.