Commercial SSL certificates on Aegir 1.x

Installing an SSL certificate on Aegir 1.x is a bit tricky, but definitely manageable. It is easy to bring all your sites down if you don’t follow these exact steps. Running a “verify” task on your site, either intentionally or inadvertently, will rewrite your SSL config and attempt to restart apache, which, if everything is not set up perfectly, will cause fatal errors upon restart and lock you out of your Aegir control panel until they are fixed.  Check out the latest documentation from the Aegir project here before following this documentation to ensure that everything matches, but do note the specifics pointed out in the steps below:

1.) Let Aegir generate its own self-signed certificate, which will create two files in /var/aegir/config/server_master/ssl.d/SITENAME.COM/:

root@aegir-prod:/var/aegir/config/server_master/ssl.d/ ls 

openssl.crt <– Replace this Aegir-generated file with the X.509 cert file from the cert provider.

openssl.key <– Replace this with the .key file generated for the CSR. Or, even better, just use this file rather than generating the CSR yourself.

2.) Add the bundle / intermediate file to this same directory, but you must name it “openssl_chain.crt” in order for Aegir to recognize or “import” this file.

 openssl_chain.crt <– This is the bundle / intermediate cert file from the cert provider, which must be created manually. It *must* be named exactly like this.

3.) If you don’t follow these exact steps, or forget to add the bundle / intermediate cert file, when Aegir runs a “verify” task on your site again (or if you run it yourself), Apache will fail to restart, and all your sites will go down! So, before you run a “verify” task on the site on the front-end to complete the installation, be prepared to comment out the SSL settings for your site at /var/aegir/config/server_master/apache/vhost.d/SITENAME.COM, restart apache, fix your errors, and start over.

Making content more relevant to individual users

The people who use any given web site are all different in terms of geography, past behavior, intent, device, time of day, the temperature of the climate they’re currently in…and the list goes on. Developing for the web is anything but easy, so, over the last few years, the Drupal community has been focusing on keeping up with the various mobile device sizes, design patterns and browser technologies, putting a lot of attention on responsive design, and doing it well. So, we’ve since been doing fairly well on adapting to various devices, but what about the aforementioned traits such as intent, past behavior and the like?

We often create personas to plan and design web sites, but the content does not embody or respond to these fictional-turned-real characters. Marketers spend a lot of time producing content that could be better-tailored to each individual. An individual’s browsing history can be cookied, if they are an anonymous user, or logged in analytics and tied to their account as an authenticated user. has been a leader in this domain. Just look at all the recommendations and custom-tailored content you receive when logged in to The site even informs the anonymous, uncookied user when there is no browsing history to act upon, encouraging further activity on the site. with no browsing history

Think about a woman in her late 60s – based purely on statistics, she might opt-out if she receives an email that contains offers for power tools and pro athlete products. Or a man who receives an email with women’s clothing. Similar consequences are in play on web sites.

Another example of a leader in context is Netflix. New videos are recommended based on your viewing habits, ratings, and even your Facebook friends’ activity on Netflix.

Screen Shot 2013-06-14 at 4.39.50 PM

The buzzword for this context is called Web Experience Management (WEM). Vendors have been developing proprietary, expensive, closed-source solutions. It is to the great benefit of the Drupal community to engage in WEM as part of What Drupal Does. There is already work being done with the WEM project that allows one to track user events as they occur throughout the site. By so doing, one can customize a user’s experience so that it is unique and relevant to the user. The WEM module also integrates with Google Analytics to further track events. Any event you track in WEM can also be sent to Google Analytics.

Events are tracked via the included  Engagement API. You can track an event via PHP on your page or during a certain hook in a custom module. The PHP would look something like this:

engagement_event_track($event_name, $event_value, $event_data, $uid);

An event can also be tracked via Javascript, like so:

Drupal.engagement.track(event_type, val, data)

An event can also be tracked via HTML, such as in an HTML email.

The WEM project is currently under active development, but already usable. It needs people to help with integration into Views, Rules, and similar Drupal architecture patterns. With that, let’s close with a few screen shots of the WEM module in action, running on on Drupal 7. One can see that UI for assigning points to events within categories is simple yet effective. User segments can be built from these categories and corresponding point totals to deliver a customized, contextual experience to your user. This effort will hopefully make WEM much less of a concept of its own, and lead to the expectations of what Drupal does as a CMS. WEM is really just a CMS, with context.

Screen Shot 2013-06-12 at 3.33.41 PM Screen Shot 2013-06-12 at 3.34.33 PM Screen Shot 2013-06-12 at 3.34.44 PM

Web Experience Management: User interface in Drupal 7

Web Experience Management: User interface in Drupal 7

Using Drupal 7 Features to configure different environments

Drupal 7 Features 2 screen

Drupal 7 Features 2 screen

Until we can override the enabled module/theme/library list dynamically in Drupal 8 via configuration, we can bundle up our environment-specific development modules and Strongarm variables in a feature and enable the feature on a per-environment basis in settings.php (or even better, local.settings.php) via a project called Environment Modules. For example, one could create a feature for the development environment, enable the devel module, and set environment-specific Strongarm variables such as those that leave Drupal core caching disabled or environment-specific settings for Domain Access domains. Additionally, whenever refreshing the development, integration or staging environment databases from the production database as part of a release cycle, doing a simple Features revert reenables the correct environment-specific modules and sets the right environment-specific variables.

As the Environment Modules project states, $conf[‘environment_modules’] should not be set on your production site in its settings.php, however the module itself can still remain enabled on production without a performance hit — it just doesn’t do anything in that particular environment.