I just upgraded from Umbraco 6.2. Almost everything is working, except that some Document Types are resulting in an error when I try to access a node that's based on the Doc Type or when I try to create a new node based on that type.
Server error: Contact administrator, see log for full details.
Failed to retrieve data for empty content item type ArticlePageOldCopy
This seems to be the corresponding error in the log:
2014-05-29 00:50:17,814 [7] ERROR Umbraco.Core.UmbracoApplicationBase - [Thread 20] An unhandled exception occurred
System.Web.HttpParseException (0x80004005): Could not load type 'umbraco.cms.presentation.login'. ---> System.Web.HttpParseException (0x80004005): Could not load type 'umbraco.cms.presentation.login'. ---> System.Web.HttpException (0x80004005): Could not load type 'umbraco.cms.presentation.login'.
at System.Web.UI.TemplateParser.GetType(String typeName, Boolean ignoreCase, Boolean throwOnError)
at System.Web.UI.TemplateParser.ProcessInheritsAttribute(String baseTypeName, String codeFileBaseTypeName, String src, Assembly assembly)
at System.Web.UI.TemplateParser.PostProcessMainDirectiveAttributes(IDictionary parseData)
at System.Web.UI.TemplateParser.ProcessException(Exception ex)
at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding)
at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding)
at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding)
at System.Web.UI.TemplateParser.ParseFile(String physicalPath, VirtualPath virtualPath)
at System.Web.UI.TemplateParser.Parse()
at System.Web.Compilation.BaseTemplateBuildProvider.get_CodeCompilerType()
at System.Web.Compilation.BuildProvider.GetCompilerTypeFromBuildProvider(BuildProvider buildProvider)
at System.Web.Compilation.BuildProvidersCompiler.ProcessBuildProviders()
at System.Web.Compilation.BuildProvidersCompiler.PerformBuild()
at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath)
at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate)
at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate)
at System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath virtualPath, HttpContext context, Boolean allowCrossApp, Boolean throwIfNotFound)
at System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp)
at System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath)
at System.Web.HttpApplication.MaterializeHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
I have created a copy of the offending Doc Type and stripped it of every single property (except the ones inherited from its Master), to no avail. I have also created a Doc Type from scratch (under the same Master), and that one doesn't have any problems.
Although I'm still not sure what caused the problem, I did find a workaround.
Creating an identical (save for the name and alias) doc type and changing the doc type for the affected nodes did the trick. To make it easier I exported the doc type, changed the name and the alias, and imported it. Copying the doc type itself in Umbraco didn't work, though.
I had this issue with Umbraco 7 - the solution was to make sure you didn't have any duplicate tabs in your document types eg. I had a Content Assignment tab in my Master type as well as my Article type (Article inherited from Master).
I'm also getting this error on a recent upgrade from 7.1.8 (everything was fine) to 7.2.1 (can't create new nodes based on my most commonly used document types [which aren't descendents of other document types so the "tabs" issue seems not applicable]).
But, since the Tabs thing was mentioned, I tried to change a tab name on one of the document types and get a red "this sql transaction has completed it is no longer usable" error, and it doesn't end up changing the tab name.
Any thoughts? Concerned we need to roll back to 7.1.8 right quick since nobody can create new content (oddly though, editing existing nodes is still fine).
@Arie, since we're continuing to have this problem, I'm going to try your solution of exporting doc types, importing them as new names, and reassigning all nodes to the new names.
But does that mean our users will now have to use new Document Type names (i.e. instead of doing "Create -> BlogItem", they'll have to do "Create -> NewBlogItem")? Or is there a way to then rename the new document type back to the original?
@Eric, I'm not sure - it depends on whether the doctype is referenced internally by its alias or by an ID. If it's by the alias you should be able to duplicate the offending doctype via export/import, change the alias of the problematic doctype, and then use the old alias for the new doctype.
By the way, did you confirm that you have duplicate tab names? If so, have you tried renaming the tab of the parent doctype?
I'll experiment with the renaming of doctypes; all my Razor code uses doctype aliases rather than IDs but I was more concerned about underlying database references.
And we don't have any parent/child relationships in our doctypes, so the tab renaming doesn't seem to apply. I've tried renaming tabs anyway, but no effect.
Failed to retrieve data for empty content item type ArticlePageOldCopy
I just upgraded from Umbraco 6.2. Almost everything is working, except that some Document Types are resulting in an error when I try to access a node that's based on the Doc Type or when I try to create a new node based on that type.
This seems to be the corresponding error in the log:
I have created a copy of the offending Doc Type and stripped it of every single property (except the ones inherited from its Master), to no avail. I have also created a Doc Type from scratch (under the same Master), and that one doesn't have any problems.
Ideas?
PS
When I try to access a node that's already based on the offending Doc Type (migrated from the 6.2 install) I get this error:
Although I'm still not sure what caused the problem, I did find a workaround.
Creating an identical (save for the name and alias) doc type and changing the doc type for the affected nodes did the trick. To make it easier I exported the doc type, changed the name and the alias, and imported it. Copying the doc type itself in Umbraco didn't work, though.
I had this issue with Umbraco 7 - the solution was to make sure you didn't have any duplicate tabs in your document types eg. I had a Content Assignment tab in my Master type as well as my Article type (Article inherited from Master).
Renaming the duplicate tab fixed the issue for me
@KevinNolan +1
A duplicate tab name was the issue for me.
I'm also getting this error on a recent upgrade from 7.1.8 (everything was fine) to 7.2.1 (can't create new nodes based on my most commonly used document types [which aren't descendents of other document types so the "tabs" issue seems not applicable]).
But, since the Tabs thing was mentioned, I tried to change a tab name on one of the document types and get a red "this sql transaction has completed it is no longer usable" error, and it doesn't end up changing the tab name.
Any thoughts? Concerned we need to roll back to 7.1.8 right quick since nobody can create new content (oddly though, editing existing nodes is still fine).
(Using SQL Server 2008)
@Arie, since we're continuing to have this problem, I'm going to try your solution of exporting doc types, importing them as new names, and reassigning all nodes to the new names.
But does that mean our users will now have to use new Document Type names (i.e. instead of doing "Create -> BlogItem", they'll have to do "Create -> NewBlogItem")? Or is there a way to then rename the new document type back to the original?
@Eric, I'm not sure - it depends on whether the doctype is referenced internally by its alias or by an ID. If it's by the alias you should be able to duplicate the offending doctype via export/import, change the alias of the problematic doctype, and then use the old alias for the new doctype.
By the way, did you confirm that you have duplicate tab names? If so, have you tried renaming the tab of the parent doctype?
I'll experiment with the renaming of doctypes; all my Razor code uses doctype aliases rather than IDs but I was more concerned about underlying database references.
And we don't have any parent/child relationships in our doctypes, so the tab renaming doesn't seem to apply. I've tried renaming tabs anyway, but no effect.
I had the same problem but it was because I tried to add an doc type without any tabs.
is working on a reply...