Cascade CMS Glossary - University of Houston
Skip to main content

Glossary of Cascade CMS Terminology

A selected list of terms used in the Cascade CMS for University of Houston web pages.

asset | internal link | external link | index/indexing | metadata | synchronize | system name


asset

within the Cascade CMS an asset represents "any entity within the system that can be used to generate content."

Commonly used assets include: Folder, Page, File, Block, Dynamic/Symbolic External Link.

Folder, Page, and File assets will be Published to a server as static entities, and so the system names for these assets need to follow UH filenaming conventions.


a dynamically tracked association between two assets within a site, based on the two assets' system IDs, created by using a Chooser tool from one of the CMS editing dialogs.

Dynamic tracking means the CMS will automatically update the internal link if/when the asset being linked to is either moved, renamed, or otherwise changed (e.g. a  dynamic/symbolic external link type asset takes on a new web address).

Internal Links will be translated from system IDs into hyperlinks using actual web addresses within the page's source code once the CMS creates the actual PHP webpage file - which only happens during a publishing step, when a webpage file is actually created and then written to a server location. Prior to publishing, CMS page type assets are basically comprised of a collection of instructions to the CMS: instructions on how to build that final webpage file and instructions on what will be included in its contents.

User is responsible for publishing/re-publishing to synchronize any affected assets with the static file structure on the server. Depending on the type of change made, and on the type of asset being used, either one or both of the associated assets may need to be published together for full synchronization. Simple block assets, for example, generally do not need to publish: once they have passed their information to the page Choosing them, the Page captures it, and only the Page[s] would need to be re-published. Files, however, such as PDFs, graphics, scripts, cascading stylesheets, etc. would need to be re-published along with the Page[s] Choosing/calling them if the called Files change content, are moved, or are renamed.

It can be helpful to view an asset's relationships to see which other assets it may have a Chooser-relationship with (see: More button >> Relationships). 


a hyper link created by using a specific URL text string to define the link, and which the CMS does not update dynamically (e.g. web address such as  http://www.uh.edu/  and which is typed into or pasted into an external link text field, as with the Insert/Edit Link dialog; or, may also be any text-string web address used elsewhere, such as a path in an included script, or stylesheet, or a manually written anchor tag in the HTML Editor, etc.).


index

(n) asset name (aka system name) of the single default page for menu-enabled "Folder with [Page-type]" assets.

(v) function within the CMS whereby enabled assets share system metadata with the CMS; aka 'indexing'.

This metadata sharing supports:

  • automated navigational element builds (e.g. Left Nav Menu);
  • Article Listing type page content (e.g. News Listing);
  • Related Links Sets' link text for internally linked assets.

See also metadata / metadata set[s] discussion.

 


indexing

see 'index'


metadata / metadata set[s]

a standard set of categories of information about each asset which is stored in the CMS database for each asset, whether it is actively used or not; see also 'index / indexing'

The basic metadata for every asset can include a(n):

  • Title*
  • Display Name*
  • Description*
  • Summary
  • Teaser
  • Keywords
  • Author
  • Start Date
  • End Date
  • Expiration Folder
  • Review Date.

Metadata sets may also include additional custom data which has been defined by CMS admin users for specific uses. A widely-used example is Folder-specific metadata.

Folder-specific metadata categories (aka settings) include:

  • Display in Menu
    Folder's immediate child 'index' page can appear in Left Nav menu for its area;
  • Display as Header
    Resets the Left Nav menu for all pages within the folder, to start with this folder's 'index' page as the top primary link, and show only this folder's menu-participating descendent pages; 
  • Enable Custom Header/Footer
    Allows this folder's immediate-child home-type 'index' page to designate an area-specific header and/or Footer for this folder's descendent pages.

An asset's existing metadata assignments can be reviewed by selecting the asset and then clicking the Details button. The Details >> Info panel can be expanded to show all metadata categories.

For page and folder assets, editors have control over the textual content of, and/or the settings for, the metadata which is used in:

  • dynamic site navigation: Folder Titles of pages included in left nav menus;
  • internal linking: Display Names can provide link's text, for internally-linked assets;
  • the building of the final published webpage[s]:
    • Page Titles feed their text to the Browser window title tab/bar;
    • Page Display Names are used for standard webpages' main headlines;
    • Search engine optimization (Summary, Teaser, Keywords, and Description metadata for pages inform search results; and can provide on-page text for dynamic features such as news articles and listings);
  • asset management:
    Start Date; End Date; Expiration Folder; Review Date.
  • asset tree: User 'Appearance of Asset Links' Setting determines whether items in the asset tree will be shown using their Title metadata, or their system-names (aka asset name).

* The most critical categories of metadata include the Title, Display Name, and Description. Thus, Editing fields for these items may appear at the top of the Edit >> Content panel for greater prominence, even though the rest of the categories in the Metadata Set appear on the Edit >> Metadata panel itself. These critical categories may also be designated as Required and thus are visually flagged by a red asterisk in the Editing dialogs. Any changes made during an editing session might be prevented from being Submitted if Required items are not addressed.

 


synchronize, synchronizing your site

Any publishing from the CMS which includes all the areas of a site which are affected by any change/edit within the CMS (including multiple changes or edits) is considered to be "synchronizing" your CMS site with the version of the site which has been written to a server location - whether those materials are published only to Staging, or whether they may also be published to a Live site.

The CMS allows users to take advantage of dynamic features, such as: automatic updating of an entire area's left nav menus based on an editor changing the title metadata for just one folder within that area. However, any dynamically propagated changes would still need to be published for those changes to be seen by anyone without access to the CMS site. It is especially important to be aware of the scope of any dynamic updates propagated within the CMS, so the appropriate material can be synchronized with the material on the server through publishing.




system name

equivalent to an Asset Name, and distinct from an asset's Title or Display Name metadata. The system name for any publishable asset is assigned upon the creation of the asset and determines that material's final filename upon being written to the server; thus, it is important that system names follow UH server file naming conventions.

In brief, system names should be all-lower-case with no spaces and with individual words separated by dashes. Dashes are preferred over underscores.

Because system names are dynamically tracked within the CMS, a system name can only be changed by using the Rename dialog found under the More button options when the asset is selected as the active asset.

Warning: do not change a page-type asset's system name from "index" to something else without considering this: the CMS' automated navigation-building-defaults expect a folder's immediate child-page to retain the system name of "index", and automatically-generated links would therefore break if a folder's default "index page" is Renamed.

Publishable assets include page-type assets, file-type assets, and folder-type assets. 

The system name for a folder asset will be used as the proximal segment of its child-page's web address
e.g. for this page: 
https://www.uh.edu/infotech/services/web-services/cms/cms-how-tos/cms-glossary/index.php)

Additionally, that folder's direct line of ancestor-folders, all the way back to the site's home folder (in the above example: "infotech"), would also be represented, respectively, as segments in the item's web address.

For sites publishing to the main UH website, the UH home location (https://www.uh.edu  or simply  https://uh.edu) will typically begin the address.