The OU Campus CMS by default includes a staging server and a production server. The staging server is not public-facing, while the production server is. The staging server can be used to preview content prior to publishing it to a public-facing web site. If Multi-Target Publish has been enabled for the account, alternative publish targets may be configured and if a user is a member of the assigned access group, they may select an alternative server to which to publish.
The staging server is used to store and serve web pages in the editing, workflow, and approval process prior to publishing on the target production server. Remember, when making updates to content within OU Campus and clicking the Save button, the file is only saved on the staging server. The updated content is not viewable on the web until the page is published.
Content on the production server is updated via the staging server. Published pages are transformed with the XSLT engine and the specific XSLs from an implementation and the resultant HTML and/or other page products (such as automatically-generated PDFs) are put on the production server. The staging server is connected to the production server through an FTP connection.
Note: When a file is deleted from the staging server, it is also deleted from the production server and any publish targets. Anytime a file is deleted, it is deleted from all locations.
When Multi-Target Publish in enabled, alternative publish targets may be defined. Access can be configured so that only a specific group of users have access to the server.
For more information, visit the Publish Targets page.
Auxiliary Sites can be configured at the account and site level. They allow for read-only repositories to be created and shared among sites so that a user may access content from an external source (such as images) across many pages.
For more information, visit the Auxiliary Site Selecting page.
With the addition of Binary Management, all content file types are under management of OU Campus on the staging server, unless the feature has been specifically disabled for the site or account by the administrator. Differences when Binary Management is enabled or disabled:
- With Binary Management enabled, new files including images and video are uploaded to the staging server and must then be published to be available on the public-facing web site. Like pages, files are assigned a dependency tag and tracked. Links to those files are updated in a fashion similar to pages under the supervision of the Dependency Manager.
- With Binary Management disabled, files including images and videos are uploaded to the production server or default publish target. Binary files will not be tracked with Dependency Manager.
For more information, visit the Binary Management page.
When Binary Management is enabled, the default for the server drop-down is the production server or the default target. Note that Multi-Target Publish must be in use for an alternative publish target to be defined as the default target. This is also the default for server drop-downs when Binary Management is not enabled. In either case, the server selector drop-down is available within various features:
- WYSIWYG image tool, media tool, and link tool
- Source Editor
- Parameters file choosers
These settings can potentially be overridden by any default image and media paths defined in the site settings or with directory variables.
Server-Side and Client-Side Scripting
In OU Campus, the staging server is physically separate from the production server. Any server-side scripts should be uploaded and/or published to the production server, where they will then execute. When previewing or editing pages on the staging server, OU Campus attempts to render the content in a way that simulates a traditional web server, but without parsing for server-side content. This allows OU Campus to be "server-side agnostic," which allows it to work with all server-side languages. As a result, server-side code will not execute until the page and the script files have been published to production.
In light of this, server-side scripting can be added to a Source Code asset, but it will only execute when the page it's placed on is published to the production server. The contents of the Source Code asset must also not contain any special characters that would cause a transformation error during the XSLT transformation on staging, if the asset is to be used on PCF pages. For these reasons, this method is not highly encouraged unless there is a need to include scripts on a few pages in particular. A better method overall would be to upload the script as a separate file and perform an include via XSL.
Symlinks in Production Environments
OU Campus supports the use of symlinks on a production server. When they are extant, the process that lists files and folder in the view of the production server will skip broken symlinks and continue with the listing. However it is recommended that broken symlinks be updated.