Percussion CMS Version 4.1 Release Notes

Enhancements

Workflow Comments

The objective of Percussion's workflow capabilities is to allow organizations to create a governance process that ensures quality while minimizing the time and effort needed to review and approve content. One of the difficulties in that process was in letting approvers know what had changed when a page was edited or in letting a content contributor know what was wrong in the event that a submitted page was rejected. In 4.1, we have delivered Workflow Comments which allow users to include a description of the changes they made or feedback they want to provide as part of the process of submitting content through the workflow. Users are prompted to submit a comment when they go to submit, approve or reject content. Users then see the comment at the next step of the workflow and a full history of comments can be viewed showing who made the comment, when and at what step of the workflow.

Viewing Workflow Comments

Incremental Publishing

For customers that are rapidly developing new content, having to choose between the Publish Now feature and a full publish to get content to the website was a difficult choice. Incremental publishing provides the ability to publish only that content that has changed since the last publish. This should minimize the time it takes to get content to the website while still ensuring content goes through the full workflow for review and approval. As pages, shared assets, or template content is modified and approved, the pages impacted by the changes are queued for incremental publishing. Those items can then be published without needing to publish the rest of the site. The administrator has the ability to review the list of pages prior to publish in order to validate that the right items are in the queue.

It is important to note that theme files are always published as part of an incremental publish. However, changes to theme files do not cause pages to be queued for incremental publish.

There are still circumstances in which a full publish is needed.

Folder path changes or navigation changes do not queue items for incremental publish
Changes to page name require a full publish in order to update links pointing to the changed page.
If a shared image asset is inserted into a rich text asset/widget, and then the image is updated, the rich text asset and pages using it are not queued for incremental publish.
Changes to image and file assets will not queue pages with autolists that would select these assets. These auto-list widgets are not dynamic, so they will not update until the page is published.
Changes to template layout or style will not queue pages using the template. However, if edits are made to template content, then the pages will be queued
Archiving or deleting items require a full publish.

Incremental publishing will be disabled for a pub server until a “Full publish” is run in the following cases:

A new pub server
A pub server updated to point to a new filesystem destination
Existing pub servers after an upgrade

Items scheduled for a future date will not be queued for incremental, and if an item is in the queue, it will be removed when a page/resource is scheduled.

Publishing a Site

Customer Incidents

The following customer incidents were addressed in 4.1:

If a given page had multiple auto-lists, there was unexpected behavior. This has been resolved to properly display each auto-list.
There was an indentation present before the doctype tag in pages generated by Percussion. This can cause issues with the rendering of pages and triggering of quirks mode in some IE browsers. This has been resolved.
The Roles tab on the Workflow page was not rendering if a large number of users (~6000) was loaded in to the system. This has been resolved.
Release 4.0 introduced regressions in supporting certain types of SFTP publishing. This has been resolved.
Upgrade was not properly updating Percussion javascript files that are used by published sites. The installer has been modified to upgrade these files.
LiveFirst Import was preventing the Percussion service from being shut down. This has been modified so that shutting down the service interrupts import and shuts down.
Users may now use a iframe to embed YouTube videos (and other content) in a Rich Text Asset.
If users were using a wildcard search when adding users via LDAP, this was causing an error. This has been resolved.
If a template had a navigation widget, and the widget was later removed, the published pages using that widget still contained references to javascript files specific to navigation. This has been addressed.
When creating a form, the form field name is no longer used to auto-generate a class for the form field. Instead the class is left blank unless populated by the user.
The login page was displaying a error message if a user tried to access the system using IE11. Now the user will see a message that IE11 is an unsupported browser. The log has also been updated to show a warning message when someone attempts to log in using IE11.

Known Issues

The issues below were reported too late to be able to be fixed in 4.1. These are under investigation and will be addressed in a future release.

It is not recommended that you use the Copy Site feature. Copy Site has caused issues where relationships between objects (such as pages and templates) are not copied correctly.
If you delete a site that has previously been published and then create a site with the same name, there may be stale page metadata entries that remain indexed within the DTS database. This issue can be corrected by removing the stale entries from the DTS database manually. Please reach out to Customer Success for more information on how to accomplish this.
There is an Internet Explorer specific issue within the Percussion UI when using the older YouTube embed code. The embedded video will display on top of the Rich text widget dialog within edit mode. We recommend updating the code to use the iframe element that YouTube currently provides. This behavior is not present when using Chrome or Firefox.
When setting a different publishing server as the default, incremental publishes may not complete correctly if there are items present in the incremental publishing queue. As a best practice, running a full publish prior to switching the default publishing server will ensure the incremental queue is cleared.
The What’s Working and Traffic gadgets are experiencing unusual slowness when using Internet Explorer 9. This behavior is not present in Chrome, Firefox or Internet Explorer 8
When creating or editing a publishing server definition, if there are errors in the configuration (for example server path name, port number, etc.), a generic error will display “Unable to publish the server [Server name]”. To correct this, verify your configuration settings.