We have an issue whereby our smart publish is wiping the web database when publish related items is checked and publish children is checked.

We have copy text components folder that is referenced in many pages, publishing this folder physically removes the pages from the web database??

I have disabled deep scan publishing for related items but this issue persists.

        This setting specifies that all the subitems of the item being published are 
        scanned recursively for changes and that all the changed items are published.
        Default vaue: true
<setting name="Publishing.DeepScanRelatedItems" value="false" patch:source="Publishing.config"/>

Surely a content editor publishing a copy text folder should not result in actual pages being removed before they are updated?

I can either wait for the publish to finish and have the website's offline - not acceptable, or I am forced to restart CM server and rollback the web database to before the publish operation was triggered. What gives?

444768 14:00:00 INFO [PublishOptions]: root:{AE79738A-1682-4CD2-9615-FD37E6D19B9B}, language:en, targets:Internet, database:web, mode:SingleItem, smart:True children:True, related:True
447740 14:00:01 WARN DeepItemPublish detected. PublishContext was overridden with DisableDatabaseCaches=True.
447740 14:00:01 INFO Starting [Publishing] - AddItemsToQueue
  • Can you confirm what version of sitecore you are running on? Also have you recently upgraded and ran the update tool? Dec 15, 2022 at 15:09
  • We're on 10.1 and have not ran an update tool @DeanOBrien
    – Sean T
    Dec 15, 2022 at 15:28
  • If you are have upgraded from 7.2=>10.1 then the upgrade guide states you should run the sitecore.update tool. Reason being it cleans up sql items that have been replaced by .dat items on disk. Adding answer just in case it helps you or someone else in similar situation Dec 15, 2022 at 15:59

2 Answers 2


Adding an answer, as this sounds very similar to a situation we faced, whereby a seemingly isolated publish (with related items) of an item led to all nodes under sitecore/content being deleted from all publishing targets.

Sitecore.Update tool

If upgrading to Sitecore 10+ from a lower version, one of the required steps in the upgrade guide is to run the Sitecore.Update tool. The reason for this is because from sitecore 10 onwards, all the important central sitecore items for core, master, web databases are stored in .dat files on disk. Because of this, the tool must be run to remove these items from the relevant databases. They are then read from disk instead of SQL.

If an item has been modified in anyway, then it is up to the person performing the upgrade to review the item, delete manually from database and then reapply the modification via sitecore UI if required. This process ensures that the most up-to-date items are used.

You can find the upgrade guide on the following page: https://dev.sitecore.net/Downloads/Sitecore_Experience_Platform/101/Sitecore_Experience_Platform_101.aspx

Our issue

When performing the above steps, it is essential that you apply the changes / deletions on all publishing targets. The issue we faced was sitecore/content or other top level items had been modified, so we deleted them from SQL (choosing not to reapply the changes). However, we did not perform the steps on two publishing targets.

Some weeks later, a publish was performed with related items checked. When publishing related items, a chain event is started, with any referenced item also being published, which can grow to a very large number of items. In our case, this also included the root sitecore/content.

At this point, a comparison was made between the master DB and the publishing targets DB. Because the sitecore/content item had been deleted in the master, but not in the publishing target, a chain of delete events were registered to remove every item under that root item. Thus deleting all data from the publishing target.

You can read more about this on my blog post here: https://deanobrien.uk/loss-of-all-content-from-our-web-databases/

Your Issue

To confirm if you are facing a similar problem, please review your web database and check to see if the /sitecore and the /sitecore/content items exist.

Look in your logs for entries like:

WARN  Publish: Target item could not be deleted (/sitecore)
WARN  Publish: Target item could not be deleted (/sitecore/content)

If neither of the above are true, then find the deepest item in your site tree and check if it is set to publishable.

  • Thanks this matches our behaviour also, content tree is gone from web and we have just recently migrated from 7.2 database. I will need to investigate and repro in our UAT environment and report back :P
    – Sean T
    Dec 15, 2022 at 16:06
  • Tnx a lot! the logs you are referring to are the Publishing.log files Sep 8, 2023 at 14:09

When related item is checked, in order to maintain the same content tree structure in the target database, Sitecore publishes every parent item of related item (till root /sitecore/Content) before publishing the related item.

So, in your case, the related item of Text component and the parent item of related item (till the root) will be published every time. In case, if one of the parent item Page is marked as Never Publish, then that Page item and all the child items will be removed in the target database.

You can refer this article which explain this scenario.

  • You may be on to something here, the top level page has been set to never publish. However is this something new functionality? We've recently moved to version 10 from version 7.2 and I was not aware of this happening in 7.2
    – Sean T
    Dec 15, 2022 at 15:30
  • Sorry but upon investigation our pages are all publishable, the top level is protected. So this does not explain the behaviour I am seeing unfortunately
    – Sean T
    Dec 15, 2022 at 15:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.