Cascade CMS 8.15

Features/Improvements

• To help you keep track of your edits, when previewing an asset we'll show you your Draft or Working Copy by default if you have one. If your Draft is out of date with the current version, we'll let you know in the preview header.
• To help prevent system instability, the max upload limit system preference is restricted to no more than 512MB for individual file uploads. Site imports via file upload and zip files being unpacked are restricted to 2GB, based on browser limitations. In addition, changing the max upload limit system preference no longer requires a restart.
• You can now create deep links to various asset actions by adding an action URL parameter to a Cascade CMS asset link. Example: Create “quick edit” links for pages with /entity/open.act?id=...&type=page&action=edit.
• The Siteimprove integration can now be enabled/disabled for individual Sites.
• A new Site Role ability has been added to restrict the visibility of the Siteimprove integration.
• To help prevent out of date files being left on your web servers, content will be unpublished by default from all enabled Destinations and Outputs during move, rename, and delete operations. The Unpublish option enabled by default when moving or deleting assets user preference has also been removed.
• Native image file metadata will now be preserved when PNG images are modified using the image editor.
• This release contains an upgrade to Tomcat 9.0.33 and the AJP Connector has been disabled by default in all installers in order to mitigate the CVE-2020-1938 (Ghostcat) vulnerability. (See Upgrade Guide for details.)
• Oracle versions 18c/19c are now supported. Support for 11g will be removed in the next on-premise release on or after 01/01/2021.

Fixed

• Addressed an issue where using the Compare to Current function would result in a StackOverflowError in some cases.
• Assets on the My Content screen and dashboard widget are now sorted consistently: Drafts and Owned Content are now sorted by last modified date and Locked Assets are now sorted by lock date.
• Errors encountered during Accessibility content checks will no longer prevent users from submitting their changes.
• Content Type Publish Sets will now be included in the automatic publish of a Page on its Start Date.
• Publish Sets associated with previous versions of a Content Type can now be deleted without error.
• Viewing previous versions of a Content Type associated with a Publish Set will now display the appropriate Publish Set instead of "None".
• To prevent issues, multiple parallel submissions of the same form will now be prevented.
• Log files will no longer contain warnings about a missing resources.customer resource file.
•   It is once again possible to filter page-level WCAG accessibility issues by compliance level.
• Previous versions of a Content Type can now be deleted.
• Recurring reviews for assets will no longer be automatically rescheduled if the asset has not been marked as reviewed by its Review Date. Subsequent Review Dates will now be scheduled when the asset is marked as reviewed or when its review workflow is complete.
• Addressed errors when deleting users associated with locked assets and/or in-progress workflows.
• Items will no longer appear partially cut off when users scroll to the bottom of the Sites, Add Content, and type-ahead Search flyout panels.
• Existing data in a field will now attempt to be mapped if a Data Definition field's field-id is changed.
• WYSIWYG fields will no longer display the Clive controls when the Clive integration is disabled.
• Users will no longer be able to switch sites when choosing or uploading assets if a chooser or WYSIWYG is restricted to a site's base folder.
• Activating a previous version of a Data Definition will no longer break relationships between the Data Definition and Shared Fields or WYSIWYG Editor Configurations.
• Shared Fields will no longer be stripped from Data Definitions if the field can't be found, for example, due to a mistyped path.

• Updates to Tomcat and AJP Connector
• First time installation?
• Upgrade Steps
• Which installer should I use?

Updates to Tomcat and AJP Connector

In order to mitigate the CVE-2020-1938 (Ghostcat) vulnerability, Cascade CMS version 8.15 contains an upgrade to Tomcat 9.0.33 and therefore a full installation is required.

In addition, the AJP Connector will be disabled by default in all 8.15 installers. Previously bundled versions of Tomcat included an AJP Connector which was configured to listen on port 8009 across all IP addresses.

The Tomcat 9.0.33 upgrade requires an additional adjustment to the AJP Connector when using custom authentication with Cascade CMS, specifically Shibboleth authentication.

In addition to the existing attributes generally used in the AJP Connector, the following attributes must be added to the connector:

• allowedRequestAttributesPattern=".*"
• secretRequired="false"

Failure to do so may result in Tomcat returning a 403 error when the user is redirected back to Cascade CMS from the identity provider. More information about these attribute changes can be found in Apache's Tomcat documentation.

First time installation?

Be sure to import our default database schema prior to installing Cascade CMS for the first time. Then follow the appropriate installation instructions for your environment.

Upgrade Steps

1. Shut down your currently running Cascade CMS environment.
2. Before you upgrade, we strongly recommend that you back-up your production database as well as set up a test environment and perform a trial run of the upgrade. All customers are entitled to a test license for this purpose.
3. Read the release notes and upgrade guides for all releases between your version and the latest version.
4. Check the table below to see which installer type is required.

Which installer should I use?

With certain upgrade paths, a full installation of Cascade CMS is required in order to ensure that the application has the latest required libraries. See the table below for a summary of which installer you should use based on the version from which you are upgrading. For any versions that do not require a full installation, using the ROOT.war upgrade method is allowed.