features

RedHen knows a lot of nifty tricks, some of which are described in the regular documentation pages, and some of which don't quite fit anywhere. This page will give you a good idea of things that RedHen does that you might not necessarily expect from a CRM, even if you might find it useful.

• Connect Drupal Users to CRM Contacts

  This is described all over the documentation, but it's a handy trick to know about! Read more here and here.

• Dynamic filtration on Contacts and Organizations

  As you add fields to Contact and Organization Record Types, RedHen intelligently makes those fields available as filters in the CRM's User Interface.

• Salesforce Integration

  RedHen was built by the same team that lead the 7.x-3.x rewrite of the Drupal Salesforce Integration module, and integration between the two modules has been carefully refined.

What is DevShop?

DevShop is Drupal DevOps in a Box. DevShop makes is incredibly easy to host multiple Drupal projects (with multiple environments each) on one or many servers.

Quick Links: DevShop | DevShop Hosting | DevShop Provision | Provision Git

Why DevShop?

The developers of DevShop have been using Aegir for years. It is great and creating a lot of platforms and a lot of sites. However, keeping these sites and platforms organized can be a real chore.

So, after years of setting things up by hand, writing new custom scripts for every new client, and wondering if there could be a better way, we set out to architect and build a Drupal development shop infrastructure... in a box.

The goals of DevShop are...

1. to simplify management of multiple environments for multiple Drupal projects.
2. to provide web-based tools that streamline the Drupal site building workflow.
3. to provide a common, open-source infrastructure for Drupal development shops.

Installation

The final step in our journey is to turn our feature into a full-blown app by integrating it with the Apps API.

The Manifest File

Panopoly and some of its extension apps like Panopoly News and Panopoly FAQ are stored on a manifest file on the Panopoly Apps server. This manifest file lets Drupal know which features are actually apps and what server they belong to. If your app is adopted by Panopoly then your app will get added to their Panopoly Apps manifest and you won't have to do anything. However if you want to set up your own App Server then a little more magic is required.

Setting up an apps server is very similar to setting up a Feature server however we will assume you have already set up your own server and that it has a properly constructed manifest file. If this is the case then the only thing that you need to do is implement the following hook in your MYAPP.module file.

Now that we have built our content types, entities and content panes and also successfully summoned the power of Panels we should have both the pieces and glue to call our bundled set of functionality an App. Sadly, it is not much of an app at this point since it only exists in the configuration stored in our database. Luckily, we can easily export this configuration into code using the Features module. For this process we also recommend the installation of the Strongarm module so that the variables that accompany your functionality are exported as well.

For a simple app like this you will likely only need to export items in the following areas. Features is good at recognizing dependencies so if you export a content type it will also export all the fields for that content type. Similarly, modular dependencies and variables will be exported as needed.

Panopoly Apps are portable bundles of functionality that are built on top of the Panopoly framework. This means that all Panopoly Apps are built with the Features module and extended by the Apps modules. Panopoly is a Panels driven paradigm and thus its apps are as well.

Why Panopoly as a Platform?

Start on the 10th floor instead of on the ground.

As a platform, Panopoly offers many key advantages when it comes to application development.