Publishing Targets

Publishing targets define the physical directories to which users publish XML pages and determine if the XML transforms to HTML upon publication.

At minimum, complete the following tasks prior to configuring publishing targets:

• Create a root page to identify the scope of the publishing target.
• Create a home page to identify the publishing target's landing page. See Creating Pages for details.
  Note

  You can use the same page for the root and home page.

Depending on your organization's publishing target needs, you may need to complete other tasks. Optional tasks include:

• If you use more than one publishing target for different site structures, your publishing targets may share similar components. Create a global component set that lives outside of the publishing target roots.
• Configure a user agent and site with or without full MVC support to transform pages via MFO on the server during publish. See MFO, User Agents, and Sites for prerequisite details.
• Create a 404-error handling page. See Creating Pages for Details.
• Configure analytics to track publishing target metrics. See Analytics for details.
• Configure a preview provider for the publishing target to enable users to preview content. See Preview (Optional) for details.
• Configure replication to enable users to perform replication. See Replicating Content for details.

Transform: MFO with User Agents and Sites

Multi-format output (MFO) allows sites to publish content in formats other than XML, with any file extension (.aspx, .php, and .jsp are some common ones). The majority of MFO configuration takes place outside the CMS. A developer ensures the site's stylesheets or views support transforming content to the desired file type, and the administrator configures the CMS to support the file types.

See Working with Multi-Format Output for details to configure MFO.

Each instance of MFO requires a unique user agent and site configuration, which associates a particular file extension with the publishing target.

Analytics (Optional)

Configure Google Analytics to receive publishing target data and statistics. See Analytics for details.

You can use Google Analytics or the sample provider. The sample provider displays pseudo data for demonstration purposes and has no prerequisites.

See Configuring Analytics Settings to add analytics to publishing targets.

Preview (Optional)

Prior to publishing, you may want to preview content via DSS Preview.

See Building MVC Sites for details.

See Preview Tab for details about previewing content.

See In-Context Editing Configuration for details to enable ICE mode in content item Edit tabs.

You may want to preview content on devices (e.g., tablets, mobile phones). See Device Manager for details to add device emulation types and dimensions to publishing targets.

See Configuring Preview Settings to use DSS Preview in publishing targets.

Page Builder (Optional)

Users with permissions can create page builder presentations to associate with publishing targets. See Page Builder Prerequisites for details.

See Configuring Page Builder Settings to set the Presentation Formatter.

File Access for Advanced Replication Target Settings

To configure Advanced Replication Settings, system administrators require access to relevant files.

In a standard CMS installation, the application runs under the Network Service on the CMS server. As such, executables and scripts configured to run as before- or after-replication commands must be granted access for the Network Service account to execute them. A common scenario is to write a script and store the file within the [Drive]:\igxsites folder. Typically, you should give the folder the appropriate rights to the Network Service account to call it from the CMS site. Additionally, you can configure the script file to allow a different user account to execute commands.

Custom Commands

A common scenario that requires appropriate rights to the Network Service account involves writing a batch script and saving the script in a new folder within the [Drive]:\igxsites folder (e.g., Drive:\igxsites\scripts\myscript.bat). If the location has the appropriate rights to the Network Service account, system administrators can call scripts from the CMS site's replication custom commands.

System administrators can use the following scenario steps as a general outline for creating test scripts to run as a pre- or post-replication commands. See Advanced Replication Settings for details to call the test script(s) to custom commands.

Use this scenario to best suit your needs.

To create the custom command test script:

1. Use the following content to create the test batch file:
   
   REM This is a simple test batch file, which just updates a *.txt file with current timestamp. for /F "tokens=2" %%i in ('date /t') do set mydate=%%i set mytime=%time%
   REM Appends datetime to designated file path. File location needs to grant rights to NETWORK SERVICE account. ECHO This script executed at %mydate%:%mytime% >> [Drive]:\[path-to]\ReplicationCommands.txt exit          
               

   Important

   : Change the [Drive] and [path-to] placeholder to an actual absolute path on your server to store the sample .txt file.
2. Save the test script to your scripts folder within the [Drive]:\igxsites location. In this case, the script is called test.bat.
3. Configure the Custom Command fields in the replication target's Advanced Settings.

Conditions to Replicate

System administrators must enable and configure replication targets to copy published files. To perform replication, content must exist in the publishing folder and the publishing target must be published at least once.

Users with permissions to publish can replicate content. Administrators can perform manual replications to copy files without publishing.

Conditions to Publish

Group members must have access to the publishing target and permissions to perform publishing actions. Content items must meet the following conditions to be published to publishing targets.

Content items must be:

• checked in to a publishing target.
• marked for publish to a publishing target.

Users with permissions can publish content via the following methods:

• Publishing within Administration (administrators only)
• Publishing within Site
• Publishing within Assets

Publishing Profiles

Publishing Profiles group publishing targets into single profiles. By using single profiles, the page updates in one macrosite and synchronizes those pages that are lingually mapped in other sites.

Creating publishing profiles requires a publishing target to reference. See Publishing Targets for details.

Publishing Permissions

Publishing System Permissions

Only Ingeniux CMS administrators have permissions in Publishing System. Site administrators can add users to the CMS default Administrators group or create a new group with administrator permissions selected. No one can modify the permissions in the default Administrators group.

See Creating Groups for details to set permissions for users and groups. To grant administrator permissions to a user group, select the following permission:

• Allowed to have system administrator privileges & change all system settingsEnables group members to modify and configure all site-specific settings such as adding users, user groups, creating workflows, etc. This permission item is in the Miscellaneous block.
  Note

  Selecting this permission enables all CMS permissions. To limit individual permissions, clear this checkbox.

Publishing Content Items and Publishing Monitor Permissions

User groups require permissions to prepare content for publishing. See Creating Groups for details to set permissions.

Users require the following permissions to perform publishing operations and access Administration > Publishing Monitor:

Permissions on page manipulations: Assigns or removes the following block of permissions related to modifying pages.

• Allowed to check-in pages assigned to others: Enables group members to check in pages that are currently assigned to another user.
• Allowed to assign pages not assigned to them to others: Enables group members to assign pages to other users, even though these pages are not currently assigned to the group members.
• Allowed to check-in and check-out pages outside of workflow: Enables group members to check in or check out pages that are not a part of a workflow. Groups with this permission can also check in or check out pages inside a workflow.

Permissions on asset manipulations: Assigns or removes the following block of permissions related to asset manipulations.

• Allowed to work with asset system: When selected, group members can access the assets manager.
• Allowed to check in assets and asset folders assigned to others: When selected, group members can check in assets and asset folders that are assigned to other users.
• Allowed to assign assets and asset folders assigned to others: When selected, group members can assign assets and asset folders to other users.
• Allowed to check in/check out assets and asset folders: When selected, group members can check in and check out assets and their folders.

Permissions on publishing: Assigns or removes the following block of permissions related to publishing site content.

• Allowed to mark and unmark pages for publishing: Enables group members to mark and unmark pages to be published.
• Allowed to execute a full publish: Enables group members to execute full publishes including a site publish.
• Allowed to execute an incremental publish: Enables group members to execute incremental publishes.
• Allowed to repeat a publish to the same root page and publishing target: Enables group members to repeat a publish request before a previous, identical publish completes.

Permissions on publishing of assets: Assigns or removes the following block of permissions related to publishing assets.

• Allowed to mark and unmark assets for publishing: When selected, group users can mark and unmark assets for publishing.
• Allowed to publish assets only: When selected, group users can publish assets without their associated pages or components.

Content and Asset Item Manipulation Permissions

Other permissions to edit items in the Site Tree and Assets Tree may benefit users who publish content. See for details about all permissions. Choose permissions that best meet each group's needs.

Permissions on page manipulations: Assigns or removes the following block of permissions related to modifying pages.

• Allowed to edit pages: Enables group members to edit existing pages assigned to the current user.
• Allowed to delete pages: Enables group members to delete pages.
• Allowed to check-in pages assigned to others: Enables group members to check in pages currently assigned to another user.
• Allowed to rollback changes: Enables group members to roll back to a prior version of the page.
• Allowed to assign pages not assigned to them to others: Enables group members to assign pages to other users, even though these pages are not currently assigned to the group members.
• Allowed to create pages: Enables group members to create a new page via page creation rules or page types, depending upon which additional permissions are selected.
• Allowed to create new pages using page types: Enables group members to create new pages by specifying the page type (as opposed to using page creation rules).
• Allowed to check-in and check-out pages outside of workflow: Enables group members to check in or check out pages that are not part of a workflow. Groups with this permission can check in or check out pages inside a workflow.

Permissions on asset content viewing and manipulations: Assigns or removes the following block of permissions related to viewing and modifying assets. Allowed to edit asset file content: Enables group members to edit assets such as text files, XML files, code, etc. Allowed to see asset history: Enables group members to view asset history.

Permissions on asset manipulations: Assigns or removes the following block of permissions related to asset manipulations.

• Allowed to work with asset system: Enables group members to access the Assets Manager.
• Allowed to edit asset metadata: Enables group members to edit metadata in the Assets Manager.
• Allowed to delete assets: Enables group members to delete assets from the Assets Manager.
• Allowed to check in assets and asset folders assigned to others: Enables group members to check in assets and asset folders assigned to other users.
• Allowed to rollback assets: Enables group members to rollback assets.
• Allowed to assign assets and asset folders assigned to others: Enables group members to assign assets and asset folders to other users.
• Allowed to create assets: Enables group members to create assets.
• Allowed to check in/check out assets and asset folders: Enables group members to check in and check out assets and their folders.

Permissions on page content viewing and manipulations: Assigns or removes the following block of permissions related to viewing and modifying pages.

• Allowed to edit the layout attribute on pages: Enables group members to change the default style sheet applied to the current page.
• Allowed to edit password elements: Enables group members to edit password elements.
• Allowed to view elements marked as "hidden" in Edit Form: Enables group members to view hidden elements in the Edit form.
• Allowed to add words to dictionary during spellcheck: Enables group members to add words to the default dictionary during a spell check.
• Allowed to see Edit Form for page edit: Enables group members to access the Edit form.
• Allowed to see page history: Enables group members to see the page's workflow history information.
• Allowed to view XML tab: Enables group members to access the XML tab in order to review XML corresponding to a specific page or component.
• Allowed to embed and unembed component fields: Enables group members to embed components within components.