The Clean Economy Network (CEN) is the national advocacy association for the cleantech and green business community. The Network emerged from the 2008 presidential election with strong ties to the CleanTech and Green Business for Obama organizations. OpenSourcery was very excited to work with an organization whose guiding principle is that "economic growth, quality jobs, international competitiveness, environmental sustainability, and energy independence are not mutually exclusive, but rather are all vital elements of a healthy, dynamic economy."

Background

The Network is a broad, nonpartisan collection of professionals, entrepreneurs, investors, workers joined by like-minded professionals and thinkers from across the economy and across the political spectrum. We work at the intersection of politics, policy and business to develop and advocate for policies and programs which meet our Guiding Principles, catalyze clean development and create green jobs.

Having emerged from the 2008 presidential election with a growing number of supporters, the Network needed a Web application that could communicate with existing supporters, deliver a strong message, and allow site administrators to easily manage content.

Key features

• Custom JavaScript slideshow on home page. No Flash required!
• YouTube video upload module to display nationally distributed video campaign
• Simple membership signup with "required" and "volunteer" fields
• Advanced "Executive" membership option that allows individuals to purchase membership onsite
• Targeted email campaigns

Challenges

The development of the Clean Economy Network's Drupal + CiviCRM Web application presented a few technical challenges. The first challenge was to provide a platform whereby the Network could quickly welcome the 7,000 existing members of CleanTech and Green Business for Obama. The Network needed a donor management system that could capture their information in a database they could use to intelligently organize members around future actions. Since one of the Network's primary goals is to "to advance policies that will promote a rapid transition to a cleaner economy," the ability to inform and promote activities among its member base is paramount.

The CEN site had to be a platform that made communicating organizational information easy. While their mission remains the same from week to week, the content itself is always changing. Multiple staff and volunteer users need the ability to manage content, whether it be to edit page content, write a newsletter, or upload a new video.

Process and Outcomes

The Clean Economy Network project is another example of OpenSourcery's Agile development process. Our project managers worked with the CEN's stakeholders to prioritize needs, iterate, and assess the project at every milestone. When pressing needs arose, as they do with time-sensitive projects, OpenSourcery was able to shift resources and address emerging challenges.

We also worked with their designers to customize a Drupal theme to fit their branding and messaging. OpenSourcery's user experience team coordinated with the CEN's themer to enhance the existing theme to increase its functionality and attractiveness. The result is an easy-to-navigate Web application that allows users to easily find the content they're looking for.

The CEN now manages the site and has seen their membership grow significantly. OpenSourcery looks forward to partnering with the Clean Economy Network as it continues to grow and increase its offerings.

On a recent project involving CiviCRM, I really needed to write tests for the workflow, which was very complex, and without tests, brittle.

The solution, partially, is Drupal's SimpleTest (which now uses it's own framework, instead of the original SimpleTest library). I say partially, because unfortunately, CiviCRM sits completely outside of the Drupal API, and doesn't play well with things such as hook_install(), which the Drupal testing framework uses to build a parallel testing database each time tests are run.

As such, the mostly complete solution was to use my custom workflow module's setUp() method to copy the existing CiviCRM database, and then run tests against that:

  /**
   * Implementation of setUp().
   */
  function setUp() {
    parent::setUp('civicrm', 'os_custom', 'os_civicompany');
 
    // Now, clone civicrm install
    global $db_prefix;
    $test_db = db_set_active('civicrm');
    // Build list of tables
    // @todo - implement this for postgresql
    $result = db_query("SHOW TABLES");
    while ($table = db_result($result)) {
      // Build list
      $this->tables[] = $table;
    }
 
    // Clone tables with prefix
    foreach ($this->tables as $table) {
      // Note, we intentionally DON'T use the bracketed table names here,
      // since the whole point is to create a set of tables that will work
      // with the testing $db_prefix.
      db_query("CREATE TABLE " . $db_prefix . $table . " AS SELECT * FROM " . $table);
    }
    db_set_active($test_db);
  }

This set of code first runs the parent setUp() method, which creates a new Drupal instance inside the existing database, but with all the tables prefixed with the $db_prefix. It then switches to the CiviCRM database, and copies each table into an identical table, but named with the testing prefix. On advantage, that is mostly a side-effect, is that instead of having a fresh install of a CiviCRM database, I get a testing copy that is configured exactly the same way as the application I am trying to test in the first place^*.

In order to clean up after the test, a custom tearDown() method is also needed:

 /**
   * Implementation of tearDown().
   */
  function tearDown() {
    // Cleanup CiviCRM database.
    global $db_prefix;
    if ($db_prefix && ($db_prefix != $this->db_prefix_original)) {
      // Only drop tables if $db_prefix is set, and not equal to the original
      $test_db = db_set_active('civicrm');
      foreach ($this->tables as $table) {
        db_query("DROP TABLE " . $db_prefix . $table);
      }
      db_set_active($test_db);
    }
 
    parent::tearDown();
  }

This simply goes and removes the prefixed copy of the CiviCRM database.

These two methods allow for my custom Drupal modules to test against the CiviCRM database in most cases. Where this method fails is for testing actual calls to the CiviCRM API. Since this API sits completely outside of Drupal, it isn't fooled by simply switching the global $db_prefix for the tests. It may be possible to trick CiviCRM into operating on the test database, but as of this writing, I haven't found an elegant way to do so.

* A similar method could be used to duplicate the configured Drupal application. Instead of calling parent::setUp(), the method would duplicate everything that function does except run the install, and instead copy every table into the test database.