Moving, Renaming, and Deleting all have something in common as far as the CMS is concerned.

What is it?
A: Each of these actions can change the site-structure pattern from which the CMS Publisher writes your site to its Server Location(s).

Why does changing the pattern matter? Because of the potential for orphaned files, non-synchronized or oddly-acting navigation menus, unwanted duplication of pages, and a variety of other avoidable headaches.

So how do you Move, Rename, or Delete things without messing up your site?

The following material may help you avoid many of the most common headaches:

• Understanding the CMS Publisher
• Submit vs. Publish
• The Publish Button
• Dynamic-propagation vs. Submit/Insert/Confirm vs. Publishing
• A Sample Move Scenario for a Live Site
  • Process to Minimize Impact on a Live Site
• Orphaned Files

Understanding the CMS Publisher: Background Information

Keep in mind: the Cascade Server CMS is not a live-edit application.

While you are working inside the CMS you are working with CMS-assets, such as Page-type assets, Folder-type assets, and File-type assets. These are items which will become, respectively, web-pages, directories, and various types of files only when they are Published out from the CMS. And it is only after materials are present on a Server that Browsers can find them and present them, online, to you and your site visitors.

Furthermore, while the CMS is a dynamic application (i.e. constantly tracking and updating materials for you as you work), the files which are Published out to the Server are "static" - meaning that once a file is written to a Server its content cannot change until it is overwritten by another file with the exact-same name and location.

Therefore, when you Move, Rename, or Delete assets from within the CMS you need to consider not only the CMS-asset itself, but whatever corresponding file may have been created on the server by the CMS Publisher at any point. Especially in a Live site, the timing/order of how you Publish and Un-Publish materials can be very important.

For further discussion, please see the Sample Scenario below.

More about Assets

Before they are Published, Assets are really only a collection of organized information, materials, and instructions which the CMS is keeping track of through its internal database, and then presenting back to you, visually, through its user interface (e.g. the Asset Tree's folders and files, or the View panel's Page Preview).

Some of these instructions you will provide, as a site Editor. Some of the instructions you may never see, such as those relating to the main UH Stylesheets, or the Standard UH Footer. The CMS always sees every instruction an asset is heir to, however, and applies everything to the Publishing process according to command. As a reminder of how the CMS keeps track of all the myriad information associated with a particular item via its internal database, you may notice each item's unique 32-character ID string, showing up as you work along through your site.

So just remember: The CMS Publisher is the functionality inside the CMS which converts all those instructions, all those pattern pieces, into their final form, and then writes them to (or erases them from) the selected server location.

And also remember, Internet Browsers cannot find your web-pages if they have not first been Published out (aka "written") to a Server Location with an accessible web address/URL (e.g. for a Live web page: https://www.uh.edu ;  or for a Staging area web page.).

Submit vs. Publish

Doesn't hitting "Submit" Publish the page?

A: "Submit" does NOT Publish anything.

The "Submit" command only tells the CMS to SAVE your changes by integrating those updates into its internal database, and to convert your user-specific Draft into the active asset which any eligible editor can then update further.

A separate, specific Publishing step must be taken to send your updated materials out to a server location - i.e. either Live or to the Staging area. In other words, only a Publishing step will result in any item being written to a server, where browsers can locate it by its URL, and present it to its viewing public.

While working inside the CMS, you also need to confirm, for each and every layer of Editing panels and Dialogs, that you want your changes saved. Otherwise, the CMS will discard them from the active asset and they may only be preserved, if at all, in a specific-user-only Draft version of the asset/page.

Draft versions of assets cannot be Published. Draft versions of "Publishable" assets (Pages and Files) must be Submitted to become active assets before they are eligible to either Publish or Un-Publish.

The Publish Button

What Publish Button?

A: You may not see a Publish Button.

The CMS is Permissions-based, which means if your particular user ID is not associated with a particular set of Permissions then you are unlikely to see whatever interface items may be needed to exercise those permissions.

A common example would be if a user did not have Publishing Permissions for a particular item, then they would not see a Publish button (cloud icon) in the right-hand information pane for the item in question.

If your user ID is associated with Publishing privileges for a particular item or area, then when you select items from within that area you will see a Publish button in the row of buttons near the top of the right-hand panel of the CMS:

Publishing privileges also govern the Un-publishing function, typically accessed under the More button:

And certain actions and editing options will only be available to a user with Publishing privileges for a selected Folder asset, such as the multi-select actions which become available for items selected from its Folder Contents List:

Dynamic-propagation vs. Submit/Insert/Confirm vs. Publishing

When you save your changes inside the CMS, you are telling the CMS to update its internal database to store those changes for you. Some of the changes you initiate - such as updating the Left-hand Navigation Menu, or changing an Internal Link - are Dynamically managed by the CMS - meaning the CMS will propagate the change throughout your site for you, without you yourself having to manually visit and edit every affected page.

This is one of the great features of the CMS!

However, you will still have to remember to Publish out all affected materials, so that your site visitors can see those changes too. This is all part of keeping the static Published pages "synchronized" with the current state of the dynamic assets inside the CMS. The CMS offers some prompting and assistance, but the Editor is ultimately responsible for recognizing the need for Publishing, Un-Publishing, Re-Publishing, etc. 

See: How do I Know What to Publish? A table of editing actions vs. dynamic response  vs. what you need to publish.

A Sample Move Scenario for a Live Site

Following are some notes on Moving and Un-Publishing/Publishing some materials from within a Live, working site.

Move Scenario: Supposing you want to reorganize your site, and want to move a page, a number of pages, or even a whole section, into a different location.

As our example involves a Live site, and as the materials we are reorganizing would have already been published at at earlier date, we will want to think carefully about how this move will impact our site visitors, and the availability of the materials themselves.

Within the CMS, you might start by trying to Move [and/or Rename] the materials by using the Move/Rename tab near the top of that material's right-hand-side information panel.

You would immediately see a specific panel allowing you to make/confirm some choices, along with an ALERT Message, and a default setting to automatically unpublish the original material upon making the change (the "Unpublish Content?" default checkbox).

Please take a few moments to consider the alert. The alert tells you how the CMS looks at things:

Previously published versions of the asset will remain on the webserver with the old path unless unpublished. Unpublishing from the remote server will delete the out of date content from the chosen Destinations.

Paraphrasing and expanding on the alert, for real time use:

• The version of the materials your site visitors have been seeing all along will remain available online, and in the way they were originally organized, unless and until you Un-Publish them (erase them) from your Live Site.
• Un-Publishing right this second, however, will remove those materials from the original location right now, and you will still need to take a separate step to Publish out both the newly moved materials, and to Re-Publish the section the materials came out of. So, if you Un-Publish this material right now, this material will be completely offline and unavailable right now, until you Re-Publish the updated materials.
  
• So, you may actually want to wait a little bit, do some impact planning, and also time these changes so that very few people are likely to be visiting your site when they happen - for example: the end of the day, the weekend, or between semesters, etc.
• So - in this Move scenario - you should probably just stop and uncheck that Un-Publish-while-moving checkbox and wait to do that until later, when you are really ready. In fact, you should plan on making a copy of these materials immediately upon finishing the Move step. The following notes on minimizing site impact will help explain why.
  

Please note that if nothing within the Moved section had previously been published, of course, then there is less to worry about, and this should be fairly straightforward: leaving the automatically-unpublish option checked really won't hurt anything. The CMS would simply look for the material to erase, not find it, and report a successful process. Thus, for that particular instance, it is a moot point whether unpublish-while-moving is checked or not.

However, if the material has been previously published, then some care should be taken to minimize the impact on the continuity of the material's availability to site visitors.

To minimize impact on a live site, you can follow this process:

1. Plan
2. Move the material
3. Immediately make an exact Copy of the material and place it back in the original location
4. Work with the relocated material and the new location
5. Manage the original location and the Copy
    

Expanding on those steps one by one:

1. First, Plan! How can you coordinate the desired changes to minimize the impact on the Live site?
   Points to Remember:
   • Only Publishing and Un-Publishing can change the static materials on the Server (e.g. the Live site and/or the Staging area).
   • It is up to each individual Site's users who have Publishing Permissions to ensure that any and all pages within a section which are being Published are in fact ready for Publishing.
   • As a general rule: to maximize continuity and availability, you should plan on Publishing the new arrangements of materials before you Un-Publish the older versions.
   • You should work during times when the fewest number of site visitors are likely to be impacted by the switchover: e.g. between semesters, during periods of low demand, etc.
   • When Moving materials, two areas of your site will be affected: the area the material is coming from, and the area the material is moving to.
   • The CMS considers Copies of materials to be brand new assets, without any internal links pointing towards them (although links pointing outward are preserved).
   • Thus, exact Copies of CMS materials, residing in the same location as the originals, can be used to Un-Publish the original materials because the Publisher and the Server are only concerned with matching Filenames, and not with any of the CMS-driven dynamic relationships.
   • To ensure Synchronized Left-Nav menus throughout your site: the relative Parent Folders for each of the changed areas (old and new) should determine the point from which you initiate the Publishing action. Remember: each area will need to be Published once it is in its final form.
   • Note: You may also want to consider leveraging your site's two publishing destinations, especially if you can afford to freeze publishing to the live site while extensive changes are being completed, approved, and ready to go-live. Just remember that Un-Publishing will still need to be done on both your hidden (staging/test) site and your Live site. And, between the two, it is most critical that you avoid any obsolete files or interrupted availability for your Live site, which the public sees and depends on for accurate information.
      
     
2. Start your Editing. Within the CMS you would first Move the material by using the More button >> Move command [don't Rename yet], making sure the default Un-Publish setting is un-checked for now.
    
   
3. Next, make a COPY of the relocated material, to place back into the original location.
   This technique ensures that both the original and the Copy can retain the same system-names. It is a good idea to make the Copy as soon as possible after Moving the material - especially if the intention is for things to be rearranged, Deleted, or Renamed in the new location. Your goal is a Copy which matches the original exactly for site structure and system names. See also: notes following on Managing the original location and the COPY.
     
4. Work with the original/Moved material as desired. Things can be altered or Renamed however you wish AFTER the COPY has been made (see next step). When ready to Go-Live with your changes: Publish the relocated material*, starting from its containing (aka Parent) folder for the area where the moved material has been placed. Choosing the correct parent folder to Publish will ensure that left-nav menus are properly synchronized between the CMS version and the Server/Live version(s). Remember: when working with the Left-Nav menu, always Re-Publish from the Parent folder of the menu item(s) which changed. 
   *Note: Also be aware that, while this process would result in the Live site having some temporary content redundancy, it also reduces the amount of time when content is unavailable to the site visitors.
    
   
5. Manage the original location and the Copy:
   • Working with the COPY:
     • Ensure that all system-names and the asset-tree organizational structure match EXACTLY with the static version(s) on the server (e.g. the versions most recently published out Live).
     • Immediately after Copying set the Copied material to be NOT Included in the Menu, and Not Indexed, so they will not interfere with the active materials. You may also wish to set these obsolete materials to be Not Publishable, temporarily, until you are certain they are ready to be removed from the Server. All of these types of settings are inheritable by Folder, so to make your task easier you may want to simply choose an appropriate Parent folder to apply them to.
   • After the new materials have finished Publishing out, then Re-Publish the parent folder of the original section (the section the materials were moved out of), to Synchronize the Live site's menus for this section as well.
     This essentially "removes" the obsolete material from the original area's live navigation menus - essentially "hiding" them, even though they are still on the server. The obsolete material still needs to be Un-Published, of course, otherwise search engines will still find the obsolete material. See next step.
     
   • If/when ready, go back to the COPIED materials and set them again to be Publishable, to enable the Un-Publishing step.
   • Use the Un-Publish command on the COPIED materials. Select all Publishing Destinations.
   • Once the COPIED materials are finished Un-Publishing successfully, they can be safely Deleted from within the CMS if desired.
   • If the COPIED materials are going to be kept for reference, they should then be set to be NOT Included in the Menu, NOT Indexed, and NOT Publishable, so they do not interfere with the site. It can be a good idea to include a note explaining the material's status when Submitting to save the new status of the saved materials.

Orphaned Files

An Orphaned item indicates a CMS Asset such as a Page or File which had been Published to a Live Destination at some point, and which had not been Un-Published upon becoming obsolete. Unfortunately, search engines can still find such content - especially, for example, if such a page contains links to live items, and/or some page is still linking to the orphaned item.

The good news is: if you know the site-path of an orphaned file which originated from your site, you should be able to use the CMS to eliminate it from the server. There are four basics steps:

1. Examine the path
2. Recreate the path
3. Un-Publish the Stand-in asset(s)
4. Back out and/or delete the recreated item(s)

Looking at that, step by step:

1. Examine the path.
   Most likely you would have a URL for the Orphaned item. For example, one of your site visitors may have sent you a link to an obsolete, Orphaned page they came across during a web search. For the sake of illustration, let's say you were sent a path like this: 
   https://www.uh.edu/yoursite/about/obsoletestuff/
2. Recreate the path.
   Your goal is to create a stand-in, or "dummy", asset structure inside your CMS site, to which the Un-Publish command can be applied. To do this, you may need to recreate a nested folder/directory structure as well:
   
   • For each directory level of the URL which is within your site there will need to be a folder in the CMS asset tree with an exactly-matching system name.
     For the example above, you would need to make sure there was a folder named "about" immediately inside your site's home folder "yoursite", and the "about" folder would need to have a folder named "obsoletestuff" immediately inside of it.
   • IMPORTANT! Check to see whether any part of the Orphan path is still active inside your site.
     If so, you will want to preserve that portion of the structure, as well as protect your site from extraneous menu/nav changes.
     Thus, if you are creating a folder which is otherwise not being used by your site, be sure to set the folder to be Not Included in Menu. It will need to be Publishable, however, so the Un-Publish command is enabled. No other settings or associated information really matter - as the Publisher and the Server are only concerned with matching paths and matching filenames.
   • Also note: even though any page(s) or files inside the innermost (e.g. "obsoletestuff") directory may not be explicitly named in the URL, you should remember that every item you wish to delete with this technique will still need to be represented by a stand-in item. The CMS will not Un-Publish any item for which it does not find an asset to match, even when Un-Publishing from the folder/directory level. On the other hand, neither does the CMS need the outter "dummy" folders to contain any other content than the necessary folders themselves; only the innermost folder needs an asset to target.
   • By default, any page displaying in a browser while not being specifically named in the URL should be first targeted with a stand-in page asset named "index". If a stand-in asset named "index" does not serve to remove the un-named targeted webpage, please contact webservices@uh.edu for assistance.
   • Also, if you are not sure what the exact contents of a directory may be, and/or if you have reason to believe there may be more Orphaned material on the server than the URL indicates, please contact webservices@uh.edu for assistance.
3. Un-Publish the Stand-in asset.
   Select the stand-in asset(s) at the appropriate level of the file structure - e.g. the stand-in page/file asset itself, and/or a folder holding only items which you wish to erase from the server
   • Then select the Publish tab. For Publish Mode, choose "Un-publish". Submit.
   • Once the command has been completed (i.e. Publisher Queue no longer lists the item being Un-published) go to a browser and enter the URL. You should receive a Page Not Found message. If you still see a page at that URL, you may wish to clear your browser's cache (or try Shift+Refresh for Mac). If clearing the browser cache does not yield a Page Not Found message, you may need to re-examine the URL vs the CMS asset-path to ensure the correct item is being targeted. 
4. Back out and/or delete the recreated item(s).
   Once you have successfully removed an orphaned item from the server, you should then be able to safely delete any assets used to create the stand-in path which are not otherwise being used by your live site.