[CMS 7.5] Deleted content and its references

Vote:
 

Colleagues,

 

We have a problem and I would really like to find out how to solve it. To reproduce you should do the following steps:

1. Create some page inside EpiServer

2. Add this page to some Content Area

3. Move that page to the Trash and empty it.

 

In that case the ContentArea will contain the reference to the deleted page and we will have an exception, that says "Content Not Found". The most interesting thing is that the removed blocks are marked with the gray color, and the problem can not be reproduced.

Is that an EpiServer bug or feature? What is the best way to avoid such issues?

Thanks in advance.

#83060
Mar 25, 2014 12:29
Vote:
 

Hey, Aliaksei,

I am not getting any errors, my page is automatically removed from the content area when I empty the recycle bin. Which exact version are you using?

This is my packages.config:

  <package id="EPiServer.CMS.Core" version="7.5.1002.0" targetFramework="net45" />
  <package id="EPiServer.CMS.UI" version="7.5.446.0" targetFramework="net45" />
  <package id="EPiServer.Framework" version="7.5.1002.0" targetFramework="net45" />
  <package id="EPiServer.Search" version="7.5.446.0" targetFramework="net45" />

    

 

#83088
Mar 25, 2014 16:08
Vote:
 

Hey, Marija,

I have the following configuration:

  <package id="EPiServer.CMS.Core" version="7.5.409.0" targetFramework="net45" />
  <package id="EPiServer.CMS.UI" version="7.5.409.0" targetFramework="net45" />
  <package id="EPiServer.Framework" version="7.5.409.0" targetFramework="net45" />
  <package id="EPiServer.Search" version="7.5.409.0" targetFramework="net45" />

    

#83113
Edited, Mar 26, 2014 9:10
Vote:
 

Here is a list of releases https://nuget.episerver.com/en/OtherPages/Package/?packageId=EPiServer.CMS.Core 

If you don't want to upgrade to 7.6, then, I suggest you upgrade to latest 7.5:

Install-Package EPiServer.CMS.Core -Version 7.5.1003.0

#83115
Edited, Mar 26, 2014 9:44
Vote:
 

Marija,

 

You're right, on UI you won't see the deleted page anymore in the contentArea, but if you try to programatically get the list of items in it you will see the reference to the deleted page.

Content Area with the deleted page on the UI: http://i57.tinypic.com/11jrkt1.png

Content Area with the items in VS: http://i60.tinypic.com/348pylt.jpg

Please let me know if you have any questions!

 

#83135
Mar 26, 2014 12:56
Vote:
 

Hey,

IMO, it should work like this, either:

- the page stays in the content area and you can see it in edit mode and remove it manually (this is how LinkItemCollection used to work, if a page is deleted, it stays in the collection and you can remove it manually)

- the page is removed from content area and you can't see it

Anyways, I don't think this is critical for this to work - since the page doesn't break and if you need to access it manually you can check if the page is deleted. But, yes, this seems like an inconsistent behavior in the CMS.

#83146
Mar 26, 2014 14:07
Vote:
 

Hi!

I'll try to explain how it works and why:

For Link Collections, we store links to internal items in a format called permanent link (~/link/[GUID]. This is then resolved to the public format when displayed on the site. A link that points to an item that has been permanently deleted will not be resolved but still shown in it's permanent format to the web site. It will also be shown when editing with the name stored in the link collection and the internal link. Following the link on the web site will result in a 404 (unless you handle this somehow).

For Content Areas, we store references to items. When displaying items to the editor or displaying items on the web site, we try loading the items from the Content Repository. If the item cannot be loaded, if will remain in the content area until someone edits the property (add, remove, move any item in the collection) where it will be automatically removed when being saved.

For consistency, it would probably be good if these two collections behave the same. I would argue that the Link Collection has the correct behaviour. Items that no longer exist should be automatically removed. Still, when looping through the items for a Content Area or Link Collection, you need to be aware that items might not be available for different reasons, for instance that they have been permanently deleted or the current user does not have access rights to see them.

I'll take this up with the development team to see if this is to be considered a bug or not.

#83155
Mar 26, 2014 16:30
Vote:
 

I'm very grateful for all answers!

Linus, could you please let me know if it is supposed to be fixed in the next versions of EpiServer?

#83172
Mar 27, 2014 8:21
Vote:
 

Hi!

We have decided that these discreptancies should be investigated and probably fixed. This might require some work though so I won't give any estimates to when this can be fixed. Here's the bug for future references:

Bug #113471: Discrepancies about how Link Collection and Content Areas work with items that cannot be resolved

#83175
Mar 27, 2014 9:22
Vote:
 

Just an update since a couple of days ago when I contacted support: this bug is still in backlog (and not publicly available in buglist).

Can we please get some more attention for it, since it's causing performance issues (especially if the DB is not that close to the website)?

Thx,

Marija

#140819
Edited, Oct 30, 2015 15:28
Vote:
 
<p>If anyone has a similar issue, my coworker has&nbsp;created a&nbsp;workaround:&nbsp;<a href="http://www.mogul.com/en/about-mogul/blog/removing-all-unused-references-from-content-areas">http://www.mogul.com/en/about-mogul/blog/removing-all-unused-references-from-content-areas</a></p>
#141991
Nov 25, 2015 16:38
Vote:
 

Experiencing exactly the same as you guys. Except I am deleting and reading blocks from a contentarea using a scheduled job. It worked fine in 7 but crashed, to my horror, in 7.5. Used almost all day figuring out what the heck was going on. The API for deleting blocks should in my opinion have a "safe delete" which is slower and takes care of the dangling references. 

#142594
Dec 15, 2015 15:17
Vote:
 

I having problems cleaning up the dagnling references. I am trying to do the following

var clone = (MyPage)p.CreateWritableClone();
var contentArea = clone.MyContentArea;

var isDanling = isDanling(clone);

foreach (var d in isDanling) {
  contentArea.Remove(d)
}

clone.MyContentArea = contentArea;

Save(clone) 

but it does not work. Anyone had any luck with programatically removing them? 

#142618
Dec 16, 2015 10:33
Vote:
 

Hi, This is still an issue i the latest episerver release 11.x.x and we cant find a reference to this bug anymore. Has it been forgotten since @Linus left the company or what? :)

In our case the .Items.Count() give as a higher value then .FilteredItems.Count() but in edit mode we cant se any reference and you have to update the contentarea it is not enough to update the page. Anyone with a fix, episerver perhaps? :) Or what happend with the bug?

#199839
Edited, Dec 13, 2018 9:54