Hmmmm....sounds strange. Is there anything in either the umbraco logs (go into the umbraco database and look at the umbracoLog table) as in if there is a record of deletion or something in the system logs (event viewer)? are the nodes still in the database?

Did you have umbsearch2 installed?  A previous version had a "very scary problem"

It caught me too, but thank god for nightly backups!

Dan

Hi, do you still have your umbraco.config in the data folder? If so, you should be able to restore from there using UmbImport package..

THanks,
nik

HI,

Sorry to hear the data loss. I  think that Dan is right about the install of UmbSearch2. Just wanted to let you know that UmbImport isn't capable (YET) to import the Config. file

Cheers,

Richard

A thought did occur to me... I may have deleted the Document Type of the containing folder in order to tidy up the document types...

Could this be responsible? If so i think that is a little harsh! I had no warning or anything...

And i have not installed any search packages or anything like that.

Cheers guys

I don't think that deleting document types will delete the content (just break it), but I could be wrong.

Is the content actually gone (as someone suggested, do you have an umbraco.config file)? Have you checked in the database. It's possible that the tree is just not rendering, which can be a symptom of some broken JavaScript.

Yeah, i guess that is quite possible... it may be that when the Document type was changed it broke the tree somehow. I will have to look when i am at work tomorrow.

Can you tell me exactly what i am looking for - in either/both the config and Database?

Cheers!

Oh, another thing that i have just remembered. I was getting the 'This node does not exist' error on the pages that were previously working after the data loss, which would suggest complete data loss!

From my experience, deleting a document type does delete the content (that uses doc-type).  I can't say for sure if it deletes it from the database - but it's removed from the content tree.  That would explain it in Alex's case.  Not sure what you can do about it (sorry) - do at slace suggested, check the database and if umbraco.config is still there.

Places to check...

In the database, try "umbracoNodes" or "cmsDocument" (for page titles), and "cmsPropertyData" for the content.

The filesystem XML cache is found at /data/umbraco.config ... it should have a whole bunch of <node> elements in there.

Good luck, hopefully you can salvage some content?

Cheers, Lee.

PS. You know, thinking about it... does anyone think it's possible to "re-create" doc-type in the database - lets say if you knew the Guid, etc?

This is what is in the .config -

<!DOCTYPE umbraco[ <!ELEMENT nodes ANY>  <!ELEMENT node ANY>  <!ATTLIST node id ID #REQUIRED> ]>
<root id="-1" />

Nothing!

And although i am not sure exactly what im looking for in the Database, i did not see anything that looked like data.

Luckily, this is still in the testing phase. I am going to recreate the possible actions i took and see if the tree is lost again.

Should this be reported in any way?

Thanks guys, for all your help.

Alex

I have just performed a test creating a blank documenttype and using it at the base of my site. Then creating documents within that.

As i deleted the document type, the entire tree was lost.

I tried recreating the same document type to reinstate the lost data (if it was hidden somewhere in the database!), But it did not work.

Alex

I have just performed a test creating a blank documenttype and using it at the base of my site. Then creating documents within that.

As i deleted the document type, the entire tree was lost.

I tried recreating the same document type to reinstate the lost data (if it was hidden somewhere in the database!), But it did not work.

Alex

Hi Alex,

I thought as much... I had a quick look at the source (using Reflector) and can confirm when you delete a doc-type, it will delete all associated content nodes. (ref: "umbraco.cms.businesslogic.web.DeleteFromType").

So unfortunately all your content (of that doc-type) is gone.

Going forward, to stop this happening - you can write some code to hook into the "DocumentType.BeforeDelete" event and cancel the delete action.

Here's an example:

using System;
using umbraco.BusinessLogic;
using umbraco.cms.businesslogic;
using umbraco.cms.businesslogic.web;

namespace Bodenko.Umbraco.ApplicationEvents
{
    public class PreventDocumentTypeDelete : ApplicationBase
    {
        public PreventDocumentTypeDelete()
        {
            DocumentType.BeforeDelete += new DocumentType.DeleteEventHandler(DocumentType_BeforeDelete);
        }

        void DocumentType_BeforeDelete(DocumentType sender, DeleteEventArgs e)
        {
            e.Cancel = true;
        }
    }
}

Feel free to copy-n-paste it and put it in your App_Code. (Do test it out on a dev environment first - don't put straight on your live site!!) But remember this means that you can't delete any doc-types (ever!)

Cheers, Lee.

@Lee - this is an awesome idea! We've all done this at one time or another.

If there were a bit more logic in it to see if the docType has any content nodes associated with it that would be the most useful... that way you could delete unused docTypes but not those in use. Throwing up a modal window with a message explaining why the delete didn't work would probably be good too (and log to the db).

This ought to be part of the core I think! Can you add it as a feature request in codeplex, please?

cheers,
doug.

I think this has been added to codeplex several times. At least it was once described as a bug and in some situations I can understand that. Hope it get's added in 4.1!

Quick update to the code/script:

namespace Bodenko.Umbraco.ApplicationEvents
{
    using System;
    using umbraco.BusinessLogic;
    using umbraco.cms.businesslogic;
    using umbraco.cms.businesslogic.web;

    public class PreventDocumentTypeDelete : ApplicationBase
    {
        public PreventDocumentTypeDelete()
        {
            DocumentType.BeforeDelete += new DocumentType.DeleteEventHandler(DocumentType_BeforeDelete);
        }

        void DocumentType_BeforeDelete(DocumentType sender, DeleteEventArgs e)
        {
            User user = User.GetCurrent();
            String userAlias = user.UserType.Alias.ToUpper();

            // check that the user isn't an Administrator
            if (userAlias != "ADMINISTRATOR" && userAlias != "ADMIN")
            {
                // check if the document-type has any content associated
                if (Content.getContentOfContentType(sender).Length > 0)
                {
                    e.Cancel = true;

                    throw new ArgumentException("Can't delete a Document Type that still has content associated with it. Please delete all content references first!");
                }
            }
        }
    }
}

This now checks the user's type/role.  If it's not an Administrator (or Admin) then it checks if the doc-type has any content associated with it - if so it cancels the delete and throws an exception.

At present, I don't know how to communicate back to the Umbraco back-office to display a "speechBubble" message - actually I don't think we can because the user (delete) action is raised from the context menu, rather than a page, (unlike the 'save' button).

I'm sure Niels and the core team have thought about this in the past.  Not sure how much business logic they would want to be introduced to deleting doc-types?  Personally I'm quite happy with the "Are you sure?" alert/confirm message.  Although it does need to be very clear that this will delete any associated content!

Cheers, Lee.

I love this! What a great idea. Thanks for sharing this Lee. 

-- Nik

Hello,

Has anyone also had this problem with datatypes? I once deleted a datatype which resulted into an exception on all document types who used this datatype and because of that all the content nodes of this document type also threw an exception. Just like the DocumentType.BeforeDelete event this should also be done for datatypes. Is there even an event for that?

Jeroen

Hi Jeroen,

No event for that. This can be prevented in the core by adding a few checks when opening the document. Please vote for this issue on codeplex. It's still Low Prio. IMHO it should be high. A work around can be found on my blog.

Cheers,

Richard

is working on a reply...