Page Comparison

...

Generate New Hostnames

To create a second channel, two new hostnames are required: the hostname for the public channel and the hostname for the Workspacer environment. In this document www.mysecondsite.com and cms.mysecondsite.com will be used as examples.

Add the new hostnames to your "hosts" file (C:\Windows\system32\drivers\etc\hosts on Windows computers) and point them to 127.0.0.1. For example:

127.0.0.1    www.mysecondsite.com
127.0.0.1    cms.mysecondsite.com

 If you use a proxy server, add excludes for these hostnames in the proxy configuration of your browsers.

Request an Updated configuration.xml from GX Software

The configuration.xml is a file with a license key that also contains the valid hostnames for your installation. To create a new channel, a new configuration.xml containing the two new hostnames is required: Send an e‑mail to developersupport@gxsoftware.com or contact your GX Software consultant in order to obtain a new configuration.xml. If you send an e-mail, do not forget to include the two new required hostnames

Update your configuration.xml

...

Back to top

Create a New Channel in XperienCentral

To create the new channel in XperienCentral, follow these steps:

...

Step 1: Name the New Channel

Image Removed

Configure the following fields:

Step 2 of 4: Configuration Settings for the New Channel

Image Removed

Configure the following fields:

Step 3 of 4: Create the New Channel

Image Removed

In step 3 you have to confirm that you want to create a new channel. Click [Create channel]. This operation could take a few moments. The new channel with one page, the homepage, has been created. You can now log in to the channel by accessing the URL by its new hostname (+port number) followed by /web/edit. Following the example in this topic, that URL is http://cms.mysecondsite.com:8080/web/edit.

Back to top

Extending the Folder Structure (Optional)

The configuration of the new channel can be extended or altered to allow separate files or presentations.

Separating Presentations

When managing multiple channels, it might be necessary to share common resources and (parts of) the presentation. In order to realize this, the following conditions must be met:

• There must be a central folder for the shared files and presentations.
• Besides the central folder, each channel also has its own folders for private files and presentations.

The following is an example of a folder structure in a presentation plugin:

<WCB JSP folder>/common/page/
                       /pagepart/
                       /element/
                       /etc
              /channel1/page/
                       /pagepart
                       /element
                       /etc
              /channel2/page/
                       /pagepart
                       /element
                       /etc

In order to be able to use this subdivision, you need to modify your configuration in the Setup Tool. On the General tab, navigate to the section "website_settings (x)" where x is the name of the channel you want to configure.

...

The descriptor directories are listed in a specific sequence. This sequence also indicates which JSPs are used if there are other JSPs with the same name. For example, if there is a page.jsp in the common directory and there is a page.jsp in the channel1 directory, then the page.jsp from the channel1 directory will be used.

The static files can be placed in a similar way as the JSPs:

…/presentationtype/static/common/images/
                                /stylesheets/
                                /scripts/
                                /…

…/presentationtype/static/channel1/images/
                                  /stylesheets/
                                  /scripts/
                                  /…

…/presentationtype/static/channel2/images/
                                  /stylesheets/
                                  /scripts/
                                  /…

Finally, the uploaded files can be placed in separate folders. In this way, the first channel can use the standard upload and upload_mm folders. Uploads for the second and subsequent channels can be placed in a separate folder below the main folder. For example:

backend/
/upload/                  for the first web initiative
/upload_mm/               for the first web initiative
/mysecondsite/upload/     for the second web initiative
/upload_mm/               for the second web initiative

These paths can be set for each channel using the following settings:

• file_upload_directory and file_upload_url (for normal uploads)
• file_upload_mm_directory and file_upload_mm_url (for Content Repository uploads)

Back to top

Sharing Content

For organizations with several channels and multiple publication channels (multi-channel publishing) it is often essential to be able to manage content from a central location and to re-use it on multiple places. This means not only content but also web users, forms etc. In a default installation with more than one channel, all content is strictly separated. Content sharing is not done automatically, so if you want to do this some settings have to be changed. Most of these changes involve assigning different read/write permissions for different channels. Editors of the various channels must explicitly allow one another to read content and to re-use content. By explicitly specifying to read per channel, everything can be set up in a safe and flexible manner.

An important feature of shared content is that shared content can only be read on another channel. For example, when an article is created in channel A then it can be displayed on channel B, but it can never be modified on channel B. This ensures that the rights of the author remain with the author. When different editors are allowed to edit content on different channels, their user accounts have to be shared as well. Editor X on channel A must be shared and granted permission to work on channel B as well.

Sharing and Accepting

In order to share content between channel A and channel B the configuration has to be changed to be able to expose (share) the content of one channel with another as well as to receive (accept) content from another channel. Sharing content is configured in three steps. For each channel, specify the following:

1. Which content types are available for sharing.
2. Which content should be shared with which other channel(s).
3. Which content should be accepted from other channel(s).

In this example, we will configure two channels so that articles from the Content repository are shared between channel A and channel B, and editors on both channel A and B are able to add new articles and to use each other’s articles on their channel.

Step 1

Which content types are available for sharing is set up in Configuration > Channel Configuration on the [Functionalities] tab under "Shared model types". In order to share the Content Repository, select it in the list. For example:

Image Removed

Click [Apply]. The Content Repository is now shared in channel A. For example:

Image Removed

Repeat this step for channel B.

Steps 2 and 3

Sharing and accepting are configured in Configuration > Channel Configuration on the [Sharing/Accepting] tab:

Image Removed

On this tab you have the following fields:

In order to share the Content Repository in this example:

1. Channel A has to share the Content Repository with channel B
2. channel A has to accept the Content Repository from channel B
3. channel B has to share the Content Repository with channel A
4. channel B has to accept the Content Repository from channel A

When this is completed the configuration looks like this:

Channel A

Image Removed

Channel B

Image Removed

Model Types

Below is a list of all model types that can be shared. When there are no comments for a model type the individual items of a model type can be shared. For example, with the queries you can choose on a query level which queries are shared or not.

Back to top

Multiple Channels versus Language Switch

For organizations that publish content in multiple languages you can either use multiple channels or use the language switch functionality available in the Language widget. The pros and cons of both approaches are described in the table below.

...

Language Switch

...

Extra Channels

...

The site structure for all language versions of the channel is the same. Not all pages have to be translated or published.

...

Each channel has its own site structure.

...

Authorization per language is not possible. An editor can edit pages and page sections in all the available languages.

...

Authorization is fully adjustable per channel. Each channel has its own edit environment.

...

All languages use the same presentation.

...

There are many ways to separate the design or share parts of the design between several channels.

...

No additional license required to use multiple languages.

...

An additional license is required for each extra channel.

...

Redirects

Alias redirects route URL requests for nonexistent URLs to a valid target URL. The target URL for an alias redirect can be a page in the current web initiative(s) as well as an external URL. Redirects allow you to use a simple, easy to remember URL to direct users to pages on your website in cases where your tree structure is complicated or the target URL contains a difficult to remember path structure.

URL aliases can only be a single identifier that contains no hierarchical structure. The address of the alias URL is relative to the root URL of your website. For example, if the root of your website is: www.gxsoftware.com, then any alias URL you create can only be reached in a browser via a URL that adds the identifier to the root address, www.gxsoftware.com/<alias> for example, where <alias> is an identifier such as "Products", "Services", "Developer Support" and so forth.

The validity of the string that forms the identifier is dependent on the operating system on which XperienCentral is running. When an alias redirect is created, a new directory is created on the file system of the server in this location: <XperienCentral-root>\webmanager-webapps\webmanager-static-webapp\target\webmanager-static-webapp-xx, where "xx" is the version of XperienCentral you are running. The name of the directory matches the name of the alias that you create. For example, if you create an alias URL named "Products", then you would see the following folder created in the path listed above:


Image Added


The name of the alias URL you create must be a valid directory or folder name for the operating system in which XperienCentral is running.

To create an alias redirect, follow these steps:

1. Navigate to Configuration > Server Configuration.
2. Click [Redirects]. The "Redirects" tab displays:
   
   
   Image Added
   
   
   
3. Click [Add Redirect]. The "Add Redirect" section appears.
   
   Image Added
   
   
4. In the "Name" field enter the internal name of the alias. This name is descriptive and only used to identify the alias URL in XperienCentral.
5. In the "Alias URL" field, enter the string for the alias. The alias can include spaces but no special characters. The string can but does not have to include an extension such as .htm or .html and likewise can be just the alias string or the string preceded by a forward slash (/home for example).
6. To select a page in the current web initiative, click [Choose URL]. The Advanced Search dialog box appears. For example:
   
   
   Image Added
   
   
   
7. Select the page to assign as the target URL and then click [Select].
8. To assign an external address as the target URL, enter the fully qualified address in the "Target URL" box.
9. Set the frameset option. Selecting "Yes" means that the alias URL will appear in the browser's address bar. Selecting "No" means that the target URL will appear in the browser's address bar. For example:
   
   Image Added
   
   
10. Click [Apply]. The redirect is added.
11. Click [Dump now] to complete the operation. For example:
    
    Image Added
    
    
12. Click [Apply]. The alias redirect is added to the list.

Deleting a Redirect

To delete a redirect, follow these steps:

1. Select the checkbox to the left of the redirect that you want to delete.
2. Click [Delete]:
   
   Image Added
   
   The redirect is deleted.

Back to top

...

Dumped Content

In XperienCentral, you can save static versions of dynamic web pages to disk in a process known as "dumping". When you dump a page, a static HTML file containing the page's contents is created. There is a speed advantage for pages that have been dumped because XperienCentral does not have to generate the content for a page when it is requested. You can set how often a static variant of a page should be saved to disk (for instance, once every two minutes). Often the home page of a website is dumped because it is the most visited page and therefore has the highest number of requests. Pages that have been dumped with the extension ".html" are processed by the Apache web server instead of WebManager's server (Tomcat or JBoss):

Image Added

Attention: The extension given to the dumped HTML file should be different from the extension of the friendly URLs. Apache determines, based on a fixed pattern in the URL, where the page data should come from. By default, Apache transfers those URLs beginning with "/web/" or ending with ".htm" directly to XperienCentral's Tomcat or JBoss server. All other URLs are processed by Apache.

For performance reasons, XperienCentral will always use the static variant of a page if one exists. For example, a page with the title "Economy" has the corresponding friendly "Economy.htm" URL and is also dumped to "Economy.html". When "Economy" is requested, XperienCentral will refer to "Economy.html" because it can be loaded faster. Requests to "Economy.htm" will also work but the response could be somewhat slower because the web server has to generate the page.

Dumping Pages to Static HTML Files

To dump a dynamic page in XperienCentral to a static HTML file, follow these steps:

1. Navigate to Configuration > Server Configuration.
2. Click the [Dumped content] tab:
   
   Image Added
   
   
3. In the 'Description' field, enter a description for the page you want to dump.
4. Click [Apply]. Fields for specifying the name of the page and how often it should be dumped appear.
5. In the "Relative URL" field, enter the friendly URL for the page, for example "/GX/Contact.htm". Note: The relative URL that you specify must match the friendly URL listed under "URLs used by active versions" in the "SEO" tab of the (Properties Widget).
6. In the "Filename" field, specify the name of the HTML file.
7. In the time field, enter the number of minutes and seconds after which XperienCentral will create a new static version of the page.
8. Select "Yes" for "Active" if you want the page to be dumped every x minutes and x seconds as specified in the time field. Select "No" if you want to dump the page only one time.
9. Click [Dump now]. The page will be dumped immediately.

Thereafter, the page will be dumped every x minutes and y seconds that you specified if "Active" is set to "Yes". (every 2 minutes in the example below). For each page, the last time the page was dumped is always indicated. For example:

Image Added

Back to top

...

Caching

Caching is essential for high traffic websites. It will handle the load created by many page requests by using an intelligent mechanism that returns pages without having to regenerate them completely. The XperienCentral caching module is also tailored to not interfere with interaction and personalization, therefore visitors to your site will not notice that they are looking at a largely static website.

This topic explains how the Caching tab in the Server Configuration panel works. For a complete discussion of caching in XperienCentral, see the document Caching on the GX Connect website.

Architecture and Overview

Caching occurs in the frontend server processes and has links with JSP rendering [D] and the timestamp table [E], as depicted in the image below. A page request [A] from a website visitor goes through various filters [B] and arrives at the caching module [C].

Image Added

The actions inside the caching module [C] can be summarized as follows (see image below):

The caching module first determines whether a cached file exists of the page request. If the file exists go to [A], otherwise go to [B].

• [A] Get the timestamp of the page (or SSI) by performing a query on the Timestamp database. (Note that the database is not always queried but that the timestamps are also cached in the caching module). The timestamp is compared [Q2] with the date of the file in the cache. If the timestamp is newer then the file is returned [D], otherwise the page has to be rendered (continue at 'If No').
• [B] The page must be (re-)generated. Therefore a request goes from the caching module to the backend servlet to render the page. This takes some time and it's the slowest scenario. After the page has been rendered it is stored as a file in the cache directory [C] and the page is returned.

Image Added

Cache Settings

Under normal conditions, XperienCentral manages the cache when content is changed, added or removed. When an editor adds an element to a page, the timestamp for the page will be set to the current date and time. The next time that the modified page is requested, the caching mechanism will regenerate the page.

There are more complex situations, for example when several page sections are involved or situations where a lot of caching timeouts are set for individual parts of a page or when the load on the server is very high and there's no time to regenerate pages. Content is normally regenerated automatically, however in some situations you do not want to wait until a visitor requests the content, but instead you want to manually force all the content to be regenerated.

Navigate to Configuration > Server Configuration > Caching. The Caching tab appears as follows:

Image Added

For each object type in XperienCentral, the following caching details are shown:

Back to top

...

Updating the Timestamps

To immediately update the timestamps to the current date and time, click the [Update Timestamps] next to the specific content type. When this action is performed, each content item will be regenerated and placed in the cache the next time it is requested. If your website contains a large number of the specific type that you update, use caution because this action could put a large load on the server.

Back to top

...

Updating all Timestamps

To update the timestamps for all content types on your website, click [Update Timestamps] next to "General Timestamp". Updating the timestamps in this manner is a relatively safe action to perform on all environments. After activating the "General Timestamp", requests from the frontend trigger two actions. The first action is that the requested content is directly served from the cache without first being updated. The second action is that the backend is requested to regenerate the content in the background. When this has finished, the cache is updated with the latest version of the content. Back to top

...

Initializing the Cache

Attention: GX highly recommends that you do not use this command on production environments. This command immediately sets the timestamp for all content (pages, articles, database objects, etc). If you have site with a lot of content, this process could take a long time and will put a heavy load on the server. The effect of this is that each request on the frontend may not be served from the cache, which leads to a request on the backend. In most cases, this has a negative impact on the performance of your website(s) and on the XperienCentral Workspace.

Back to top