Today I received a question on the newsgroup about what the different steps of the background processing job are doing as this is not properly documented.
Here is the list of all the steps and what they are doing:
Step 1) Process expired postings
This step does what it says: it deletes expired postings. This step is not enabled per default. This allows authors or editors to update the posting and publish it again with updated content if required.
Step 2) Purge content for deleted pages
MCMS stores placeholder content and custom property values in page objects and publishing properties (start date, expiration date, display name) in posting objects.
Connected Postings use the same page object (that’s how the content is shared)
This step will remove the all page objects (including placeholder content, custom property content and resource usage information) and historical revisions of pages that do not have a posting object.
Step 3) Update gallery based resources
This step ensures that attachment and image links to resource gallery items in placeholder content point to the latest revision of a resource gallery item. Historical revisions of the page will still point to the old resource which is still in the database. This step will guarantee that all the placeholder links of the active revision point to the correct content.
Step 4) Purge deleted right groups from container ACLs
MCMS rights groups are assigned to channels, resource galleries and template galleries to implement authorization. When a rights group is deleted then the assignment to the specific container still exists.
This step will remove all the no longer existing rights group assignments from the containers
Step 5) Purge data for deleted resources
Resources, local images and local attachments are stored as so called BLOBs (binary large objects) in the database. When a resource gallery item is deleted or when a page holding a local attachment is deleted then the BLOB of the resource is not removed automatically.
This step will remove all unused BLOBs from the database
My question is related to step 3 above.
I thought that the url to a gallery resource was consistent throughout the lifetime of the resource.
If this is the case, then why would the revisions have to be updated by the background job when a resource gallery resource is updated?
Also, using the Update functionality in resource gallery, does it keep the same resource GUID? I ask because we are experiencing when adding a gallery item to a posting and then updating the gallery item, the posting still points to the old version and we need to delete and add the item to the posting again to see the update.
your impression is wrong. The URL will change and is not necessarily consistant. The number after the GUID will vary depending on the revision.
When I go into the Resource Manager and add a resource, and then click on the Preview Icon, it loads a page where the url contains:
and then if I edit the resource contents and click the replace icon for the resource and replace it, when I click on the Preview Icon it brings up the new version, but the url to the preview is still:
Do the following test:
– add a resource gallery item
– bind it to a posting
– check the URL
– now replace the item
– go to the posting
– check the URL
– now open historical revision
– check the previous revision of the posting
(you will see the old image)
– check the URL to the image
What about where local attachments have been update by users? How do I purge unused local attachements that were not loaded into a resource gallery?
historical revisions of local attachments are bound to historical revisions of postings.
When purging the revision history in Site Manager the historical revisions of postings and local resources bound to these revisions are purged as well.
We have a similar problem in our application where upon updating an XML file in the resource gallery and we try to view a posting that is using the XML file the old version is still being used. We do not directly reference the xml file in the posting. What we do is we just store the XML file location in a placeholder and some backend code opens the XML file and generates a DHTML menu from its contents. The weird thing is it is only happening in one of our servers but for other environments the XML update is reflected immediately. Could this be just a cache setting on the server?