Early this morning I woke up to a text from my boss telling me that our client's site was down. Every page in the site was throwing a 500 error error because of a NullReferenceException coming from the GetXmlNodeById call. It was odd because the site admin was working fine. I thought perhaps a content editor had deleted something critical but everything was in place and no one reported that they were working on the site at the time. Just to be sure, I did a database rollback and re-published the entire site -- same problem. Finally, upon inspection I noticed that that umbraco.config file was not in the ~/App_Data folder. I restored a backup of the file done a few hours before and suddenly the site started working again.
Any ideas on how the umbraco.config file could have suddenly gone missing? I thought that perhaps the application pool identity permissions weren't set correctly but they were.
I was content to move along with my fingers crossed until my boss asked me to setup a custom 404 page. I quickly discovered that any new document type I created wouldn't work. I could create a template, a document type, and then a document without a problem, but when I published that document, the generated firendly url was just a pound sign and the link obviously didn't work. I got a 404 whenever I clicked preview even though the document was published. Thinking I may have set something up wrong or named one of the objects something funny, I repeated the process with several different variations and the same result -- no working url.
Recently I upgraded the site frrom 4.7.0 to 4.7.1, hoping it would fix a separate problem with generated urls. It didn't so I had to implemented a workaround. I've noticed that when I create new documents of document types created before the 4.7.1 upgrade, the url generation and publishing work fine.
Not sure where to go from here. Wait on 4.7.2? When will that be? I imagine all the effort right now is going into getting 5.0 out the door.
That sure are some weird issues you're having there.
Umbraco 4.7.1.1 should be just right around the corner but I'm not sure the solution in your case is to upgrade as I'm not sure that will solve the issues you're experiencing.
Do you have some custom code running that interacts with the API somehow?
Are there other people working on the site or are you the only one doing development tasks?
Have you checked the log table to see if that give you some hints? And have you tried checking the event viewer on the server to see if that can give you any clues?
Also have you checked that you have not by mistake used a character like "-" in a documen type alias? Perhaps try and check the alias names in the database to see if there is a weird character in there, which I have a suspission could cause issues.
What caused your issue? How did you resolve it? I'm having a similar issue (well, maybe, our site had hash signs in place of friendly URLs but someone republished the site before we had a chance to look at the umbraco.config file).
Weird problems with 4.7.1
Early this morning I woke up to a text from my boss telling me that our client's site was down. Every page in the site was throwing a 500 error error because of a NullReferenceException coming from the GetXmlNodeById call. It was odd because the site admin was working fine. I thought perhaps a content editor had deleted something critical but everything was in place and no one reported that they were working on the site at the time. Just to be sure, I did a database rollback and re-published the entire site -- same problem. Finally, upon inspection I noticed that that umbraco.config file was not in the ~/App_Data folder. I restored a backup of the file done a few hours before and suddenly the site started working again.
Any ideas on how the umbraco.config file could have suddenly gone missing? I thought that perhaps the application pool identity permissions weren't set correctly but they were.
I was content to move along with my fingers crossed until my boss asked me to setup a custom 404 page. I quickly discovered that any new document type I created wouldn't work. I could create a template, a document type, and then a document without a problem, but when I published that document, the generated firendly url was just a pound sign and the link obviously didn't work. I got a 404 whenever I clicked preview even though the document was published. Thinking I may have set something up wrong or named one of the objects something funny, I repeated the process with several different variations and the same result -- no working url.
Recently I upgraded the site frrom 4.7.0 to 4.7.1, hoping it would fix a separate problem with generated urls. It didn't so I had to implemented a workaround. I've noticed that when I create new documents of document types created before the 4.7.1 upgrade, the url generation and publishing work fine.
Not sure where to go from here. Wait on 4.7.2? When will that be? I imagine all the effort right now is going into getting 5.0 out the door.
Hi Jason
That sure are some weird issues you're having there.
Umbraco 4.7.1.1 should be just right around the corner but I'm not sure the solution in your case is to upgrade as I'm not sure that will solve the issues you're experiencing.
Do you have some custom code running that interacts with the API somehow?
Are there other people working on the site or are you the only one doing development tasks?
Have you checked the log table to see if that give you some hints? And have you tried checking the event viewer on the server to see if that can give you any clues?
Also have you checked that you have not by mistake used a character like "-" in a documen type alias? Perhaps try and check the alias names in the database to see if there is a weird character in there, which I have a suspission could cause issues.
Hope some of these pointers can help you out.
/Jan
JasonN,
What caused your issue? How did you resolve it? I'm having a similar issue (well, maybe, our site had hash signs in place of friendly URLs but someone republished the site before we had a chance to look at the umbraco.config file).
is working on a reply...