KKDK Project: Solution description. KKDK Project. Solution description. Version 1.0

Transcription

1 KKDK Project Solution description Version

2 Revision History Date Version Description Author Initial draft 01 Miroslav Banov Draft version 02 Miroslav Banov Draft version 02 Miroslav Banov 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 2

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. 3

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. 4

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. 5

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. 6

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. 7

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. 8

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 Piwikintegrated menus, showing most visited pages within a sub-section of the menu structure. 9

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. 10

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 11

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. 12

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. 13

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

15 View: Most read pages It shows top 5 most visited children (based on Piwik visits) for a selected menu item. Configuration: Design: 15

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. 16

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. 17

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. 18

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. 19