3. Understanding Templates Within Sitekit CMS 5

Document Control
Address / Operations Centre
Bloxham Mill
Barford Road
Banbury
Oxfordshire
0X15 4FF / Development Centre
Sitekit House
Broom Place
Portree
Isle of Skye
IV51 9HL
Document Title / Standard Training Pack - Style Build.doc
Date Created / 09/12/2011 15:34:00
Version / 2.0
Document Creator / Joseph Lyons
Document Owner / Integration Department
Business Division
Document Identifier
Publisher Rights / © 2012 Sitekit Solutions
Coverage: / If printed, documents are typically useful for three months from the last modified date. Please check source after this period.

1. Overview 3

2. Responsibility as integrator 4

3. Understanding Templates within Sitekit CMS 5

4. Sitekit Proprietary Code 6

5. Using Templates within Sitekit CMS 7

6. Trees, Pages and Inheritance 10

7. Configuring and Styling Sitekit CMS Navigation Blocks 12

8. Breadcrumb trails 14

9. Global Variables – Why You Should Use Them 15

10. Let Editors Easily Manage Links to Pages and Downloads 16

11. Sitekit Reserved Words (“Magic Words”) 18

12. Sitekit CMS Conditional “If” Statements 19

13. XML Data Islands and XML Web Services 20

14. Where to get help and support 21

1. Overview

This document is part the Sitekit CMS Training materials designed to help you use the CMS effectively with your web site, extranet or intranet.

This document covers areas of the CMS such as Templates, Syntax, Modules, Configuration and other areas that integrators using Sitekit CMS should be familiar with.

Because this document covers core principles of Sitekit CMS, it is a useful document for those planning a site or having overall responsibility for a website development project – regardless of language skills.

It is assumed that the reader will have some understanding of what a Content Management System is, why it is needed, and how it differs (and the advantages) over other web site methods such as static pages.

It is also assumed the reader will be familiar with the latest iterations of core markup languages used throughout the CMS such as HTML, XHTML, and XML, and also a knowledge of Cascading Style Sheets.

A knowledge of JavaScript and is also useful, though not critical, unless your particular site makes use of it.

If you wish to integrate features utilizing XML web services, you may also be required to write XSL transform documents. At the time of writing, Sitekit CMS currently supports XSLT version 1.0 and also some eXSLT features. Specific web services are not discussed in this document, however their implementation via XML data islands is covered. Documentation for individual Sitekit CMS web service APIs can be found on the Sitekit extranet.

If you wish to review any of the above disciplines, suggested external online resources are listed below:

General links

W3Schools – a good place to start learning markup languages:
http://www.w3schools.com/

Google Code University – basic learning in video form:
http://code.google.com/edu/submissions/html-css-javascript/

Sitepoint – useful quick references and printed publications:
http://www.sitepoint.com/

Position Is Everything – browser CSS “quirks” explained and demonstrated:
http://www.positioniseverything.net/

A List Apart – this article and others demonstrating best practice techniques:
http://www.alistapart.com/articles/practicalcss/

2. Responsibility as integrator

Perhaps above all, integrators should be familiar with the role of the editor. One of the key aims for an integrator is to make a site manageable, allow pages to be easily populated and content to be easily edited. Integration that is overly complicated, not “robust”, not efficient and not intuitive is more likely to behave unpredictably and editors may either misuse features or simply avoid using them altogether if they do not find it easy to work with.

Your web site may involve a team of editors and administrators or conversely your job may cover multiple roles where you are acting as both an integrator and editor too. Whatever the makeup of your team, your integration should be able to accommodate editors’ content, and an intuitive implementation will facilitate efficient editing and page population, and ultimately save time for everyone involved.

Please note the term “robust” used above. Specifically this is used with regard to making and styling templates in such a way that they will be able to accommodate editors’ content as above, but to do this for almost any quantity of content entered. As one example, the integrator might consider: “What will happen to this page if an editor uploads an image that is larger than anticipated – will widths be “forced out”, or will content be obfuscated or the image simply be cut off?” or “What if a large quantity of text is added – will background images scale far enough?”

If integrator and editor roles are to be handled by different people, or different teams, then it can be difficult to anticipate what the content of pages will be, particularly the quantity and size of it. Therefore, “robust” integration should allow for this to the greatest degree practicable and in the event that content exceeds it, then it should “fail gracefully” where possible. While editors should be aware of limitations, in reality it is hard to enforce restrictions on what can be done - the CMS does contain features which are capable of this, but potentially it can often hinder editors rather than help them.

In summary, integrators should be familiar with editors and their abilities with regard to the CMS – much of the way the integration is achieved will depend on this factor, alongside future extensibility and possibly anticipating for future redesigns of the site.

3. Understanding Templates within Sitekit CMS

The idea of using templates to build websites is not a new idea. The aim of using templates is to overcome one major weakness of static web pages, where if a feature or style needs to be deployed, or a change needs to be made across a whole site, or selected pages, then it would need to be made individually on every page and would be time-consuming, particularly on large sites – obviously this is not scalable.

Therefore, templates applied to pages pull together elements common to many or all pages of the site so that deployments and changes can be made easily and rapidly in only one place, and to make content independent from markup, and markup independent from style. Most CMS systems today use some sort of template system, and even other systems such as Wordpress also use templates. By separating content from markup, knowledge of markup languages is no longer a requirement for content editors, and therefore a more familiar “word processor” style interface can be used to edit content instead.

Every page in Sitekit CMS has three layers of visible templates that the content of the page will appear in, and be styled by.

It is best practice to keep the number of templates as low as possible to make the site more manageable, and this can be done by careful planning at the design and pre-integration stage in conjunction with advice given in this document. If many templates are used, where each template has only minor differences from another (e.g. just one image that changes from template to template), and perhaps to the extreme that each page is given its own individual template, this really renders the advantage of using templates obsolete. If the minor difference is unique to lots of pages, then it may be that the change should be part of the content of the page rather than the template. It is accepted that there are sometimes individual pages that are radically different from others and will require their own templates, and they may be the only page using them (as an example, typically the homepage will have its own unique templates) but ultimately, the more templates a site has, the more difficult it can be to manage, especially if a re-design of the site is made in the future. By following the advice in this document, and by utilizing Sitekit CMS features properly and fully, template manageability can be achieved.

4. Sitekit Proprietary Code

Much of this document discusses code proprietary to Sitekit CMS. It is not really necessary to learn all such code, as online references and training materials are provided for your reference. However, it is beneficial to recognize the syntax this code usually takes. Almost all Sitekit CMS code in this document is valid XML. It will often take one of the following forms, depending on its application, and some code can work in more than one form:

· XML-style tags:

e.g. <COMMENT>CONTENT</COMMENT>, <VARIABLEBLOCK>TITLE</VARIABLEBLOCK>, <ENQUIRYFORM<FORMID>123</FORMID</ENQUIRYFORM>

· Sitekit CMS System Variables (also previously referred to as Sitekit “Magic Words”):

e.g. :::date:::, :::thispageinfo.bodylength1:::, :::variableblock-title:::

· Sitekit Conditional “If” Statements:

<sitekit:if op1="1" operator="!=" op2="2">YES</sitekit:if>

· XML Data Islands:

The application of the above syntaxes is discussed throughout this document, but this demonstrates what you should expect to see.

Another important note, is the (X)HTML head section of all Sitekit CMS pages. Alongside standard <meta> tags Here you will find much useful information on your site, including the Sitekit CMS Site ID, the unique Shortcut ID of the page you are on, the version of Sitekit CMS your site is running, as well as the name of the Server it is being served from:

Some of this information may be important to know where to find when integrating your templates, and using some features in Sitekit CMS.

5. Using Templates within Sitekit CMS

Page Layouts

As mentioned, every page in Sitekit CMS is defined by three template layers. The first of these is the outer “Page Layout” sometimes referred to simply as the “Layout”. Page Layouts can be applied site-wide (in “Site Settings”), inherited from a parent page, or applied independently on a page-by-page basis. The default “Page Layout” for a site (if one is not specified) can be set in the “Site Settings” area of Sitekit CMS.

Essentially, the Page Layout is the (X)HTML code directly inside the opening and closing body tags of the page. The layout does not actually contain the <BODY> tags – these are entered automatically by the CMS.

The layout will contain the basic outer <div> based structure that is common to the majority of pages on your site. For more information on a why <div> based structure is strongly advised, please refer to the “accessibility” section of this document.

Every tag that opens in the layout should also close in the layout – i.e. you should not have a <div> tag that opens in the Content Layout but closes in the Page Layout.

Page Layouts may also include (but not limited to) elements such as headers, logo, footer, navigation, breadcrumb trails, Sitekit XML data islands, Embedded Forms, Internal, External, Child and Download Links. None of these items are mandatory, and many may also be part of Sitekit Variable Blocks (discussed later). However, every layout must include the Sitekit CMS <COMMENT>CONTENT</COMMENT> element, which is where the chosen Content Layout for the page will appear.

Though only one is required, typically a site will have at least two or three page layouts at least. Often, the homepage of a site may require its own layout due to being substantially different from other pages. Also, module pages may require their own layout due to code placement of the navigation and also as a way of differentiating module pages from standard pages. Modules and module pages are discussed in the “modules” section of this document.

Placement of the navigation element(s) is an important factor to consider. Putting Sitekit Navigation code in the Content Layout instead of the Page Layout is allowed, but will mean an additional layout for modules is required if you wish navigation to appear on those pages, as the module content becomes the content type. Often this happens anyway as the structure of your <div> code can mean that navigation code cannot be put in the layout without breaking the above rule regarding tags only opening and closing in their own template.

Sitekit CMS supports multiple navigations per page – i.e. a “top level horizontal navigation” bar and a “secondary” vertical navigation. These can be styled independently using the ID’s and classes that Sitekit CMS outputs.

Content Layouts

“Content Layouts” are included in every page on your site that is not a module page. They will define the structure of the content on a page, and are included in the chosen layout with the <COMMENT>CONTENT</COMMENT> syntax. They are usually applied on a page-by-page basis, but can also inherit from a parent page.

Content Layouts may include (but not limited to) elements such as navigation, breadcrumb trails, Sitekit XML data islands, Embedded Forms, Internal, External, Child and Download Links.

Content Layouts primarily define where the editable images and text will appear on a page. This is done through the <COMMENT>BODY#</COMMENT> and <COMMENT>PIC#</COMMENT> includes. Tags must be numbered, starting from 1, with a maximum of 99. You may have more PIC than BODY tags, or vice versa – they are numbered independently. Numbers do not need to be consecutive, but you may not skip a number, or have more than one instance of a number. For instance, the following would be valid:

<div<COMMENT>BODY4</COMMENT</div>
<div<COMMENT>BODY2</COMMENT</div>
<div<COMMENT>PIC3</COMMENT</div>
<div<COMMENT>BODY3</COMMENT</div>
<div<COMMENT>PIC1</COMMENT</div>
<div<COMMENT>PIC2</COMMENT</div>
<div<COMMENT>BODY1</COMMENT</div>

Style Sheets

CSS “Style Sheets” are applied to every page on your site. They can be applied on a page-by-page basis, or inherited from a parent page, but are usually applied site-wide in “Site Settings”. Your site may only require one CSS Style Sheet. “Advanced” options for Style Sheets allow you to add a print Style Sheet that is attached to a parent Style Sheet, and will apply when a page is printed using the :::printthispage::: system variable link. Secondary Style Sheets may be included for alternative page styles and colours etc.