2

Sitecore: Sitecore.NET 10.1.1 (rev. 005862) Publishing service: 5.0.0

I am trying to find a way to cancel the ongoing publishing and revert the changes done by the current publishing.

I have the following understanding:

  1. Reverting the changes from the web database can only be done manually. Backup before publishing is not a feasible option.

  2. During publishing Sitecore does the following internally.

    -Creates manifests of items to be published.

    -Moves items from the Master DB to the selected publishing target databases.

    -Triggers re-indexing (re-indexing of published items or the whole site depends upon the number of items published and the value in config) and clears the cache.

I did see the articles:

https://mikael.com/2019/07/learnings-from-a-year-of-implementing-sitecore-publishing-service/

Guys, is there a way to achieve this? Or can you guide me in which direction I should work?

Improve this question
6
  • ou need to run the following command from the Publish Service webroot: Sitecore.Framework.Publishing.Host schema reset –force
    – Rameshkumar
    Commented Feb 24, 2023 at 8:26
  • Not sure I fully understand the need here. Sitecore doesn't have the option to cancel queued jobs. I'd like to have that and it can be implemented with custom code. But why would you cancel an ongoing job (other than killing it due to SPS ending up in endless loops etc)? There is really no history of what was previously in the database and anyone should be able to publish anything at any time. The web/target db's are just subsets of master db. If you have "unfinished" work in master, it should be prevented from publishing using workflows, lifetime or some other publish restriction mechanism.
    – mikaelnet
    Commented Feb 24, 2023 at 8:50
  • @mikaelnet: I agree with you. There are situations when a campaign has to go live only at a certain time and content editors create it a day or 2 before. And someone accidentally publishes it.
    – NutsAndBolts
    Commented Feb 24, 2023 at 9:04
  • 1
    Sounds like you should teach the content editors the use of publishing restrictions. Those can also be used to "unpublish" unwanted items: doc.sitecore.com/xp/en/users/101/sitecore-experience-platform/…
    – Sebastian Lay
    Commented Feb 24, 2023 at 9:41
  • Yes, scheduled campaigns should have a set date/time as publish restrictions and content editors should be taught to do that. However, it's a bit annoying that Sitecore doesn't have auto-publish of scheduled items out-of-the box. I'd suggest you build such scheduled publisher instead. It's a fairly easy to build and I think I've written a post with sample code for that at some point. Content editors obviously don't want to have to login and publish at exactly the release time, so with such extension you can make Sitecore publish the items automatically right after they're scheduled for publish
    – mikaelnet
    Commented Feb 24, 2023 at 10:29

1 Answer 1

Reset to default
2

I'd say it's simply not possible to cancel and rollback a publish job due to the nature of how publishing works in Sitecore. There is no history of what content was previously in the web database as it is being overwritten by a publish operation, regardless if using the built-in publishing or Sitecore Publish Service (SPS).

Since Sitecore doesn't have the history, you're basically left with just two options: Restore a database backup or rely on database transactions. You've already ruled out the backup/restore option, so database transaction is the last one to give a thought.

SPS have some kind of transaction support, but doesn't seem to be very well tested. Since SPS performs publishing in large batches, I think the idea was to avoid leaving the database in a corrupt state if something went wrong. Having this enabled can cause major issues as transactions become way too large to be practically handled. IIRC, transactions was enabled by default in early versions of SPS but was then changed to be disabled by default.

Theoretically, I guess you could enable transactions in SPS and try to find a way to cause SPS to crash, so that the database would rollback your content, but I would certainly not recommend it. Your largest publish operations must fit in a db transaction or you won't be able to publish it at all. If you can make your publish operations fit into a transaction, your solution is probably not big enough for SPS to be a viable option in the first place.

One can of course increase the size limit of a transaction in SQL Server, but that also comes with larger/longer commit/rollback execution times causing tons of other issues, such as timeouts etc. I've experimented with it - it's simply not worth it.

Improve this answer

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.