Cloud Connected

Requirements for CMS Publishing

What does "publish" mean?

In a CMS, publishing means moving content from a draft state to a published version. It will update the content on the published target(s) with the changes made since the last publish date. This sounds simple enough but the requirements for publishing are usually far more complex and interesting.

What Publishing must do

  1. Publish must work
    Seems like this is stating the obvious but it is critical. Must be able to confidently publish desired content to the right place and at the right time.

  2. Collaboration
    Publishing is usually more than changing the status on content from “draft” to “live” status. Changes to content often need to occur together and therefore get published together. Alternatively some changes are independent of other changes and should be published separately. Supposing you have an update scheduled to occur every hour in a day, e.g., product updates on black Friday. The ability to separate each scheduled release to review, maybe to cancel or update, are all perfectly reasonable requirements. Cloud CMS uses Editorial Tasks (a mini branch) to collaborate on changes, when finished the Editorial Task is published now or in the future. This is a perfect mechanism to collaborate on content and then publish as required.

  3. Related content / Structured Content
    A simple example: edit and publish a news article. The news article also has related content such as images. When publishing the news article any related content should also be published otherwise the article would appear broken on the target. It may be difficult for the editor to know all the related content and could be very difficult as a manual task to determine what needs to be published. In Cloud CMS the relationships are defined in the Content Model. Therefore, when content is published in Cloud CMS, the related content is also published. Note: the publish will only publish content that has been updated and the related content that has not already been published

  4. Scheduling
    Content needs to be published either immediately or at scheduled in the future. This may be a single change, a small group of changes, or a major campaign or launch. Often content need to be published at precise times, prepared in advance, reviewed. With Cloud CMS there are no limitations. You can schedule for any date/time in the future. You can even add your changes in to an existing scheduled release. You can review your scheduled changes and even go back to past scheduled releases to review what was in that release.

  5. Accurate and Timely reporting and status
    When content is published (or scheduled to be published) the editorial team needs to know the status: whether scheduled, or the content is successfully published on the target, or whether there are any errors.

  6. Merge Conflicts
    A Conflict occurs when any two users make changes to the same piece of content such that their changes are incompatible. In Cloud CMS when a user tries to publish the conflicting change, Cloud CMS identifies the issue and asks the editorial team to determine which of the two sets of changes to keep. We also have an option to allow for a merge conflict to always accept the latest change.

  7. Multiple Publishing Targets
    What if you need to publish:

  • different content to different targets?
  • the same content to multiple targets?
  • Large and frequent publishing to various targets.
  • Not all publishes have the same priority Is this a separate paragraph

Cloud CMs publishing let you define deployment targets and then within the project define the publishing strategies. Therefore, the editor can automatically publish to the desired targets without the need to call devops.

  1. Workflow Approval process
    Usually, some level of review and approval is required in a publishing process.
  • Preview changes
  • Track changes
  • Comment of a set of changes
  • Finally, approve or reject (or cancel) With the Cloud CMS publishing Workflow Comments can be added and workflow events defined. Changes can be reviewed at any time and a preview option is available for a branch (in this case either the editorial task or a schedule release are branches so they can be previewed)
  1. Priority of content publishes
    Some content publishes are more critical than others. Eg., news alert that must go out now, a message for the CEO, an external site update is more important than an internal site update. With Cloud CMS we address this issue is a number of ways:
  • Making the publish as efficient as possible
  • Job Bandwidth: reserving bandwidth for certain projects, jobs, users
  • Job Queues: additional queues for certain projects, jobs, users

More information

With Cloud CMS we try provide solutions for now and the future. We do not want you just meeting 60% or less of your requirements or to be limited in your use of the CMS. We want you to meet all your requirements now and in the future. Our Publishing Solution has grown with our experience and our customers feedback. If you want to find out more, demo, request a free trial please contact us at info@cloudcms.com

Coming Soon - Cloud CMS 4.0

We have been working diligently for some time on our new release Cloud CMS 4.0. The release includes enhancements and new features which will allow for a simpler and faster editorial process with more control of the publishing process. Cloud CMS 4.0 has grown into a significant release and in my unbiased opinion looks great. Cloud CMS is designed to scale to meet the ever growing needs of the enterprise with content and publishing reliably to numerous channels.

Starting with a reassurance: Cloud CMS has all the features which are in Cloud CMS 3.2 and more. We have extended Cloud CMS 3.2 which means that existing APIs and scripts will continue to work.

In planning this release the objectives were:

  1. Improve usability
  2. Provide powerful permissions with the new Access Policy feature
  3. Improve performance and add granular scheduling to publishing
  4. Provide accurate and timely reporting on Publishing and the status of published content

What's new

The following enhancements Cloud CMS 4.0 provide robust and powerful solutions for meet your content and publishing needs:

Publishing

With 4.0 we provide the tools to give you confidence that what you publish is on the target(s). This value proposition should not be understated - getting this right is so fundamental for the business.

  • Fast and Efficient: will only publish new content, and updated content, and unpublished related content
  • Can schedule publishing for a single change or multiple changes
  • Accurate content deployment status and reporting

Publishing.png

Look and Feel

The UI in Cloud CMS 4.0 is a much more enjoyable experience. There are many changes providing a crisper UI including fonts, themes, tweaks here and there, and more editorial space where needed.

  • Updated Navigation providing to simplify the editorial process
  • Publish, Edit in Draft, Unpublished buttons have been replaced with Editorial Tasks
  • More space to view and edit content
  • Easy to configure Themes and CSS

UI.png

Access Policies

An easy and powerful way to describe the access control that should be granted. Provides unbounded granular control for all access across all content for all users

Across Projects: Example, create an access policy to grant a user Consumer role for content in Project A and Project B.

By Role or Function: Example, create an access policy to grant editor role for all Spanish content

Access_Policy.png

Editorial Tasks

A lot of ideas came together in Cloud CMS 4.0. A key feature is the Editorial Task. This is a ‘mini’ branch for making your editorial changes (large or small) safely. This enables changes to grouped to together, in a task/unit of work, and then published. Changes can be tracked and reviewed.

Key features

  • Work as a team or individually
  • When finished schedule now or in the future
  • Approval process to review, accept/reject changes
  • Track changes and tasks

Editorial1.png

Editorial2.png

Search

Subtle enhancements have made searching for content easier and faster:

Search Results with highlighted search terms The search term is now highlighted in the search results saving you time to scan through the content types and properties to find exactly where the term is used.

Saved Searches it is easy to build focused and specific searches on your content using the filter options. In addition, you can save these searches for future use and customize the format of the results for reporting. The search results can be easiliy exported to Excel, CSV, ZIP.

Search across Projects More power.. Search across projects at Platform level in the UI or in a single API request. Perhaps to confirm the content is in both Author and Live projects?, or validation required across projects? ..

Search.png

More Information

If you want to find out more, demo, request a free trial please contact us at info@cloudcms.com

Query Performance

Application queries

Application code which consumes Cloud CMS content typically runs query API calls. These queries can be optimized in the following ways:

Request only the properties needed

When an application requires only a few properties from a set of nodes you should use “_fields” to limit the properties returned. This can drastically reduce the size of the payload and therefore the response time. In this example, we only need “_doc”, “title” and “_type” so these are the only fields that will be returned.

let result = await cloudcmsSession.queryNodes(repository, branch, { _type: "custom:blogpost", tags: “tag1”, _fields: { _type: 1, title: 1 } }); Note that “_doc” does not have to be included in the “_fields” list. It is always included by default.

Use indexes

Cloud CMS allows you to create custom indexes on content stored in MongoDB. When you know what the queries used in your application look like you can improve the response to those queries using indexes. Whenever a query is sent to MongoDB it will look for an index that can be used to optimize the query. Create the index by including the properties you use in the select part of the query plus any fields you sort on. Given the query from above, the index could look like this: { “_type”: 1, “tags”: 1 }

  • 1
  • 2