Solution description · The multi-site has a cluster of web servers that are used for every site on...

KKDK Project: Solution description

1

KKDK Project

Solution description

Version 1.0

20.02.2015


2

Revision History

Date Version Description Author

30.11.2014 01 Initial draft 01 Miroslav Banov

10.01.2015 02 Draft version 02 Miroslav Banov

18.02.2015 03 Draft version 02 Miroslav Banov

20.02.2015 1.0 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.dk project

Summary

The project is an extension profile of the multi-site profile. This means that all functionality of the

multi-site is inherited and it is part of the kkdk_profile. Also additional functionality that is specific

for KK.DK has been developed initially for KK.DK but might be reused in the future by other

projects.

KK.dk funtionalities

Integrations

Here are listed KK.dk project functionalities that related to integrations with external services.

Edoc

Edoc integration requires that the Fujitsu FTP is set up to upload to a specific directory

(edoc_stream_path). The same directory must be configured in the Drupal site, so the site

knows to look at it and import the content. There is a cron task in Drupal that processes the

XMLs in the directory, and creates drupal content, then deletes them. The functionality depends

on XSL, Xpath, DOM php extensions.

There are several content types that are created from this:

● Committees

● Meetings

● Agendas

There are no global listing pages, but it is intended that committees are added to the menu

structure, and there is a section page for displaying the list of committees, providing navigation

to them. From the committee page, the Meetings and agendas that are part of that committee

can be accessed.


4

The meetings are simply denoted by the date that they were held. In each one there is an

agenda and minutes file that show transcription of what transpired on that meeting. When

opened, the details of that meeting are displayed.

Multiple handling points and PDF attachments are displayed and can be viewed separately.

This is how a handling point looks.


5

KGB maps

KGB is an integration with a map provided from Septima. The map ID is stored on the Drupal

side. The configuration for the map (the enabled layers) is all stored externally in Septima map

service. The implementation is as a field, so it can be added and reused to other Drupal entities

if necessary. On the KK.dk profile, this functionality is used on a special KGB map content type.

Clicking Configure map will open a dialog for configuring the map. The configuration for the

mapid is Stored entirely with Septima service.


6

After saving the map, a preview is shown on the administration page.

Finally, after saving the KGB map node, the map is available to be displayed to site visitors. The

KGB map is meant to be used as secondary content, from main content. This is how it displays

to end-users.


7

E-recruitment

E-recruitment is an integration with peopleXS, which periodically retrieves job offers and imports

them in Drupal. The job offers then are shown on a search (listing) page, and there is

information, and forms for enquiry and application for the job. Here is how the jobs list page

appears.

After finding a job and displaying it directly, more information about it is shown.


8

From there, visitors can navigate to the job agent and the job application form.

Plan2Learn

Plan2Learn is real-time requesting (Plan2Learn) external service and showing the results in a

Drupal search page: "courses/list". From that search page, all links point to external site.


9

Main functionalities

Functionalities not related to external integrations that are implemented specifically for the kk.dk

project.

Migration from Sitecore

The content is initially migrated from the old Sitecore site. The content was mapped to drupal

content. The following entities were migrated from sitecore:

● Users

● Files

● Articles

● News

● FAQ

● Factboxes

Crisis info

A global configuration option was provided to allow site Administrator to set a crisis page where

every visitor will be redirected to, but once only. This is intended to direct visitors to important

and urgent information, like a fire or landslide or flood. This is done from the bottom of the Site

information page.

Menu extensions

Additional menu options were developed to help Administrators create an easier site navigation

better experience. This includes Menus with images for the main site sections, and Piwik-

integrated menus, showing most visited pages within a sub-section of the menu structure.


10

Front page menu is intended for the home page and is showing the main site sections.

Top level menu item is intended to be used on the main section pages, in combination with the

very flexible Front page menu tree.

Also, there is the most read pages menu which is showing pages based on Piwik statistics.


11

All of these menus and others are used as menu panes from section pages.

Working with menu panes

Types of panes

Currently we have 4+1 types of panes available:

Hovedmenu menu tree - Displays all children of a selected menu item. Displayed are the

names of the links and their descriptions.

Front page menu – Displays all direct children of the current menu item. For each of the

children are displayed the following elements: image (icon), the 2nd level menu item (if

you have placed the pane on 1st level menu item) and the two most visited children of

the 2nd level menu item. For each children of the 2nd level menu item the user will be


12

able to set it to be Sticky, which allows you to push the item to the top of the list. The

sorting is: Sticky, most read, alphabetical.

Second level menu block – Just a pane that works like the second level menu block on

nodes (example: Article).

Top level menu item – Displays the current menu item with big icon and description.

View: Most read pages – Displays top 5 most visited children (based on Piwik visits) for

a selected menu item

Hovedmenu menu tree

It displays all direct children of a selected menu item. Displayed are the names of the links and

their descriptions.

Configuration:

Starting level – by default set to “1st level (primary)”. Blocks that start with the 1st level

will always be visible. Blocks that start with the 2nd level or deeper will only be visible

when the trail to the active menu item passes though the block’s starting level.

Maximum depth – by default set to “Unlimited”. From the starting level, specify the

maximum depth of the menu tree.

Fixed parent item – by default set to “<Hovedmenu>”. Alter the “starting level” and

“maximum depth” options to be relative to the fixed parent item. The tree of links will only

contain children of the selected menu item.


13

Design:

Front page menu

It displays all direct children of the current menu item. For each of the children are displayed the

following elements: image (icon), the 2nd level menu item (if you have placed the pane on 1st

level menu item) and the two most visited children of the 2nd level menu item. For each children

of the 2nd level menu item the user will be able to set it to be Sticky, which allows you to push

the item to the top of the list. The sorting is: Sticky, most read, alphabetical.


14

Second level menu block

It is a pane that works like the second level menu block on nodes (example: Article).


15

View: Most read pages

It shows top 5 most visited children (based on Piwik visits) for a selected menu item.

Configuration:

Design:


16

Important note: For all panes related with Piwik statistics (“Most read pages” pane and the two

most visited children of the 2nd level menu item in “Front page menu” pane) additional

configuration must be made. For each child (node) part of the whole tree the user must select

the parent of the child item from the “Main menu” dropdown. The “Main menu” dropdown is

located in the “Taxonomy” tab on the node edit page.

The “Menu settings” settings and the “Main menu” dropdown are not relevant to each other.

Both settings should be configured properly in order everything to work as expected. If you have

only configured the “Menu settings” settings this does NOT mean you have selected anything in

the “Main menu” dropdown – this will cause the node NOT to be displayed in the panes that

work with Piwik statistics.

Menu breadcrumbs

Breadcrumbs were developed for the kk.dk site, that are based on the menu structure. With the

addition of breadcrumbs, the navigation for the site is made as easy and intuitive as possible.

This is needed for the kk.dk because it has a lot of content, and so the menu structure is deep,

which makes it harder to discover specific pages.


17

Additional user roles

For the KK.dk project, specific roles were needed, as “News editor” for example. These are

limited roles that are intended to have few permissions to administer only specific things.

Multi-site extensions

As part of the KK.dk projects, extensions to the Multi-site profile were also developed. These

are not listed here, because they are not unique to the KK.dk. Refer to the Multi-site

functionalities section for information about functionalities that are part of the Multi-site profile.


18

KK.dk production environment

Infrastructure

KK.dk is deployed on an environment that is separate from the Multi-site, but still shares some

important system components.

Separate web servers

The multi-site has a cluster of web servers that are used for every site on the multi-site system,

and are maintained in Aegir. KK.dk has completely separate cluster of web servers that is

maintained separately.

Separate database server

The database of KK.dk is on its own server and is not mixed with the other sites on the multi-site

system.

Separate memcache server

Memcache server is separate from the memcache server used for the multi-site.

Same Varnish

The Varnish cache server is the same. This is not a requirement in any way. The Varnish can

easily be split from the multi-site, if it is necessary for scaling purposes.

Same Solr

The same Solr is used, and this is an important requirement for the content sharing between

KK.dk and other sites that use the same Solr. This may eventually cause performance

problems, but splitting to different Solr servers will mean that there can be none of the thus far

developed content sharing functionalities can be used for sharing content between Multi-site

installations and KK.dk. Any performance problems that arise should be handled another way,

not by separating Solr.

Same CTAX/CMT

This is another requirement of the content sharing to be possible. It’s unlikely that it will lead to

hard to solve scaling problems.

Maintenance

Upgrade procedures for maintaining the KK.dk production.


19

Not Aegir

The production environment for KK.dk is not maintained in Aegir. The site is deployed on a

separate set of web servers, and has its own deploy and migrate procedures.

Compatible with Aegir

The upgrade procedures for the KK.dk comply with the guidelines for maintaining a site installed

from the Multi-site profile. As such, the KK.dk can easily be deployed on Aegir, for testing or

production purposes.

KS ops maintain

The production environment for the KK.dk is maintained by KS ops. The responsibility for

upgrading and maintaining is also with KS ops.

Solution description · The multi-site has a cluster of web servers that are used for every site on...

Documents

Transcript of Solution description · The multi-site has a cluster of web servers that are used for every site on...