2 May 2012

April 2012 delivered a fresh batch of promising and useful-looking new contributed modules to the Drupal world. Perhaps because the immediately-preceding DrupalCon gave developers some time to collaborate and work on their contributions more than they normally might, this month seems to have a notable number of interesting new projects, especially considering the relatively “mature” state of Drupal 7 at this point. To help keep abreast of some of the most interesting new developments we have planned a monthly article to showcase these new modules; this is the first edition of our “Modules of the Month”. At this point in the release cycle, newly released modules are mostly only being released for Drupal 7, but a few have also been released for Drupal 6 as well; where Drupal versions are not mentioned, you should assume the module is only for Drupal 7.

Caveat: I have tested some, but not all of these modules. Be especially careful if you choose to use any of the “pre-stable” releases on production sites. I should also note that some other awesome modules released in April may not be included—I did my best to select the modules I’d be most likely to use, but there are some “special use case” modules which were not covered, but which might be very useful for some sites. The 30-something modules included here have been sorted into very loose categories.

3rd Party Integration / Social Media

Twitter Follow Block

The Twitter follow block

The Twitter Follow Block module, by Pradeep Saran, provides a nicely styled box to show your Twitter link and followers in a jQuery-loaded block that can be placed in any region of your theme. You can configure the dimensions of the block (and thus, the number of “follower thumbnails” displayed) and you can choose from different color schemes to better match your current theme. It currently only displays the Twitter feed for one Twitter user, but what might be an interesting development would be a way to dynamically load the Twitter username (e.g. from a Profile field) so that the Twitter follow block would link to different users (based on the author of content currently viewed or the profile page being viewed, if applicable). The module is currently available as a “stable” 7.x-1.0 release and I look forward to seeing this get further developed.

Social Buttons

The Social Buttons module by Linnovate’s Raz Konforti, provides a field that can be added and configured for any content type (or any fieldable entity) and includes default button code for Facebook, LinkedIn, Twitter and Google+, but you can also easily add new buttons. Since it’s a field, you can also determine where and whether it is shown for each display (node view, teaser, RSS, etc). It has a 7.x-1.0-beta2 release as well as more recent commits to the developer branch.

Content Access Control

Hidden Nodes

The Hidden Nodes module, created by Bryan Ollendyke of Penn State University, helps allow staff to hide nodes from regular visitors while still allowing users with “staff” permissions (admin or author/editor -type roles) to see the content in the menu as it will appear when the content is finished. This helps get around the issues caused by the “black-and-white” absoluteness of published/unpublished status (and only being able to access content through the “administer content” system). It was created to integrate well with the Outline Designer module, another project sponsored by Penn State. Hidden Nodes has recently had its fourth beta release and is certainly an interesting project for streamlining team-based content workflows.

Restrict node page view

The Restrict node page view module, authored by Christian Johansson of Sweden’s Kodamera AB, helps prevent users from viewing content outside of its intended context. The example use case for this module involves a requirement to prevent users from directly viewing Views slideshow nodes (via their node/xxx paths), but of course there could be other content you want to restrict access to but still have its information available in a Views display, so direct access to the node by most roles can easily be blocked with this module. The initial release is shown as “stable”, and it’s simple enough, so may never require any fixes or updates. That said, I do hope that they modify the module so that full-node access is only restricted to selected node types (i.e. blacklist). It currently adds a set of permissions for all node types, which defaults to no view access for all roles and content types, which would be a pain on sites with lots of roles and content types, especially if the goal is only to restrict non-staff access to one limited node type out of many.

The permissions created by the Restrict Node Page Access module.
30 March 2012

We have a major upcoming project here at Cocomore which is in the initial planning phase. It’s too early to provide the finer details of the project, but it involves creating a product database for a large publishing house and Drupal 7 has been chosen as the project framework. By mid-June, we will likely have four developers working on it, full-time. Of course, anyone who deals with software development almost certainly knows the problems that tend to occur during the planning of large-scale, long-term projects like this one: in the beginning, the client is often not yet 100% certain of their needs or desired end results, so new requirements and ideas arise in the middle of project development. This means that projects built to the initial specifications often fail to completely meet the client’s needs, which can be disappointing for everyone involved.

Hoping to avoid this scenario, we (our software development team, and project and senior management) proposed implementing the project using Scrum. This allows us to flexibly respond to changes in requirements and keeps the customer closely tied to the project development process so we can avoid unpleasant surprises at the end of development. At a recent Cocomore “KnowledgeLab”, I presented a brief overview of Scrum methodology, a topic which is certainly too broad to cover, in-depth, in an hour-long presentation. So I limited the scope of my presentation to the most essential elements of the Scrum process: roles, events, and artifacts; then used Lego Scrum to try to better illustrate the model. This article provides an overview of the same basic concepts covered in our workshop session and describes how I helped immerse team members who had not previously worked with Scrum in the concepts and processes. We have been using Scrum for other “ambitious” Drupal projects and plan to provide in-depth case studies for some of them, with details about more specifics related to Drupal; this article provides a general foundation for understanding these upcoming case studies.

Scrum: a process model for agile software development

Agile software development is characterized primarily by an iterative procedure with alternating planning and development phases. The advantage this provides is that parts of the system are developed early on and can be tested before implementation of other parts. This reduces the risk that project development heads in the wrong direction. Rather, responding quickly and flexibly to changes in the requirements, the components of a system can be redefined to best meet a client’s real needs.

agile_workflow_with-url_03.png

21 February 2012

Story header graphic logos associated with the Drupal 8 initiatives

I was already planning to provide an overview of what’s been going on in the various Drupal 8 initiatives even before last week, when Dries announced the timeline for Drupal 8, which includes a “feature freeze” for Drupal 8 in only a little more than nine months from now, and planned release at the DrupalCon Europe, in late August 2013.

Drupal 7’s Plateau of Productivity?

I think we reached the Plateau of Productivity for Drupal 6 sometime in late 2009, about 18 months after its release. At that point there was no advantage to developing in Drupal 5, and Drupal 7 was still a long way off. --Dries Buytaert, June 8, 2011 (about 5 months after Drupal 7’s release)While most of the top Drupal 6 modules are now available, in some state or another, for Drupal 7, and I would certainly choose Drupal 7 for a large Drupal-based project that is not expected to be deployed for some time, from the outcry of protests I think there are a lot of people who would not agree that Drupal 7 is yet at its Plateau of Productivity. I would choose development in Drupal 7 for most projects, but there is still plenty of reason for site builders to work with Drupal 6, especially if they need particular features (e.g Nodewords / Metatag functioning properly, among others) and if they need to deploy the site now, with those features ready for use. Dries indicated that he thought Drupal 6 reached its Plateau of Productivity in late 2009, about 18 months after its initial release. At that point, there were fewer than 20,000 sites using Drupal 5 and more than 200,000 sites using Drupal 6. While this order-of-magnitude-greater-usage is not likely to ever be seen comparing Drupal 7 vs Drupal 6 usage (at least not before Drupal 8 is released), I do think that it’s significant that Drupal 7 usage has finally overtaken Drupal 6. That said, I don’t think we are truly at Drupal 7’s Plateau of Productivity, the point where building a new site on Drupal 6 would be “pointless”. Both in terms of time-after-release and usage statistics, it is arguably premature to say we are quite to that point yet.

Quibbling aside, I also don’t think it matters whether we believe we have reached the Plateau of Productivity for Drupal 7, or not — and it certainly doesn’t matter whether we are all in agreement about that. I do think Drupal 7 is very “ready for use”, though and I do think we are ready to see core development for Drupal 8 get kicked into high gear and I don’t think it will significantly delay the development of certain lagging contrib modules or resolving core issues in Drupal 7 which are the final barrier, in my view, to truly reaching its Plateau of Productivity. Additionally, many of the fixes and features going into Drupal 8 are regularly being back-ported to Drupal 7, and there is increased discussion of relaxing the criteria for what can be back-ported to Drupal 7, so I see the increased attention to Drupal 8 core development as exciting: a win-win for the whole Drupal community. We now have a release date for Drupal 8, which is important for business decisions, and a better timeline to facilitate a roadmap for the final stages of determining feature inclusion.

Drupal 8 Core Initiatives

Currently there are 6 official Drupal 8 Core Initiatives which are working on various aspects of desired improvements to core. There are others likely to be added to the list as soon as a bit more progress has been made on the current list and/or as qualified individuals step up to take on some of the other “top 10” desired improvements we had on our collective community wishlist. Some of the improvements require fixes to issues plaguing Drupal 7 and 6 and have been backported. Most of the others involve dozens, if not hundreds, of related issues. Following is a brief summary of each of the current core initiatives and what their priority goals are for Drupal 8. In the interest of brevity, the explanations leave out a lot of juicy details, but for those who haven’t been paying close attention and who might like to get involved, I hope this summary is useful:

Web Services and Context Core Initiative

The Web Services and Context Core Initiative (WSCCI, pronounced “Whiskey”), formerly referred to as the “Butler” project, is a core initiative led by Larry Garfield of Palantir.net, aka “Crell” on Drupal.org. While the traditionally typical HTTP request has been for HTML pages, the modern Web has brought with it the need for HTTP services which deliver information which is not necessarily in the form of HTML. This is especially true for mobile applications, but also applies to feeds and other communications via HTTP. The goal is to “take Drupal from being a first-class Web CMS to being a first-class REST server which includes a first-class Web CMS”. Really, this initiative spans a huge range of related issues and without writing an article many times the length of this one, I could not possibly cover everything, but…

20 October 2011

As part of the Knowledge Lab at Cocomore on 2 September, 2011, I outlined how to use Jenkins to implement Continuous Integration for a Drupal-based project.

15 September 2011

If Frankfurt isn't too far for you to drive, you can mark your calendars (and sign up!) for next month's Drupal Meetup, to be held here at Cocomore's main offices. For over two years now, the Frankfurt area has had a "Drupal Stammtisch", where people from the local Drupal community have enjoyed an informal monthly gathering at KP21, a nice little bar/restaurant on the west side of Frankfurt every second Thursday of the month.

29 August 2011

Sometimes, when troubleshooting a Drupal issue on a site, it's best to determine how much time you are willing to spend on fully solving an issue and be willing to accept a reasonable compromise. We encountered such a situation recently with a rather odd issue: If an authenticated user attempted to post a comment on any of the German blog posts here, they were unable to complete the operation since the "save" button was missing ("preview before save" was required) and for some odd reason, "preview" was not working for admin or other authenticated user roles.