Companies with several business units, websites, brands, and extranets are often looking for ways to centrally manage all their outlets and initiatives from one application or platform. GX WebManager is designed to manage multiple websites and handle multi-channel publishing. It is possible to set up new web initiatives without installing additional hard- and software. In fact, every web initiative is a website with its own page structure and its own edit environment. The added value of multiple web initiatives is the possibility to share and reuse information across multiple web initiatives. Media Repository articles that have been created in one web initiative can be reused in another web initiative. It is possible to specify exactly which functionality and content can be shared between which web initiatives.

This topic describes how to set up extra web initiatives and how to share information between these web initiatives. Furthermore, it explains some additional functionality.

In This Topic

1     Creating a new web initiative

The steps below describe how to extend a GX WebManager installation with an extra web initiative. Some of these steps have to be taken by a system administrator and/or application manager due to some necessary configuration changes.

This document is intended for local environments and development environments. A multiple website setup for production environments can be performed with similar steps, but requires extra configuration of the web server(s) and possibly other software. Procedures for production environments are described in the Linux and Windows installation manuals for production environments.

Þ       Before creating a new web initiative, stop GX WebManager.

1.1   Generate hostnames

To create a second web initiative, two new hostnames are required: the hostname for the public website and the hostname for the editor environment (the generator). In this document www.mysecondsite.com and cms.mysecondsite.com will be used.

Þ       Add these 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.

1.2   Request an updated configuration.xml

The configuration.xml is a file with a license key that also contains the valid hostnames for the installation. To create a new web initiative a new configuration.xml with the two new hostnames is required:

Þ       Send an e‑mail to developersupport@gx.nl to obtain a new configuration.xml. Do not forget to include the two new required hostnames in your e‑mail.

1.3   Update the configuration.xmls

The new configuration.xml file has to be saved in the following locations:

Þ       For local installations created with the .ZIP file:
<GX‑installdir>\webmanager‑webapps\webmanager‑backend‑webapp\target\webmanager‑backend‑webapp‑1.0‑SNAPSHOT\WEB‑INF\siteworks\
AND
<GX‑installdir>\webmanager‑webapps\webmanager‑backend‑webapp\src\main\webapp\WEB-INF\siteworks\

Þ       For local installations created with the .EXE file:
<GX‑installdir>\webmanager\webapps\backend\WEB‑INF\siteworks\

Þ       For production environments (depending on the configuration)
<GX-installdir>/configuration/

Tips:

• Use the search function to locate these folders.
• The right location can always be found in the GX WebManager Setup tool on the tab [General Configuration] search for the setting ‘config_filename’.

1.4   Create a new web initiative in GX WebManager

The steps to create a new web initiative:

Þ       Start GX WebManager.

Þ       Log in to GX WebManager.

Þ       Open the menu Configure > Web Initiative configuration.

Þ       In the pull-down menu ‘Select website’ choose the option ‘<new website>’.

Þ       A new window is opened with four steps to create a new web initiative.

Step 1 of 4: Name the new website

Step 2 of 4: Configuration settings of new website

Step 3 of 4: Create a new website

In step 3 you have to confirm that you want to create a new web initiative by clicking on the [Create website] button and confirming this choice for the second time.

Step 4 of 4: Confirmation

After a successful creation of the new web initiative (step 4) you can exit the wizard by clicking the [Close] button.

After completing the wizard, a new web initiative with one page, the homepage, has been created. You can now log in to the web initiative by accessing the URL by its new hostname (+port number) followed by /web/edit. With the example in this document, that would be http://cms.mysecondsite.com:8080/web/edit.

Note: The homepage of the new web initiative can only be viewed if the status will be set to ‘Published’. Otherwise visitors will see a blank page (in Firefox) or a message that the web page cannot be found (in Internet Explorer).

1.5   Optional: extending the folder structure

The configuration of the new web initiative can be extended or altered to deal with separate files or presentations.

1.5.1    Separating presentations

On large websites with multiple web initiatives it might be necessary to share common resources and (parts of) the presentation. In order to realize this:

• There must be a central folder for the shared files and presentations, for example with the name common.
• Besides the central folder, each web initiative also has its own folders for private files and presentations.

Example of a folder structure in a presentation WCB:

To be able to use this subdivision, some configurations have to be made in the Setup tool:

Þ       In the /web/setup tool, select the [Website specific setting] tab.

Þ       In the first web initiative, navigate to ‘presentation_jsps_url’. Enter the following folders:

1.        /WEB-INF/%PACKAGE%.%WCB NAME%/<dir> (e.g., WEB-INF/project/nl.gx.solutions.userprofileextension/jsp)
2.        /WEB-INF/wm/jsp/ (optional)              

Þ       Click on the ‘Update’ button for this web initiative.

Þ       For each web initiative, repeat the above steps by replacing ‘<dir>’ with the name of the folder in which the web initiative specific JSPs are located.

Explanation: In the /web/setup tool, the descriptor directories are listed in a particular sequence. This sequence also indicates which JSPs are used if there are more JSPs with the same name. For instance, if with above settings, a page.jsp exists in the common folder and a page.jsp exists in the website1 folder, then the page.jsp from the website1 folder will be used.

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

Finally, the uploaded files can be placed in separate folders. With this, the first web initiative can use the standard upload and upload_mm folders. Uploads for the second and subsequent web initiatives can be placed in a separate folder below the main folder.

In the Setup tool, also these paths can be set for each web initiative, on the [General Configuration] tab underneath the Configuration Set Definition “website_settings”, in the fields:

-       ‘file_upload_directory’ and ‘file_upload_url’ (for normal uploads)

-       ‘file_upload_mm_directory’ and ‘file_upload_mm_url’ (for Media Repository uploads)

2     Sharing content

2.1   Introduction

For organizations with several websites 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 web initiative all content is strictly separated. Content sharing is not done automatically. So, if this is wanted then some settings have to be changed. Most of these changes involve assigning different read/write permissions for different web initiatives. Editors of the various web initiatives must explicitly allow one another to read content and to re-use content. With explicitly assigned what to read per web initiative 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 web initiative. When for example an article is created in web initiative A then it can be displayed on web initiative B, but it can never be modified on web initiative B. This is to ensure that the rights of the author remain with the author. When different editors should be allowed to edit content on different web initiatives their user accounts have to be shared as well. Editor X on web initiative A must be shared and granted permission to work on web initiative B as well.

Note: In the following sections, ‘content’ is used in a broader context and is used as a synonym for content types, model types, settings, web users etc. Language labels don't belong to this form of content. Language labels are maintained in a single object pool that is valid for all websites.

2.2   Sharing and accepting

In order to share content between web initiative A and web initiative B the configuration has to be changed to be able to expose (‘Share’) the content of one web initiative with another, but also to receive (‘Accept’) the content from another web initiative.

Sharing content takes place in three steps. For each web initiative, specify the following:

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

Example: articles from the media repository must be shared between web initiative A and web initiative B, and editors on both web initiative A and B should be able to add new articles and to use each other’s articles on their website.

Step 1

Which content types are available for sharing is set up in Configure > Web Initiative configuration > [Functionalities] under ‘Shared model types’. In order to share the Media Repository the ‘Mediabank’ option has to be selected in the ‘Shared model types’ in Web Initiative A. This step must be repeated for web initiative B. You can use the ‘Select website’ dropdown list in the panel to switch to web initiative B.

Step 2 and 3

Sharing and accepting are configured in Configure > Web initiative configuration on the [Sharing / accepting] tab:

Short explanation:

-        Select websites (1): The current web initiative

-        Select websites (2): Filter to show only items of a specific web initiative.

-        Select model type: Filter to show only certain model types.

-        Share: Selection of items that this web initiative offers to other web initiatives; in the above screenshot, the content of the Media Repository (‘Mediabank’) is offered to the other web initiative (which has the name “WI B”).

-        Accept: Selection of items that have been accepted from other web initiatives. In the above screenshot the current web initiative has accepted all content from the Media Repository.

-        Share automatically: If this option is checked all sharable items of the selected model type (that are available) are automatically shared

-        Accept automatically: If this option is checked all sharable items of the selected model type (that are available) are automatically accepted

Note: ‘Share’ and ‘Accept’ do not always contain more items because this cannot always be configured at this level. In that case everything is shared or nothing is shared. Examples are the Media Repository and web users.

In order to share the media repository according to the example:

-       Web initiative A has to share the media repository with B

-       Web initiative A has to accept the media repository from B

-       Web initiative B has to share the media repository with A

-       Web initiative B has to accept the media repository from A

When this is completed the configuration looks like this:

Web initiative A (with the name “MyWeb”):

Web initiative B (with the name “WI B”):

2.3   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.

3     Multiple websites vs language switch

In organizations that publish in several languages the question may arise how to accomplish this. The organization may either use more web initiatives or use the ‘language switch’ functionality. To make this decision for the shorter and longer term, the pros and cons are described below.

For a straightforward one-to-one translation of a website and when the content is translated by the same group of editors the natural choice would be the language switch. In cases where extra functionality is required or per language authorization is required the natural choice would be to set up a separate web initiative and to use sharing and accepting to share content.