Hi!

That is not standard functionallity in Episerver. You must have some sort of custom events that create the meda contents. Try searching you solution for any events handlers

I gotta ask, what is on the pictures? :-)

hmmm... i dont think i'm using any custom handlers for creating media... but i will check it..

The images are just the same of 1 (logo and some other one).

Definitely not standard functionality. There has to be some extra added functionallity that does this somewhere in your solution. 

strange... no custom handler to be found... Also i cannot delete the media items :-) "move to trash" is greyed out... very strange!!

What if you search for "businet" in your solution, which loooks to be the name of one of the image files. You should also check your references to see if you have any unknown referenced dlls. Also, do a "clean solution" and check your bin folder for any remaining dlls

Let me first ask: Does the item "disappear" when you hade an other/new item to the page?

If so do you have the same problem as us. I have reported this earlier, but since I'm no EpiServer partner (can not report bugs) and no reply on the forum have we not been able to get this bug fixed. It seems that sometimes does media item not connect properly to a page and therefore show up on every new page in the editor. "Parentless items"?

I've fixed this once by removing this in the database, but new items appear for some reasons time to time and manually removing in DB is a bit on "living on the edge". I have therefore not removed the new items (without parent page) in a while.

Hi Vishal,

I believe that the images you see is because something has gone wrong when those images were uploaded as sven.tegelmo mentions. Unfortunately I have no idea of what happened, we have no known bug for this yet.

Does anyone in this thread know of a way to reproduce this on a new site?

When you create a new page the page will have a link to a global asset folder (usually with id 4). The idea is that once an editor tries to create a block or image in there a new unique folder will be created for that specific page and the block or image will be placed in that folder. Somehow your images were placed directly in the global asset folder and that is why you see it on every new page you create. You could verify that by uploading a new image or create a new block in the new pages asset folder and see if the images "dissapear" for that page.

That's quite interesting.What if you navigate directly to the folder, something like  /EPiServer/Cms/#viewsetting=viewlanguage:///en&context=epi.cms.contentdata:///4 and if the five image files appear in that folder, you delete them?

YES guys! When i create a new media file in the "for this page" folder of the newly created page, all the other media files are removed!! 

Soo.. what does this mean now... and how can we fix these orphaned media files.

@Per:

if i navigate to that url: i see nothing:

Unfortunatly havn't I been able to reproduce this. I have just since that various different users creating these items. I haven't been able to add one myself. I wild guess is that site is updated with new code can this happen (?).

In our case is the items not added to global asset folder. The items can not be removed anywhere in editor mode. (The "Move to recycle bin" is not enabled).

@Sven... exactly.. these items cannot be removed/deleted

@Vishal, if you hover the "For this page" folder after you've created a new page, what is the ID? And could you try to navigate to it? Use the same url as earlier, but replace "4" with the ID

I've seen similar issues which blocks. They somehow end up in all "For this page" folders. I think they get the wrong parent id somehow.

@Per, if i create a new page, without publishing, the id of the "for this page" folder is 4. It contains the media files. Now when i publish the page, the "for this page" still has the id 4. 

After that i added a new media file to the "for this page". Once if done that, the id of the "for this page" changed to a high number, and immediately the default (orphaned)media is gone... 

@Johan: were you able to find a solution for this?

What about the IDs for the images? Are you able to edit them? Either try editing them, or find the ID by hovering the content and navigate to it. The assets pane should then update to show you the actual location for the images.

Also:Have you tried resetting your views? In edit mode, go to {Username] -> My Settings > Display Options > Reset Views. It's a long shot, but worth a try I guess.

@Per.. using the ID of the images, i can edit the content, but cannot delete it. 

And reset views didnt help. 

Are you able to see where in the content structure the images are located when you edit them? The navigation pane should update

We are having the exact same problem as OP; when creating a new page, the "for this page" media folder contains 3 media elements.  Following the ID of this media folder takes us to a folder filled with subfolders corresponding to pages with media content as well as the 3 aforementioned media elements.

The question for us now is:  How did these elements end up directly under this directory in the first place? And is there any way of deleting these without accessing the database directly?

We still don't know of any way to reproduce this. I'm however in the process of trying to make sure that items that end up in the global asset folder are moveable or deletable so that you don't have to dig in the database to remove them.

@Niklas That's great news!  Any ETA on this change?  And in the meantime; is there any "safe" way of deleting these from the database directly (without corrupting the version history etc)?

No @Kjetil, no ETA unfortunately. We're working on it and it will be released when any fix is ready. I'll try to remember to update this thread when we get there.

Regarding if there's any "safe" way to delete the blocks/media from the database I can't say because I don't know. I would recommend that you contact support about it.

@Nicklas.. thanks for the update.... any SQL Query would already help to do this safely in the meantime until the fix is ready. I'm not familiar with the database structure and dont want to go "play" in the production database for now. 

We've found and internally fixed the bug that prevents you from deleting assets that for some reason have ended up in the asset folder root. CMS-6995

But the problem is that the fix requires us to make a breaking change so we will not be able to release it without creating a new major version. So we will hold the fix for this bug until we're ready to release CMS.UI 11.

While you guys wait for that you can remove the items there but I would not not recommend doing it by SQL since it is very hard to remove everything in the correct way. The safest way to remove items is using the API.

I'm going to give you some example code here to give you an idea of how it could be done. But please don't go executing this code on any production server without testing it. You need to be 100% sure that the code does the correct thing before running it in production.

var contentRepo = ServiceLocator.Current.GetInstance<IContentRepository>();

//Use something more specific than IContent if you have a lot of children to the ContentAssetsRoot
var contentAssetChildren = contentRepo.GetChildren<IContent>(SiteDefinition.Current.ContentAssetsRoot);
var deleteItemIfItIsReferencedByOtherContent = false; // Set to true if you want to force the delete. This will create broken links if anything references the content.
foreach (var child in contentAssetChildren.Where(c => !(c is ContentAssetFolder)))
{
    contentRepo.Delete(child.ContentLink, deleteItemIfItIsReferencedByOtherContent, AccessLevel.Delete);
}

@Nicklas

Hi, just wondering if you know if there is any information on a permanent solution on why assets end up in the asset folder root? 

@Christoffer

No, we still haven't got any new information on how we can reproduce this and then it's hard for us to do something about it.

@christoffer, i used the snippet Nicklas provided and that helped clear the assets. And after that we didnt got the problem anymore. 

And yes its hard to reproduce. Even we dont have a clue how it happened in the first place.