Shared Functionality on Department of Commerce Websites

Background

Background

• We started building our new Content Management

System (CMS) platform about two and a half years ago.• Commerce.gov was several years old, the theme was

not mobile-friendly, and it was running on Drupal 6.• Our small team was responsible for maintaining a number

of other DOC Drupal 6 sites, plus a handful of static HTML

sites put together with Dreamweaver templates -- including

the Department-wide intranet (internal DOC link).

Goals

• Move from Drupal 6 to Drupal 7• Fully responsive design• Cohesive look-and-feel for sites managed by our team• Multimedia galleries• Web content able to be produced and maintained by

Subject Matter Experts (SMEs)• Efficient maintenance of all of our sites

Plan

• (Originally) Central content repository, with several

sites consuming and displaying content from that

repository.

Plan

•(Ultimately) Build functionality that would be usable

on all sites managed by our team (Commerce.gov and

other public-facing sites, the Department-wide

intranet, and any other sites that might come along).

“Base Theme”

“Base Theme”

•Cohesive look-and-feel•Options to use preset color palettes or fully customize

your colors•Branding•Other theme options•(examples)

Drupal Features

Drupal Features

•All “Features” -- bundles of functionality -- are available

to all sites using our platform, and each “Feature” can be

enabled or disabled on a per-site basis.–Structured content types–Content listings, layouts, and landing pages–Roles and permissions

•Some “Features” are site-specific.•One code repository for all Drupal 7 sites.

Examples: Reusable

• Most content type definitions (i.e. structured content

type schemas for policy content, blog posts, events,

tools and resources, etc.)• Multimedia gallery functionality• Taxonomy definitions (i.e. categorization)

Examples: Platform-specific

• Some content types vary on public vs. internal sites• Some content types are only meant for internal sites• Some content types are specific to just one site• Some content types were built for use on a specific site

but intended to be reusable if a need arises

“Cons”

• Making configurations reusable is very tricky and time-

consuming...• Codebase is huge

“Pros”

• Cohesiveness -- for end-users and content managers• Easier development and maintenance -- only have to

build, update, or fix things in one place.

One more gratuitous kitten picture