CMS Basics: Switching Out Index Pages - University of Houston
Skip to main content

Switching Out Index Pages

A discussion of how to proceed to switch out 'index' pages in Cascade (e.g. switching out a Home or Standard page for a Landing Page). If you need further assistance, please contact either or

| Quick Summary: switching out pages NOT calling a Custom Header
| What is a Home-type Page?
| Longer Notes: switching out a page which calls a Custom Header

Quick summary:
switching out pages which are NOT calling a custom header for their area.

  • 1st, switch off indexing and publishing for the original "index" page;
    [ Edit > Configuration > un-check those settings ]
    then change its system name by Renaming it to anything different than just "index"
    (e.g. "index-old").
    [go to the More button > Rename dialog]

    Note: because the replacement page will end up with with the same system name as the original, you do not strictly need to un-publish at this point; and you may override the automatic un-publish if desired.
  • 2nd, check other pages which have Chooser links to the original page;
    Make note of any other pages which may have a Chooser-type link to it
    (i.e. an Internal Link somewhere in your site for which the Chooser points to the page you are deprecating). It can be helpful to look at the original page asset's Relationships:
    [ More > Relationships ] 

    Any items so linked would need to be manually updated so that their link[s] point now to the new page; and then those items would need to be Re-Published (4th step) once everything is ready. This could include the area's Custom Header menu. If so, please read the additional notes below regarding the header-local asset.
  • 3rd, Rename the new page so its system name is now "index";
    and allow the CMS to Un-Publish it while Renaming.
  • 4th, Publish the new page, along with any items which may have an Internal Link to it.



If the new page is not a home-type-page which is calling a custom header for its area, then you should be able to synchronize with your published site by just republishing the page and any items which have Internal Links pointing to it (links made with a Chooser), and possibly also its immediate parent folder to be safe.

Be aware that any Internal links (links created within Cascade using a Chooser tool) will need to be manually updated so they point to the new page instead of the original page. However, for the 'automated' navigation items like left-nav or breadcrumb, you shouldn't have to manually update links in that case; you would just need to remember to republish everything affected by the change to synchronize your site.

Also be aware that it may also be important whether or not you are doing any other changes to the area in question at the same time you are switching pages out, such as: possibly re-ordering the left nav, adding a page or deleting a page, etc. If your site structure for the area you are working within has changed, remember to publish from the parent folder of the folder which has changes, in order to synchronize any such changes with your published site.

Your published site might be either your Staging area site or your Live site (aka Production). It is recommended practice to always publish first to Staging to review your work and make any needed adjustments before publishing to the Live site.

However, if your left nav menu or breadcrumbs have not been changed, it is likely that synchronizing anything other than the page itself and any other pages Choosing it would not be needed.


A home-type page is a page which is capable of calling a custom header and/or a custom footer for its area. Home-type pages include pages with a Content Type of "Home" or "Landing". Some pages with the Content Type of "Modular" may also act as home-type pages; however, the use of that specific Content Type has been deprecated.

If in doubt, check the Details button for the page, under the Design tab's Content Type information. The Content Type should include either the word "Home" or the word "Landing" (or "Modular").

You can also check the page's Edit panels:

  • Pages with a Home or Modular Content Type have header and footer Choosers near the top;
  • Pages with a Landing Content Type have header and footer Choosers near the bottom;

If a page does not have the capacity to Choose a custom header for its area, then it is not a home-type page.

Additional notes:

Cascade CMS allows Sites Admins to set a link on the User's Dashboard which, for their convenience, takes them directly to the site's designated 'home page'. If the original home page for a Site is switched out with a different page, then that Dashboard link would continue to point to the old page until changed on the Cascade Admin side. Please contact or to adjust or switch off that setting for you.

If the items you are switching out are home-type pages and are calling a custom header for their area (and/or custom footer), then there is significantly more to think about.

There will be some steps which need to be taken before other steps, so please read through everything first before diving in.

Switching out a Home-type Page for an Area Which is using a Custom Header

    1. Check the folder settings, especially if the area does use a custom header:
      • The area's home folder settings govern whether that folder's descendants/ area can even use a custom header or not. Select the Folder then go to the Edit button to check the settings.

        [√] Display as Header  and  [√] Custom Header both need to be selected for a folder to allow its descendents to use a custom header / "header-local" asset;
        (If the folder does not allow a custom header, then the area will inherit either the header being called by the next nearest ancestor, or will default to the basic generic UH header.)

      • If the folder settings have had to change, chances are the site navigation for the area may also have changed.

        If in doubt (but, AFTER all other changes are ready!) then you should synchronize the area by publishing the area's home folder and everything inside it.

        But BEFORE you do that - you would make sure that everything else is ready:

    2. Check the home-type-page-asset's settings and system name:
      • For the area to use a custom header (its own header-local-type asset) the immediate-child-index-page for the folder in question has to be one of the "home-type" page-types capable of calling a header (and footer).
        Also, if it is not inheriting from its own parent, then it needs to have a relevant header-local type page and a custom footer type page selected appropriately in the home-type-page's Edit panel. For "Landing"-type pages the settings will be near the bottom of the Edit panel. For "Home"-type pages settings are near the top. Both of those are home-type page assets because they are capable of calling custom header/footer.
        (To tell the exact "type" of page you're working with, select the page in question then look under the Details button > Design panel > Content Type.)
      • The ACTIVE immediate-child-index-home-page has to have its "indexing" switched on. 
        [Edit >> Configuration >> include when indexing]
      • Any other home-type pages which are immediate-child-pages of same folder should either:
        • not have headers and footers Chosen at all.
        • or have their "indexing" switched OFF, as they are still otherwise capable of offering a header and/or footer to other pages. 
        • Check some of the interior pages for the area/folder. If, from Cascade's page preview, you can see that pages in the site are displaying multiple headers and/or footers, then there is one (or more) home-type page asset[s] somewhere still capable of offering-out the designated "extras".
        • Note: Only those pages which are in the mechanical site-position of a homepage and which have the role/purpose of a homepage should have a header and/or footer Chosen. Home-type pages in development should retain their header-footer selections ONLY if their "indexing" is switched OFF.
      • The active home page for an area needs to have the system name: "index"
        Similarly, any Folder's immediate-child-page should always have the system name of "index", so that Cascade's assumptions when building the automated navigation are met.
        Rename if needed. [Go to: More >> Rename]
        NOTE: the obsolete page can first have its indexing and publishing switched off, and then be Renamed to anything else except "index" (e.g. index-old); and then the intended new home page can be Renamed to "index". Be sure to update any Internal/Chooser-type links which previously pointed to the old page. You will want to republish everything using those once all your updates are in place. See also the Quick Summary notes above.
      • Publish the new home page when ready.

    3. Check the header-local asset itself:
      • The header-local asset itself needs to point-to (Choose) the desired home-page / "index" page for its own area. If an area's home page is being switched out, then re-Choose to select the new "index" page. This Chooser should be fairly near the top of the Edit panel for the page.

        Additionally, what the header-local menu links point-to are also manually set via Choosers, under the Edit panel in the header-local asset - and there are potentially 3 levels:
        • Menu Bar Item
          (appears directly along the bottom of the header)
          • Dropdown Menu Item
            (opens out when the Menu Bar Item is selected, aka 'Child' item)
            • Nested Sub-menu Item
              (flys out from the Dropdown Menu Item, aka 'Grandchild' item)
      • Remember, any manually-set links (ANYTHING you used a Chooser for, to set the link) in the header local menu which previously pointed to the obsolete page will need to be re-Chosen now by the header-local menu Choosers.
      • Publish the updated header-local asset when ready.

Once everything in the checklist has been addressed, then synchronize with your published site by publishing the area's home folder and everything inside it.

Remember, you should publish first only to Staging to review how everything works in its new setup; and then publish everything to the Production/Live area when ready.