Design principles of the Drupal CSC website

Transcription

1 CERN IT Department Report Design principles of the Drupal CSC website Stanislav Pelák Supervisor: Giuseppe Lo Presti 26th September 2013

2

3 Contents 1 Introduction Initial situation Problem definition and requirements Investigation results and recommendations Content embedding Site architecture Cloning Content retrieval Implemented solutions 11 4 CSC Cloner technical documentation Use case Implementation Technical parameters Conclusion 17 3

4

5 Chapter 1 Introduction 1.1 Initial situation Main CSC s website is currently created and administered using a dedicated client-side software. This software allows the administrator to build a complex content out of many independent blocks. Content of these blocks is not duplicated, which is essential for automatic change propagation to all sites containing a particular block. The website contains basic information about CSC in general as well as information about particular schools for students. Content (HTML files) are organised hierarchically in a structure of folders in file system. Creation of a website for a new school is done simply by copying the files on the filesystem. 1.2 Problem definition and requirements The vision for the following years is to migrate the CSC sites to Drupal a free open-source content management framework based on PHP. Comparing to current solution, the way how Drupal organises and maintains the content differs: Content is stored in a database as a node - a general container identified by it s unique node ID. Nodes are independent and their organisation is flat rather than hierarchical. Structure of a node can be restricted by assigning a Content Type to it. 1

6 1. Introduction Content Type defines attributes of a node. Rendering of a node and its attributes can be defined using Content Type settings, or templates for more complex definitions. Extension of Drupal functionality is done by modules. Differences between Drupal and current solution leads to a several important questions that need to be investigated to decide, whether Drupal is a satisfactory solution to manage CSC websites and if so, how should it be used in order to make the content management the most intuitive and simple for a non-programmer Requirements The most essential problems to investigate were following 1 Composition: Which Drupal technique should be used to achieve combining several simple standalone pieces of contents into a complex page without duplication? Scalability: How to manage a vast amount of content if there is no hierarchy how to retrieve a desired content in a simple and quick way? Cloning: How to replicate/clone the content of a certain school for a new school making sure that the inner links are consistent? 1 The goal of the investigation is to find out whether it is possible to fulfill these requirements, propose a solution how to do that (which modules should be used etc.) and demonstrate the solution on a development Drupal site. 2

7 Chapter 2 Investigation results and recommendations 2.1 Content embedding In Drupal s concept of nodes, it is very simple to embed a content of one node into another using a [[nid:nodeid 2 ]] directive directly in the content. The drawback of this solution is, that it requires the user to find the ID of a node they wish to embed, which could be difficult concerning that the desired node could have an URL alias, so it might require some deeper understanding of Drupal to be able to retrieve the node s ID. To overcome this drawback, I would recommend using the Node Embed module. This module works as a plugin to CKEditor module (WYSIWYG editor) and adds a button for selecting node to embed. After selecting the desired node to embed, this plugin will automatically generate an embedding directive with a node ID in the content, so it is not necessary for the site s administrator to look for a node ID. Required modules: CKEditor 3 (WYSIWYG content editor) Node Embed 4 2 Embedded node s ID embed 3

8 2. Investigation results and recommendations Follow installation manual, requires IFrame Dialog 5 plugin for CKEditor Figure 2.1: Node Embed module Dialog for selecting the node to embed is accessible via NodeEmbed button in CKEditor toolbar (highlighted top right). The result of embedding is highlighted in the content (on the left). After proper installation of Node Embed module, it needs to be allowed in: admin/config/content/ckeditor/edit/{profile name} tab Editor appearance section Plugins check Plugin file: NodeEmbed. Also, the NodeEmbed button should be placed to a CKEditor profile s toolbar. The result is shown on figure 2.1. In Node Embed dialog, the site administrator needs to find desired content in the rather long list of all nodes. To simplify searching, Node Embed allows filtering by content type and node s title. Therefore it is essential to use Drupal content types to simplify the filtering. More about this topic in section 2.4; 5 4

9 2.2. Site architecture 2.2 Site architecture The structure of the current CSC website is rather complex and some users might find it confusing. The main problems are: 1. Several levels of menus with a significant number of items. 2. Separation of CSC 20xx (i.e. 2013) and CSC Live in main menu. It is not clear whether to look for a desired information in CSC 20xx or CSC Live. CSC Live should be by its nature a child node of a CSC 20xx 3. All information in one place both general information and information specific for current school. Students of the school don t need general information about CSC (for example during the school). In opposite, a person looking for general information about CSC doesn t need information dedicated to current school s students. Website s visitors should see only what they are potentially interested in / what they need to see according to their role and use case, not more. Design of a site s architecture has an essential influence on further decision making. For these reasons, I recommended to split the website into two independent parts a general information part (for general visitors looking for information about CSC, application process etc.) and a school details part (for the students of a certain school). For splitting these parts, two main approaches were considered: 1. Physically separated sites Each site (general CSC website, CSC 20xx websites) are standalone Drupal sites. Pros: Cloning almost equivalent to current solution full clone of a school-specific website. No need to implement any cloning mechanism. Less content in a single database (simpler content retrieval). 5

10 2. Investigation results and recommendations Cons: Need Drupal team to clone the website (can t be done at home less control). Problems with synchronization of several Drupal sites configuration (i.e. installing additional modules) and content (shared content among the sites). Impossible to use taxonomy across the independent sites Logically separated sites Websites look like they are standalone, but physically they are just a subsections of a single Drupal site using only one database. Pros: All resources (nodes/media/taxonomy), modules and configuration shared among all sites. Full control over cloning. Cons: Requires implementation of a custom module for cloning (but only once). Larger amount of content in a single page (a good technique for a content retrieval is necessary). Considering these attributes, I recommend to use logically separated sites, which allows to use global taxonomy, even though this requires more sophisticated content filtering methods (both will be discussed in section 2.4). By separating the CSC websites logically, all of the logical websites are basically only a sections of a single physical website accessing a single Drupal database. To achieve this, each homepage of a logical website is accessible via top-level menu link, which is hidden. Therefore: User sees only second-level menu, which is rendered as a first-level menu sites appear to the user as physically separated. Links in the (second-level) visible menu depend on an active toplevel menu link, e.g. the logical site different logical sites have different menus. 6 More discussion about the usage of taxonomy in section

11 2.3. Cloning By setting URL aliases to hidden top-level menu links, logical sites can use their own namespaces (i.e. csc.cern.ch/icsc2014). Figure 2.2 demonstrates this concept. Figure 2.2: Architecture of a CSC website using logically separated subsites. 2.3 Cloning By separating CSC websites logically, it is desirable to implement a mechanism for cloning the content of a past school and create a logical site for a new school completely automatically. For this purpose, a dedicated module was implemented. CSC Cloner module was created as an extension of existing module for CSC administration. Its full technical documentation is in section 4. 7

12 2. Investigation results and recommendations 2.4 Content retrieval As a result of a single-site architecture, a problem with managing a large amount of content appears. For effective content retrieval, I would propose two crucial techniques: Content Types and Taxonomy Content Types Content Type in Drupal terminology describes a type of a node, its attributes, representation etc. Each node has exactly one Content Type, which can be also a custom one. Advantages of using content types: Basic and essential Drupal technique of categorising the nodes (i.e. Registration, Person, etc.). Ensuring that a certain node has desired attributes. Custom graphical representation of all nodes of a certain Content Type using templates. Filtering according to the Content Type (i.e. Enterprise Base and Node Embed modules). etc Taxonomy Drupal s nodes are not hierarchically organized. To capture a relation among them, we can use taxonomy. Tags (or in Drupal language terms) can be hierarchically organised inside their vocabulary. Each node can have (by default) any term from any vocabulary assigned (that can be also restricted to a specific vocabulary/terms). Hierarchy of the content is therefore shifted to hierarchy of tags/terms assigned to the content. For CSC, in addition to Content Types (described in previous section), I proposed to use taxonomy terms to distinguish content of different schools (fig. 2.2). For this purpose, only one-level of taxonomy terms is enough. All nodes have exactly one term from School codes (machine 8

13 2.4. Content retrieval name: school codes) vocabulary assigned, so it is clear, which school they belong to. School codes vocabulary contains also a general term, with which a content of a General CSC site should be marked Conclusion For the CSC website, I strongly recommend to use nodes of custom Content Types for specific content (panel with registration/event details, panel with bio and picture of a student etc.), as well as templating for custom graphical representation of these nodes. In addition, to improve content filtering, I suggest all Content Types to have a hidden required attribute of a single taxonomy term from School codes vocabulary Required modules Enterprise Base Adds filtering by Content Types to Find content view Needs to be set to filter by taxonomy terms (add filter): Taxonomy admin/structure/views/view/enterprise content admin/edit Filter criteria Add Content: Has taxonomy term 9

14

15 Chapter 3 Implemented solutions For testing purposes, some of the proposed solutions were already implemented and set up on csc2.web.cern.ch site: All recommended and required modules were installed and set up. Enterprise Base, Taxonomy, Node Embed, etc. Taxonomy-based filtering was set up for Enterprise Base module. See /admin/modules for further details and configuration. School codes taxonomy vocabulary was created. See admin/structure/taxonomy/school codes for the list of terms. Vocabulary as well as school-code terms are created automatically by the CSC Cloner module. Term general added manually and assigned to some pages of a general CSC site (all nodes should be tagged with a term from School codes vocabulary). Custom CSC cloner module was installed and tested (cloned pages didn t have a full content though). Accessible via CERN School of Computing shortcut in the top administrative panel School Management Create a new school. Custom Registration Content Type added for registration or event status panels nodes (i.e. sport events, gallery etc.). See /admin/structure/types. 11

16 3. Implemented solutions Added a template to display this Content Type in a custom way. Server filesystem: themes/csc/templates/node registration.tpl.php and custom style themes/csc/css/custom.css. Registration status (Open/Closed/Pending) generated automatically. If status is Pending, date and time of opening is displayed, otherwise the the displayed date and time is the deadline. Two nodes of Registration Content Type were created (see Find content select filtering by Registration Content Type). The result is demonstrated on the figure 3.1. Figure 3.1: Demonstration of a custom Content Type rendered using custom template and style. 12

17 Chapter 4 CSC Cloner technical documentation In order to automatize the process of cloning a school, an extension to existing CSC module was implemented. 4.1 Use case Initial state Goal CSC Drupal website (optionally containing some school site). New CSC school site created as a clone of existing school site (or empty). The new school site is available at a specific URL alias host/school code (i.e. csc.cern.ch/icsc2014). Hierarchy of menu links corresponds to original site s menu (if an empty site was created, there are only basic menu links, i.e. Overview). If original site has some nodes embedded, cloned site has clones of originally embedded nodes embedded User interaction 1. User selects Create new school link from CSC module menu. 13

18 4. CSC Cloner technical documentation 2. System displays form to set basic parameters of cloning: type of school (CSC, icsc, tcsc), school year (-5 to +5 years from now), existing taxonomy term of a content to clone (existing terms in School codes vocabulary and Empty option for creating a new school without cloning the content). 3. User selects desired attributes and presses the Next button. 4. System validates, that desired school does not yet exist (by checking existing taxonomy terms). 5. If the data is valid, system displays all the content of selected school to clone grouped by Content Type. 6. User deselects the content he/she doesn t want to clone (fig. 4.1) and presses the Create school button. 7. System clones the desired content and creates a new school as specified in Goal list. 8. System redirects the user to the homepage of a new school. 4.2 Implementation Cloning of a school follows this algorithm: Create and save a new taxonomy term to School codes vocabulary (school code + school year i.e. icsc2014 ). Vocabulary is created on Create new school form display if not already present. 2. Recursively parse the original site s menu. 3. Clone all nodes and fill map of pattern-clone pairs. Clones have the new taxonomy term assigned. If cloned page is the homepage of a pattern school, name the cloned page after a school (i.e. icsc 2014 ).

19 4.2. Implementation Figure 4.1: Selection of existing content to clone 4. Recursively clone the menu to the new site. If a certain menu link s node was not selected for cloning and a) some of its child links nodes was, or b) it is a Home node, assign a new empty page to the parent link instead of missing node. 5. Parse content of all all cloned nodes and look for node embeddings (directives [[nid:node id]]). If such embedding was found and embedded node was cloned as well, replace embedded node ID with the cloned node s ID. 6. Set the URL alias for the new site s homepage to host/school code (i.e. csc.cern.ch/icsc2014) 7. Redirect the user to the new school site. In case the user selects to only create an empty school, the algorithm is slightly simplified: 1. Create and save a new taxonomy term (the same as before). 15

20 4. CSC Cloner technical documentation 2. Create an empty page with title according to school being created and tag it with the new school s code. 3. Create a basic menu links (hidden top-level and its child Overview link, both pointing to the new empty page). 4. Set an URL alias (the same way as before). 5. Redirect the user. 4.3 Technical parameters Required modules - Node - Taxonomy Drupal core version - 7.x 16

21 Conclusion Several possibilities of migrating the current CSC website to Drupal content management framework and techniques how to achieve it were investigated and discussed in this document. On the basis of these investigations, it is possible to conclude, that Drupal is capable of providing a suitable functionality for the needs of CSC website. Solutions how to solve crucial issues were proposed and tested on a development version of a CSC Drupal site. Tests showed that proposed solutions are possible to implement and capable of providing desired functionality. Further work needs to be done to actually create all Content Types, templates, styles (regular/printing), create custom views etc. and also to populate the website with an actual content. 17