Drupal 7 HTTPS

In order to keep up with Google’s HTTPS recommendations and related SEO implications, and in order to take advantage of CloudFlare’s recent move to support SSL for all sites, including free plans, with its “Universal SSL” initiative, we at Origin Eight are setting up all future Drupal sites (at least those that we host under our DripDrop Hosting umbrella) with site-wide HTTPS,  using CloudFlare’s Flexible SSL at a minimum.

For Drupal 7, we found the following configuration works quite well:

Add the following text in the gray box to .htaccess right after it says “RewriteEngine on”, or, even better, add to the webserver config in a site-specific manner so that upgrading Drupal core does not wipe out the .htaccess file:

# Various rewrite rules.
<IfModule mod_rewrite.c>
RewriteEngine on

RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

# Set "protossl" to "s" if we were accessed via https://.  This is used later
# if you enable "www." stripping or enforcement, in order to ensure that
# you don't bounce between http and https.
RewriteRule ^ - [E=protossl]
RewriteCond %{HTTPS} on
RewriteRule ^ - [E=protossl:s]

Then, add

$_SERVER['HTTPS'] = 'on';

to local.settings.php, ensuring local.settings.php starts with <?php and does not include a closing ?>, also ensuring the local.settings.php file is included via settings.php like so (make sure to clear your caches afterwards):

  # Additional site configuration settings.
  if (file_exists('/PATH_TO_DRUPAL_INSTALL/sites/www.SITENAME.com/local.settings.php')) {

Tutorial 1: Introduction to Drupal

How To Use Drupal 7 Tutorial Series



Series Introduction

This tutorial series will cover how to go about operating a website using the content management system (CMS) Drupal 7. This series will give you the basic knowledge needed to operate a Drupal 7 site. The OriginEight series How To Use Drupal 7 will start with an introduction to Drupal 7 and how this powerful, easy-to-use system can make website maintenance an enjoyable experience. The rest of the series will cover the various steps needed to operate your Drupal 7 website.


Part 1 – Introduction to Drupal 7.

Drupal is an open source content management system or CMS. The term open source describes software whose source code is made available, often under very generous and flexible licensing agreements, for use or modification by users or other developers. Besides that, open source software itself happens to be free of charge.

A content management system is software that facilitates the creation, organization, manipulation, and deletion of information in the form of images, documents, scripts, and plain text. The fact that Drupal is open source means that it is free to use. How can a system with this much power be free? This is due to a dedicated community around the world who share a basic principle that software should be open and free.

It is this large global community that makes Drupal 7 the powerful system that it is. The Drupal system is comprised of modules. To understand a module, think of a machine that has a special task like presenting a slideshow, e-mailing all of your clients a newsletter, or inviting friends on Facebook. Drupal 7 has hundreds of modules that can provide you with specific tools you need to provide the exact user experience that you desire for your website. Whether your site is a store (eCommerce), an event website, your company’s web presence, or a personal website, Drupal 7 can do it all. Your imagination is the only limitation you have when using this highly extensible framework.

Drupal 7 is scalable (grows with your organization), robust (powerful software that doesn’t break), secure, and portable (you can host it on most major hosting providers). These are all very important traits when you are going to operate a website. Further, Drupal 7 is efficient, reliable, flexible, and intuitive to work with, which adds even more value to an already free system.

How do you get a Drupal 7 site? You can build one yourself (for more technical folks and those with web development experience), create a site on DrupalGardens (similar to wordpress.com – allows you to pin up a Drupal site with a limited set of common features), or, for more advanced functionality and customization, hire a company like Origin Eight. If you are a technical person and know how to run and install software on a web host you can have your Drupal 7 site up and running in a matter of minutes. However, if you are like most people it may be beyond your ability or time constraints to create a site on your own.

Hosting is another factor in the equation. To make Drupal 7 really perform well, stay secure, and stay up-to-date, you should consider an optimized web host such as DripDrop Hosting, a sister company of Origin Eight. We have all the services you need to make your mark on the web. Origin Eight can provide top-notch graphic design, mobile design, custom development, site building, hosting, training, and more. To discover more about Drupal go to http://drupal.com and, for more information on the community, go to http://drupal.org.



Serve static HTML from Drupal 7

Ever wanted to serve a static HTML  page from Drupal? A quick-and-dirty was of doing this is as follows:

  1. Create a new subtheme from Zen or your favorite base theme, or roll your own. Maybe call it “Blank Theme.”
  2. Trim down your theme’s html.tpl.php file to look like this:
     <?php print $page; ?>
  3. Trim down your theme’s page.tpl.php file to look like this:
    <?php print render($page['content']); ?>
  4. Create a content type called “Static HTML” and paste the entire HTML doc in the body field of nodes of this content type. Ensure that the text filter for either defaults to “Full HTML” sitewide, or for this content type by using http://drupal.org/project/better_formats .
  5. Use http://drupal.org/project/themekey to create a rule that switches the theme to “Blank Theme” for this content/node type.
  6. [OPTIONAL]: Create a new content type called “File Attachment” and use https://drupal.org/project/attachment_links to manage any image or other assets in your static HTML through the Drupal UI. Use the links that this module provides to create a permalink to these files, thus avoiding Drupal’s default behavior or renaming new files uploaded to a given field. Otherwise, just reference your assets via <img src=”/hardcoded/path/to/theme/image01.png”/> and such.

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/sitename.com# 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.

Amazon.com has been a leader in this domain. Just look at all the recommendations and custom-tailored content you receive when logged in to amazon.com. The site even informs the anonymous, uncookied user when there is no browsing history to act upon, encouraging further activity on the site.

Amazon.com 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.