Clone

Overview

One of the available site actions is the Clone feature. The Clone feature can be used to help create a new site. When using Clone, just the site record can be cloned, or the site record and the site staging files can be cloned. Level 10 administrator privileges are required to use the Clone feature as it is available in Setup > Sites.

Once the clone action has been started and the site record is cloned to start with, but not yet saved, all of the panels that are available when creating a new site are available. However, the LDP Settings and Auxiliary Sites panels, as well as the UUID and public key information, are not available until the record is saved, which is similar to new site creation. When cloning a site, it is necessary to change the Production Server FTP Settings in order to not overwrite existing information that has already been published to the web server. The combination of HTTP Root, FTP Root, and FTP Home must be unique within the account.

For more information, visit the Site Settings page.

Copy Staging Files

When cloning, staging server files can also be copied to the newly cloned site by selecting the Copy Staging Files checkbox. All the files seen in a Content > Pages list view get copied. 

Feature/Functionality Clone Site Record Copy Staging Files Notes

Staging Server Files

No

Yes

Everything from Content > Pages

Production Server Files

No

No

 

OMNI-INF

No

No

The site-level OMNI-INF is not copied.

Binaries

No

Yes, if Binary Management is enabled on the original site.

If the original site has Binary Management on and the target clone does not, binary files are still copied to staging. The Purge tool can be used to delete binary files from staging if Binary Management will not be used on the cloned site.

Dependency Tags

No

No

The site files are cloned, the dependency tags for the site are reverted, and then the site is rescanned, producing new dependency tags.

Recycle Bin Location

Yes

Yes

This is a site setting.

Recycle Bin Contents

No

No

 

LDP Registration

No

No

Must register site if using LDP Forms

RSS Feeds

No

Yes

 

RSS feed assignments

No

Yes

Access settings are not cloned.

RSS Feed XMLs

No

No

The XML feed files are not on staging and no files are copied from production. Note: if the directory that contains the rss feed was created with the creation of the rss feed on the originating site, the cloned site will not necessarily have that directory on staging.

RSS Groups

No

Yes

 

RSS Items

No

Yes

 

Snippets and Snippet Categories

No

Yes

 

Reports such as the Checked Out Content Report

No

No

Report information is not cloned, but the Recent Saves report will immediately display the cloned files as saved.

Assets

No

No

Assets are not cloned. Assets are created within a site, but available for an account, unless the Lock to Site checkbox is selected. A page subscribed to an asset remains subscribed to the original asset on the original site. Asset linking is unchanged and continues to point to the original asset with a dependency tag reference; however, asset linking is supported across sites within an account.

Access Settings (Directories and Pages)

No

Yes

 

Access Settings (all others) 

No

No

 

Directory Variables 

No

Yes

 Copied only if staging files are copied. 

Find and Replace Last Replace Results

No

Yes

 

File Locks (including checked out files, scheduled actions and workflow)

No

No

 

Versioning

No

No

Previously published versions and committed backups are not included in the cloning.

Account-bound items are available for all sites: Users, Groups, Toolbars, Font Size Sets, Gadgets/Custom Gadgets, Google Analytics, Add-Ons

No

No

Are not cloned, but are still available within the new site as they are account-bound items.

Gadgets with site-specific information will not include old site's history such as for My Checked-Out Content or Activity. Images may include default paths.

Templates

No

Yes

Location setting, and template files at the site level are cloned if they are stored in a local staging folder (which is used by default).

Template Groups

No

Yes

 

Facebook Pages Setup

No

No

 

Twitter Account Setup

No

No

 

Default Tweet/Wall Post

Yes

Yes

Part of the site record.

How to Clone a Site

The length of time required to clone site files is dependent upon the size of the site in terms of number of files and file sizes. A particularly large number of media files large in size could possibly take a considerable amount of time to clone.

It should be noted that any use of the Site Clone tool (with file copy) should only be done when all users are logged out. The source site and its files, folders, and access settings are not affected by the use of the Site Clone tool. 

In order to clone a site, follow the steps below:

  1. Navigate to Setup > Sites
  2. Hover over Actions on the site row and click Clone.Site Actions Menu
  3. Create a unique Site Name. This identifies the site being edited. It is also the file name of the folder that contains the sites files on the staging server. A Site Name cannot include spaces, but can include uppercase and lowercase letters, numeric values, hyphens, and underscores. It also should not include duplicated names even if the letter case is different. In other words, www and WWW would be an example of a duplicated name. Note: Keep in mind that when a site is set up within a subfolder (e.g., http://www.college.edu/admissions) and there will also be a site at the domain (e.g., http://www.college.edu/), it may happen that users create folders within the main domain site that overwrite the contents of the other sites contained within the subfolder. Use caution when setting up this type of site structure.
  4. In the Site Information panel, select the Copy Staging Files checkbox in order to also copy the site files and directories. Otherwise, leave cleared to just copy a site record.Site Information Panel for Cloning a Site
  5. The following three fields must form a unique combination. Together they are combined to build the URL:
    • FTP Root: Where the files are served from. For example, /public_html. A trailing slash should not be used. 
    • FTP Home (Optional): FTP Home should be configured as a subdirectory of FTP Root. If this field has been filled out, the FTP Home and the HTTP Root form the URL for the Dependency Manager links. For example, if the FTP Root is /public_html, FTP Home could be /public_html/art, and the HTTP Root could be http://college.edu/art/.
    • HTTP Root: The URL root of the website. A trailing slash should be included, eg. http://www.college.edu/. If a path exists in the FTP Root, that path must match the HTTP Root. For example, if the FTP Root is /site, then the HTTP Root would be http://www.college.edu/site/. If the HTTP Root changes, the entire site will need to be republished.
  6. The Dependency Manager honors both the source and the clone settings. When cloning, it is not necessary to manually revert/rescan for dependency tags. The Dependency Manager will manage the creation of new dependency tags for the cloned site by reverting and rescanning. Links among sites within an account are maintained. The Dependency Manager settings can also be used to take absolute links from the source site and have them scanned into Dependency Manager links on the clone site.
  7. Click Save. The Clone feature does not clone the following items in the site record, but are available after save.
    • Public Key
    • LDP Settings
    • Auxiliary Sites/Publish Target

These settings are always unique to the site and are not duplicated between sites.

Additional Steps to Go Live

The following steps will need to be performed similarly to new site creation:

  • Quick Search: After cloning, it is necessary to build the index for the Quick Search in Site Settings for the new site (Setup > Sites > Edit for the site > Options > Quick Search).
  • Site Publish: When using Copy Staging Files to clone files, it is necessary to publish the entire site to the production server. All files can be published from Setup > Sites > Publish > Publish Site.
  • Initialize: Initialize adds a DirectEdit button to each page that is missing one.
  • Site Access settings and any directory variables for the site may need to be reconfigured. Administrators Only is set as the Access Group by default.
  • Any internal absolute paths pointing to the old domain name would need to be fixed. For example, if dependency tagging wasn't in place for an URL and http://www.exampleschool.edu/about/index.html was used in a link, it would need to be updated. If the cloned site is at: http://artcollege.exampleschool.edu/about/index.html, then the hard-coded link would now be incorrect.
  • If the clone was created by adding an appending an additional directory to the domain and site-root relative paths were used in include files (or other pages) rather than dependency tags, then the paths need to be updated. For example, /about/index.html would need to be /clone/about/index.html

The Find and Replace feature can be used to selectively fix changed paths.

More About Dependency Manager and Site Clone

The use of absolute or relative links should be considered when cloning a site. The functionality of the site clone when using the file copy option honors both the source site’s and the clone site’s Dependency Manager settings. The Clone feature can smartly revert scan and rescan Dependency Manager links to update the Dependency Manager tags. The Dependency Manager settings can also be used to take absolute links from the source site and have them scanned into Dependency Manager links on the clone site.

Use Case Examples for Dependency Manager Settings

The scenarios below illustrate the result of a clone with the various options of Dependency Manager settings and for whether the site setting for URLs is absolute or root relative.

Source Site Dependency Manager On, Clone Site Dependency Manager On

Source Enabled; Clone Enabled

When Dependency Manager is enabled for both source site and clone site, the following occurs:

  1. The source files are copied to the new site.
  2. Dependency Manager performs a Revert scan of the tags.
  3. Dependency Manager re-scans the cloned site using the settings for URLs, absolute or root relative.

    The end result is a cloned site with Dependency Manager tags that are all local to the clone and not pointing to the source site. 

Source Site Dependency Manager On, Clone Site Dependency Manager Off

Source site enabled; Clone site disabled

When Dependency Manager is enabled for the source site and off for the clone, the following occurs:

  1. The source files are copied to the new site.
  2. Dependency Manager performs a Revert scan of the tags. The scan uses link formats based on the cloned site's settings for URLs (absolute or root relative).

The end result is a cloned site with no Dependency Manager tags. All URLs are absolute or root relative to itself and not pointing to the source site.

Source Site Dependency Manager Off, Clone Site Dependency Manager On

Source site disabled; clone site enabled

When Dependency Manager is disabled for the source site and enabled for the clone, the following occurs:

  1. The source files are copied to the new site.
  2. The Dependency Manager scanner creates links on the cloned site as specified by the cloned site's settings for URLs (absolute or root relative).

The end result is a cloned site with Dependency Manager tags that may or may not all be local to itself. Any pre-existing local Dependency Manager tags will remain pointing to the source site (see Edge Case #2 below).

Source Site Dependency Manager Off, Clone Site Dependency Manager Off

Source site DM disabled, Clone site DM disabled

When Dependency Manager is disabled for both source site and clone site, the following occurs:

  1. This only copies site files.
  2. No Dependency Manager scanning of any kind occurs.
  3. A true copy of the source site is made.

The end result is a cloned site without any action being taken for Dependency Manager tags. Any existing Dependency Manager tags are copied as is and will continue to point to where they pointed before they were cloned.

All URLs in whatever form (absolute or root relative) point to itself and not to the source site. Any pre-existing absolute URLs that pointed to the source site will remain pointing to the source site (see Edge Case #1 below).

Note for all use cases: Any Dependency Manager tags that exist in the source site that point to web sites other than the source will continue to point to those other sites from the clone no matter what combination is used. The same is true for Asset tags, the asset tags will continue to point to the proper asset.

No matter what combination of setting mentioned above is used, there is one common scenario that will require the admin to do some post processing after the site is cloned. If the source site contains absolute URLs pointing to any binaries on the source site’s production server, the admin will need to use the Global Find and Replace feature on the cloned site. This is to take into account the different HTTP Root to correct all the binary absolute URLs (if they need to be pointing to the cloned site’s HTTP Root). This is because URLs pointing to binaries are not under Dependency Manager control and are not changed as part of the Site Clone’s file copy function.

For more information about Find and Replace, visit the Find and Replace page.

There are also two edge cases that could require the administrator to do some pre- or post-processing depending on the state of the source site and the expected result for the cloned site.

Edge Case #1

In this scenario, the source site has absolute URLs and Dependency Manager is off, and the admin wants Dependency Manager to remain off for the cloned site and still use absolute URLs.

The cloned site would have absolute URLs that point to the source site.

An administrator would need to either use the Global Find and Replace to correct for the cloned site’s HTTP Root to correct for all the link URLs incorrectly pointing to the source site.

Alternatively, the admin should set the Dependency Manager setting for the clone to be turned on before clicking Submit to start the clone procedure. When it is complete the admin can use the Revert feature to un-scan the Dependency Manager tags back into absolute URLs.

Edge Case #2

In this scenario, a site clone is made when the source site’s Dependency Manager setting is off, but the source site contains Dependency Manager tags that point to pages on the source site.

These Dependency Manager tags will be preserved in the cloned site, and they will continue to point to the source site’s page URLs. This is on purpose, as there are cases where this is the intended or required result of a site clone procedure. If this is not the intended result, the administrator needs to be sure to turn the source site’s Dependency Manager setting on before the site clone tool is used. Once the site clone process is complete the admin can reset the source site’s Dependency Manager setting to off.

Use Case Examples for Site Settings

Example 1

A university with a domain of gallena.edu would like to create a site at a subdomain for the art department, art.gallena.edu.

The OU Campus level 10 administrator could use the following settings:

Site Name: art

Server: art.gallena.edu

FTP Root: /public_html

HTTP Root: http://art.gallena.edu/

FTP Home

The URL is http://art.gallena.edu/ and the FTP Home can be left blank. Logging in via FTP, the user would be putting files to the FTP Root.

Example 2

In another example, the Art Department at Gallena University would like to create a site for the ceramics course of study. 

The administrator could use the following settings:

Site Name: ceramics

Server: art.gallena.edu

FTP Root: /public_html/ceramics

HTTP Root: http://art.gallena.edu/ceramics/ 

Things to Remember

  • The FTP Home field is optional. If it is empty, the combination of HTTP Root and FTP Root creates the URL. If FTP Home is filled out, the combination of HTTP Root and FTP Home creates the URL.
  • The FTP Home needs to be a subdirectory of FTP Root.
  • If FTP Root is different from the default of what the cloned site was using (i.e., public_html) and not using local templates, then the path for templates needs to match also. For example, if FTP Root was changed to /public_html/art then the path to the template directory would be /public_html/art/_resources/ou/templates.
  • The cloned files on staging need to be published.
  • Users should not be active in the site during cloning.