Anchor | ||||
---|---|---|---|---|
|
Companies Entities with several business units, websiteschannels, brands, and extranets are often looking for ways want to centrally manage all their outlets and initiatives from one application or platform. XperienCentral is designed to manage multiple websites channels and handle multi-channel publishing. It is possible to set up new web initiatives channels without installing additional hard- hardware and/or software. In fact, every web initiative is a website with Every channel has its own page structure and its own edit Workspace environment. The added value of multiple web initiatives channels is the possibility to share and reuse information across multiple web initiatives. Media Repository articles those channels. Content Repository items that have been created in one web initiative channel can be reused in another web initiativechannel. It is possible to specify exactly which functionality and content can be shared between which web initiativeschannels.
This topic describes how to set up extra web initiatives channels and how to share information between these web initiatives. Furthermore, it explains channels as well as some additional functionality.
In This Topic
Table of Contents | ||||
---|---|---|---|---|
|
Creating a New Web Initiative
The steps below describe how to extend a XperienCentral installation with an extra web initiative. Some of these steps Some of the tasks have to be taken performed by a system administrator and/or application manager due to some necessary core configuration changes. This topic describes both local and development environments. A multiple website channel setup for production environments can be configured in a similar way, but it does require extra configuration of changes to the web server(s) and possibly other software. Procedures for production environments are described in the Linux and Windows installation manuals topics for production environments.
Before creating a new web initiativechannel, stop XperienCentral (the web server).
In This Topic
Table of Contents | ||||
---|---|---|---|---|
|
...
Generate New Hostnames
To create a second web initiativechannel, two new hostnames are required: the hostname for the public website channel and the hostname for the editor Workspacer environment (the generator). In this document www.mysecondsite.com
and cms.mysecondsite.com
will be used as examples.
Þ Add these the new hostnames to your ‘hosts’ "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 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 the your installation. To create a new web initiative channel, a new configuration.xml
with containing the two new hostnames is required :
Þ - Send an e‑mail to developersupport@gx.nl developersupport@gxsoftware.com or contact your GX Software consultant in order to obtain a new configuration.xml
. Do If you send an e-mail, do not forget to include the two new required hostnames in
Update your
...
configuration.
...
1.3 Update the configuration.xmls
...
xml
The new configuration.xml
file that you receive from GX Software has to be saved in the following locations:
Þ For local installations created with the .ZIP file:
<GX‑installdir>\XperienCentral‑webapps\XperienCentral‑backend‑webapp <xperiencentral-root>\webmanager‑webapps\webmanager‑backend‑webapp\target\
XperienCentral‑backend‑webapp‑1webmanager‑backend‑webapp‑1.0‑SNAPSHOT\WEB‑INF\siteworks\
AND
and
<GX‑installdir>\XperienCentral‑webapps\XperienCentral‑backend‑webapp <xperiencentral-root>\webmanager-webapps\webmanager‑backend‑webapp\src\main\webapp\WEB-INF\siteworks\
Þ For local installations created with the .EXE file:
<GX‑installdir>\XperienCentral\webapps\backend\WEB‑INF\siteworks\
Þ For production For production environments (depending on the configuration):
<GX <xperiencentral-
installdir>root>/configuration/
Tips:
...
...
Tip |
---|
The correct location for the |
...
Tool on the |
...
General tab (the setting |
...
|
...
|
...
...
Create a New Channel in XperienCentral
The steps to To create a new web initiative:
Þ Start XperienCentral.
Þ Log in to XperienCentral.
Þ Open the menu Configure > Web Initiative configuration.
Þ In the new channel in XperienCentral, follow these steps:
- Start XperienCentral and log in.
- Navigate to Configure > Channel Configuration.
- Select "<new channel>" from the pull-down menu
...
Þ A new window is opened with four steps to create a new web initiative.
Step 1 of 4: Name the new website
...
Fields
...
Description
Name
...
- at the top of the panel, The New Channel wizard appears.
Step 1: Name the New Channel
Configure the following fields:
Setting | Description |
---|---|
Name | The name of the new |
channel. |
Identifier |
The identifier of the new |
channel. |
Based on |
channel |
Choose a |
channel here if all the parameters are similar to those of an existing |
channel. We recommend that you base the new |
channel on an existing |
channel because all the configuration settings (such as paths) will be duplicated. |
...
Step 2 of 4: Configuration settings of new website
Settings for the New Channel
Configure the following fields:
Fields | Description |
Hostname |
Choose the
The hostname of the public |
channel. |
Generator |
The hostname of the |
Workspace environment. |
Default e-mail address |
Default
The default e-mail address for functionality |
that makes use of e-mail messages. |
Folder for uploads |
The folder where uploaded files are stored. |
Upload URL |
Base URL of the
The base URL for uploaded files |
Folder for multimedia uploads |
Base
The folder where binary files are stored. |
Multimedia Upload URL |
The fase URL of the uploaded binary files. |
Descriptor folders |
Presentation
The folders where the presentation JSPs are stored |
. A scheduled task scans these folders for descriptor files. Multiple folders can be specified separated by semicolons. |
Redirect base directory |
The base folder of the static files. |
...
Note |
---|
The settings above can be modified in the General (R30 and older) tab of the Setup Tool after the channel has been created. |
Step 3 of 4: Create a new website
the New Channel
In step 3 you have to confirm that you want to create a new web initiative by clicking on the channel. Click [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 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 web initiative channel by accessing the URL by its new hostname (+port number) followed by /web/edit
. With Following the example in this documenttopic, that would be URL is 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).
...
Note |
---|
By default, the home page of the new channel is not in the published state, therefore visitors who navigate to the frontend of that channel will see a blank page until you publish it. |
...
Extending the Folder Structure (Optional)
The configuration of the new web initiative channel can be extended or altered to deal with 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, for example with the name common.
- Besides the central folder, each web initiative channel also has its own folders for private files and presentations.
Example The following is an example of a folder structure in a presentation WCBplugin:
Code Block |
---|
...
|
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:
- /WEB-INF/%PACKAGE%.%WCB NAME%/<dir> (e.g., WEB-INF/project/nl.gx.solutions.userprofileextension/jsp)
- /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:
- Which content types are available for sharing
- Which content should be shared with which other web initiative(s)
- 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”):
...
| |
<plugin 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.
- For the first channel, enter the following folders for the setting
presentation_jsps_url
:/WEB-INF/%PACKAGE%.%WCB NAME%/<dir>
(WEB-INF/project/nl.gx.solutions.userprofileextension/jsp
, for example) where<dir>
is the name of the folder where the channel-specific JSPs are located./WEB-INF/wm/jsp/
(optional) - Click [Save Changes].
- Repeat the above steps for each channel.
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:
Code Block | ||
---|---|---|
| ||
…/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:
Code Block | ||
---|---|---|
| ||
backend/
/upload/ for the first channel
/upload_mm/ for the first channel
/mysecondsite/upload/ for the second channel
/mysecondsite/upload_mm/ for the second channel
|
These paths can be set for each channel using the following settings:
file_upload_directory
andfile_upload_url
(for normal uploads)file_upload_mm_directory
andfile_upload_mm_url
(for Content Repository uploads)
...
Anchor | ||||
---|---|---|---|---|
|
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 reuse it in 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 you have to configure it. Most of these configuration properties involve assigning different read/write permissions for different channels. Editors of the various channels must explicitly allow one another to read and reuse content. By explicitly specifying what can be read per channel, everything can be set up in a safe and flexible manner.
An important feature of shared content is that it 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.
Note |
---|
In the following sections, the term "content" is used in a broader context and should be regarded as a synonym for regular 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 channels (see Language Labels). |
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:
- Which content is available for sharing.
- Which content should be shared with which other channel(s).
- 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 configured 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:
Click [Apply]. The Content Repository is now shared in channel A. For example:
Repeat this step for channel B.
Steps 2 and 3
Sharing and accepting are configured in Configuration > Channel Configuration on the [Sharing/Accepting] tab:
On this tab you have the following fields:
Field | Description |
(Filter block) Select channel | Select a channel to configure. |
(Filter block) Select model type | Filter to show only specific model types. |
(Share settings) Share | Select the models that you want to share. |
(Accept settings) Accept | Select the models that you want to accept from the other channel. |
Share automatically | If this option is selected, all sharable items of the selected model type (that are available) are automatically shared |
Accept automatically | If this option is selected, all sharable items of the selected model type (that are available) are automatically accepted |
In order to share the Content Repository in this example:
- Channel A has to share the Content Repository with Channel B
- Channel A has to accept the Content Repository from Channel B
- Channel B has to share the Content Repository with Channel A
- Channel B has to accept the Content Repository from Channel A
When this is completed the configuration looks like this:
Channel A
Channel B
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.
Model |
Type | Comment |
Application integration: filter definitions |
Applications |
Applications
Content Repository | The entire Content Repository is always shared and not individual content types. |
Form resources | Form resources and form |
Forms
steps |
Form models |
Form rules (all handlers) |
User groups
Forms | |
Languages | |
Page section labels |
Always the entire media repository, no individual media items
Personalization | Both personalization expressions as well as personalization |
Presentations
Note: only presentations and no presentation variants
Queries
Frameworks
Style cluster
Style properties
Frames
Languages
Frames
models | |
Presentations | Only presentations and no presentation variants |
Queries | |
User groups | |
Web users |
All web users |
are always shared and not individual web users. |
...
3 Multiple websites vs language switch
...
...
Multiple Channels versus Language Switch
For organizations that publish content in several languages the question may arise how to accomplish this. The organization may either use more web initiatives multiple languages you can either use multiple channels or use the ‘language switch’ functionality. To make this decision for the shorter and longer term, the language switch functionality available in the Language Widget. The pros and cons are described below.
...
Language switch
...
of both approaches are described in the table below.
Info |
---|
See Working with Language Versions in XperienCentral if you want to maintain multiple language versions of your channel(s). |
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 content 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 |
License is part of the ‘Versioning’ component.
between several channels. | |
No additional license is required to maintain multiple language versions of your channel(s), however it does require extra development work. | An additional license is required for each extra |
channel. |
For a straightforward one-to-one translation of a website channel 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 for each language, then you probably want to set up a separate web initiative channel and to use sharing and accepting to share content.
...