Incremental Publishing Items growing large

Our Incremental publishing has grown over a period of time. Even if we update few items, it publishes over 1000 items. There are many content items like images, autoindexes etc that were not even touched, but do get republished.

Does anyone has any clues on how to resolve this issue?


Manvinder, we have the same issue that I am attempting to resolve. You can try using this JSP page to help with your investigation.

We see similar behavior, where a single content item is updated and 500 items publish. I dug into it a while back and found that the workflow action sys_TouchParentItems is really aggressive in determining what’s related and what needs to have an updated modified date, to put it in the next incremental. We are planning on writing our own version of that workflow action to be more conservative and smarter about the content types, since many of our content types should never trigger all ancestors to re-publish, or many items should never be re-published just because they are ancestores (binaries for example). It would be really nice if we could even determine what changed (if anything) before we touch parent items. Right now just updating a content item, but making no changes, then moving the item back public triggers a re-publish of hundreds of items.

Manvinder: We’re struggling with the same issue as well. I did implement Riley’s JSP page but it doesn’t reflect the volume of items included in every incremental cycle.

I even had a sandbox of our environment where I was the only user logging in. One of my tests involved running a full publish of the entire site (using nt:base), followed by four incremental cycles of an edition that used a JCR query that limited to a single content type. I manually initiated one as soon as the previous finished and I had done a cursory review of the previous job’s pub log. I want to stress that I never navigated away from the Publishing Runtime tab, much less touched a single item of content during this test. Over thousands of items would publish each time, none of which included an auto-index slot. This took about three days to let each job complete.

We’d be interested in any solutions others have found to limit the “depth” or type of ancestors “touched” by changes. TIA – Bernadette

How many items were in full publish, and how many are in incremental?
I resolved my issue as something was wrong in many of the templates that we inherited.