I am running an instance of Umbraco 6.1.x and it has started throwing 404 on published pages.
My page structure is as follows,
Content
Home
About
Course
...
Component
Home
About
Course
Where component holds all resources and modules (HTML sections and stuff) for a page and using a partial view macro I dynamically load all components at runtime for a specific page.
We are facing an issue where we get 404 on every page after a full republish once we hit the HomePage. Before hitting home page they are all fine, but the moment we hit the homepage they are all throwing 404. By overriding the handlers I found out that they are hitting ~/umbraco/RenderMvc!
Any idea what can cause this?
Thanks in advance.
EDIT:
It is actually throwing:
No template exists to render the document at url '/'
considering the aforementioned scenario.
I have proper allowed template setup and property on nodes are showing the correct template associated with the respective items. Not sure why it's losing template info. I can force it to load under correct template using ?altTemplate=templateName.
Some pointers, we have a view in Views/Shared folder (apart from macro partials) tied to a surface controller.
One thing I would like to say is, we are using nested (library.RenderMacroContent with Umbraco markup) in our partial views and I have realized that the whole page throws 404 if there's a page with a link to the broken page which is broken (i.e. page got re-created and on t==e of the components is holding a link to the page with previous id). Suggestions?
did you get to the bottom of this? We're having exactly the same problem at the moment, on the same version of Umbraco.
I've noticed that when it happens, the umbraco.config becomes either corrupt or rolls back to a much, much earlier version, with all sorts of attributes missing. This lead us to believe it was a sync issue between the DB and umbraco.config.
We initially thought we had solved it by deleting App_Data > TEMP > ExamineIndex and recycling the app pool etc. Maybe give this ago, as it fixed it for a while for us, but alas, the demon has reared its ugly head once more. We are still in a full on dev stage though, so the constant changing may be complicating it further for us - perhaps it will be a fix for you.
If you have any more info, or even a fix, it would be greatly appreciated.
Cheers
EDIT:
Ok, I think I've solved this now, but only time will tell. Try emptying your recycle bin & then republish entire site.
I managed to consistently recreate the bug using IIS SEO site analysis. Each time I did this, the log threw up an error 'cannot find node id xyz', turns out that (and other) nodes were in the recycle bin. Upon emptying it the errors stopped. Good luck!
Related
The Problem
I have a website running in IIS. If I rename or delete one of the layout page .cshtml files under /Views/ the site immediately begins throwing following yellow screen error as expected
The layout page "_Layout.cshtml" could not be found at the following path: "~/Views/_Layout.cshtml".
What surprises me is that if I recreate or rename the file so it is exactly like it was before, the yellow screen persists. Why is this particular 500 error sticky?
I currently think that this has something to do with IIS and is specifically related to error handling. The site immediately detects that the layout page file is missing. It does not immediately realize when the file is back in place.
Thanks!
Some interesting clues
This happens on all of my sites I've tried this on so far. It isn't related to a specific site
I tried this on two websites at the same time. On one site I repeatedly and consistently refreshed the page hoping for a success. On the other, I left it alone for several minutes before checking again. The site I leave alone will resolve its problems and find the layout page on disk again. The site I continually make requests to appears to display the error indefinitely.
What I've tried
I have reproduced the problem on Umbraco websites using Umbraco's default routing as well as regular MVC pages using custom routing. The problem is the same for both.
I don't have output caching configured in IIS
When I am reproducing the yellow screen error, I am able to reproduce the error in multiple browsers, so I don't believe it is related to browser caching
I checked on the httpRuntime in the root web.config and the fcnMode is set to fcnMode="Single"
I've fiddled around with the web.config customErrors and httpErrors. Nothing I've done here has affected the problem.
I am able to reproduce the problem on websites where there is no custom code for caching. No CDN. No load balancer.
Versions
IIS: I have reproduced the problem on Windows Server 2012R2 running IIS 8 and Windows 11 running IIS 10
CMS: All of the websites I have tested on so far are Umbraco 7 sites. However, I have reproduced the problem on pages that are routed using Umbraco's out of the box routing as well as pages that are just set up using MVC and aren't leveraging Umbraco.
It appears to be part of the behavior of FcnMode="Single". See https://learn.microsoft.com/en-us/dotnet/api/system.web.configuration.fcnmode?view=netframework-4.8. It isn't an issue with caching. It is a problem with the way that the site's file change notifications (FCN) are configured.
The sticky 500 behavior on renaming files happens when I use FcnMode="Single" but not when I use FcnMode="Default".
FcnMode="Single" will result in only a single object to monitor file changes. This single object is responsible for monitoring changes to files in the main directory and sub directories.
FcnMode="Default" will result in a separate object to monitor file changes for each directory.
Umbraco sites, by default, use FcnMode="Single". This makes sense because Umbraco sites cache under very deeply nested directories in /App_Data/. This can result in so many of these monitors that it can affect the performance of the site. There is a great explanation of FcnMode and why it matters for Umbraco here: https://shazwazza.com/post/all-about-aspnet-file-change-notification-fcn/
Unfortunately, it appears that the single file monitor can miss renames of files in some cases.
My umbraco backoffice application is not loading the content tree all of the sudden. I can't figure what I would have done to make this stop working.
When I open backoffice, a request to the following URL is failing
umbraco/UmbracoTrees/ApplicationTree/GetApplicationTrees?application=content&tree=&isDialog=false
This is the message that's coming back:
)]}',
{"tree.String":"A value is required but was not present in the request."}
I don't have a lot to work with here... I've tried deleting cookies and rebuilding the app but I'm not having any luck. I really need to get this working ASAP...
I figured out what the problem was...
I added a filter to the HttpConfiguration on start up and it make BackOffice quit working. The filter simply validated any models passed to WebAPI. Oh well, I don't really have time to look into anymore so I'm just not going to use the filter...
Ok, I'm building a PoC for an ASP.NET MVC 4 mobile application that needs to have offline capabilities, and I have several questions about whether I'm designing the application correctly and also what behavior I will get from the cache manifest.
I'm progressing with the PoC but I'm observing a weird behavior on a working controller action right after adding the manifest attribute to my Layout.cshtml.
Before adding the attribute, every time I requested that URL, a breakpoint I had on the controller action would be hit just once every time. After adding it, the breakpoint is being hit 3 times the first time the page is requested (first time ever), and it is no longer hit at all until I manually delete the local cached manifest.
Nothing else changed, so this makes me believe that this type of offline caching works differently that the regular way in which browsers cache works. I'm thinking that since the page I'm visiting is listed on the manifest, the breakpoint is hit the first time because I requested the page, and then a second time because it is listed on the manifest.
That is weird already. Why is that?
Besides that, why is it being hit a third time?
I've verified that the behavior goes away if I manually delete the locally cached manifest and also remove the manifest attribute from the html tag, so this is most likely the culprit.
Can anyone explain what's going on please? Thanks.
Well, no one replied and I was no longer able to reproduce the breakpoint being hit 3 times, although I'm sure it happened a few times.
And yes, appcache or html manifest caching works in a different way than regular caching.
With the first visit a page, that had the manifest attribute on its html tag, the same page being listed on the manifest made a request to the server for the same page.
I'm making the answer a wiki in case someone wants to add anything.
I have about 50 pages in my Umbraco site and for some reason all of the URLs went from being based on the site structure to either just # or just the id of the page, like /1083
What would have caused that to happen and how can I fix it now?
Also, it would be nice to understand how these URLs get created if there is some method somewhere that manages it or they are in the database somewhere.
Delete the App_Data/umbraco.config file and then go into the admin and republished the whole site.
Thanks #Pauli
I'm stuck with a bug at the moment which is puzzling me. I have a
layout containing some HTML and a partial (for the navigation) - there
is nothing else there other than the yield.
If the nav is included as a partial I get nothing returned to the
browser at all (blank page) but everything else appears normal
If I remove the partial the page works fine
If I put the nav code directly in the template it works fine
if I replace the nav code in the partial with a simple string, I get
a blank page again.
Does anyone have any ideas as to what the problem could be, or know how
I might debug it?
Found the issue, the partial was in the layouts folder, instead of the
relevant controller views folder.
However, Rails was throwing a ActionView::MissingTemplate Exception
which was only visible via the debugger which is probably a bug.
First off, check the log file to see if you're getting an error message somewhere. If that doesn't help follow these steps:
Make a copy of your template & partial, linked as the original
Test that they exhibit the problem
Start removing things from them until you have the simplest possible case that still exhibits the problem (your string in the partial test is a step in this direction)
If you don't figure it out in that process, come back and edit your question to include the code for the simplified case
I have had this error on a number of occasions. The problem has always been solved by changing something in the offending template or one of it's partials (in my latest case, I added a blank line into the source between a </div> and a <div>, which was in a partial invoked by the template; changing the template itself had no effect). The really odd thing is that the problem rarely occurs when I actually change a template, but usually when I change something related (e.g. edit an image displayed in the page or the CSS relating to the page). While the problem is often related to a partial, the entire page is blank, not just the portion provided by the partial.
BTW, restarting the web server (in this case Unicorn) does not fix the problem. Running Ruby 1.9.3, Rails 3.1.3. Using SASS and Unicorn.
UPDATE: Just determined that Rails is returning a 304-not modified, based upon the "If-none-match" header sent by my browser (which in turn was based upon the ETAG of the previous page). However, in the meantime, the browser cleared the window. So, presumably, something in what Rails sent caused the browser to clear the window.