Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Adam Prendergast 33 posts 77 karma points MVP c-trib
    Oct 08, 2012 @ 14:49
    Adam Prendergast
    0

    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.

  • Stephen 767 posts 2273 karma points c-trib
    Oct 08, 2012 @ 19:51
    Stephen
    0

    Have you tried right-clicking on the "Content" root node and republish all?

    Usually that situation happens when the XML cache got corrupted somehow.

  • Adam Prendergast 33 posts 77 karma points MVP c-trib
    Oct 09, 2012 @ 10:22
    Adam Prendergast
    0

    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.

  • Stephen 767 posts 2273 karma points c-trib
    Oct 09, 2012 @ 10:49
    Stephen
    0

    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...

  • Adam Prendergast 33 posts 77 karma points MVP c-trib
    Oct 09, 2012 @ 11:08
    Adam Prendergast
    0

    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.

  • Chris Gaskell 59 posts 142 karma points
    Oct 09, 2012 @ 11:08
    Chris Gaskell
    0

    @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.

  • Adam Prendergast 33 posts 77 karma points MVP c-trib
    Oct 09, 2012 @ 11:15
    Adam Prendergast
    0

    We'll update you with some error logs shortly.

  • Stephen 767 posts 2273 karma points c-trib
    Oct 09, 2012 @ 12:33
  • James Billingham 5 posts 25 karma points
    Nov 15, 2012 @ 15:58
    James Billingham
    0

    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:

    • I made some doc type changes - added some fields & renamed one of them. Assigned a template, but didn't set it as a default template
    • Deployed the release - used octopus deploy
    • Set the default template
    • New template not showing yet - as I'd expect, so clicked preview. This seemed to be this point where everything broke.

    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.

Please Sign in or register to post replies

Write your reply to:

Draft