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 o Content o Editing Privileges • All are on the same database • Utilizes core functionality (as of Drupal 8) o Taxonomy, Content Types, Fields, Views, Blocks Goals of Single-Source Architecture • Eliminate Redundancy as it applies to: o Websites o Content o Administration & Maintenance • Simplify syndication and distribution of content Websites follow a fairly predictable pattern • Web content falls into 3 categories o Static: Content that is regularly edited/updated but never replaced – About Us o Ephemeral: Information that is rarely edited but regularly replaced – News story o Dynamic: Information produced in response to a user’s input – Directory list, App • Websites are generally comprised of the same assets o Home Page (static with dynamic elements) o Page (static) ex. About Us o Employee (static) ex. Faculty Profile o Announcement/Blog (ephemeral) ex. “Congrats…”, “System Maintenance” o Event (ephemeral) o News (ephemeral) o Date (static) ex. “Last day to register”, Holiday o 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: o from the bottom up (Newsletter), OR o from the top down (Leadership Communications) • Provides the first layer of filtering o 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 o Date Content Type needs only a month/day attribute o Event requires a month/day/start-time and location attributes o Employees have email, phone, and job title attributes o 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 o Fields provide a handle for building Views o 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 o field_email (Not field_faculty_email; field_department_email ) o field_phone o field_address • Provides more granular filtering o 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 o Page views typically used to build content administration tools (Bulk Operations) o 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 o When the source is updated, all references are updated o 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