Single-Source Architecture Principles Single-Source Architecture is - - PDF document

Single-Source Architecture David Kirkwood, DrupalCon 2018, Nashville

Single-Source Architecture Principles

Single-Source Architecture is strategy for building websites in an iterative manner

• Each sub-site is distinct to the others
• Content
• Editing Privileges
• All are on the same database
• Utilizes core functionality (as of Drupal 8)
• Taxonomy, Content Types, Fields, Views, Blocks

Goals of Single-Source Architecture

• Eliminate Redundancy as it applies to:
• Websites
• Content
• Administration & Maintenance
• Simplify syndication and distribution of content

Websites follow a fairly predictable pattern

• Web content falls into 3 categories
• Static: Content that is regularly edited/updated but never replaced – About Us
• Ephemeral: Information that is rarely edited but regularly replaced – News story
• Dynamic: Information produced in response to a user’s input – Directory list, App
• Websites are generally comprised of the same assets
• Home Page (static with dynamic elements)
• Page (static) ex. About Us
• Employee (static) ex. Faculty Profile
• Announcement/Blog (ephemeral) ex. “Congrats…”, “System Maintenance”
• Event (ephemeral)
• News (ephemeral)
• Date (static) ex. “Last day to register”, Holiday
• Lists (dynamic) ex. Directory

Why do we create completely separate sites that do exactly the same thing?

• Each department needs a ‘Home Page’
• Content control/separation
• Limit editing access to a small group of editors
• Ability to grant access to an entire sub-site with the option to access individual pages

Single-Source Architecture addresses each of these needs

• Each department needs a ‘Home Page’ – Designate a ‘Department’ Content Type
• Content control/separation – Taxonomy

Single-Source Architecture David Kirkwood, DrupalCon 2018, Nashville

• Limit editing access to a small group of editors – Taxonomy
• Ability to grant access to an entire sub-site – Taxonomy

Added advantages

• A single instance of content can be syndicated across sub-sites – Views, Taxonomy
• Content can be easily aggregated across sub-sites and sent to third-party apps
• Core, module and theme updates only have to be applied once
• Very low dependence on contributed modules means forward compatibility is built in
• Scalable

Single-Source Architecture uses Drupal’s Core functionality

• Taxonomy – Vocabulary mimics the reporting structure of the organization
• Content Types – Classifies content by shared attributes; all attributes contained in fields
• Views – Content distribution and syndication
• Blocks – Places Views into pages providing a Taxonomy term as a Contextual argument

Step One: Taxonomy

• This is the backbone of the Single-Source Architecture strategy
• Each entity within the organization is represented by term
• Terms are arranged in a hierarchy resembling the reporting structure
• Required Field – All content must be tagged upon creation
• Designates specifically the content belonging to each entity
• Designates the hierarchical relationship to other content
• When used as a contextual argument with depth, a single View block can aggregate:
• from the bottom up (Newsletter), OR
• from the top down (Leadership Communications)
• Provides the first layer of filtering
• Pull all the content belonging to specific entity ex. College of Business
• Matching the Taxonomy term on a User’s account to the term on the content provides

editing access [Visual: Example of Department vocabulary] Step Two: Content Types

• Each Content Type designates content with a specific set of attributes
• Date Content Type needs only a month/day attribute
• Event requires a month/day/start-time and location attributes
• Employees have email, phone, and job title attributes
• Departments have email, phone, and business hours attributes
• Each Content Type is comprised of a unique set of attributes
• All attributes must be contained in a field
• Fields provide a handle for building Views
• Fields also remind the creator to include important information

Single-Source Architecture David Kirkwood, DrupalCon 2018, Nashville

• Fields should be reused and named for the general type of attribute it contains
• field_email (Not field_faculty_email; field_department_email)
• field_phone
• field_address
• Provides more granular filtering
• We can now pull all of the Academic Programs from the College of Business

[Visual: Example list of Content Types] Step Three: Views and Blocks

• Retrieves data that already exists in your Content Types and distributes
• Blocks will be used almost exclusively for site building
• Page views typically used to build content administration tools (Bulk Operations)
• The taxonomy term from the page provides the contextual argument
• A few blocks do an amazing amount of work
• Syndicates content to all related departments (Academic News from across campus)
• Distributes single instances of content to many places
• When the source is updated, all references are updated
• Improves accuracy of information with a minimum of administration personnel

[Visual: Example of all the different types of lists and page elements that can be built] Single-Source Architecture

• Makes it possible to build numerous sub-sites
• Consolidates features and administrative tasks
• Is scalable
• Forward compatible because it uses functionality of Drupal Core