Yes. We that's normally our default answer to most issues like this. However, in this case it does not clear the issue.
When nodes are '#' in the url they are also going to a 404 on the front end. This essentially brings the whole site down.
At this point we are avoiding the 'Republish All Nodes' option as we suspect that it might be causing the issue. This is very much trial and improvement to find the root of the problem.
Our main issue is client confidence in Umbraco at the moment. But this could be an issue specific to our setup. If any one else is having this issue at least we can rule that out.
We've had the same issue in the past. Basically, some publishing goes wrong and the XML cache does not get loaded. So, the back-end generates all urls as # and the front-end routes all pages to 404.
Have you checked the Umbraco log (table in the database)? The failed publishing _should_ log some exception in the log...
Have you tried hitting http;//YOURDOMAIN/Umbraco/dialogs/republish.aspx?xml=true to recreate the whole XML?
In our case, we had the XML of one document in the cmsContentXml table that was invalid XML--no idea why. So anytime the XML was reloaded from DB it failed, and we had to republish that precise node to fix the isse.
I see you mention it happen when making changes to doctypes : changes to doctypes can trigger long-running updates to the database, that at the moment can collide with updates made by some other users, and trash the XML. It's a bug.
Regenerating the whole XML should fix the issue. Maybe you'll have to manually republish some nodes.
In some cases we've decided not to do doctypes changes on the live database while users where editing content. Either we lock them out for a few minutes or we do it at night or...
The point that stands out is making changes to DocTypes. I suspect that if we are doing this while other developers/content editors are also making changes to content things can get messed up.
We are going to put in place a content freeze when making DocType changes and along with a database backup. I'll let you know if we still run into the issue with this safety net.
@Adam - we're experiencing the very same thing, we're now very nerous about updating doc types.
@Stephen - what you've said makes complete sense and it's a good idea to lock users out during doctype changes. The bug, do you know if it's on http://issues.umbraco.org? I've had a look but cant see anything. If it isnt I'll raise it.
The release started at 10:40 & finished at 10:42 according to Octopus, so I queried the Umb log from 10:35. (SELECTTOP 1000 *FROM umbracoLog WHERE Datestamp >='2012-11-14 10:35:00'ORDERBY Datestamp)
One particular bit of the error log stood out to me as a potential issue - the app pool appeared to be closing (crashing?) and restarting during index updates.
If you'd like to see the full log I exported, we probably can provide it, but obviously need to be careful about divulging any client information, etc.
All nodes reverting to # 'hash' url 4.7.2 & 4.9
We are having a difficult issue with two sites, one running 4.7.2 and the other 4.9.
When making back office changes (most likely to doc types) the urls for nearly all pages reverts to a #
This has happened twice on the production instance of the 4.7.2 site.
Has anyone else encountered this issue. We are having to manage some tricky client relationship issues because of this.
Any help and support would be greatly appreciated.
Have you tried right-clicking on the "Content" root node and republish all?
Usually that situation happens when the XML cache got corrupted somehow.
Yes. We that's normally our default answer to most issues like this. However, in this case it does not clear the issue.
When nodes are '#' in the url they are also going to a 404 on the front end. This essentially brings the whole site down.
At this point we are avoiding the 'Republish All Nodes' option as we suspect that it might be causing the issue. This is very much trial and improvement to find the root of the problem.
Our main issue is client confidence in Umbraco at the moment. But this could be an issue specific to our setup. If any one else is having this issue at least we can rule that out.
Some hints:
We've had the same issue in the past. Basically, some publishing goes wrong and the XML cache does not get loaded. So, the back-end generates all urls as # and the front-end routes all pages to 404.
Have you checked the Umbraco log (table in the database)? The failed publishing _should_ log some exception in the log...
Have you tried hitting http;//YOURDOMAIN/Umbraco/dialogs/republish.aspx?xml=true to recreate the whole XML?
In our case, we had the XML of one document in the cmsContentXml table that was invalid XML--no idea why. So anytime the XML was reloaded from DB it failed, and we had to republish that precise node to fix the isse.
I see you mention it happen when making changes to doctypes : changes to doctypes can trigger long-running updates to the database, that at the moment can collide with updates made by some other users, and trash the XML. It's a bug.
Regenerating the whole XML should fix the issue. Maybe you'll have to manually republish some nodes.
In some cases we've decided not to do doctypes changes on the live database while users where editing content. Either we lock them out for a few minutes or we do it at night or...
They are really good points. Thanks Stephen.
The point that stands out is making changes to DocTypes. I suspect that if we are doing this while other developers/content editors are also making changes to content things can get messed up.
We are going to put in place a content freeze when making DocType changes and along with a database backup. I'll let you know if we still run into the issue with this safety net.
@Adam - we're experiencing the very same thing, we're now very nerous about updating doc types.
@Stephen - what you've said makes complete sense and it's a good idea to lock users out during doctype changes. The bug, do you know if it's on http://issues.umbraco.org? I've had a look but cant see anything. If it isnt I'll raise it.
Thanks both,
Chris.
We'll update you with some error logs shortly.
Created http://issues.umbraco.org/issue/U4-1002
Hey,
I work on the same dev team as Adam. We had this happen whilst I was doing a live release yesterday, so I collected some information about it.
What generally happened as far as I can remember:
example.com was showing the mobile site.
www.example.com was showing a .Net error yellow page - was this exception:
umbraco.requestHandler..ctor(XmlDocument umbracoContent, String url) +3715
umbraco.UmbracoDefault.Page_PreInit(Object sender, EventArgs e) +1293
The release started at 10:40 & finished at 10:42 according to Octopus, so I queried the Umb log from 10:35. (SELECT TOP 1000 * FROM umbracoLog WHERE Datestamp >= '2012-11-14 10:35:00' ORDER BY Datestamp)
One particular bit of the error log stood out to me as a potential issue - the app pool appeared to be closing (crashing?) and restarting during index updates.
See this log:
http://issues.umbraco.org/_persistent/Error%20log.xlsx?file=64-388
If you'd like to see the full log I exported, we probably can provide it, but obviously need to be careful about divulging any client information, etc.
is working on a reply...