Post on 25-Jul-2020
transcript
KKDK Project: Solution description
1
KKDK Project
Solution description
Version 1.0
20.02.2015
KKDK Project: Solution description
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
KKDK Project: Solution description
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.
KKDK Project: Solution description
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.
KKDK Project: Solution description
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.
KKDK Project: Solution description
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.
KKDK Project: Solution description
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.
KKDK Project: Solution description
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.
KKDK Project: Solution description
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.
KKDK Project: Solution description
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.
KKDK Project: Solution description
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
KKDK Project: Solution description
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.
KKDK Project: Solution description
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.
KKDK Project: Solution description
14
Second level menu block
It is a pane that works like the second level menu block on nodes (example: Article).
KKDK Project: Solution description
15
View: Most read pages
It shows top 5 most visited children (based on Piwik visits) for a selected menu item.
Configuration:
Design:
KKDK Project: Solution description
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.
KKDK Project: Solution description
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.
KKDK Project: Solution description
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.
KKDK Project: Solution description
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.