Our system is set up with database publishing. Through the workflow, first we publish to a staging database, and then in a later state to a production database. All of this seems to be working correctly, in that content items are added to and removed from each of the databases when expected.
However, at least when publishing to the staging database, it appears Rhythmyx is not publishing the current version of the content item. This is confusing to our content editors, because they are making changes, but those changes aren’t appearing in the database, even though they do appear correctly in the Content Explorer and in the Rhythmyx repository.
How can we make it so that the latest version of the content item is pushed to the database when publishing?
In anticipating some questions that may be asked:
We are running 6.5.2 with the latest patch
We have a ‘Staging’ Publishable flag that has a value of ‘s’
We have a ‘staging’ item filter that filters on sys_filterByPublishableFlag set to ‘s’
Thank you to anyone who can point me in the right direction to troubleshoot and solve this.
In the interest of adding further information in hopes of getting an answer here, we’ve looked at the Rhythmyx repository database tables, and we have multiple revisions of the same content item, with revision numbers 1-8. 8 appears to be the latest changes, but it seems that 1 is the one getting published. Why would this not be pulling the latest revision when we publish?
There are at least 3 different revisions on an item that are important:
The current revision: this is the revision that was last checked in. In most cases, this is the one that should publish
The “last public” revision: this is the revision that was the current revision the last time that the item ENTERED a public state
The “edit” revision: this is the revision that will be changed when you edit an item.
When an item is checked out, the revision you see in the CX is the “edit” revision.
When an item is in an “ignore” state (which your staging state should be), the publisher publishes the “last public” revision.
In the case of publishing to the Production web site, publishing the last public revision is the correct result, but when you are publishing to staging, you really want the “current” revision, not the “public” one.
To get around this, we added the PSORevisionCorrectingItemFilter to the PSO Toolkit. You pass this item filter a parameter named “workflow_states” which is the comma delimited list of workflow state names where you want the “current” revision published instead of the “last public” revision published.
So, if you haven’t already done this, the first step is to install the PSOToolkit and then configure your content list to use this new filter.
Ok, I can follow that explanation at least, but that brings up a few additional questions…
You said our staging state should be “an ignore state” - why would that be the case? The only state in the workflow that has Publishable set to “Ignore” is the QuickEdit state; is that what you mean by “an ignore state”? Or were you referring to something else?
What is it that updates the “last public revision” to the current revision? Is it transitioning to a state where the Publishable value is set to Public? Or something else?
Yes, the “Quick Edit” state is an example of an ignore state. You will need a separate staging state for items that have been public (at some point in the past) and this state should be an ignore state.
The transition into a public state is what sets the last public revision field.
“You will need a separate staging state for items that have been public (at some point in the past) and this state should be an ignore state.”
Could you explain this a bit further? I’m not following how this would/should work.
What necessitates the separate staging state, and why would I want that to be an ignore state?
If I have a separate staging state, does that also mean I need a separate Publishable flag and item filter, to distinguish between staging-never-been-public versus staging-after-public?
Likewise, if the separate staging state is an “ignore” state, how do I tell the difference between something marked “ignore” that I want to have published to staging, versus something marked “ignore” that I don’t want published to staging? We only want to have content in the staging database while it is in the workflow states where it is being reviewed/approved, not all the time.
Thanks for your help with understanding how all these pieces fit together.