Tag Archives: OpenAtrium

Our webhost, Acquia, provides security updates as a service through Remote Administration Automation. This means that, when a security update is released for any contrib modules used in any of our sites, Acquia is immediately aware and immediately begins the process of updating said module. Once they have the module’s updated version committed to our git repository, they can either automatically deploy it or simply notify us of the update so we can review it and deploy it ourselves.

In a Standard Drupal Core instance, this is great! It cuts the estimated 25% Full Time Employee (FTE)’s time to keep Drupal up to date down to ~5% (my own rough estimate). However, with an instance of Open Atrium, this automated-update process can cause problems.

With Open Atrium, even with critical security updates, the proper process is to hold off on individual module updates and wait for an official release of the Open Atrium project. This is because there may be other changes to OA modules/themes that are now required due to the contrib module’s update.

This means that when the automated process detects an available update for a module in OA, it will apply the upgrade only to the contrib module. If notified, Acquia will wait for the proper OA release and perform the update with it but it often takes some back and forth correspondence and may introduce extra delay in getting that update to production. When the update contains a patch for a critical security issue, that may not always be tenable and manually upgrading may be the only option.

My colleague has produced a series of commands that, when executed from a level above your docroot will update OA, keeping your sites directory intact as well as all your dotfiles, robots*.txts, and, in our case, our simplesaml configuration:

Last month, Open Atrium released one of their largest upgrades since version 2. Included in this upgrade is a complete revamp of the theme layer. You can read more about the changes in 2.6 here: A Fresh New Look for Atrium.

Browse to Appearance Config(/admin/appearance) and select Set As Default for oa_basetheme.

Run the oa_basetheme bootswatch starter Drush command:

1

drush oa_basetheme"My Subtheme"

No errors this time! I’m honestly not sure if the resolution was the fact that I moved oa_basetheme from the Open Atrium profile to sites/default or the fact that I set oa_basetheme as the Default theme. I’m inclined to think the fix was the latter since the error was a Bootswatch conflict with oa_radix, but, alas, I have yet to actually confirm this.

This will put the new subtheme in “docroot/sites/all/themes”. If you don’t need it in /sites/all, be sure to move it to /sites/default.

1

mv/docroot/sites/all/themes/my_subtheme/docroot/sites/default/themes

Browse to Appearance Config (/admin/appearance) and select Set as Default for the original theme from Step 3.

Remove the copy of oa_basetheme from your site’s theme directory

1

rm-rf docroot/sites/default/themes/oa_basetheme

Now, if you have a fresh install of OpenAtrium 2.6x, you can go ahead and “Enable and Set as Default” directly from Appearance Config (/admin/appearance) and you’ll be good to go!

Upgrading from 2.5x to 2.6x?

However, if you, like me, are upgrading an existing OpenAtrium site from 2.5x to 2.6x, there are a few more steps you need to take to enable all the new features of the theme.

Enable the Open Atrium Site Layout Defaults module. This is a module that ships with OA 2.6x and contains the default panels config required for the new functionality in the new 2.6x theme.

1

drush en oa_site_layout_defaults-y

This will also enable dependencies: oa_site_layout and panels_everywhere

Go ahead and Enable your new subtheme in Appearance Config (/admin/appearance) but do not Set As Default just yet.

The OA base theme’s panel layout is defined in a Page called site_template for the Panels Everywhere module, however, out of the box, it’s configured to be used only when the current theme is either oa_theme or oa_basetheme.Since we have a new subtheme, we need to update the selection rules for the pertinent Variant within that Page to use the Variant for our new subtheme as well. Sooo… browse to “/admin/structure/pages/nojs/operation/site_template/handlers/site_template__atrium-modern/criteria” (or go to Admin > Structure > Pages > Edit site template Tab > Selection Rules)

Under the Criteria Table, select “Current theme” from the drop down and click the “Add” button.

On the Selection Rules config page of the Modern layout Variant, select “Current theme” and click the “Add” button

Select your new subtheme from the dropdown menu and click the “Save” button.

Select your new subtheme and click the “Save” button

Click the “Update and Save” button at the bottom of the Variant Options for the Default site template page.

Once your new selection rule has been added, click “Update and Save” on the Variant modal.

Finally, go back to Appearance Config (/admin/appearance) and select Set as Default for your new subtheme.

Clear caches and you’re all set to start working on the theme’s code itself.

1

drush cc all

One more thing… Regarding Concurrent Themes

We are currently planning to deploy our new subtheme to a subset of users: a beta group.

This requires keeping our existing theme from 2.5x enabled and using ThemeKey and ThemeKey User Profile (packaged with the ThemeKey module) to allow users to “opt-in” to the new theme.

To accomplish that, forego Step 7 of the previous list, leaving your old 2.5x theme as Default and your new subtheme simply Enabled. Follow these steps to install and configure ThemeKey and ThemeKey User Profile.

Browse to the UI Settings for ThemeKey (/admin/config/user-interface/themekey/settings/ui), expand the Selectable Themes table and check the checkbox for your old 2.5x theme and your new 2.6x subtheme.

In the UI Settings table, select “Add theme option to user profile”.

Click the “Save configuration” button.

Browse to User Permissions configuration page, and ensure the permission: “Select different theme” is enabled for your required roles (in most cases, authenticated user). Or, add the permission to the role with Drush:

1

drush role-add-perm'authenticated-user''select different theme'

Now when a user browses to their Edit Profile page, they’ll be presented with a field to select the theme to use.