We have a discrepancy in our development and production content servers (11g) in the
way that expired content is automatically handled.
– In dev, the original file is deleted and replaced with a file of the same
name, except with a “~1” appended to the end of the web location. The original
file is no longer available from it’s original web location.
– In production, the same process occurs, but the original file is still
accessible via the original web location, which indicates it was not deleted.
It’s been a struggle to track down the source of this configuration. Is this an
out-of-the-box feature, or does this have to be configured on it’s own?
Yes, this functionality is the out-of-the-box feature.
By default each content item’s revision has meta-field ‘Expiration Date’ which defines when expiration will occur.
Expired content revisions are marked correspondingly in the database (revisions.dstatus=’EXPIRED’) thus they will not be accessible in application via search, but can still be found by administrator (Content Management -> Expired Content).
Expired revision files are not deleted from weblayout, but renamed instead as not latest revisions – marked with ~{number} postfix.
Expired revision files are neither deleted from vault nor renamed.
Lets say we have 2 revisions (dID=31026 and dID=31025) of a picture 009139 (dDocName=009139). Both revisions are expired. In this case:
Regarding your issue with prod – make sure you had no further revisions after the expired one (in this case this revision will be, of course, available)