I am working on a database publish that is going fairly smoothly, but I’ve run into a hiccup: I need to publish into two separate databases… one for preview, one for production. The production publish is no problem. I am using the “Public” filter and all is well. For the preview database, I am choosing the “Preview” filter, but it is also pulling archived items, which is confusing to the end users… they want to see pending and live content, but shold not see archived content. Is there any way I can create my own Item Filter that properly publishes all items except archived items, and if neccisary can unpublish items that have recently been archived?
You should be able to use the PSItemFilter API to create an item filter Java extension that does everything the preview item filter does with exception to content items marked “archive” (u). Let me know if you need more direction with the Java extension.
You don’t need to use the api you can just create a new item filter within workbench. The key is you want to base this on the preview filter but use the filter by publishing flags extension that is on the public filter. That filter sets the flags as “y,i” to publish only public and quick edit content. You probably want “y,i,n” a is the archive flag.
Thank you for identifying an easier solution. The documentation references sys_filterByPublishableFlag but I was struggling to see where this extension could be used in a new item filter because the documentation doesn’t reference Item Filters located under Assembly Design in Workbench. The Workbench Help Contents has the correct documentation; however, I always forget about this resource and rely on searching through PDFs that I have downloaded. Do you know if the Workbench Help Content is available in a PDF format?
Jason: I realize that you’ve said that the solution, as presented, worked for you. However, you stated that this use case is for a “preview” database. If you only use the sys_filterByPublishableFlag with “y,i,n”, you’ll end up with the PUBLIC_REVISION of the items instead of the EDITREVISION or the CURRENTREVISION.
Background… Every content item has three relevant revisions (found in the CONTENTSTATUS table):
EDITREVISION - If item is being modified and is currently checked out by a user then value is CURRENTREVISION + 1; otherwise, the value is -1.
CURRENTREVISION - If an item is being modified and is currently checked in then the value is greater than the PUBLIC_REVISION; otherwise, the value is equal to the PUBLIC_REVISION.
PUBLIC_REVISION - The revision of the item as it was workflowed into a publishable state (as defined in the workflow).
So a check-out of an item populates the EDITREVISION = CURRENTREVISION + 1.
A check-in of an item sets CURRENTREVISION = EDITREVISION and then sets EDITREVISION = -1.
Workflowing an item to a publishable state sets PUBLIC_REVISION = CURRENTREVISION.
The sys_previewFilter item filter rule used by the preview item filter does something fancy. It modifies the revision of the items in the content list (either for publishing or slot content finders) to correspond to the EDITREVISION or the CURRENTREVISION, whichever is applicable (because an EDITREVISION of -1 would imply that you really want the CURRENTREVISION).
Now, mind you, I’ve only figured this out based on anecdotal evidence: knowledge of the backend tables, reading the API, and a small snippet of the PDF documentation about Item Filters in the Technical Reference. The PDF documentation doesn’t even mention the sys_previewFilter item filter rule. From the IPSItemFilterRule API:
A filter rule defines a single criteria that may be used in an item filter. Each filter rule processes all filter items. Each item will be processed in one of the following three ways:
•If the item is acceptable to the rule, it can be passed without change
•If the item does not meet the rule, it will be not be returned in the output list
•If the item meets the rule, it may require a different revision than the original item specifies. In this case the item is cloned with a different item id.
It’s that last bullet that is the tip-off.
Conclusion: if you want a revision other than the public revision to go into your preview database, then you probably doneed to write a custom item filter rule using the API.
I’m going to test chaining the sys_filterByPublishableFlag (with y,i,n) and the sys_previewFilter item rules to see if that will get the desired effect of publishing the current revision instead of the public revision while omitting “unpublished” content. I’ll report back with results.