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" />

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" />

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

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!

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.

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.

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?

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

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

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. 

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? 

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?