KK Multi-site project - Københavns Kommune · KK Multi-site project: ... and are part of the Hosting Drupal project. ... KK Multi-site project: Solution description 8

KK Multi-site project: Solution description

1

KK Multi-site project

Solution description

Version 1.0

20.02.2015


2

Revision History

Date Version Description Author

25.11.2014 01 Initial draft 01 Miroslav Banov

19.01.2015 02 Draft version 02 Miroslav Banov

20.02.2015 03 Updated version -1.0 Biser Simeonov

Document Authors

Written by: Miroslav Banov Dev Team Lead

Approved by: Boyan Borisov Solution Architect

Reviewed by: Biser Simeonov Project Manager


3

KK Multi-site project

Summary

This project is for developing a multi-site system. It gives administrative tools in order to create

and maintain multiple sites for the municipality of Copenhagen. The sites are created fully-

functional and ready to be used. The Aegir platform is used as an administrative tool for

maintaining the system. Aegir is highly reliable, and features sensible backup procedures, so

every task is fail-safe. The sites are created from profiles, which package the codebase and

functionality of a site. The main profile is the “Multi-site profile” (kkms_profile), which is generic

and geared towards extranet sites for dispensing of information to unauthenticated (anonymous)

end-users. It features accessibility, intuitive UX, and a balance between customization options

and uniformity of experience. A versioning scheme is used where incremental release versions

are developed, tested, and deployed. The Multi-site profile can be extended with more specific

profiles that meet more specific requirements. This is done by creating another profile that

generally inherits all the functionality of the Multi-site profile, and adds additional functionality on

top of that.


4

Multi-site system infrastructure

Scaling and performance

Server setup

Traffic from the extranet is resolved on the Varnish reverse proxy server. The Varnish passes

the traffic to the Haproxy load balancer, which sends the traffic randomly towards a web-server.

The web-server is part of a cluster of web-servers, and each one of the web-servers can

process the request and compute a response. Each of the web-servers is connected to a

number of other external devices or machines. An NFS filesystem is mounted on every single

web server, so the files can be centralized. Additionally there are remote memcache and

database machines. Also Apache Solr is used for searching and indexing, and the web servers

are occasionally connecting to the Varnish reverse proxy, in order to invalidate specific cached

pages when they need to.

It’s that simple

The following chart shows basically how an HTTP request is handled.


5

Not quite

In reality, it is slightly more complex, because of failover (mysql replications, etc.), and network

infrastructure specifics (firewall, traffic routing, etc). KS ops are in charge of the specifics of the

setup. This chart only shows the bare essentials of the setup.


6

Multi-site maintenance

The multi-site system relies on several pieces open-source software that comprise Aegir, in

combination with a few custom extensions to it, for providing the function to maintain the system

and all the sites on it.

Aegir server

The Aegir server is an essential part of the setup for maintaining the Multi-site system. Aegir is a

web-server on which the Hostmaster site is installed. Hostmaster is used as a web interface for

creating and maintaining web sites. Aegir is able to connect to the subsystems of the Multi-site,

like any other web server. It is able to connect to Solr, Varnish, NFS, Database, etc.

Hostmaster

Hostmaster is the administration part of an Aegir system. Hostmaster is a site that provides the

web interface for maintaining a multi-site system. A Hostmaster site invokes Provision

commands in the backend, which are executed on the Aegir server. The administrative

features of a Hostmaster site which are responsible for monitoring, logging, queueing tasks,

and maintaining Aegir are called Hosting features, and are part of the Hosting Drupal project.

The maintenance of the sites is accomplished through Hosting tasks. These tasks are run on

the Aegir server. Additionally, as part of the tasks, the codebase and configuration is

synchronized to all of the web servers on the web cluster.

Hosting queues

There are two queues that exist in any Hostmaster site:

1. Tasks Queue

Every task that is started in Hostmaster is added to the Tasks Queue, and is then

pending execution. The queue is processed periodically, and there is a configuration that

specifies how many tasks can run at the same time.

2. Cron Queue

For every site on the Aegir, Site cron needs to run periodically. The cron queue cycles

through each site and executes the Site cron.


7

Hosting entities

Hostmaster has several different entities which define different parts of the Aegir system. Here

are some of the important ones:

1. Web server - A machine that can host sites.

2. Database server - SQL databases for sites.

3. Web cluster - a grouping of Web servers.

4. Platform - A specific Drupal codebase on which sites can be installed.

5. Site - A single site that can be installed.

Upon installation of a Site, the Platform, Database server, and Web server (or Web cluster) is

specified. The Platform will be synced to the Web server (or to all Web servers on a Web

cluster). The site can later be migrated to different Platforms, Web Servers, Databases, etc.

Hosting actions

On Hostmaster entities, various actions can be executed. When running an action on an entity,

a task is queued for execution. Here are some of the available actions that Hostmaster

administrator can run:

● Install

● Migrate

● Verify

● Delete

● Backup

● Restore

● Clone

When running a potentially dangerous task on a site, like migrate, typically the site is backed

up, so it can be restored in case the task is detected as failed. This happens automatically, so

it’s rare that server operations would have to manually recover a site. The site is also put in

maintenance mode, so activity on the site won’t interfere with the task.

Here is an example of the flow of a typical Hosting task:


8

The synchronization of the Platform (codebase) is very important step. All of the web servers

are supposed to have a complete and identical version of the codebase in order to ensure

consistency and integrity of a site.


9

After the synchronization steps, all Web servers and the Aegir server are expected to have

identical server setup for the site, so the result of an HTTP request would be exactly the same,

regardless of which Web server receives the HTTP request.


10

Multi-site content sharing

Content sharing is an important concept for KKMS project as it introduces many benefits to the

editors and the organization itself.

The goal of the content strategy for the KKMS Drupal platform is to:

● Encourage recycling and reuse of content across the entire platform

● Avoid repeated creation of the same content from scratch

● Improve the value of the multi-sites by making valuable reusable content available for

these sites

● Avoid duplicated content that needs to maintained several 'places'

● To use /reuse content in context of the site where the user finds it.

The Multi-site system features several types of content sharing. They rely on sharing a single

Apache Solr index, and the multi-site search functionality. Additionally there is a centralized

repository for content and taxonomies (CTAX), which is creating content that is synchronized to

all sites connected to the same CTAX. There are a number of sharing functionalities that

depend on one or both systems being available.

CTAX (shared content repository)

This is probably the only content sharing that does not rely on Solr at all. Sites know how to

connect to the correct CTAX, and this is part of the Aegir setup. Every site on the Multi-site

periodically requests any updates to the shared content, and they apply the changes locally.


11

This type of content sharing implies content duplication. It is intended to be used sparingly for

only a few content types, which are meant to be centrally managed and shared to all Sites.

Currently these are: Institution; Place; Person.

Sharing multisite information form Solr

Every site that connects to the same Solr will send information to the Solr about the site. This is

done by sending a special document containing “Multisite metadata”. This is how a document

with multisite metadata appears in Solr:


12

Every site will also request information for all sites from Solr. This way all sites connected to the

same Solr will have the information available and know what sites are connected to that Solr,

and how each site can be accessed. This is a key prerequisite for almost all types content

sharing on the Multi-site.

One important field is the Apachesolr site hash, or “hash” as it appears on the document. This

is a unique, randomly generated string that is different for every site. This field is added to every

document that is indexed in Solr, and allows sites to know what site indexed a specific Solr

document, and to query Solr only for documents containing that specific hash, in this way

possibly showing only the site’s own content. Here is an example for how the hash is sent as

part of a Solr document for the Event content:


13

Copying remote content

This content sharing relies on the site having Solr multisite information available on the site.

Every site can produce a list of remote content that can be copied locally, available in the

Editor's Workbench. The list is provided from the Solr search index. This can be accessed from

My Workbench -> External content (admin/workbench/pull-content). There the content can be

searched by content type, site, and title. Copying is one-time thing and no reference is kept to

the original. The content can be changed and there is no obligation to keep any semblance of

the original. Also, there is no information about what was copied, and nothing is stopping a user

from copying the same content several times.


14

Showing remote content

Since every site is connected to the same Solr, it is possible to query Solr for content created on

other sites, and display the information on a specific site. The concept of content “channels” was

developed to group content in channels for the purpose of sharing between sites. Additionally

there is the option to share content to a specific site directly. The site administrator picks what

channels content belongs to, and to what sites it is shared, as they create or edit the content:

This sharing information is sent to Solr, as part of the document.


15

Of course, just picking a channel on site A is not enough, site B has to create a content listing

that subscribes to that channel. The sites can create customizable listings of shared content to

be displayed on section pages.

The content listing will display a list of content created from different sites with links to the

content pages. Clicking on a link will mean that the visitor will leave the site and will navigate to


16

a content on a different site. In the configuration, there is an option to “link to content in local

context”. Choosing this option will mean that the visitor will not navigate away from site B, but

the information will be transferred in the backend between both sites, and the visitor will be able

to see content from site A, without leaving site B. This is on-demand content sharing, which

avoids content duplication.

Content sharing – overview

An overview / summary about the implemented content sharing options are listed underneath.

Site sharing filter - Channels

● Channels are taxonomy terms.

● Channels can be created, renamed, deleted on the CMT.

● Channels are only created on the CMT.

● Creating channels directly on the local site will break the correct flow.

● The site’s channels are picked from the site administration.

● The site can choose from channels that were created on the CMT.

● All nodes of the following content types will have channels associated to them:

● Area, Article, Blog entry, Event, Institution, News, Self service, Service situation, Tender

● The content can be tagged only with the channels chosen for the current site by the site

administrator.

● Default channels for every content type are also able option for the site administrator.

Site sharing filter - Sites

● The filter contains all files from the multisite platform.

● The site administrator selects other sites to push content to.

● Every piece of content can be pushed to other sites.

● Every piece of content can be pushed only to the sites selected by the site administrator.

View panes: Shared content

● Two kind of views are available:

○ Content shared to Channels

○ Content shared to this Site


17

● First views have filter by Channels and will display all nodes tagged with them (also the

views have additional filters like - Content types, Created on sites and KK common)

● Second views have the same filters without the Channels one.

External content in local search results

In order to see external nodes on the local search page of your site, you should add one or

more “Shared content” view pane on section page(s) and to select “Link to content in local

context” checkbox for that pane (as shown on the screenshot underneath). Only in that case the

user will be able to see all nodes from the view pane in the search results.


18

Multi-site production cycle

Development for the multisite is done with profiles. The main profile is "kkms_profile" (KK Multi-

site profile). Extension profiles can also be developed. When a new release candidate is

developed, the profile is tagged with a new incremental version. Then on test Aegir, a platform

is built from that version of the profile. For testing purposes, sites are created on that platform,

and other sites are migrated from a platform built on a previous version of the profile to the new

platform. Automated and manual tests are executed, and if the tests pass, the version is

considered to be ready to be deployed on production Aegir.


19

Profile development

Architecture of Multi-site profile

Make file

Contains all the information for the codebase of the Drupal build. It contains all modules;

themes; libraries, their versions, and how to retrieve them. It is basically used by calling "drush

make" command in order to build a complete (Multi-site) Drupal build, ready to be used for

creating sites on the build, or migrating sites from other builds to that build.

Info file

Contains all the modules that need to be enabled. The modules must exist on the build which is

created from the Make file. Adding them to the info file makes sure that they will be enabled

when a Drupal site is created from the Multi-site profile.


20

Install file

Contains code that will be executed on installation of a site and will set up certain default

configurations one-time while still allowing them to be changed. Additionally, it contains code

necessary for updating from one version of the Multi-site to another.

Profile file

Similar to Install file, as it contains tasks that will be executed on installation of a site and will set

up certain initial content and sensible defaults. Usually tasks that require the language system

to be set up, are placed in the profile, as there is control on the exact order of the tasks, which is

only possible in the Profile file.

PO files

Portable Object files are used to specify translations for a site, installed from this profile. The

GNU gettext format is used for that purpose. The site must be installed in Danish language, in

order for the po files to be imported as translations when the site is installed.

Working with the Multi-site profile

For the purpose of developing functionality for the Multi-site profile, there are guidelines for

setting up and maintaining a site for development purposes. Additionally, there is an automated

build tool, which helps simplify and streamline development. For production, Aegir is used for

automating this work.

Setting up a site

Execute 'drush make' in order to build the codebase and create a drupal build:

drush make /path/to/kkms.make /path/to/drupal/build

Execute 'drush site-install' in order to install the site from the Multi-site profile:

drush site-install kkms_proile

Execute 'drush features-revert-all' in order to apply all configurations maintained in features to

the site:

drush features-revert-all

Updating an existing site

Execute 'drush make' in order to build the updated codebase and create a drupal build:

drush make /path/to/updated/kkms.make /path/to/updated/drupal/build

Move the site to the new build

mv /path/to/drupal/build/sites/example.kk.dk /path/to/updated/drupal/build/sites


21

Execute 'drush updatedb' in order to apply all pending updates to the existing site:

drush updatedb

Execute 'drush pm-enable kkms_profile' in order to enable all modules that were added to the

Profile info file:

drush pm-enable kkms_profile

Execute 'drush features-revert-all' in order to apply all configuration changes maintained in

feature modules to the site:

drush features-revert-all

Using automation tools

There is a phing build tool that is maintained specifically for developing Multi-site profile and

extension profiles:

https://kkgit.kk.dk/drupal-7-kkms-modules/kkms_setup

This tool automates some of the routine tasks that need to be done in development. It is used

for automating the update process, and for making new releases. Refer to the README.md file

for how to use it:

https://kkgit.kk.dk/drupal-7-kkms-modules/kkms_setup/blob/master/README.md

The tool can be branched/forked and modified to fit specific needs. Alternative tools can also be

developed, and they could work equally as well for automation purposes.

Using the multisite with Aegir

For production, and also for stage and test purposes, we use Aegir (with some modifications

and extensions) in order to use the profile for creating and maintaining sites. This is true for all

pure Multi-site installations, and for sites installed from Multi-site extension profiles as well.

Automation tool for kk.dk

www.kk.dk is a site created from a Multi-site extension profile, but not maintained from Aegir.

The site has its own upgrade procedures developed and maintained by KS ops. There is no

requirement to use Aegir on production, as long as the scripts/tools comply with the Aegir flow.

All tools should work exactly the same

The guidelines for creating and maintaining sites are identical to what Aegir does. And all

automation tools work the same as Aegir. This way, we avoid the situation where upgrade

mechanism is developed, but it doesn’t work when executed on production.

https://kkgit.kk.dk/drupal-7-kkms-modules/kkms_setup

https://kkgit.kk.dk/drupal-7-kkms-modules/kkms_setup/blob/master/README.md


22

Multi-site configurations

Configuration for a multi-site mainly is done with feature modules, and install hooks.

Feature modules

Features are used for configurations that should never be changed by site users. These

configurations are made by the developers, exported to features and are used as such. If a site

user has the permissions to adjust the configurations, and does that, then they will be reverted

automatically, whenever the site is Migrated or Verified in Aegir. Features may be reverted at

any time, and overriding a feature-controlled configuration should be avoided. As an example,

configurations that are in feature modules include:

● Roles

● Permissions

● Fields

● Content types

● And more

Configuration that is not in features

Other configurations are left to be adjusted by the users that have sufficient permissions. These

are not maintained in features. Often they are initially set up by profile an module install hooks.

For example, the site front page is initially set, but is not in features, and therefore configurable.


23

Multi-site functionalities

Integrations

Here are listed Multi-site functionalities that related to external services.

Kultunaut

Kultunait is an external site that requests information about events from the KK.dk and possibly

other sites. The integration is exposing an XML feed for kultunaut to import so as to display

events from the Drupal site.

Ubivox

Integration with the Ubivox email delivery service. This allows to subscribe to externally

maintained newsletters. There is a good module documentation that can be consulted for

details. See "https://kkgit.kk.dk/drupal-7-kkms-modules/ubivox/tree/master". The module is not

automatically enabled on all multi-sites, and is available to be enabled if needed.

Piwik

Piwik integration relies on contributed Drupal modules, with a few custom extensions (the

Workbench tab). Configure from "admin/config/system/piwik". It's important to remember that if

in Piwik is set up to force SSL (force_ssl=1) which appears to be the case for KK Piwik

(http://piwik.kk.dk/), then it is advisable to have https URLs in both "Piwik HTTP URL" and "Piwik

HTTPS URL" fields to be configured with the https URL, so as to prevent the redirect and this

bug in Piwik (http://piwik.org/faq/general/faq_75/), also for better performance.

Main Functionalities

The Multi-site is a general profile, and is mainly focused on content. Following are the main

multi-site functionalities that don’t relate to external integrations.

Accessibility

Complies with WCAG 2.0 AA and so it is accessible to people with disabilities.

Responsiveness

Responsive layout is developed, which means that sites smoothly transition between different

browser display dimensions, and are optimized for devices of various display sizes.


24

Content types

There are over 30 content types available on the multi-site profile, and extension profiles can

have even more. Content is loosely distinguished as "primary", and "secondary". Primary

content is intended to be displayed directly as a page, and secondary content is intended to be

used as part of a primary content.

Uniformity of design

Most content types follow very consistent design, and they appear in similar ways, which helps

the sites' visitors more easily process and comprehend the information.

Content classifications

● Primary content: intended to be displayed directly to a visitor. Event page and Article

pages can be good examples.

● Secondary content: intended to be used as parts of another primary content page. FAQ,

and Map pages can good examples.

Navigation and structure

The profile is designed so the navigation can be intuitive and the content is discoverable. There

are functionalities that apply visibility rules to the menu structure, so for example only immediate

parent and children menu items are shown in the right-side menu.

Section pages

An exception to the uniformity of design, the section pages are highly configurable content types

that use panelizer and in-place editing, and their main purpose is to be used as landing pages to

easily discover and navigate to specific content.

Flexible content listings

On the section pages, there can be attached smart content listings, that allow to group and filter

content, including remote content from other sites in the Multi-site system.

Workbench

For the purpose of easily finding and editing content, the Workbench administration page

provides various tabs available to be used.

Predefined Listings and Searches

There are several predefined Search and Listing pages. Most of them are Solr search pages.

These are the relative URLs:

● search/site


25

● news/list

● employees/list

● events/list

● events/grid

● events/map

● institutions/list

● contact/list

● blog

Theme customization options

The theme is sass-enabled. It has customization options for specifying colors, layout, header,

logo, footer.

Extensibility of Multi-site

The multi-site profile can be extended with more advanced, and more specialized profiles. The

general idea is that the extension profile includes all of the codebase of the Multi-site profile.

Additional code is added by the extension profiles. So extension profiles generally include all

Multi-site modules, and also some new modules developed specifically for the extension

profiles. For added flexibility, the extension profiles may choose not to enable certain Multi-site

modules, which can allow the functionality to diverge more freely. This is not recommended to

be overused, as it might make upgrades of the extension profile more difficult.


26

Dependencies for KKMS

It is well known that every project is faced with many and different risks. There risks also might

be raised during different phases or sprints of project and the team has to be well prepared to

handle them. However, while some risks may be beneficial, in that the sponsor and a

This document aims to define, identify and possibly cutting down the effect of potential project

risks. Usually the risk management planning has to be completed early during the project

planning stage since it is crucial to successfully performing the other project management

phases.

The risk management plan identifies and establishes the activities of risk management for the

project in the project plan

Reusability in general

Profiles

Drupal sites are installed from profiles. Profiles are collection of modules and are used for the

purpose of installing the initial site modules, and for maintaining site configuration. Profiles can

be thought of as packages of functionality. Profiles are NOT reusable by definition.

Modules

Modules are a set of functionality. Some have heavy dependencies and tight constraints which

make them non-reusable.

Feature modules

Feature modules are machine-generated modules that are exported from the "Features"

module. They are used to store and maintain configurations. They are NOT reusable by

definition, because they contain configurations that are specific to a site or profile.


27

Themes

Themes are reusable in general and can be extended in sub-themes. Some themes are basic

and serve as a framework for sub-themes. Others are very complete and feature-rich, but

cannot be extended easily or changed dramatically in a sub-theme.

Reusability of KK profiles in extension profiles

All KK projects can be found on https://kkgit.kk.dk/. Feature modules reside in shared

repositories: kkms_features, kkdk_features. The profile make files and profile info files can be

used for details on all modules that are used on a profile.

KKMS profile

KKMS profile is an exception to the rule and is a profile that is made to be reusable and

extendable. By extension, the Feature modules that are included in KKMS are also reusable.

KKMS profile is a very flexible and feature-rich without extending. It includes many content

types, intuitive editorial experience, customizable theme, several content sharing options,

integrations with external services, and feeding of centrally managed categories and content.

Extending the profile means the this functionality is taken as a base, and other specific

functionalities can be implemented on top of it, that would be needed on specific sites and not

on all multisites. The caveat is that any profile that extends KKMS would have to include most of

the KKMS functionality, including the constraints and dependencies. This would make it more

difficult for developers, because the complexity of the profile is high at the start of a new profile

that extends KKMS. There is a much higher chance that new functionalities and developments

will conflict with existing ones.

Reusability of individual KKMS modules separately

[apachesolr_channels, kkms_search]

- Related to content sharing and rely on CTAX, Solr, also depend on kk_client_request. Non-

reusable separately from KKMS.

apachesolr_date


28

- Too specific to be useful outside of the KKMS profile.

cld_api

- Reusable.

cld_client

- Used for fetching translations from centralized management. Reusable but tied to the CLD.

history_node_deleted

- Reusable.

kk_charts


kk_decision_tree

- Reusable.

kk_scs_extra

- Is reused from KKNI and is Reusable.

kk_ui_help

- Reusable.

kkms_media_alter


kkms_openlayers


kkms_panes

- Too specific to be useful outside of the KKMS profile, and has some heavy dependencies.

kkms_performance



29

kkms_related_content


kkms_social

- Reusable.

[taxon_taxonomy, kk_client_request, kk_taxon_taxonomy_alter]

- Related to shared taxonomies and rely on CTAX. Reused from KKNI, but have some heavy

dependencies.

[pull_content, pull_content_feed, services_node_view]

- Related to content sharing and rely on CTAX, Solr. Reusable but have heavy dependencies.

ubivox

- Reusable.

working_hours

- Reusable.

Reusability of individual KK feature modules separately

Generally speaking individual feature modules cannot be reused separately. They are meant to

be configurations specific for the profile or site on which they exist. The exception to the rule is

when a KKMS profile extension is created. In this case many of the KKMS profile features can

be and should be reused.

Reusability of individual KK themes separately

KKMS theme

This one is too specific for the KKMS profile to be reused. Also, it uses SASS to compile the

CSS, and BlessCSS to split it up, so it will require several ruby/nodejs extensions in order to

work on it. Also, because the theme is very complete and thorough, it can be extended with a


30

sub-theme to make a few minor adjustments, but it is difficult to significantly change it. This is

why, extending the theme should only be done from KKMS extension profiles. KKDK theme is

an example of this.

KKMS admin theme

This theme is a sub-theme of the core Seven theme. It is too specific to KKMS sites to reuse it

elsewhere.

More information about the theme is provided within the document “KKNH Theme - Guidance”.

KKMS profile maintenance and releases from PP side

KKMS profile has incremental tags wich serve as releases. The tags follow the Drupal tag

naming convention. They start at 7.x-1.0, then 7.x-1.1, and so on. The tags are all created from

the master branch. The most recent tag is 7.x-1.28 at time of writing. This version is not yet

tested for regressions. Version 7.x-1.23 is currently deployed on production. It is the latest

stable and tested version. PP uses kkms_setup for working on and maintaining the KKMS

profile. Creating the incremental releases, maintaining the testing environments, and setting up

the project on individual developer's computers is all done with kkms_setup.

Creating and maintaining KKMS extension profiles

Let's say that we want to create a new profile and call it kkms_extension_profile. Here are the

minimum steps for working on it.

Dependencies and restrictions of the KKMS extension profiles

KKMS profile, and KKMS extension profiles have a number of integrations and requirements

that need to be done in order to be set up correctly. These include external services: CTAX,

Solr, CLD (not yet). Also, the following requirements to work on the theme: Compass, SASS,


31

BlessCSS. Some of these requirements are easier to configure and maintain properly, using the

kkms_setup tool.

Creating KKMS extension profile

Create a new git repository. Clone it and add the following files to it:

kkms_extension.make

The make file has to include the kkms_extension_profile profile as part of it. Additionally, a tag

of the kkms_profile needs to be included in the make:

includes[] = "https://kkgit.kk.dk/drupal-7-kkms-modules/kkms_profile/raw/7.x-

1.28/release.make?private_token=a7rLF5tWAer6DYvCqyBd"

See kkdk.make for reference. The make file can also be split in multiple files using includes, and

also it is possible to override any of the included projects to change versions, add patches, etc.

Notice that the file is not named kkms_extension_profile.make. If it was named like that and it

included the kkms_extension_profile as part of it, it would keep recusing within itself and never

finish.

kkms_extension_profile.info

In this files, add all of the kkms_profile modules that this profile needs to reuse (enable).

Generally, all Contrib, Custom, and Core modules that are in kkms_profile.info in the tag that is

included, need to be added here. Depending on what kkms_extension_profile does, some

features may need to be disabled, and re-created as separate kkms_extension_profile-specific

features. For example kkms_roles_and_permissions feature may need to be enabled, and a

new kkms_extension_profile-specific feature may need to be created. Particularly if new roles

are added, this is likely to be the case. If the kkms_theme is not used, and instead a different

theme is used (even if a sub-them of it), then all of the block-related features may need to be

disabled, and new ones to be created to replace them. Alternatively, features_override module

can be used to override these features in new features, but this is not guaranteed to work.

kkms_extension_profile.profile

This file holds some installation tasks and initial content creation and configuration. The

contents can be directly copied from kkms_profile.profile file, but make sure to change the name


32

of the functions, so they don't match. Make sure none of the function names match any of the

functions in kkms_profile.profile, or this will cause the Aegir to throw an error when trying to

detect it.

kkms_extension_profile.install

kkms_profile.install can be used as the basis for this file. See the kkdk_profile.install for

example of how it needs to be done. Remove the update hooks, as they are not needed.

Change the prefix of the leftover hooks. Do not rename this function

"kkms_profile_submit_theme_settings()", as it is esential for compiling the theme CSS files from

kkms_setup phing update task, or from Aegir migrate/verify task.

Upgrading KKMS extension profile

Whenever an extension profile needs to move to a newer version (tag) of KKMS profile, the

following steps need to be taken:

Change the included tag in the make file.

Diff (compare) the new tag of kkms_profile to the old.

Add new modules found in the kkms_profile.info to the kkms_extension_profile.info. If

they are features, they may not be needed to be enabled see 7.2.2 for information.

Implement the new update hooks from kkms_profile.install to

kkms_extension_profile.install. Developer should consider if the hooks are needed.

There is no hard and fast rule. Each one should be considered separately.

kkms_setup build tool

The build tool is recommended for KK profiles development and used by PP a lot. It is based on

Phing. The build tool mimics the migration flow of Aegir, and is used for dev purposes:

Easily setting up a KK project from scratch.

Updating the build to the newest version.

Detect problems with Aegir migration early, because Phing update task mimics the

Aegir migration flow.

Installing pre-commit hooks to do code style checks.


33

Creating incremental releases/release candidates.

Prevent mistakes by automation and removing the human element.

Can be automated further with Jenkins to make daily builds, for example.


34

KKMS: Conclusion and final check about the initial project goals

Short description of project

In Y2013 and Y2014 Propeople and Municipality of Copenhagen have been working in close

cooperation with in order to develop and deliver a Multi-site solution based on Drupal that can

be easily used for the creation of approximately 750+ websites (most of them managed by KK

team).

One of these websites based on the KK Multi-site solution will be also KK.DK (Københavns

Kommunes official website) which will be re-launched in Drupal with a significant number of new

features and new design (including responsive design) in Q1/2015.

Solution implemented so far

The KK Multi-site solution is based on the following main components:

Aegir Hosting System - a platform for managing large multisite Drupal installation

Central Taxonomy Server (CTAX) - a standard Drupal 7 installation that is used only for

administration of shared taxonomies across all sites;

Piwik Statistics Server;

Drupal installation profile for KK.DK - by developing a separate installation KK.DK

profile, we ensure that it contains only the features that are specifically needed for the

KK Home website.

A separate Drupal installation profile for all sites (except KK.DK) built on Multi-site

solution:

In regards to the KK Multi-site solution (KKMS) KK team had a major focus on the requirements

listed below and we are very proud to be able to meet them:

KKMS factory based on Aegir (capable to maintain and manage code-based for different

profiles and sites);

Usability and Website accessibility in a common KKMS sense (for example, IA, WCAG,

responsive design, etc.);


35

Code quality and code re-usability as the 750+ websites are expected to use the same

codebase and it also should be possible these sites to be easily customized based on

requirements and needs provided by different site owners;

Response times and websites performance;

Flexible system that can be easily upgraded / extended;

Content sharing functionalities across different KKMS sites and the Central Taxonomy

Server;

Use of standard Drupal modules but also the custom modules also developed for

another KK projects;

A user friendly backend interface with great editorial experience;

Well-defined roles for authenticated users.

Please note: the first public website released on KK Multi-site platform was in April 2014.

Currently on KKMS Production environment there are more 200 sites from which 100+ sites are

already released.

Documents

KK Multi-site project - Københavns Kommune · KK Multi-site project: ... and are part of the Hosting Drupal project. ... KK Multi-site project: Solution description 8