Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 36 min 10 sec ago

Last Call Media: Drupal's Pipeline for the Soul: See ya in Austin!

Thu, 29/05/2014 - 18:21
Drupal's Pipeline for the Soul: See ya in Austin!

I’ve always loved Open Source. As a college student, studying philosophy and reading Emma Goldman and Mikhail Bakunin, discovering the Debian/Linux community was an affirmation of the ideal collaboration possible between humans. I made Debian my chosen distribution of Linux and ran off of the Sid repository because I had newer hardware which needed experimental drivers at the time. Sid is the codename for the unstable distribution of Debian where the initial heavy development happens, where packages are released first. I watched with every apt-get dist-upgrade as a tireless open source community labored to make it all work. New features every day, new fixes and sometimes new bugs, only to be followed again by new fixes.

Nobody had to be doing it. They just did. They just wanted to. They were making it work for them and it was working for me. It was beautiful.

There is something about solving problems that is really enjoyable. Solving them in collaboration with other people is even better. It is a mode of being that is truly rewarding and intrinsically valuable. In software development, there is a solvable problem at every turn and instant gratification when the 1s and 0s align. Doing this in collaboration with others is more than just gratifying. As if the strategy of collaborating to survive and thrive is innate to us; it triggers a sense of belonging to something greater than ourselves.

As I later fell into a career as an IT consultant, I stayed very close to open source. There was no doubt in my mind that whatever the answer was going to be, it was going to have open source in it. This was when Drupal started taking off like a wild fire. As if designed for collaboration, it seemed the entire open source community was looking to Drupal as its solution to the world’s content management problems. Drupal code was easy to share, fix and contribute back. As the community grew, so did the collaboration. My company started doing projects in Drupal and contributing our work back to the community. Not only was this rewarding to everyone involved, it also rewarded my company with new incoming billable projects. It was basically a “Pipeline for the Soul.”


Running a business can be hard. There is no promise that anyone will need your help ever and you only stay in business as long as you are needed. The upcoming batch of work is your “pipeline.”  While waiting for people to call for help leaves too much to chance, keeping that pipeline full while doing your current work can often seem an impossible task. In the web development business, one option is to respond to as many formal Requests for Proposals as possible. You win a few here and there and hopefully stay in business. It is a well known fact that responding to Requests for Proposals is time consuming, demoralizing, and it basically completely sucks to do. With Open Source, there is another beautiful dynamic that makes for a truly healthy pipeline of upcoming work.

A healthy pipeline is not only one that is full. A healthy pipeline is one that fills in naturally.

Consider the current state of Drupal as an open source community. There are community organized elements within it that create the kind of pipeline I am describing. These are Camps, Conferences and Community Involvement.

Rob and I are starting to prepare for our trip down to Austin, Texas for the 2014 North American DrupalCon. It is here we will be looking forward to getting some face time with people we’ve been collaborating with, solving Drupal problems with, over the internet on a regular basis. For us, the primary goal of conferences is not lead generation. That’s not how this works for us. We go to the conferences for the community and for the in-person collaboration and community presentations (sometimes given by us). We know from experience that our involvement here will help take care of our lead generation on its own.

Here is the path we've watched our clients follow on their way to engaging their first project with us:

  1. Seeing us at Camps and Conferences
  2. Seeing our Community involvement
  3. Finding our Drupal Marketplace page
  4. Visiting our Website
  5. Downloading our Sales-y brochure thingy
  6. Contacting us by phone, form, or email

We’ve realized that the first two stops on that list are who we really are. We love the collaboration and the learning and sharing of knowledge at the Camps and Conferences. We love the involvement of contributing back work to the same community pool of code we benefit from. It simply just feels good. While the next three are a presentation of who we are (with the last one being engagement), the beautiful part to us here is the experience that we stay in business to the degree in which we stay authentic to who we are. Doing the things we love and being ourselves fills our pipeline.

We’ve also realized that these first two steps to engagement are not only self-sustaining but have a strong positive impact on the health of our team. This is due to the personal motives in play in the type of participation involved. Open Source software is inherently inclusive and collaborative. The vast majority of participation is driven by intrinsic motives for personal growth, relationships, and helping others. It is an endeavor that creates actual happiness, dedication, and community. To do this as a team is invaluable. Doing this as a society is our best work.

So... See ya in Austin! You will find us in a great session, at an after conference event, or participating/mentoring in a code sprint.

Categories: Elsewhere

Acquia: Ultimate Guide to Drupal 8: Episode 4 - Multilingual Improvements

Thu, 29/05/2014 - 18:15

Welcome to the 4th instalment of an 8-part blog series we're calling "The Ultimate Guide to Drupal 8." Whether you're a site builder, module or theme developer, or simply an end-user of a Drupal website, Drupal 8 has tons in store for you! This blog series will attempt to enumerate the major changes in Drupal 8. Successive posts will gradually get more technical, so feel free to skip to later parts (once they're published) if you're more on the geeky side.

Categories: Elsewhere

Drupal Association News: The Business Side of Drupal: A Research Journey

Thu, 29/05/2014 - 17:58

Jonathan Sims is Assistant Professor of Strategy at Babson College. A 2013 PhD graduate from the University of Texas at Austin, he wrote his dissertation on entrepreneurship within Drupal.

Over four years ago, as a 3rd year PhD student at the University of Texas at Austin, I made a risky move. I asked my advisors, all hard-core researchers, to foot the bill to send me to SXSW Interactive. I told them that “Interactive” was the future of SXSW, a conference that at the time was known far more for music and film.  I needed a dissertation topic, and argued that the conference that birthed Foursquare and Twitter was a great place to look.  They took the bait.

At the conference, I attended a session entitled, “Selling the Milk when the Cow is Free.”  Several of you were there. It was my first introduction to open source business models.  The panel spoke eloquently about the business benefits of “giving back” and “riding the community wave.”  For a student of strategy, these were almost heretical ideas.  Dominant strategy theories emphasized the “resource based view,” arguing that companies should protect, even at great cost, whatever resources they had that were valuable, rare, or difficult to imitate or substitute.

Here was a room full of entrepreneurs succeeding by doing the opposite.  I’d found my dissertation topic, and a new friend – for on that panel was Palatir’s Tiffany Ferris, who told me I “must go” to my first DrupalCon in San Francisco. Four DrupalCons and a Drupal-themed dissertation now behind me, I continue to research the novel business ideas that make Drupal firms so successful.

Over the next several weeks, I’ll be sharing those research findings in a series of posts.

In the next post, I’ll reflect the main findings of my dissertation, which was made possible thanks to the support of the Drupal Association and the 250 organizations that completed the Drupal Business Survey.  If you’re interested in reading more about the results of that survey, I’ve worked with a talented team at Palantir to make a formal report available for download.

Later this year, I will be launching another Drupal Business Survey in partnership with the DA.  We’re still putting on the finishing touches… and in the spirit of Drupal, we’re asking what you would like to know.  What research questions do you have for entrepreneurs in the Drupal community? Send you suggestions to me at or tweet me @jonsims.

Next Up: Four “So What” Research Findings about the Drupal Community

Categories: Elsewhere

Acquia: Acquia Cloud API Applications: A quick tour

Thu, 29/05/2014 - 13:27

The Acquia Cloud API is a web service and CLI that allows developers to build powerful tools, automate repetitive tasks, and create custom development and testing workflows for sites on the Acquia Cloud platform. Released two years ago, our customers and partners have been building amazing things on Acquia Cloud API and we figured it was time to share some of them.

Categories: Elsewhere

Shushu's blog: Organic groups API == nicely built architecture

Thu, 29/05/2014 - 08:27

I started to work in Gizra more than 6 months ago. While I did have lots of Drupal experience, I didn't have a lot of Organic groups experience, especially not in Drupal 7 version.
As a developer, I am more interested in the way things are built and less in the way they look. I mean, I know my way around front-end and user interface, but a good looking UI won't make me as exceited as a well developed piece of code.
This is why I enjoy working with OG - since it is well-structured, lots of things works flawlessly, and easy to enhance.

In this post I want to focus on one particular task, and how it was easily done once you know OG API.

Our client decided they want to have a description for each taxonomy term, and to show the description when showing the taxonomy term page. This is easy, considering by default there is a description field. Then they decided they don't want to show the field in all pages, and they want it to be configurable.

The solution seems simple - adding a new boolean field for each taxonomy term, which will define whether the description will be seen or not, and then to use the taxonomy-term.tpl.php to show or hide the description according to this field.

The problem is that since we are working in OG (specifically in OpenSchoalr project), we can't and should not add the field manually, and considering each of the authorized site users can create their own vocabulary, we need to add the field automatically when the vocabulary is being created.

Gladly, OG API is built for those kind of tasks, and with several steps we can achieve what we want.

First, we need to define the field that we need. Once it is defined, it can be exported and then used in code. While it might be possible to define the field manually, I believe it is always better to avoid guessing Drupal multi-dimentional-unvalidatible arrays, and to leave this task for the machine.

  • Create a taxonomy vocabulary via and then add the field you need via
  • Use the features UI in order to create a new feature that includes the new field you just created. We won't use the feature as is, this is just a simple way to export the field configuration (I guess there are other ways as well).
  • Once you download the features file, look for the code inside the hook_field_default_field_bases() and hook_field_default_field_instances() implementations. This is the code we will use later on.

Second, we need to tell OG we have a new field, and to define how OG should use it. This is done using hook_og_fields_info(). What you need to do is to create a new module (or use one of your own modules), and create an implementation of this hook, in which you will add the code exported from the last step (with minor changes). One important issue is the name of the field - it needs to be correct in all places, and it is what you will use later on.
Please look carefully into the comments inside the code in order to see what needs to be changed manually.

Note that the best way to verify your configuration is correct is by using the OG UI in order to manually add this field to your structure via If your configuration is correct (don't forget to clear cache...) you will see the new field in the fields list.

To be certain, just add it manually to a vocabulary and see whether it is being added properly.

Third, we want to add an action saying "whenever new taxonomy vocabulary is created, add our cool field to it". To do so we need to hook into Drupal core bundle creation (thankfully, vocabulary is an entity, and each new vocabulary is a bundle...), and this is done via hook_field_attach_create_bundle. What you need to do is to create an implmenetation for this hook in your module, and there to use the nicely-structured OG API `og_create_field` with the name of the field you defined in the last step.

Yep, "this is it" !

Is it ?

It is, as long as you build new site. Considering you might handle an existing OG site, that might already have a bunch of taxonomy vocabularies, you must handle all of them as well, and the best way to do it is automatically via the installation or upgrade process.

On how to use the `hook_install`, `hook_update_n`, and when and how to use the Batch API - in another post.

Hope this post helps anyone,


Ralates to: DrupalDrupal PlanetOrganic groupsOpenScholarhook_og_fields_infohook_field_attach_create_bundle
Categories: Elsewhere

Palantir: D8FTW: Unit testing for realsies

Wed, 28/05/2014 - 23:54

Code testing: It's like exercise. It's good for you, but most people really don't want to do it. Unless you develop a habit for it and feel the benefit, most people will try to avoid it. And if it's too hard to do it becomes easy to avoid.

That's really unfortunate, as good testing can have a huge improvement on the quality of a system and, over time, even improve how fast a system can be developed because you spend less time finding and fighting old bugs and more time building things right the first time.

Drupal 7 introduced testing to the Drupal world for the first time, but not really unit testing. Unit testing, specifically, is testing one "unit" of a larger system in isolation. If you can verify that one unit works as designed you can confirm that it doesn't have a bug and move on to finding bugs elsewhere. If your tests are automated, you can get notified that you have a bug early, before you even commit code.

The problem with Drupal 7 is that it doesn't really have units. Drupal's historically procedural codebase has made isolating specific portions of code to test extremely difficult, meaning that to test one small bit of functionality we've needed to automate installing the entirety of Drupal, create for-reals content, test that a button works, and then tear the whole thing down again. That is horribly inefficient as well as quite challenging to do at times, especially given the poor home-grown testing framework Drupal 7 ships with. As a result, many many developers simply don't bother. It's too hard, so it's easier to avoid.

Now fast forward to Drupal 8 and we find the situation has changed:

  • That historically procedural codebase is now largely object-oriented, which means every class forms a natural "unit" candidate. (Class and "testable unit" are not always synonymous, but it's a good approximation.)
  • Because most of those classes leverage their constructors properly to pass in dependencies rather than calling out to them we can easily change what objects are passed for testing purposes.
  • In addition to Simpletest, Drupal now includes the PHP-industry standard PHPUnit testing framework.

All of that adds up to the ability to write automated tests for Drupal in less time, that run faster, are more effective, and are, in short, actually worth doing.

Smallest testable unit

Let's try and test the custom breadcrumb builder we wrote back in episode 1 (The Phantom Service). Here it is again, for reference:

// newsbreadcrumb/src/NewsBreadcrumbBuilder.php
namespace Drupal\newsbreadcrumb;
use Drupal\Core\Breadcrumb\BreadcrumbBuilderBase;


NewsBreadcrumbBuilder extends BreadcrumbBuilderBase {
   * {@inheritdoc}
  public function applies(array $attributes) {
    if ($attributes['_route'] == 'node_page') {
      return $attributes['node']->bundle() == 'news';


   * {@inheritdoc}
  public function build(array $attributes) {
    $breadcrumb[] = $this->l($this->t('Home'), NULL);
    $breadcrumb[] = $this->l($this->t('News'), 'news');
   return $breadcrumb;

We want to test that the logic in this class works as expected but without testing the entirety of Drupal, or even the entirety of the breadcrumb system if we can avoid it. We just want to test this code. Can we? With good OOP design and PHPUnit, we can!

First, let's create a new testing class in our newsbreadcrumb module. This class does not go in the same directory as our code itself. Instead, it goes in a separate "tests" directory but follows the same file/name pattern.

// newsbreadcrumb/tests/src/NewsBreadcrumbBuilderTest.php
namespace Drupal\newsbreadcrumb\Tests;





* Tests the News breadcrumb builder.
class NewsBreadcrumbBuilderTest extends UnitTestCase {

  public static function

getInfo() {
    return array(
      'name' => 'News breadcrumb tests',
      'description' => 'Tests the news breadcrumbs',
      'group' => 'News breadcrumb',



It should look fairly familiar for anyone who's written a Drupal 7 test. The main difference is that we're extending UnitTestCase, which is a very thin extension of PHPUnit's main base class for tests. Now we can define some test methods. As in Drupal 7, a test method is one that begins with test. Rather than assume we have a complete Drupal install and making actual HTTP calls against it, though, we'll just test our class directly.

  public function testApplicablePage() {
    $node_stub = $this->getMockBuilder('\Drupal\node\Entity\Node')


$attributes = [
      'node' => $node_stub,
      '_route' => 'node_page',


$builder = new NewsBreadcrumbBuilder();


Categories: Elsewhere

Propeople Blog: Challenges and Opportunities in the Upcoming Drupal 8 Upgrade

Wed, 28/05/2014 - 21:08

When Drupal 7 reached public release in January of 2011, it made waves for being more accessible and more performant than any Drupal to come before. Drupal 8 is likely to receive similar acclaim in the same vein, but to a much greater degree. Easier to use, better performance, and offering simpler, more flexible development, Drupal 8 is poised to improve the Drupal ecosystem more than ever before.

It’s still around six months until the core change, but this post will run through the challenges and opportunities coming up in Drupal 8.


An object-oriented approach lowers the barrier to entry for new developers

Drupal 7 and all previous versions used a procedural approach to scripting. This means that code is executed the same way every time the script is run. Procedural scripts are more reliable, but less customizable. Reliability is good, but in order to capitalize on it, developers must be intimately familiar with exactly what procedures are occurring, and in what order. This depth of knowledge gave Drupal 7 its famous steep learning curve.

The object-oriented approach used by Drupal 8 means that the execution of scripts will be much more dynamic. Functionality is treated like mutable objects, able to be modified programmatically. With object orientation, Drupal will operate more like a true API. Newcomers will appreciate this, since the framework will more closely resemble popular imperative languages such as C++ or Javascript.

Having a lower barrier to entry for new developers means that the Drupal community will grow even faster. This is good news for everyone, since it means more Drupal projects will be created, more Drupal jobs will be available, and the labor pool for Drupal development will be even larger.


“Twig” reduces front-end programming, makes it easier to develop site themes

Theming is a huge part of Drupal. It’s what separates the look and feel from the functionality of a site. Previously, Drupal used its own PHP framework for developing and executing theme files. Drupal 8 is integrating the Twig framework from the Symfony library, giving frontend developers a new box full of rich and well-established tools. Twig doesn’t reduce the capability of Drupal’s theme engine, but instead makes it easier to accomplish the same tasks with fewer lines of code.

Since Twig is used widely among Symfony developers, the barrier to entry for newcomers will be lower here, as well. More developers creating themes more easily means that we’ll see a real surge of high-quality themes moving into the future.


Streamlined content editing inspired by “Spark”

There are several ways to create content in Drupal 8. The default experience is simple and understandable, but not the most intuitive process. Starting with Drupal 8, the Spark framework will be fully integrated with Drupal core, enabling the following features:

  • True WYSIWYG via drag-and-drop layout tools

  • Powerful save tools: autosaves, drafts, and more

  • Mobile content authoring and administration support

A more streamlined authoring environment means your content creators will spend less time fighting the interface and more time creating great content. Imagine a content authoring system that’s more like Google Docs and less like Facebook Posts. This is the vision of Drupal 8.


Redesigned toolbar for centralized navigation

Good user experience begins with intuitive navigation, no matter the framework. Drupal 8 has a redesigned toolbar that appears at the top of the page for any content moderator — not just admins.



With the new “shortcuts” menu, authors will be able to bookmark popular content. This will be particularly useful during development — both of the site and of content in progress.


Accessibility options expand the audience for your site

Drupal 8 has several new accessibility options built into core, such as:

  • Large fonts for the visually impaired

  • Braille export for the severely visually impaired

  • Screen reader export

  • Better multilingual support

In the age of online content, the more markets you can reach with your message, the better. Drupal 8 is bringing content to a whole market segment that very few appeal to — the visually impaired.

In addition, Drupal will have dynamic multilingual capabilities including on-server translation. In areas where Google translate is not available, Drupal will offer to translate pages for users. If you have a dedicated localization team, you can optionally save content for a page in each language and have your team review it.


Simpler integration with third-party web applications

Part of the object oriented approach to Drupal 8 is its expanded support for RESTful applications. With the Web Services framework, Drupal will be able to seamlessly communicate with any web platform that uses the REST API. In additional, Drupal content can be serialized between formats such as JSON, XML, binary, and plain text. This enables tighter and more performant integration between different platforms.

Drupal 8’s launch is still half a year away, but the developers at Propeople are already getting excited. Nothing scratches a programmer’s itch like a truly flexible core, and Drupal 8 is all about flexibility. These changes come at the cost of familiarity, however. Instead of a scriptable core, we’ll have a programmable core. Although the transition will take some time to get used to, we agree with Drupal creator Dries Buytaert that the big changes will be worth it.

The upgrade to Drupal 8 won’t be easy, but as Dries Buytaert (the founder of the Drupal project) stated:

The reason Drupal has been successful is because we always made big, forward-looking changes. It’s a cliché, but change has always been the only constant in Drupal. The result is that Drupal has stayed relevant, unlike nearly every other Open Source CMS over the years. The biggest risk for our project is that we don't embrace change.

These words of wisdom apply not just to Drupal, but to any business with a significant online presence. When it comes to websites, the biggest risk in ignoring emerging technologies is the possibility of being left behind. Contact us to learn how Propeople can help you stay ahead.

Tags: Drupal 8Check this option to include this post in Planet Drupal aggregator: planetTopics: Tech & Development
Categories: Elsewhere

Phase2: Having Drupal Performance Nightmares? Join the Dream Team in Austin!

Wed, 28/05/2014 - 19:45

We’re exactly a week away from the start of DrupalCon Austin and I’ve been working hard over the past two months to button up our High Performance and Scalability with the Dream Team training at DrupalCon Austin. I’ve been honored to give this training at DrupalCon Denver, DrupalCon Munich, and DrupalCon Portland, as well as a free version of it at BADCamp 2013.

The Curriculum

In the training, we go from a base Ubuntu LTS machine and go through the process of configuring it first for a basic LAMP stack and then adding in key pieces of the scalability puzzle like Redis, Varnish, and configuration tweaks that help with front-end performance tweaks for Drupal. We also go over MySQL query analysis and optimization, as well as basic profiling with the Devel module and on into advanced profiling with XHProf to dig into performance problems. (A printed copy is also provided.)

This time around, we’ve done a revamp of the Varnish section to talk about exciting new changes in Varnish 4 and are also adding a good amount of new information on MySQL query analysis and optimization, as well as incorporating considerable feedback from previous trainings.

We also typically try to leave a little time at the end of the training to take freeform questions – the combined team has a wide variety of experience with a number of performance, monitoring, and automation tools. In past years, we’ve set up basic automation with Jenkins, talked about ApacheSOLR and advanced Varnish configuration, and distributed filesystems.

The Team

The team here really is a dream team, and I’m humbled to be able to share the podium with the others trainers every time we do this training.

Dan Reif

Dan is a longtime Drupal sysadmin and a member of the infrastructure team. He helped the Drupal project scale its own web infrastructure, and assists with ongoing performance and stability. By day he is the Director of Emerging Technology at BlackMesh, who offers managed hosting and private cloud solutions to help a variety of customers run their websites without worrying about their management. BlackMesh is generously donating the training server environments to participants in the training so you will have a server reference of the work done in class (provided for a limited time after DrupalCon).

Mark Sonnabaum

Mark Sonnabaum is the Senior Performance Engineer at Acquia. He has contributed significantly to projects that make it easier to scale and manage Drupal including the Redis Queue and XHProf modules as well as considerable work on Drush. He is also the maintainer of the cache and queue subsystems in Drupal core and has dedicated considerable time to improving the architecture of Drupal 8. He has also done a good deal of work on optimizing the performance of Acquia Hosting.

David Strauss

David Strauss was a driving force in creating Pressflow 6, a fork of Drupal which made high-performance sites possible in the Drupal 6.x series. He has helped high-profile clients like Wikimedia Foundation, Creative Commons, The Economist, and NBC Universal scale their web infrastructures to handle massive traffic. He is currently a co-founder at Pantheon where he has been pushing PHP performance to its limits using the latest technologies in the Linux kernel and systemd and empowering major clients to run their Drupal (and WordPress) sites without worrying about servers.

Yours Truly

I’ve had the pleasure over the years of working with major media, publishing, and government clients to ensure that their sites would stay up under heavy traffic load, including helping Robin Hood’s small infrastructure handle millions of visitors for information about their 12-12-12 concert for Sandy relief. I’m also a member of the infrastructure team where I manage the logging infrastructure that helps us process more than 2 billion logs a month for aggregation and search to track down errors and help keep all the * properties up and stable. I’ve also recently been doing work on helping to make it easy to scale Drupal on Red Hat’s OpenShift Platform-as-a-Service.

Join Us

As of the publication of this blog post, we still have a few seats left. Please join us in Austin if you manage a Drupal site and want to learn how to scale it!  In the meantime check out Phase2′s top 10 DrupalCon Austin session picks.

Categories: Elsewhere

Phase2: Workflow within Open Atrium 2

Wed, 28/05/2014 - 19:37

A key requirement in most organizations is a content approval workflow.  The typical Drupal solution uses the Workbench Moderation module. However, the Workbench Moderation module only allows you to create a single site-wide workflow.  What if you need different workflows in different Open Atrium spaces, or between different content types?  The solution is the new Open Atrium Workbench module!

The Open Atrium Workbench module, along with several dependent modules, was a collaboration between Phase2 (srjosh and myself) and the Community (dsnopek).  It allows you to define multiple workflow “profiles” and apply them to content types within Open Atrium Spaces and Sections.  It also allows you to specify the Groups and/or Teams who are allowed to moderate content through the workflow.

Workbench Moderation Profiles

A workflow “profile” is a collection of States and Transitions.  A “State” represents where in the workflow a specific piece of content is, such as “Draft”, “Needs Review”, “Published”, etc.  A “Transition” is the act of moving between two states. Typically a Transition can only be made by a specific set of users with proper permissions.  For example, only members of a specific Working Group might be allowed to approve content, or only members of the Marketing team allowed to Publish content.

The Workbench Moderation module allows you to create these States and Transitions, but applies them globally across the entire site.  The new Workbench Moderation Profile module (currently a sandbox) creates a new entity-type for storing workflow profiles.  The States and Transitions are still created globally by Workbench Moderation, but the actual collection of these being used for a specific workflow are controlled by the profile entity.

Workbench Moderation Profiles is very generic and doesn’t care exactly how these profiles are applied.  Submodules to support Organic Groups and Content Types are provided.  Hooks are available for further control.  The Open Atrium Workbench module uses these hooks to provide Space-specific and Section-specific workflow profiles.

Turning it all on

To add workflow to Open Atrium, download and install the Open Atrium Workbench module and all it’s dependencies.  There are several patches needed to Workbench Moderation documented in the oa_workbench.make file.  Eventually these will get committed to Workbench Moderation and much of the Profile sandbox will be incorporated directly.

Once all of the modules are enabled, the various Drupal permissions and Organic Groups (OG) permissions need to be set.  Permissions in Workbench Moderation are a bit backwards from the norm:  submodules *revoke* access rather than *grant* access.  Typically this means you will set the Drupal Workbench Moderation permissions (including View Unpublished content) to be allowed for all authenticated users, then use OG permissions to restrict to Members and/or Space Admins, then optionally use OA permissions to restrict to Groups/Teams.

After enabling permissions, you next need to enable Moderation of Revisions on the specific content types that you want to use workflow.  When using Open Atrium, enabling Moderation on a content type will not turn on the workflow features until the Space itself enables a Profile.  Typically this means you will enable Moderation on many content types, such as Document Pages, Events, etc.  In most cases, moderation will *not* be used on Discussion Posts since those are usually ad-hoc discussions that do not require approvals.

Finally, the last step it to create your custom Workbench Profile containing the transitions you wish to include, then enable this workflow Profile for your Space or Section.  For Spaces, the workflow profile is set within the Config/Workbench Moderation page.  For Sections, the workflow profile is set by editing the Section node and setting the profile field.

To limit transitions to Groups or Teams, enable the oa_workbench_access module (included with oa_workbench).  To allow transitions to be scheduled automatically in the future, download and enable the Workbench Moderation Scheduled Transitions module (also a sandbox).

How it works

Once Open Atrium Workbench is configured, creating new content within a Section will display the normal Workbench Moderation messages panel.  This panel provides information about what State the document is in and allows options for moving to a different state if you are approved to make that transition.

For example, a Member creates a new content Draft.  Once they are happy with the draft, they move it to the “Needs Review” state.  Somebody authorized to review the document visits their “My Workbench” page from their User Badge dropdown menu and goes to the “Needs Review” tab to see all of the content awaiting their approval.  After reviewing the document, they can either Reject the document, sending it back to the Draft state, or they can approve the document, sending it to the Published state.  Only the users authorized to publish the document will see the Published option in the workbench panel.

Once content is published, a new draft can still be made.  Workbench Moderation supports having one revision of content published while a different revision is in the draft state.  The new draft will only replace the currently published revision once it is approved and published via the workflow.

See you at DrupalCon Austin!

For more detailed information on using Open Atrium Workbench, watch my hands-on demo webinar.  If you are coming to DrupalCon Austin, stop by the Phase2 booth for a demo, or schedule a demo to discussion your specific organizational needs.  Or just come to our booth and say “Hi” and tell me about the cool and interesting ways you are using Open Atrium 2 in your organization.

While I’ve been using the default publishing approval workflow as my example, each organization has different workflow needs.  The workflow profile used for publishing documents is quite different from the workflow used to manage tasks or issues.  The workflow used in a private section (if any) is likely different than the workflow used in a public section.  Open Atrium supports all of these different cases in a systematic and easy-to-use way, consistent with users familiar with the Workbench Moderation module.  This functionality makes Open Atrium a key solution in the Enterprise Collaboration space on par with many non-Open-Source systems.

Categories: Elsewhere