I'm suddenly getting a YSOD thath puzzles annoys me:
(Umbraco version is 7.2.1)
The thing is (of course) that the WorkerSection document type no longer exists (was renamed weeks ago, actually) and is never explicitly asked for... I'm sure this is some kind of .NET object cache playing tricks with me - had a similar issue where a Razor partial couldn't render a property that was visible in the XML cache (and renderable with XSLT - yay, go XSLT!), and I was told to touch the Web.config to "fix" it. I've already tried this here but it doesn't seem to work. At first it does, but then as soon as I try to Preview a page, it explodes in my face again.
Yes, tried deleting the preview XML too, but it comes back...
And this is actually the second YSOD because I replaced the first partial that complained, with an XSLT macro, but then I just got the error from another partial - so I'm guessing the call to .Children is actually where the shit hits the fan, so to speak...
I don't use Visual Studio, so I can't give you any insights from various .NET inspector tools.
@Anders: I really appreciate the answer and it my indeed solve the problem (we'll see, time will tell :) - but it bugs me to hell, that I have to do this :-)
@Morten: No content of that type - it is a single "container" type that was renamed. Haven't checked the DB, though.
@Lee: The XML cache is perfectly up to date, and XSLT macros render everything - it's just the Razor bits that are confused by some old stuff :-)
It could be a bug in the content type cache, if it is not updated correctly when container types are renamed. If an App Pool recycle fixes the problem, then that is very likely.
@Morten: I totally think it's a bug :) What bugs me to no conceivable end is that the Umbraco.config file has always been "the truth" in these matters. I could always just open that one if something seemed wrong, and lo and behold - yes, I'd forgotten to publish the renamed document or something similar. That's no longer a viable option for me, and I'm stuck with this very cryptic message, referring to something I can't find anywhere in the tree or in the Umbraco.config file.
Well, the umbraco.config has never (to my knowledge) contained information about container doctypes?
Let's assume that doctypes are cached, and a cached doctype has an alias reference to it's container doctype. If you rename the container, and the child doctype is not updated in the cache, that would generate an error similar to what you see.
Can you reproduce this?
If so, try this:
Rename container
Verify error
Save the child doctype(s)
See if the error is still there
Saving the child should update the cache for it, thus also removing the invalid reference, without recycling the app pool.
@Chriztian... you know I love you and I hate being an arse... How sure are you that there isn't a WorkerSection node in the XML cache?
To explain...
I'm looking through the Umbraco core source and the only ways that this specific exception would happen is:
if the DocType rename didn't clear an internal PublishedContentType cache (I can go into detail, but it doesn't help explain)
or if an XML node still had a name() (or @nodeTypeAlias) of the old DocType alias value
If it is a caching issue, then it's all about the memory - which you can either force (e.g. kicking the web.config), or wait to let it expire naturally (depends how IIS is configured - usually after 20 mins of idle time).
Because you say that the DocType rename happened weeks ago - so I'd rule out memory/cache... which leads me to think about the rogue WorkerSection XML node.
To clarify: A "container" doctype is just a doctype like any other doctype - it's just used to wrap others. Even if you enable "ListView" for a type, it'll still show up in the XML.
Will see if I can do the tests and confirm the bug.
@Lee:
I love you too man - no worries :-)
Dead certain there was no WorkerSection in the XML - looked for it & searched for it. Not a trace.
So I managed to fix it (appears so, anyway) - I did this:
I hit preview on the Home page - YSOD
Deleted the just generated preview XML
Hit refresh in the browser - page now renders but with Preview badge (wat????)
Clicked the badge to exit preview
Did a hard "Publish" on the "previously-a-WorkerSection" node
OK cool. Hmmm, definitely sounds like a core bug then. By renaming "WorkerSection" DocType, there must be some reference to it "somewhere" (in memory/cache or database) ... the question is where? (or I'm completely wrong and misleading)
@Jeroen - that could very well be the issue - having the @nodeTypeAlias out of sync with the element name would probably explain this. Also seems to match what Lee outlined...
(And yes, I looked through the Umbraco.config file with XPath, so the nodeTypeAlias could in fact have been the old one... would never occur to me that they could be out of sync)
The strange thing with the issue mentioned was that even a save and publish of the node would still show the old doctype alias. Only a republish entire could fix it.
We had exactly the same problem on a solution yesterday, and exactly the same solution. Save and publish makes everything look right in the XML cache, but only Republish entire site solves the YSOD. I totally agree that not having umbraco.config be the single source of truth anymore is frustrating.
I have a similar problem, occurring only in published release builds. The error message is
Failed to find a media type with alias "BackgroundImage"
The code is actually searching for a property called "backgroundImage". I have never defined a media type "BackgroundImage" (or if I did it was ages ago).
Republishing the whole site, even using the dialog does not help, nor does recycling the app pool.
The site works perfectly from Visual Studio, so I don't know whether to look in database, indexes or code. Pretty stuck.
Actually I have now flushed and rebuilt my test website and it works. This indicates something, perhaps in the App_data has changed. It can't be umbraco.config, as that changes with a republish from the back office. It can't be the database, as that has not changed. Examine indexes?
I got my test release version to work by deleting everything and republishing. It still uses the same database. It now works. I think there was a problem somewhere in App_Data but not at all sure what.
ContentTypeService failed to find...
Hi all,
I'm suddenly getting a YSOD thath
puzzlesannoys me:(Umbraco version is 7.2.1)
The thing is (of course) that the WorkerSection document type no longer exists (was renamed weeks ago, actually) and is never explicitly asked for... I'm sure this is some kind of .NET object cache playing tricks with me - had a similar issue where a Razor partial couldn't render a property that was visible in the XML cache (and renderable with XSLT - yay, go XSLT!), and I was told to touch the Web.config to "fix" it. I've already tried this here but it doesn't seem to work. At first it does, but then as soon as I try to Preview a page, it explodes in my face again.
Yes, tried deleting the preview XML too, but it comes back...
And this is actually the second YSOD because I replaced the first partial that complained, with an XSLT macro, but then I just got the error from another partial - so I'm guessing the call to
.Childrenis actually where the shit hits the fan, so to speak...I don't use Visual Studio, so I can't give you any insights from various .NET inspector tools.
What can I do to nuke this?
/Chriztian
Try recycling the application pool, and then republish the entire site. Seems to have solved similar issues I have had in the past :D
So the doctype has been deleted, but has all the content been deleted as well?
If you go to the DB, are there any children that have the old doctype?
That's my assumption too... that there is still content (XML nodes) with the old DocType alias in the XML cache.
As Anders says, republishing the entire site - or more specifically each of the old "WorkerSection" content nodes - that should resolve the problem.
It's a strange scenario though, as I though the Umbraco core already handled regenerating the content node XML for DocType renames. Hmmm.
Cheers,
- Lee
I would first rebuild the examine index in the developer tab. I had lately a lot of problems with the examine index not being up-to-date.
@Anders: I really appreciate the answer and it my indeed solve the problem (we'll see, time will tell :) - but it bugs me to hell, that I have to do this :-)
@Morten: No content of that type - it is a single "container" type that was renamed. Haven't checked the DB, though.
@Lee: The XML cache is perfectly up to date, and XSLT macros render everything - it's just the Razor bits that are confused by some old stuff :-)
And thanks for chiming in everyone - appreciated!
I missed that it was a rename.
It could be a bug in the content type cache, if it is not updated correctly when container types are renamed. If an App Pool recycle fixes the problem, then that is very likely.
@Morten: I totally think it's a bug :) What bugs me to no conceivable end is that the Umbraco.config file has always been "the truth" in these matters. I could always just open that one if something seemed wrong, and lo and behold - yes, I'd forgotten to publish the renamed document or something similar. That's no longer a viable option for me, and I'm stuck with this very cryptic message, referring to something I can't find anywhere in the tree or in the Umbraco.config file.
/Chriztian
Well, the umbraco.config has never (to my knowledge) contained information about container doctypes?
Let's assume that doctypes are cached, and a cached doctype has an alias reference to it's container doctype. If you rename the container, and the child doctype is not updated in the cache, that would generate an error similar to what you see.
Can you reproduce this?
If so, try this:
Saving the child should update the cache for it, thus also removing the invalid reference, without recycling the app pool.
If that is the case, then it is definitely a bug.
@Chriztian... you know I love you and I hate being an arse... How sure are you that there isn't a
WorkerSectionnode in the XML cache?To explain...
I'm looking through the Umbraco core source and the only ways that this specific exception would happen is:
if the DocType rename didn't clear an internal
PublishedContentTypecache (I can go into detail, but it doesn't help explain)or if an XML node still had a
name()(or@nodeTypeAlias) of the old DocType alias valueIf it is a caching issue, then it's all about the memory - which you can either force (e.g. kicking the web.config), or wait to let it expire naturally (depends how IIS is configured - usually after 20 mins of idle time).
Because you say that the DocType rename happened weeks ago - so I'd rule out memory/cache... which leads me to think about the rogue
WorkerSectionXML node.I already asked, but have you tried rebuilding the examine indexes? That would match the first bullet of Lee.
@Morten:
To clarify: A "container" doctype is just a doctype like any other doctype - it's just used to wrap others. Even if you enable "ListView" for a type, it'll still show up in the XML. Will see if I can do the tests and confirm the bug.
@Lee:
I love you too man - no worries :-)
Dead certain there was no WorkerSection in the XML - looked for it & searched for it. Not a trace.
So I managed to fix it (appears so, anyway) - I did this:
Still kinda baffled about this... :)
/Chriztian
@Damiaan: Thanks - no I didn't try that. I've never tinkered with that tab, so was kinda hoping I wouldn't have to :-)
Sorry - which was the old alias "WorkerSection" or "WorkerItem"? (Check for the old one)
Maybe republishing that specific node has resolved the issue now?
@Lee - was a typo on my part, I've fixed now to avoid confusion. The node was called "WorkerSection" - then renamed to "Employees".
/Chriztian
Didn't read the entire topic, but it does sound a lot like this issue: http://issues.umbraco.org/issue/U4-5301
This happens if you rename a doctype or change the doctype of a node.
Jeroen
OK cool. Hmmm, definitely sounds like a core bug then. By renaming "WorkerSection" DocType, there must be some reference to it "somewhere" (in memory/cache or database) ... the question is where? (or I'm completely wrong and misleading)
@Jeroen - that could very well be the issue - having the @
nodeTypeAliasout of sync with the element name would probably explain this. Also seems to match what Lee outlined...(And yes, I looked through the Umbraco.config file with XPath, so the nodeTypeAlias could in fact have been the old one... would never occur to me that they could be out of sync)
/Chriztian
The strange thing with the issue mentioned was that even a save and publish of the node would still show the old doctype alias. Only a republish entire could fix it.
Jeroen
@Jeroen: That makes perfect sense because that's what I endend up doing - I thought "Save and publish" would do it, but it didn't.
We had exactly the same problem on a solution yesterday, and exactly the same solution.
Save and publishmakes everything look right in the XML cache, but onlyRepublish entire sitesolves the YSOD. I totally agree that not havingumbraco.configbe the single source of truth anymore is frustrating.I have a similar problem, occurring only in published release builds. The error message is Failed to find a media type with alias "BackgroundImage" The code is actually searching for a property called "backgroundImage". I have never defined a media type "BackgroundImage" (or if I did it was ages ago). Republishing the whole site, even using the dialog does not help, nor does recycling the app pool. The site works perfectly from Visual Studio, so I don't know whether to look in database, indexes or code. Pretty stuck.
Actually I have now flushed and rebuilt my test website and it works. This indicates something, perhaps in the App_data has changed. It can't be umbraco.config, as that changes with a republish from the back office. It can't be the database, as that has not changed. Examine indexes?
I got my test release version to work by deleting everything and republishing. It still uses the same database. It now works. I think there was a problem somewhere in App_Data but not at all sure what.
is working on a reply...