How to unpublish content – Cloud CMS Support

Cloud CMS provides a range of options for making content available to your presentation tier. The most common scenarios are:

1) Use the Publishing setup within Cloud CMS; Workflow, Lifecycle states, deployment configurations. https://www.cloudcms.com/documentation/welcome/publishing.html

With Publishing Enabled for a project, there are 2 simple workflows: `simple publish` and `simple unpublish`. See the Publishing example for further details: https://www.cloudcms.com/documentation/publishing/example-setup.html

2) Use an attribute on your Type

Quick and easy to implement. Just add an attribute to mark instances as published by defining within the type's JSON:

“published”: { 
"type": "boolean", 
"title": "Published?” 
}

You can then filter out items where this value is False.

3) Create a Feature for consistency

Of course, if you have several content Types, you'll want to avoid re-defining the same publishing attribute over-and-over. When such a shared element occurs, it's a great case for taking advantage of a Feature. Start with moving the field into its own segment by accessing:

Definitions > My Definitions > Create Definition > Feature Type

and adding the exact same value to its JSON settings, such as:

"properties": { 
“published”: { 
"type": "boolean", 
"title": "Published?” 
} 
}

Now you can apply this to any existing types as needed by updating their JSON to include:

"type": "object", 
"mandatoryFeatures": {
"your: QNameforFeature": {
"enabled": true
}

which adds the attribute onto the receiving definition's graph. In addition, any future changes to it are propagated too.

Let's say we now want to move from a simple boolean to a date range. Go ahead and update the Feature to have:

"properties": { 
"Start": { 
"type": "number", 
"format": "date", 
"readonly": false 
}, "End": { 
"type": "number", 
"format": "date", 
"readonly": false 
} 
}

and see every type using it reflect the change immediately - without any server restarts. Provides for a smooth content model evolution.

4) Leverage Branching to create a complete “time slice”

If you need frequent snapshots or require coordination across different pieces of content, you can tag any tip change set as an Edition / Release, to mark a full “time slice” of the repository. This also enables you to flip between the underlying branch IDs as needed (i.e. un/publish).

Branches let you coordinate full release sets of content all at once. A branch is similar to a GitHub branch in that you get an entire new copy of the content set where many different changes can be made. Scheduled releases let you specify when a branch "goes live". Going live means that it will be served by default from the API but also means that you may fire out to external hooks (for things like CDN invalidation and other activities that occur as part of your release process).

Articles in this section