Dev GuideAPI Reference
Dev GuideAPI ReferenceUser GuideGitHubNuGetDev CommunityDoc feedbackLog In
GitHubNuGetDev CommunityDoc feedback


## Add the domain to the Admin Console

For the Admin Console to display the contents of the website within the newly created domain, it needs to be added to the Admin Console. Complete the following steps to add the domain to the Admin Console:

  1. Go to **Admin Console** \> **Websites.**

  2. Click **Edit** for the desired Website or click **Add Website.**

  3. On the **Details** finger tab, enter the appropriate domains in the **Domain Name(s)** field.

  4. Click **Save**.

At the time the Admin Console is first accessed, after configuration of the **Domain Name(s)** field (**Admin Console** \> **Websites**), the service will make a call to the <<product-name>> licensing server. If the domain exists in the registry, it will perform a date check. If it passes, the user will be authenticated into the Admin Console. If the domain does not exist in the registry, it will be created with a 30 day temporary license. This procedure allows the use of <<product-name>> for 30 days. Following this process allows development teams to use additional domains such as qa.yourdomain.com, dev.yourdomain.com and so forth. Each domain respectively will be registered with a 30 day temporary license when the Admin Console is accessed for the first time.

If an error occurs during the call to <<product-name>>, it will issue at Temporary license and recheck in 10 days.

To support ongoing development, it is common for development teams to submit tickets to Optimizely Customer Success requesting that development environment domains be converted to permanent domains. Use the [Submit a Ticket](🔗) link at the top of page to make this request.

Additionally, <<product-name>> provides developers with a test URL of the format \*.local.com which has a permanent license.

## Move content between pilot sandbox and production environment

When a customer is working on a new site, they are generally creating and modifying their content in the pilot/sandbox environment until they are ready to go live. During that process, it is common to want to move the content from one site to another.

This data is contained within several tables: **ContentItem**, **ContentItemField**, and **ContentPageState**.

This document will outline the general approach to migrating this data from one place to another. There is an assumption that the database lives on separate servers.

In general, the approach is to create a transfer database, populate it with the data to move, move the db to the new environment and merge the data. The scripts and documentation below adhere to this approach.

It is further presumed by this documentation that the user wishes to copy the content from the Sandbox (pilot) server to the Production server. We will be using the database named ContentTransfer for the transfer db and Insite.Commerce.SourceDB for the source database and Insite.Commerce.TargetDB for the targetDB. It is more likely that the source and target databases will be named the same, just reside on different servers.

  1. Create an empty transfer database on the Sandbox server.

  2. The scripts will resolve any differences in native IDs for the language, user, and persona but the website ID MUST MATCH EXACTLY between the two systems. If they don't once you have the data in the ContentTransfer tables, update the WebsiteId.

  3. The personas and language must exist in the target db even if they may not have the same ID values- the script will use the natural keys to find the corresponding language and persona and reassign it.

  4. Because content has users, language and persona associated with it, we will need to isolate the associated data in the content tables and insure it is available as we post it over ot the target db. Use the following:

    
  5. The steps above effectively gather all the data required to transfer the data. Next take a backup of the ContentTransfer db and restore it in the target environment and run the following script to replace the target data with the source data.

    Note

    This will overwrite any existing CMS content with the new data. Make sure to have a backup of the target db in case there is an issue and do this in off hours so that you can restore the db if there is a problem.

    Product content, dealer content, specifications and category content are stored in different tables and this is not going to affect that data.

    

## Work with favicons

A favicon (favorite icon) is the small image associated to the website displayed in various locations: browser tabs, address bar, browser history, and so on. Favicons are important to a website for many reasons which includes helping drive brand awareness by displaying the company logo and colors in multiple locations, as well as making your website easier to distinguish when working with multiple webpages in a browser.

Favicons can be found in multiple sizes and formats: 16 x 16, 32 x 32, 48 x 48, or 64 x 64 pixels in size, and 8-bit, 24-bit, or 32-bit in color depth; however, the recommended size is 16 x 16. They can also be created in multiple formats: .gif, .png, jpeg. However, the industry standard for sometime now is the .ico format.

### Add a favicon to a site

  1. Access the Admin Console.

  2. Go to **Websites** select a website.

  3. Click **Edit**.

  4. Within the **Details** tab, click **Browse** adjacent to the **Website Favicon** field.

  5. Select the desired image.

    Note

    There are multiple favicon generators available online if you don't have access to an existing favicon image file.

  6. Click **Save** to accept changes.

Note

It may take several minutes for the Favicon to appear on the website's tab.