Drupal Planet

In Part 1 of this article we explored the major benefits and broad concepts of RedHen CRM. In this article, we will take a detailed look at RedHen's current feature set - as demonstrated in our sample RedHen installation profile.

In this RedHen CRM demonstration, we will show how the framework could be leveraged to build an association management system (AMS) supporting a fictional organization: The National Association of Pet Shelters.

In this example, we have created two different types (or in Drupal speak "entity bundles") of individual contact records - one for shelter staff and another for volunteers, each with its own unique set of fields. Similarly, we have created two different types of organization records - one for the shelters themselves and another for foundations that support the work of these organizations. We can then leverage RedHen to show the connections between these contact and organization records, as well as to manage both individual and organizational memberships within our fictional association.

Working with Contacts

Configuring Contact Entity Bundles

RedHen CRM defines a custom entity type for "Contacts." As mentioned above, RedHen CRM allows site administrators to create their own "contact bundles" - each with its own unique sets of fields:

Below is a listing of the fields that have been added to our demonstration CRM's "volunteer" contact bundle:

The "RedHen Contact Email" field is a new field type defined by RedHen CRM to provide additional options for managing the unique email communication preferences of your RedHen contacts. The "Availability" field provides an example of how we can extend contact records to include additional, customized field data about our contacts.

Filtering Contacts

Once we've configured our content entity bundles, we can view and search our contacts across various fields and properties:

Notice that when we change our "contact type" filter (or, in Drupal speak, when we filter on "contact entity bundle"), RedHen CRM's contact listing automatically pulls in the fields available as filter options for the selected bundle:

Working with Individual Contact Entities

The default contact entity display:

Editing fields and properties on a contact entity (In this case, a staff contact entity):

Connecting Content Entities with Drupal User Accounts

Optionally, you can choose to associate contact entities with Drupal user accounts on your site. You can either choose to connect the contact entity with an existing user account:

Or, you can create a new Drupal user account for the contact entity from within the RedHen interface:

Within the next month, we will be extending this feature to allow Drupal users to edit their own content information via this linkage. But for now, this feature is primarily leveraged for managing access control and Drupal user roles via our membership management tools, which we describe shortly.

Working with Organizations

Organizations work similarly to Contacts. RedHen defines an entity type for organizations - which can be extended by a site administrator as custom organization entity bundles.

Connecting Contacts and Organizations

RedHen CRM leverages the Relation module to allow for different types of relationships (or connections in RedHen CRM speak) between contacts - as well as between contacts and organizations.

As with all the other entity types/bundles that are part of RedHen CRM, these relationships are fieldable:

This means that you can add fields to your relationships to track metadata about the connections between RedHen entities.

Managing Primary Contacts for Your Organizations

When managing connections between contacts and organizations, site administrators can also determine the primary contact for an organization entity. See the "Primary Contact" link on the right-hand side of the screenshot below:

The primary contact is a dynamic property for organization entities, and has been exposed to Views and Rules.

Managing Memberships

Our clients' reoccurring need for a flexible and customizable membership management solution was one of our primary motivations in developing RedHen. Selling Drupal user roles with Drupal Commerce, or managing the expirations of Drupal user roles with contributed modules such as Role Expire is simply not a robust enough solution for large membership organizations with complex business rules around membership-based services.

Individual vs. Organizational Memberships

With this in mind, RedHen CRM allows you to create different types of memberships, which can be applied to both content entities organization entities. These membership types are, of course, entity bundles, so again - they are fieldable.

Assigning Drupal User Roles Via Memberships

As mentioned above, Drupal user accounts can be associated with RedHen contacts. Once these connections are made, the assignment of an active membership can be leveraged to provide a user account with a Drupal user role.

When a RedHen membership that is associated with a Drupal user role is assigned to a RedHen Organization - this role is applied to all Drupal user accounts associated with contacts related to that RedHen organization.

Let me repeat this point, because it is truly one of the most unique features of RedHen CRM:

With RedHen CRM, you can manage Drupal user roles via organizational memberships.

Role-based Membership Benefits

It goes without saying that Drupal's role-based permission and access control system is one of its great strengths. Combining the Drupal user role framework with CRM functionality represents on of the most important value propositions of RedHen CRM and, more generally speaking, native Drupal CRM tools.

Leveraging RedHen CRM with Drupal Commerce, you could use these membership management tools to provide discounts on e-commerce transactions. Leveraging a wide variety of contributed access control modules, could you could also build premium content libraries. The "Association Management Solution" (AMS) opportunities are endless.

Capturing Notes on Contacts and Organizations

Notes can be added to both contact and organization entities. As an entity bundle, notes can be extended with fields.

In the case of our RedHen Demo CRM, we have extended the notes bundle with a taxonomy reference field for the "type" of note that is being recorded. When viewing note history, these notes can then be filtered by this type taxonomy.

Engagement Scoring

In the notes screenshot above, you'll also notice a dropdown option for Engagement Score.

Engagement scoring (often referred to as "engagement analytics" or "engagement metrics") is a relatively new concept in measuring the interactions of web site visitors. Web analytics packages such as Google Analytics generally focus on measuring quantitative analytics - or the number of page visits and clicks. Engagement scoring focuses on measuring the quality of these interactions by weighting the value of different types of interactions between site visitors and your website. For example, sharing an article from your website to a social network might be worth "5 engagement points", commenting on a blog post might be worth "10 points."

The RedHen Engagement module provides an API and framework for tracking this type of engagement. The module also integrates with the "RedHen Notes" module, so that offline interactions with RedHen Contacts can also be tracked and scored.

Tracking Event Registrations

RedHen CRM integrates closely with the Entity Registrations module - which our ThinkShout geeks also maintain. As shown in the screenshot below, the Entity Registrations module allows you to manage event registrations as entities.

When enabled, the RedHen Registration module adds an additional tab to the contact entity screen called "Registrations." There, both authenticated and anonymous event registrations will be listed for each contact, based upon a matching email address.

Note: In the future, we plan to extend this module such that new registrations associated with email addresses not found in RedHen CRM will trigger the creation of new contact entities.

RedHen Organizations as "Groups"

The RedHen Organization Groups module allows you to groupify organization entity bundles.

This module provides functionality similar to Organic Groups. A groupified organization can have node content associated with it. Optionally, this content can be made private, and therefore only viewable to Drupal user accounts associated with RedHen contact entities which are in turn associated with a specific RedHen organization entity.

In the screenshot below, you can see how a node can be added to a groupified RedHen organization:

Then, when looking at a RedHen organization entity, you can see all associated group content:

So, why not just use Organic Groups?

The description above begs the question: Why not just use OG? In developing this feature, we considered leveraging Organic Groups. However, the relationships between Drupal user records, contacts and organizations were too complex to cleanly build this feature on top of both RedHen and Organic Groups. That said, much of the architecture of this module is based upon design patterns from Organic Groups.

What's Next?

ThinkShout will be launching our first client sites on RedHen CRM this summer. We are currently working towards a stable 1.0 release of RedHen - while simultaneously exploring new features and tools.

We are very interested in continuing to explore:

• Deeper integration with Drupal Commerce.
• CRM data visualization - most notably geolocation and mapping of constituent data, as well as Google Charts visualization of engagement scoring data.
• Bulk import tools, as well as Migrate 2.x integration.
• Apache Solr integration.
• The development of better HTML5 and responsive themes for RedHen CRM interfaces.

We hope that the community will continue to work with us to make RedHen CRM a leading association management solution. We'll see you in the issue queues and at a Drupal Camp near you!

Tags: RedHennon-profit techDrupal PlanetDrupal Give

Introducing RedHen CRM

The Drupal community has long aspired for native CRM functionality for many years. Unfortunately, solutions to this problem in older releases of Drupal were less than perfect - usually relying on the node system to manage contact data. Of course, the node system was designed for managing content, so these node-based CRM solutions required lots of extra code and duct tape to keep content and contacts separated.

Fortunately, the arrival of the entity framework in Drupal 7.x core has opened the door to the development of more robust CRM solutions built natively in Drupal. So, after a year of scheming and over 700 hours of very intense development, ThinkShout is proud to announce the Alpha release of RedHen CRM.

Why Does Native CRM Matter?

CiviCRM is a mature open source CRM solution that integrates with Drupal, so why not just use that? Drupal also integrates well with many 3rd-party SaaS solutions, such as Salesforce, why reinvent the wheel?

There are many benefits to integrating your Drupal site with a 3rd-party CRM solution. But there are many missed opportunities and drawbacks to these integrations as well. The most obvious benefits to native CRM in Drupal include:

• A more seamless user experience for site visitors registering for events, making donations/payments, or engaging in other website transactions.
• The opportunity to leverage Drupal's growing suite of mobile and responsive tools and themes for CRM interfaces.
• The ability to expose CRM data as content, and/or the ability to display aggregate CRM data on your site.
• Increased opportunities to integrate CRM data with Drupal contributed tools - such as data visualization tools, geo-mapping tools, and more.
• Decreased staff training costs - because staff doesn't need to get trained on multiple platforms.
• Potential reductions in technical risk - because all your tools rely on a single, Drupal framework.
• Potential reductions in hosting and IT costs.
• The ability to do complex engagement scoring or engagement analytics (more on this later).
• And probably most important - the ability to fully customize your CRM solution.

Native CRM And (Not Verses) Enterprise CRM

One last point before diving into the guts of RedHen CRM:

While we think that it's possible to build very robust, large-scale CRM solutions natively in Drupal, our goal in releasing RedHen is not to compete with the enterprise CRM market. Platforms like Salesforce will inevitably out scale what we can build with Drupal.

That said, enterprise CRM solutions are often overkill for small to mid-sized organizations. Moreover, even if your organization does need an enterprise CRM solution, we see RedHen as a natural integration point between your website and such a system.

With the right Drupal development partner, tools such as RedHen open the door to the creation of highly innovative "front end" CRM tools. We anticipate that collecting and displaying data in RedHen (and Drupal) will often be much more affordable and nimble than trying to develop comparable features upon larger, more cumbersome enterprise packages.

What Can You Do With RedHen CRM?

RedHen CRM has been largely designed around the association management (AMS) needs of membership organizations. That said, the RedHen framework is flexible and can be leveraged to develop a wide range of CRM solutions. For example, RedHen could be used as a light weight sales pipeline management tool for small to mid-size businesses.

Getting Started

RedHen CRM is similar to Drupal Commerce in its modular structure. As with Drupal Commerce, the core RedHen modules that can be downloaded on the Drupal.org project page won't provide you with a working CRM right out of the box. They require configuration. In the future, ThinkShout is likely to release RedHen "Features" or "Apps" that provide prepackaged CRM solutions for different use cases.

In the short term, if you would like to explore RedHen CRM, we would encourage you to check out our demonstration RedHen CRM installation profile. This install profile will build out a simple example of how RedHen could be leveraged to support the CRM needs of a fictional "pet shelter" organization.

Project Structure

RedHen CRM relies heavily on custom Drupal entity types and bundles. The Entity API module is leveraged to do most of the heavy lifting for these custom entities. The Relation module is leveraged to manage connections between these custom entity bundles. The core RedHen module provides shared APIs, although the majority of RedHen features are broken out into separate sub-modules that ship with the main module. As with Drupal Commerce, we will continue to include key sub-modules with the main module code base. However, we anticipate that an ecosystem of plug-in modules will soon be available to extend the core feature set.

Basic Concepts and Features

• RedHen CRM defines two main entity types: Contacts and Organizations. Site administrators can then create different entity bundles for each of these types. Each bundle can then be fielded.

• Connections can then be made between contacts, as well as between contacts and organizations. Connections are managed as custom entity bundles as well, based upon the relation entity type defined by the Relation module. As such, these connections can be fielded as well. In other words, you can create a relationship, or connection, between contacts and organizations that include field data about the relationship. Potential connection fields might include "job title" or "job start date."

• Memberships are another custom entity type defined by the "RedHen Membership" module. Both contacts and organizations can be associated with memberships. RedHen's membership management features are very flexible and feature rich. Memberships can be associated with the management of Drupal user roles to provide website access based upon individual and organizational membership status.

• Optionally, contact entities can be associated with Drupal user accounts. Currently, these connections are managed from the contact entity edit screen. Contacts can be associated with existing Drupal user accounts, or a new Drupal user account can be created from the contact entity edit form.

• Notes is another custom entity type and bundle provided by the "RedHen Notes" sub-module. Notes provide a site administrator a simple tool for capturing tagged notes about contacts and organizations. As a custom entity bundle, notes are fieldable as well.

• The Notes module also integrates with the "RedHen engagement scoring" sub-module. Engagement scores allow a site administrator to track and score various types of interactions with contact entities.

• Finally, RedHen CRM ships with a "RedHen groups" sub-module that allows you to groupify RedHen organizations. Groupified organizations function similarly to Organic Groups, in that they provide a simple container for managing private node content associated with each organization.

Extending RedHen CRM with Views and Rules Integration

The RedHen CRM framework does not require Views. However, because RedHen is built upon Entity API, you can easily extend RedHen to work with Views and Rules. With Views, you can customize your instance of RedHen CRM to create personalized reports of contact, organization, membership and/or engagement scoring data. With Views plugins such as Views Bulk Operations and Views Data Export, you can further extend RedHen with bulk editing and export tools.

For More Information

Complete RedHen site administration docs will be coming soon. You can also check out the README files contained with each RedHen module. For technical issues, please use the D.O. issue queue. For community support and to learn about RedHen usage, please consider joining the RedHen Drupal group and follow us on Twitter @RedHen_CRM.

Next Up: A RedHen CRM Feature Deep-Dive

For a detailed look at RedHen CRM, check out Part 2 of this article.

Tags: RedHennon-profit techDrupal PlanetDrupal Give

Many of you might be familiar with the module Skinr (http://drupal.org/project/skinr). It gained a lot of support back in Drupal 6 by providing an easier, albeit somewhat verbose, way of dynamically configuring how elements on your site are styled.

When I first started using Skinr, it worked as advertised; however, it ultimately left me with a bitter taste in my mouth. I felt like I was constantly trying to navigate an endless maze while blind-folded. There were options upon options and fieldsets within fieldsets. It had almost everything but the kitchen sink in it.

If you enjoy our content, please consider subscribing through RSS, so you can read our posts in your application of choice.

read more

We were having a situation with a site where sessions weren’t being shared between insecure (http) and secure (https / SSL). The one major difference with this site was that we were using Nginx as a reverse proxy, but we weren’t quite sure how it was affecting us. We ultimately found the cause to be a combination of Nginx settings and how Drupal differentiates between different domains.

read more

There’s a new kid on the block in the configuration management world that claims to be lean, simple and easy to understand. We’re using it internally for some exciting new projects, and have found that it lives up to it’s promise.

Ansible’s goal is to unify two similar but traditionally separate tools: configuration management and deployment. Instead of using a combination of Puppet + Capistrano or Chef + Fabric, you can now use a single tool to update your configuration, deploy new code or execute ad-hoc tasks against groups of servers. There is no requirement to setup any daemons or any software at all on the target servers - as long as you can reach them over SSH, you’re good. There is also very little setup on the machine running Ansible, since it only relies on a few standard Python libraries. There’s a detailed comparison page in the FAQ that compares Ansible to these various other tools.

To illustrate some of the features, we’ve created a playbook that sets up an Ubuntu 12.04 server as a multi-user LAMP developer environment. Our old method of creating a server would be to perform these steps once, document them on a wiki, and then anytime we want another similar server, clone the first one or repeat the steps manually. This procedure is fragile over time and in the case of cloning, virtualization-platform specific. It’s far better to create a reusable, automated set of steps that can be tweaked and improved, and executed against any fresh Ubuntu 12.04 server, running anywhere. The example is documented and fully functional, although it’s not 100% secured so be careful.

Playbooks

The tasks that need to be performed are recorded in YAML formatted Ansible playbooks, which are then executed against the target host. The main components of a ‘play’ are:

1. Hosts against which the actions are performed.
2. Variables that can be used in the play or in file templates.
3. Actions that will be performed when the play runs.
4. Handlers that respond to change events from the actions.

Here is an abbreviated example from our server build playbook file, setup.yml, that will apply php.ini and restart Apache if the file has changed:

setup.yml

---
- hosts: all
  user: root
  vars_files:
    - vars/settings-default.yml
  tasks:
    - name: PHP configuration file, php.ini
      action: template src=templates/etc-php5-apache2-php-ini.j2 dest=/etc/php5/apache2/php.ini
      notify: Restart Apache
  handlers:
    - name: Restart Apache
      action: service name=apache2 state=restarted

The first two directives, ‘host’ and ‘user’, are easy - they specify that the play should by default run against all hosts, as the root user. In the following sections we’ll cover what the others do.

Variables

The vars_files section lists files that will be imported into the current play. The variables specified in these files are then available to use as value substitution or logic control in both the play and in the templates.

In our case, the settings-default.yml file contains a list of configuration variables for the services like Apache, MySQL, etc. They’re all organized into their respective sections, but looking at the file as a whole we get a great birds-eye view of how the play will be modifying the default server configuration. Here is an excerpt:

settings-default.yml

---
# php.ini
php_max_execution_time: '90'
php_display_errors: 'On'
...
# my.cnf
mysql_max_allowed_packet: '128M'
mysql_character_set_server: 'utf8'
...

Any value that will be modified from it’s default out-the-box state is recorded in this one place. This makes changing settings really easy - no more grepping through thousands of lines of configuration in the master template file.

Tasks & Handlers

tasks:
  - name: PHP configuration file, php.ini
    action: template src=templates/etc-php5-apache2-php-ini.j2 dest=/etc/php5/apache2/php.ini
    notify: Restart Apache

These are the meat of the playbook. Each task is given a descriptive name and an action. In the example above, the action is ‘template’ and the parameters ‘src’ and ‘dest’ point to a source template on the local host, and a destination location on the target host, respectively.

To execute this step, the Ansible ‘template’ module will be invoked, passing the etc-php5-apache2-php-ini.j2 file through the Jinja2 templating engine, which performs variable substitutions in the appropriate place. For example, in this template we can insert the value of the variable php_max_execution_time (sourced from settings-default.yml above) in it’s correct place:

etc-php5-apache2-php-ini.j2 which becomes php.ini

; Maximum execution time of each script, in seconds
max_execution_time = {{ php_max_execution_time }}
...

The great thing about Ansible modules is that they’re idempotent, meaning no changes will be made if the new file is identical to the old one. And since we have this data available, we can trigger events when changes are actually made. That’s what the ‘notify’ section does - when Ansible detects this file has changed, it will call ‘Restart Apache’, which is defined at the end of the play and does exactly what you might think it does.

Modules

When Ansible executes a task, it creates an SSH connection to the target server and copies the required module over. The module is then executed on the target with the correct parameters, and all the module has to do is return a JSON object containing pass/fail and other optional status information.

This has several advantages: for one, modules can be written in any scripting language, as long as the target can execute that code from the shell. It also means your modules can be quite sophisticated, and since they’re running locally on the target server as opposed to sending individual commands over the wire, they run fast.

There are git, apt, yum and service modules, just to name a few. Developing extra modules is easy and there is a growing collection of ‘contrib’ modules that come from the community but are not part of core Ansible.

Command mode

In addition to creating playbooks, you can also execute ad-hoc tasks against your servers using the exact same modules and syntax. For example, I could execute from the command line:

ansible webservers -m shell -a '/sbin/reboot now'

That would reboot all servers defined in the ‘webservers’ pool. This shared syntax and configuration is one of Ansible’s strengths, we can reuse a single server cluster specification for all tasks.

Project Status

Michael DeHaan is the project lead, and he has a lot of experience in this area, having worked at Red Hat & Puppet Labs, co-created Func and developed Cobbler.

Ansible is still very new, having only been released this year. However, it’s already used in production and there is a strong community forming. Michael announced recently that he’d written almost zero code in the upcoming 0.5 release, a sure sign of good community momentum.

Resources

Check out the pedantically commented playbook example, that covers almost all the features in one place.
The Ansible mailing list is active and friendly.

I got annoyed by the mess on my laptop. Three years hence, its' hard disk has turned into an archive of stuff I've been working at some point or another. The vast majority ranges from fully fledged projects we maintain to half borked vanilla Drupal installations I once used to demo something to fully fledged. Over time, I changed employer a time or two and did some freelance stints. Each time, I had to adapt to new conventions, configurations, versioning tools and development setups.

In the end, the thing I *didn't* do well was managing my own development environment. I'm not talking about the technology I'm using (as it happens: I'm on a OSX using MAMP) but the way, or lack of, I kept order in the data I manage. Inevitably, you're development environment gets cluttered over time. If you're not very careful, you'll end up with stale databases, different versions of files, directories and dumps with no specific purpose, cryptic leftover configuration files,... In short: chaos. Why? There's only so much time, and at the end of the day, it's very easy to just wing it rather then clean up abandoned local projects. That's what happened to me.

So, I set forth to think how to improve this for myself. I've started using a set of common conventions each time I set up a new project. Most of them I picked up at Krimson. I decided to share them, here it goes:

Filesystem

• Create a Workspace folder i.e. /home/you/workspace. All PHP files, applications, DB dumps,... should be stored here.
• Group each project in it's own folder. i.e. /home/you/workspace/myproject. Of course, you might work for different clients or employers. Just prefix your folders: i.e. colada_project and krimson_project.
• Each project has four basic subfolders: www/ which contains your document root, db/ which contains database dumps, docs/ which contains your development information (notes,...) and patches/ with specific drupal patches you might need when setting up that project.

 

Webserver

• Use virtual hosts. No exceptions. Putting each project in a subfolder of the documentroot so you can surf to http://localhost/myproject is bad practice since such setups require extra configuration in .htaccess. When you go live, you might end up doing mucking in your .htaccess. Or worse, discovering you have to change hardcoded URL's in your code if you were really careless!
• Use a comprehensive local domainname. You could go for "myproject.dev" or "myproject.lan". I use "netsensei.myproject" for extra clarity. The first part could also refer to the hostname of my machine.
• Each vhosts comes with its' own vconf file. In my MAMP, I have a separate folder called sites/ which contains a vhost configuration per project.
• Each configuration file is called netsensei.myproject.conf.
• Use a working template file for your configuration. Just copy and paste and alter when need to do so (you shouldn't on your own machine unless really needed!) This way, you'll avoid having to debug your configuration for the gazillionth time i.e. because the path to your logfiles contains an error.
• Same goes for your /etc/hosts file: keep it clean! I try to keep all the entries alphabetically ordered so I can easily find an entry in the list.

Of course, you don't have to work with /etc/hosts and configuration files. You could also do a one time setup of a local BIND DNS server and let Apache do the heavy lifting for you. Check out this article on how to set up a smarter MAMP.

Database

As a Drupal dev, I'm 99.9% of the time working with a MySQL setup. But these should serve for any db system really...

• Never, ever use the root user to connect to your database from your project. Not even on your development machine. Why? It's a bad habit and mistakes are easily made. Moreover, if something goes really wrong, you don't want other projects to get messed up too.
• Use the same name for your database as for your user. Ie. DEV_MYPROJECT. Each user only has privileges granted to that database.
• Be consistent in how you name your user and database: always go for uppercase or lowercase. But don't intermingle. Keep things clear and simple.
• I use the DEV_ prefix on my local machine. Why? When my PHPMyAdmin tool is open, I want to be pretty sure that's not a production database I just dropped.

 

Drush

You didn't install Drush? Shame! You should! Drush Makes developer life a breeze!

• Use Drush aliases for every project you start! An alias file allows you to load and bootstrap Drupal from the command line from every location.
• Each file is called netsensei.myproject.alias.drushrc.php

Those are a few conventions we try to live by. Of course, most of this is sheer repetition after a while. To avoid errors, we wanted to automate the process of setting up a project. A few years back, we worked with a set of shell scripts to get the job done. Over time, we converted our scripts to Drush commands. We couldn't share them because they were very Krimson specific, locked in our own workflow. A few months back, we started using Git. Integrating support in our tools turned out to be quite the hack. So I ventured out and created my own Drush toolset called Rum. It does two things:

Setting up a new local project starting from a vanilla Drupal core setup or setting up an existing project from a remote repository (Git or Subversion) honoring the above conventions.

Rum allows you to delete the entire project including the vhost configuration setup, database and reference in the host file.

This is strictly a aid for use in a development environment. Of course, this is just one way of doing things. These might be the right tool when you're working on your own but turn out to be contraproductive on an enterprise level where individual developers many more variables to take into account. There are other ways of setting up development environments which allow you to easily and safely sync. I highly recommend looking at Vagrant which allows you to rapidly setup and tear down custom tailored virtualized development environments per project. I would also recommend taking a look into the realm of DevOps, which is a fairly young field aiming to tear down the wall between developers and system operators, lowering the bar for deployment, maintenance, security,... in terms of efficiency and flexibility.

I presented Rum and my own setup as a BoF session at DrupalCampGent 2012 on May 26th. I've put my slides on Slideshare (Dutch)

Entity Sync is a module which allows site to synchronize entities fully or partially to another D7 installation or installations. It was designed from the ground up to be easy and fast to set up. It relies fully on Rules to do the actual synchronization logic, so to get entity information transferred to another drupal installation an event triggered rule is needed to call the synchronization action. Super simple, exportable and clean!.

"PHP Sucks!" -- A lot of people

PHP is a language with a bad reputation. This isn't a story like we often see in movies. Where someone has gotten a bad reputation from life circumstances that just weren't fair. Then they have a chance to redeem themselves. I believe PHP has earned the bad reputation it has. Have you looked at the code powering many of the most popular PHP projects in the world. I develop in PHP and reading some of these codebases makes me very very sad.

But, PHP is popular. Extremely popular. According to W3Techs:

PHP is used by 77.9% of all the websites whose server-side programming language we know.

Jeff Atwood (a.k.a. Coding Horror) just made the observations that while PHP is bad it is pervasive and has an ecosystem because of that. Other languages, some much better than PHP, just don't have that.

So, how do we solve this PHP bad code problem?

Continue Reading »

In Drupal you can have base themes and sub-themes where sub-themes inherit the functionality of their base theme. Wouldn't it be cool if you could do the same thing with Drupal install profiles and make files? Imagine creating your own profile that inherited all the functionality of OpenPublic. Now you can, and this article will show you how easy it is.

It’s official. After months of development, ELMS has been labeled Beta.

read more

Last time I blogged about how to start a workflow explicitly via webscript. In our Canopy solution, if desired, the workflow can be started automatically upon a document submission from Drupal to Alfresco as well. The document upload is usually done via CMIS Alfresco.

read more

For the last few days, I was down in San Diego, California for the 2012 ISTE conference. I was down there running a session for people to learn about Drupal. I have added the notes I used for my presentation into the handbook in the Tutorials section.

During the conference, I wandered onto the vendor floor to touch base with some friends who were working in different booths. Once I recovered from the shock of a bright orange gimp-man shilling hardware, I was struck by the overwhelming lack of any open source representation. Aside from a single Moodle vendor, I didn't see any open source representation.

This paucity is all the more striking because of the amazing, innovative work I see happening within education using open source tools. On a very regular basis, I see schools using a range of open source tools to support curriculum mapping, online classes, collaborative projects, community outreach, professional development, portfolios - and in these cases, schools aren't paying exorbitant fees to vendors, or losing control of the work performed by teachers and students, or ceding flexibility for convenience. They are just working - intelligently, intentionally, making mindful progress towards articulated goals, and using open source tools to support and extend that work.

But this narrative seemed largely missing at ISTE - possibly, this is due to the company I keep, as I tend to gravitate more toward people who are doing the day to day work in the classroom. But from visiting the vendor floor, the story of educational technology - at least this year - seemed to be one of convenience and speed over vision and ongoing effort. Technology, at least the vision of it being articulated and sold on the vendor floor - is the panacea. It is the thing that makes the difficult easy, and makes all of us smarter.

Open source has a role to play in articulating a different narrative about education - a narrative that values individual effort within a community that is loosely united toward a common goal. The development model within open source communities (and this model has been in place and thriving well before the days of Web 2.0-ifying everything) has always supported (in general terms) peer to peer learning and support. The absence of open source companies in the larger mainstream educational technology world is a loss for both open source and educational technology.

For an additional perspective on the state of data control and access to data, Audrey Watters has a piece over at Hack Education on how vendors responded to questions about data portability and apis. She was aided on the quest by Kin Lane, who knows a thing or three about APIs.

I helped start the Drupal Association in 2006 because we needed a checking account for the $10,000 or so required to produce a Drupal conference and to support our infrastructure. In a short six years, we grew the Drupal Association from a volunteer-run organization to one of the largest Open Source non-profit foundations with an operating budget of $3 million USD and 8 full-time employees. Today, we support over 18,000 developers, 9,000 conference attendees, 2,300 individual donors, 800 organizations, and a web presence that reaches over two million people every month.

read more

I helped start the Drupal Association in 2006 because we needed a checking account for the $10,000 or so required to produce a Drupal conference and to support our infrastructure. In a short six years, we grew the Drupal Association from a volunteer-run organization to one of the largest Open Source non-profit foundations with an operating budget of $3 million USD and 8 full-time employees. Today, we support over 18,000 developers, 9,000 conference attendees, 2,300 individual donors, 800 organizations, and a web presence that reaches over two million people every month.

A lot of that credit goes to Jacob Redding, who took the position of Executive Director two years ago. Under Jacob's leadership we have broadened our activities, streamlined our operations, and significantly increased our revenues. We have supported the Drupal community in its exponential growth from 70,000 members to over 800,000 and from 700 committers to over 18,000. And we are just getting started.

Today, we are announcing an important leadership transition at the Drupal Association. We're sad to say that Jacob, who has worked tirelessly and effectively to grow the organization to where it is today, has told us he intends to step down later this year. Needless to say, it was a difficult decision for Jacob to leave, but he has agreed to stay on until the right replacement has been found, and plans to stay involved as a member and volunteer after his responsibilities have been transitioned.

This transition doesn't come as a surprise for the Drupal Association's Board of Directors. With Jacob's help, we have been preparing and planning for this transition for a while. The Drupal Association is in a good place; we are better organized than ever before and have more momentum than ever before.

This leaves us with a tremendous opportunity ahead. We are now seeking someone to help lay the foundation for our next stage of growth. Someone to help drive us to become the largest Open Source non-profit organization. This will need to be an experienced executive to take over Jacob's responsibilities and to grow the Drupal Association from a $3M organization to a $10M organization over the next few years so we can better support our massive growth as a community and project.

If you are interested, or if you know someone that is interested in this job, please take a look at the job description. I think this truly represents one of the most exciting opportunities out there for someone with a strong leadership background, and that is interested in fostering enormous growth within a non-profit and collaborating with an extensive and active volunteer network. Together with the Drupal community this person could change the way the world builds websites.

Following on from my post 'Managing files when moving to multi-site in Drupal 6' where I explained about updated file paths in the files table, and other tables in the database. Here is a handy command to use if you have any hard coded image paths in code.


find ./ -type f -exec sed -i 's|sites/default/files|sites/example.com/files|' {} \;


It's best practice not to hard code image paths in your code, but it does happen, and you may have inherited a site with this issue.

DrupalDrupal 6filesfilepathscodecommand

A brief video conference session between the Portland Drupal Meetup (featuring former DBUG host jyee) kicked off conversations of fires, narcotic diversion, climbing Drupal ladders, and entities. As seems to be the trend these days, lots of great companies are hiring. So, if you are looking for an employer or employee, check out the DBUG page and make sure to come down to the next Meetup.

Shout Out: Climb the Drupal Ladder

Drupal has a thriving community, yet only 0.5% of active Drupal users have contributed to Drupal Core. techgirlgeek introduced the Boston Initiative, a plan to change that. drupalladder.org is a site dedicated to offering sequential lessons which if followed, will lead people up the “Drupal Ladder” to be able to be core contributors. The goal is to have 1% of active Drupal users contributing to Drupal core by 2014.

Along with the site, there are also learning sprints and issue sprints taking place across the world. The Denver/Boulder DrupalChix have taken the lead by hosting these sprints each month. Everyone is invited (not just DrupalChix) and it is a great way to get to know other Drupal afficionados, get cozy with Drupal core, and contribute back to the community in a meaningful way.

Drupal Ladder Meetup 3rd Thursday of Every Month (alternates between Boulder and Denver) 

• 7/19 Denver Drupal Ladder Meetup 6pm Creative Density Coworking 
• 8/16 Boulder Drupal Ladder Meetup 6pm Applied Trust 

How Cool is Drupal’s Entity API? This cool...

We often talk about Drupal’s power as a CMS which allows for so much extensibility and power through the user interface, but last night’s meetup was a nice reminder that Drupal’s API is equally powerful and adaptable. Our friends, Cirro, just down the hall from Aten, showcased a new web app they are rolling out which leverages the Entity API to efficiently parse data and display information in intelligible and downright fun ways for their client.

The Situation:

Claro Scientific analyzes urine samples for traces of 107 different drugs (yes, very glamorous work). Until Cirro entered the picture, massive amounts of data were being transported in fairly creative ways- from copying Word documents to tracing over data samples with pencil to compare results. Bleary-eyed scientists were poring over thousands of rows of data, most of it empty, spending days analyzing sample results. Suffice it to say the process was cumbersome and expensive.

The Drupal Answer:

Cirro took this problem and decided that their app would need to be able to filter out irrelevant data (typically people test negative for about 90% of the drugs, some of which haven’t been around since the 60s) and drill down to the results that their clients really needed to analyze closely. The age-old question of “Do I try and bend Node to fit my needs or do I build my own Entity from scratch?” came up and in this case they went the DIY route. They went about the typical process of building an entity - naming it, making it fieldable, and adding the fields. Now with an Entity customized to their needs they used EntityFieldQuery to pull the data and with some magic from the Isotope library the clients had themselves an interface to be able to easily load results, read and manipulate data, and make informed decisions on the findings.

Some of us kicked it afterwards at The Interstate, a place where you can find out what a Boilermaker tastes like and why bacon should never be separated from its dear friend mac and cheese.

Dries himself said Mobile is the next biggest opportunity within Drupal. During his keynote at Drupalcon Denver he expanded on a quote from Mary Meeker of Kleiner Perkins and said "we are now in the 5th major technology cycle of the past half century”. Dries continued, “these 5 cycles are mainframe -> mini computer -> desktop -> internet -> mobile.”

We could not agree more.

Session submissions for the Core Conversations track at DrupalCon Munich are open until tomorrow!

Since it was introduced at DrupalCon Chicago, the Core Conversations track has grown to become a fundamental place for contributors to promote new ideas, discuss community issues, and present problems for brainstorming. Core conversations cover technical topics, community needs, existing initiatives, and new proposals, among other things, and are aimed at those who are contributing in the Drupal Community. The Core Conversations track will run in parallel with all the other sessions and are either one 30 minute presentation or two 15 minute presentations, followed by 30 minutes of discussion with the audience.

The Web Services and Context initiative, the Blocks and Layout initiative, the Configuration Management Initiative, the ongoing efforts to replace Drupal's rendering layer with Twig, and other major efforts were all born out of past Core Conversations sessions. Drupal 8 code freeze is approaching fast, so now is the time to discuss what we want to make sure happens by by then.

If you're a contributor to the Drupal community, consider proposing a Core Conversation session today.

Session submission closes June 29, 2012 at midnight Munich time (CEST).

Core conversation sessions will be selected from among the submissions by a group consisting of Daniel Kudwien, Larry Garfield, and Dries Buytaert. The selected sessions will be announced on July 9, 2012.

In a nutshell, the regular tracks and sessions present existing things in Drupal, whereas Core Conversations focus on changing Drupal.

If you are new to Drupal, work mostly in contrib space, or simply want to learn more about Drupal and Drupal development then you will get far more out of the regular sessions, particularly in the Coder, Themer, and Sitebuilding tracks.

Update: The call for Core Conversations is now closed. View proposed Core Conversations.

Please note all deadlines are 11:59PM CEST.

Once upon a time in the Drupalsphere, there was the Image module, which was the preferred image solution for all Drupal sites. It dynamically resized images for display, so you could upload one image and get other sizes. But it was limited to one image per node, which made it hard for situations where you wanted to insert several images into one article. All kinds of workarounds emerged, but it was all a bit kludgey. It was nice to have something, but people were looking for something better. When Imagecache came about, it was received with much excitement, and it soon took over as the preferred image handling solution for Drupal, because you could attach several images to a node, and because it was much more performant and scalable. When Drupal 7 was in development, this functionality was considered so essential that Imagecache was incorporated into Drupal 7 core and renamed "Image". (Yeah, it can be a bit confusing if you don't know the history.)

If you were riding Drupal through those image solution shifts, it could be a bit of a rough go. In my upgrades over the years, I lost my Image node-generated posts. They were there from 2006-2007, but my upgrade to Drupal 5, when I adopted Imagecache for my images, left them adrift. I had figured those posts were doomed to obscurity, with no hooks to pull them out of database obscurity. Oh, you could see the text, but the images were gone. And if you tried to edit the node, you got no node edit form, just a blank page. I wasn't going to try to fix that for a handful of posts. I figured I just had to write them off, sacrificed at the altar of progress.

I was wrong.

I recently discovered that this content loss due to Image module deprecation has a solution. When I first saw this, I guessed it was too late for me, as I should have done this in a previous Drupal upgrade, ideally when I made the initial jump away from the Image module.

But I thought, what the heck, give it a try!

Field Converter module

It was this module I found myself looking at that got me excited.

A framework for non-CCK modules to use to convert their Drupal 6 custom data to Drupal 7 FieldAPI fields....

...Currently, Image and User terms are using this framework to migrate their data to fields on Drupal 7.

Ooh! Maybe I can rescue my Image nodes after all!

I started digging around, and learned that there is really no documentation on this. You have to read the code and figure it out.

I went to look at the old Image module in contrib, where it said on the project page:

Upgrading ... from Drupal 6 to 7: Image node data may be converted to Image fields using Field convert module; the image_legacy module (in this project's git repository's 7.x-1.x branch) provides the necessary field conversion information.

Nice! Obviously I couldn't simply enable image.module, as it would conflict with the core module's namespace. So I looked for documentation, but didn't find any there, either. I explored the Image module issues, and found Image module migration, a critical open issue with lots of discussion on just this migration need. There I saw more mention of the image_legacy module, which, as it turns out, is a module within the Image module package. People were saying it was working, albeit with issues.

Hmmmm. I had the basic elements to give this a try. I made my backups and hunkered down in my dev environment for a potentially long session.

Image -> Imagecache -> Image

Because of the namespacing conflict, it makes sense that there is no Drupal 7 image module release. You have to check it out via Git. I did that. I used Drush to install Field Converter.

I enabled the Image Legacy module and the Field Converter.

And found nothing available in any menus or admin screens. Digging around the Field Converter code, I found:

<?php
function field_convert_menu() {
  $items['admin/content/field_convert'] = array(
    'title' => 'Convert fields',
    'page callback' => 'drupal_get_form',
    'page arguments' => array('field_convert_select'),
    'access arguments' => array('administer software updates'), // @TODO CHANGE ME
    'file' => 'field_convert.admin.inc',
  );

  return

$items;
}
?>

That gave me the admin screen path (.../admin/content/field_convert), so I entered that into my browser toolbar, and a very simple screen with a couple of checkboxes appeared. One checkbox was for converting Images.

So I checked the box and submitted the form.

A few moments later, the process was done. Did it work? I went to /admin/content and found all my image nodes updated, with valid node type designations no less! The entire effort took me all of ten minutes.

Elbow grease required

When I looked at the nodes, though, the images were not there. However, when I clicked to edit a node, the form loaded, which itself was a victory, complete with the node body field, as well as the original image and two resizes listed in the File Attachments.

From there it was an easy manual remediation task:

1. Load the Filefield Sources module, configure it to look in the folder where the old images were still residing.
2. Edit the image node and mouse over the original image attachment link to see the actual image filename.
3. Select that file from the Filefield Sources dropdown.
4. Save the image node. The image was now there!
5. Repeat for each image node.

And the cat blogging is returned! Since I had only a few dozen images, this wasn't so bad. If I had hundreds, this probably would have been a bigger task meriting exploration of some kind of batch processing.

Thank you

My big thanks to joachim for the awesome work, contributing the code for the Field Converter and Image Legacy modules, sharing a workable solution for what seemed to be a problem with no easy answer!

Related:  responsive pattern topics:  Drupal, Drupal 7, Image Legacy module, Field Converter module, Filefield Sources module.

There are currently 102 new Drupal contributors awaiting review of their first project. This is a great place to contribute to the community and learn about interesting upcoming projects, for example...

Module: Responsive Image Styles

What's it Do?

The Responsive Image Styles module allows you to create an image style for each viewport you are targeting, and tell Drupal when to show the desired image based on viewport size. There are a couple other modules that do similar things, but Responsive Image Styles claims to take a unique approach.

Potential Uses

If you haven't noticed, responsive web design is all the rage these days. Using media queries in your CSS to target various viewports is fairly straight-forward, but dynamically resizing images can be a challenge. Images are the main contributor to slow page loads on mobile devices, so Responsive Image Styles module can potentially help mitigate those issues.

Look Useful? Review It!

If this sounds like something you'd like to see readily available on Drupal.org, you should review it and help make that happen.

Note: As of this morning someone had flagged this module as "Needs Work", but based on comments, it will likely be moved back to "Needs Review".

Review It

Pro Tip: If you've never reviewed a project application before, you can find instructions for reviewers on Drupal.org and the Code Review group is happy to help more people get involved.