This page is intended as a guide to both identifying and updating some of the parts of a standard content page which do not necessarily fall within the main WYSIWYG editor, such as: UH Header and UH Footer; the web address or URL; Breadcrumbs; Site or Area Name; Left Nav Menu; Display Name; Layout images, Related Links sets.

Webpage Jargon & Illustration | Editing Chart | Header and Footer notes | Web Address (URL) notes | Left Nav Menu & Breadcrumbs notes

UH Webpage Jargon

The following image illustrates some of the most common terminology used to describe the various parts of a typical University of Houston webpage. Some of these relate directly to the page's underlying “Regions" structure, some to the Editing dialogs, and some to general web jargon.

 See also: Using an Asset's Essential Metadata and its System Name
 

The UH Header and UH Footer

The standard-page-type asset itself does not contain a UH header per se, nor does it determine which custom header it can use. Only Home-type-page assets can call a custom header and push that header to their parent folder's child-pages.

A default UH Header will be displayed unless a custom header is used within the site, or a sub-area of the site – then, a "header-local" page-type-asset is created and called throughout an area by that area's Home-type "index" page. The custom header must also be enabled by the relevant home folder's metadata settings.

See settings in 3 general areas which can affect or determine the use of a custom header:

1. the site/dept home folder metadata; Edit folder >> Metadata dialog >> Display as Header? / (use) Custom Header
2. the site/dept home "index" page Edit panel Choosers (e.g. Edit home-page-type asset >> Home Page section >> Header/Custom Footer Choosers )
3. and the "header-local" asset itself. The main text identifying the site can be changed in the header-local Edit panel. Edit header-local-page-type asset >> Site Name textfield

The default UH Footer is also displayed unless the site (or sub-area) uses a custom footer – then the site's or area's home index page type also calls the "_ssi" folder item, custom-footer xhtml block (a "page-type" block which may be dedicated to holding only an 'include' instruction).

Multiple UH Headers or UH Footers Showing

Typically, if pages are displaying more than one UH Header or UH Footer it is because multiple home-eligible page-type assets are "requesting" them for all the pages under their influence.

If either multiple Headers or Footers are showing inside the CMS, then the CMS will be including them on the published pages, so avoid publishing any pages until it is corrected. If any pages were published with multiples, they can simply be republished after the issue is corrected.

In the case of a multiplied Header, typically users might have created alternate home pages to experiment with new layouts, but might have forgotten to switch off "indexing" for any home page alternates which are not 'active'. Edit the Home-type page asset(s): go to the Configure panel, and de-select "include when indexing" to insure the page will not call its designated Header throughout its area.

Similarly, if pages are displaying more than one UH Footer it is usually due to more than one asset calling a custom footer. De-select any unwanted footers by finding the relevant page's Footer Chooser and disconnecting the called file. Page-type assets which are capable of calling a custom footer include: Home Page, Modular Home Page, Landing Page.

For Home Page and Modular Home Page, header and footer Choosers are near the top of the Edit panel >> Content dialog.
For Landing-type page assets custom header and footer Choosers sit beneath the Page Settings section at the bottom of the Edit panel >> Content dialog.
 

Web Address (URL)

The CMS basically translates a Site's literal root folder name into the initial stem/domain; e.g. http://www.uh.edu/
and then:

• adds a concantenation of the relevant nested folders' system names, including all of a page's direct ancestor folders back to the site's (or area's) home folder
• plus page/file system name
• plus file-extension (e.g. ".php" for page-type assets).

Therefore, when any folder's system name changes, the URL changes. Please remember that any CMS system name which gets changed after the asset has been created must be changed with the Rename dialog (e.g. via the Add Content menu). Additionally, you should always un-publish any folder which needs to have its system name changed; however, you have some options on timing. The un-publish can be done immediately at the CMS's prompt during the Rename process, or it can also be accomplished by preserving a copy of the original asset – which can be saved first with a backup name, and then renamed to the original name solely for the sake of un-publishing (and then deleted). 

CMS location vs. URL example - this page:

Becomes:
http://www.uh.edu/infotech/services/web-services/cms/cms-how-tos/change-non-content-page-items/index.php

CMS Identifier – the asset's CMS ID

By contrast: when working inside the CMS with an asset selected, you may notice your browser's address bar contains something which does not look at all like the final URL for the selected material. This is because, within the CMS, each page (in fact, every asset) is assigned a complex and unique identifier when it is created. Even an asset created through copying another asset has a new, unique ID created for it. This unique ID is how the CMS database tracks every asset in your site as a separate entity. This CMS ID stays constant with an asset regardless of whether it is renamed, moved, modified, or even sent to the trash. You might also see the asset's CMS ID displayed when your cursor rolls over it.

Left Navigation Menu, Breadcrumbs

Left Navigation Menu – based on inheritance

Most of your site's "interior" pages will display some sort of on-page left-column navigation menu and breadcrumbs.

However: the content, structure, and order of the ‘Left Nav’ Menu and Breadcrumb string are actually determined by the Folder Metadata from every Folder-with-a-child-page which resides within a given section, together with the material’s parent-child relationships within the larger context of the Site’s structure, and not through any direct editing panel of the Page itself.

The Folder/Page partnership is often spoken of as simply The Page, but remember that each item contributes differently to the page's visible content and presence within your site.

The text for both that ‘Left-Nav’ Menu and Breadcrumb string comes from the same source: Folder Title information which content editors assign. The range of pages onto which each page's links are rendered into the left nav menus is governed by that page's immediate-parent-folder's parent-folder*.

Every page inside that folder will "see" the link (i.e. site visitor would see the item included in the left nav menu). Pages outside that scope will not "see" the link.

Whenever the CMS builds a Left-hand Navigation Menu into any page, it will include all of the following items (provided eligible items have ‘Display in Menu’ elected):

• the page itself and each of the page’s peers;
• any ‘child’ item(s) immediately subordinate to the page on display (i.e. no ‘grand-children’ will appear);
• the parent page of the page on display; (note: if the page is a top-level item, this is the same as the area’s home page/folder)
• each of that parent’s peers, if any; and…
• each of that parent’s ancestors and each of those peers.

Once assigned to be included, the CMS will dynamically update and integrate all Left-hand Navigation Menu and Breadcrumb information for you throughout your Site, and do so for you automatically whenever you change anything affecting them:
1) Changing the text; 2) Removing/Adding item(s); or 3) Changing the order.

(Note: Breadcrumb order might change if the site structure is modified. Left Nav Menu items' order can be changed manually via Folder Contents List drag and drop. Click the Order column head to display items in Ascending or Descending order before dragging.)

You are then responsible for making sure that the Live, Published version of your site stays Synchronized with the CMS version.

Remember, it is the Folder information (or position) that has to have changed for them to have changed; so basically follow this RULE: Publish from the *Parent to synchronize your site. This means you will be publishing from the Folder which is the parent of the Folder for which the information changed. And this will ensure that each and every page which "sees" any changed Left Nav items gets Published.