Looking for best practices to prevent accidently removing lots of links.

I think there has been improvements in this area.

Scenario delete home node (accidently), popup launches for option for break links dialog. Select remove broken links, thinking deleting another node. Break links takes a while. Cancel delete operation. Job to remove broken links continues in back ground. Later realise lots of links have been removed, and roll back database.

At time was a bug, when deleting a proxy configuration item that didn't refresh UI. And so if went to delete item again, as item already deleted would default to the hone node and delete that instead. (fixed since) Also seen case where content author deleted a large section, and chose remove broken links.

One is education, saying in dialog what actions will be performed, how many items deleting, how many links about to break etc. Defaulting option to not break links.

Other is extending pipeline to prevent mass deletion of items. Recall adding pipeline before to say are you sure you want to delete 100 items etc, and preventing deleting 1000 items in one go.

Other is auditing/alerting that a bulk delete/remive links operation has been requested. Do doesn't go days before realising all links broken in master.

Wondering what best practices are, how others have protected from these scenarios


This is a question with really a mryaid of possibilities for an answer.

It boils down to client requirements.

As a Best Practice, I advocate working with the business owner to iron out what the real requirements for workflow, security, and guard rails, are and then based on that information, create stories for tailoring Sitecore to your desire.

Sitecore makes it very easy to build in the guard rails you need in order to limit breaking links from deletions.

Options include:

  • Event Handlers for delete, rename, and move
  • Custom Button overrides to toggle enablement of delete button.
  • And if you're feeling creative, create your own custom pipeline to validate whether an item can be deleted that makes it extendable as use cases grow.
  • Yes, this is similar to what we did. uiDeleteItems processor. Check if not important node, and check children beneath item about to delete is under an agreed threshold, either requiring confirmation or aborting without giving option. – Ian Oct 11 '16 at 21:37

To reduce the risk of this happening I'd limit access rights. Perhaps only certain roles should be allowed to modify, let alone delete the Home item, section items and so on. It might still be possible for less priviliged roles to restrict publishing if they need to remove something from the public website.

  • Yep, certainly some security restrictions. All though for removing old versions of items I think delete is required. And superusers will still be able to breaks lots of links by accident. With warnings telling them how many links about to break. And forced to delete items in smaller batches. – Ian Oct 4 '16 at 21:56

I'm not sure about restricting this but we've had this issue where content editors didn't have the permissions to remove the links and it meant broken links were left in place.

We recently added code to handle broken links in our MVC views when this happens.

This is quite easy to do silently in Glass (if your using it) just rename this file: z.Glass.Mapper.Sc.ViewRender.config.example to remove the .example.

However we wanted to show some nice error messages about broken data sources to content editors so we took a similar approach to this:http://www.hhogdev.com/blog/2015/june/mvc-rendering-exception-handler.aspx

Here are some other useful links on this subject:




Hopefully this is useful to someone else.

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