XML and XSL in Omni CMS
Omni CMS stores each page as a custom-formatted XML file, called a PCF, or Publish Control File. This file type carries only the editable content specific to each page, such as page parameter values and editable region content. Each PCF page references at least one XSL file that converts the content into the final published products on the production server.
Your XSL files are located in Content > Pages, most likely under
/_resources/xsl/. However, depending on your implementation, it's possible that they're located somewhere else in your Omni CMS files. Newer implementations also reference a global XSL that Modern Campus maintains, so you may come across references to XSL files that are not in your Omni CMS implementation.
When working with XSL in Omni CMS, remember three things:
- You don't need to publish XSL for changes to take effect; just save the file.
- Always save a version before and after you make a change.
- An error on an XSL stylesheet affects all pages in Omni CMS that reference or import that XSL. The live website won't be affected, but you can't publish those pages until the error is fixed.
What is a Template?Link to this section
The word "template" is used to refer to multiple items (Omni CMS templates, XSL templates, and design templates), and it is important to distinguish between the three when discussing developing pages in Omni CMS.
Omni CMS Template
In Omni CMS, "template" refers to the linked TCF, TMPL, and image files that combine to create a new PCF when the +New button is clicked. These are the templates managed in the Setup menu, and unless specified otherwise, it can be assumed that the word "template" refers to these.
The Templates topic in this section covers how to create new page templates. Alternatively, see the reference guides for TCF and TMPL files for full lists of the attributes that can be used to build them.
XSL uses an instruction called
xsl:template to either match nodes in PCFs and transform them, or to create repeatable code blocks. If
xsl:template is used with the
match attribute, it identifies elements in the PCF file and says what to transform them into.
<xsl:template match="table"> <table class="responsive"> <xsl:copy-of select="./node()" /> </table> </xsl:template>
xsl:template is used with the
name attribute, it outputs a block of content that can be repeated as needed.
<xsl:template name="common-header"> <xsl:copy-of select="ou:include-file('/_resources/includes/header.inc')"/> </xsl:template>
The first example matches a
<table> node in the PCF. The output will be a
<table> node with a class called
responsive. Inside of this node, everything inside the matched
<table> node is copied as-is. In a typical implementation, the
xsl:copy-of statement would be replaced with an
xsl:apply-templates statement so the content within the table could potentially be matched with other
match statements in the XSL.
In the second example, an
xsl:call-template statement can call this block of code whenever necessary. In this case, the XSL calls a standard OU XSL function called
ou:include-file, which takes the path and outputs a virtual or PHP include statement pointing to the referenced file.
XSL ArchitectureLink to this section
Often, multiple XSL files reference each other. In most implementations, a PCF file references a template-specific XSL stylesheet (e.g.
program.xsl). That stylesheet contains the XSL templates and code associated with the unique content and structure found on that type of page.
Then, to build out the surrounding elements of the page, that XSL stylesheet references a
common.xsl defines shared page structures such as header and footer placement, sidebars, and main content areas. It also references additional XSL stylesheets that that define specific content pieces and additional functionality, such as
This segmented structure makes it easier to affect both specific pages and the site as a whole. If you want to make changes to only one page type, then having the XSL for that page type in its own stylesheet compartmentalizes those changes. Alternatively, having stylesheets like
common.xsl that all page types reference means a change to the global design only needs to be made once to be applied to all page types.
This structure also eliminates the need for "if-then" logic checks, where the structure of the pages referencing a page-type stylesheet is built using if-then statements. For example, in some online XSL resources and older implementations, all PCF files may reference a
default.xsl stylesheet. This
default.xsl can then contain a series of "if-then" logic checks to output content based upon a parameter or other identifier in the source PCF. While this structure can still provide the ability to define shared page structures without repeating code, it is more difficult to compartmentalize individual page types and changes without affecting all pages.
Another benefit of a segmented XSL architecture is the rapid construction of new “one-off” templates. Once you have
common.xsl and other shared stylesheets, new templates can easily be added by creating a new XSL stylesheet, importing common.xsl, and then adding any unique code structures.
Similar to CSS, XSL has a concept of import and XSL template precedence. Common content can be overridden with template-specific content, as the XSL stylesheet closest to the PCF takes the most precedence. For example, content defined in
interior.xsl will override content defined in
common.xsl if there is a conflict.
This also applies to named XSL templates. A named template on a closer content region takes priority over content imported farther back in the architecture. If
landing.xsl both call
common.xsl, then they can each have different versions of that named template. For example, a site could have a common sidebar across most page types with a unique sidebar on landing pages. In this case, the
common.xsl might have an XSL template named "sidebar," which can be referenced by pages that import
common.xsl, such as
landing.xsl. The landing page output can be modified to have its own sidebar by adding an XSL template with the same name of "sidebar" to
HTML OutputLink to this section
For each PCF, the XSL takes the page-specific XML content in the PCF and inserts it into the defined HTML structure, providing you the preview within Omni CMS. On page publish, this same combination of PCF content and the page design outputs a flat HTML file (though the file extension can vary depending on production server settings). This separation of content from design is one of Omni CMS' core functions.
Obvious benefits of this separation are ease of editing content, minimized opportunities for accidental changes to design, and global styling that only needs to be edited in a central location to affect multiple pages, but it provides other opportunities as well. By using XSL logic, pages can have adjustable layouts and optional features, as input content and user-set options are read by the XSL and used to adjust the design, creating built-in flexibility. For example, an optional feature such as sidebar content can be stored on a page, but then whether or not the XSL displays it depends on the option selected in page parameters. Multiple user options can be configured, and the XSL is written to determine how to handle each selected option.
XSL can also transform simple content into more complex formats, such as with table transformations. Content editors add or modify information in a simple structure such as a table, and then XSL takes that content and places it into a complex HTML structure, creating design elements like sliders, callout cards, and other pieces.
Additionally, XSL can create multiple output products for each page. Besides the HTML page, on page publish a PCF file can create other products, such as data files or PDFs (using XSL-FO). A common use case is an include file that has two products, a desktop header and a mobile header. The PCF-to-include file references different XSL stylesheets for each output in the head of the source code.