I'm experiencing a strange error. When I save and publish a node, the changes I make aren't reflected in the umbraco.config XML file. The server seems to regenerate the XML file because Visual Studio asks me if I want to refresh the file when I have it open, but the changes are not there in the XML file - it's just the old values.
The only way to make the changes visible in umbraco.config is to use "Republish entire site" or just delete umbraco.config to force a new one to be created.
I'm running umbraco v
4.5.2 (Assembly version: 1.0.3891.20719) on a Window 2008/IIS7 server. The application pool is ASP.NET 4.0 with integrated piplelines and NETWORK SERVICE is the user that is set as its identity. NETWORK SERVICE has been granted full access to all the folders it needs and I have double checked that this is true both for the App_Data folder and the umbraco.config file.
I have also checked the cache settings for my macros. The cache period is set to 0 and the "Cache by page" is checked. I think this is the default setting.
Installed packages: Umbraco Contour and Umbraco Log Mangager for Umbraco V 4.
Please help me out with this one - it has me stumped!
Right clicked on the top node and selected "Publish". In this dialog I told it to publish all subpages and include unpublished child pages.
After this everything is back to normal and changes I make to the pages are reflected directly after I save and publish. Just to clarify - I did this once and after that everything is back to normal. I also emptied the trashcan but I'm not sure that it had anything to do with the solution of this problem.
Is is reproduceable and/or deterministic, ie does it happen for every document of the installation, every time you save-and-publish?
Makes me think about some try {...} catch {...} blocks in Umbraco, that catch the exception, and do nothing of it, So it seems that the save-and-publish went well, but actually only part of it took place--and you don't know it. Not 100% sure about it, but we faced similar issues in the past. You'd need to run a debug build of Umbraco, in Visual Studio debug mode, to track the exception...
I have experienced the same thing a couple of times with v4.5.2 (and I think also with 4.0.3). Somehow a node gets corrupted and then publishing/sorting and other things may not work on itself and other nodes on the same level and below. I use the term "may not" because sometimes it may only be half of the nodes on the same level that gets affected.
I have thought it being dependent on which order they are present in the xml - but this is not something I know for sure.
As Thomas Kahn states you can fix the problem with a manuel unpublish/publish on the corrupted node.
The problem has been difficult to pinpoint, because you doesn't notice the problem untill next time you want to update the nodes. If it can help anyone looking more thoroughly into the problem, I have experienced it once when I copied a node and the copy turned up corrupted. I immediately afterwards deleted the corrupted node and did another copy on the same node, and it worked perfectly. Very odd indeed.
It sounds like this is something that should be submitted as a bug on Codeplex(?) But as you say, it's difficult to pinpoint these types of weird errors.
This reminds me of an issue I had a couple months ago.
The client had deleted a bunch of nodes, which of course unpublished those nodes. They recreated the nodes with the same name, and then accidentally somehow managed to publish some nodes from the recycle bin. They must have been copying and pasting or something.
Anyway, this resulted in the recycle bin nodes being published. Even if you hit publish on the non-bin node, you'll still see the content from the bin node.
I think recycle bin nodes should be disabled from any edits, saving or publishing.
ps. Oh and what was also interesting was the client deleted some of the new nodes but the pages remained viewable. It took some thinking to figure out what the hell was going on.
Save and publish does not alter umbraco.config
Hi!
I'm experiencing a strange error. When I save and publish a node, the changes I make aren't reflected in the umbraco.config XML file. The server seems to regenerate the XML file because Visual Studio asks me if I want to refresh the file when I have it open, but the changes are not there in the XML file - it's just the old values.
The only way to make the changes visible in umbraco.config is to use "Republish entire site" or just delete umbraco.config to force a new one to be created.
I'm running umbraco v 4.5.2 (Assembly version: 1.0.3891.20719) on a Window 2008/IIS7 server. The application pool is ASP.NET 4.0 with integrated piplelines and NETWORK SERVICE is the user that is set as its identity. NETWORK SERVICE has been granted full access to all the folders it needs and I have double checked that this is true both for the App_Data folder and the umbraco.config file.
I have also checked the cache settings for my macros. The cache period is set to 0 and the "Cache by page" is checked. I think this is the default setting.
Installed packages: Umbraco Contour and Umbraco Log Mangager for Umbraco V 4.
Please help me out with this one - it has me stumped!
Regards,
Thomas Kahn
Is it the same with all sites on the server or only this installation? :)
No, only in this installation, but this is the only umbraco v 4.5.2 installation on the server.
/Thomas
Now I have it working!
Here's what I did:
After this everything is back to normal and changes I make to the pages are reflected directly after I save and publish. Just to clarify - I did this once and after that everything is back to normal. I also emptied the trashcan but I'm not sure that it had anything to do with the solution of this problem.
/Thomas Kahn
Is is reproduceable and/or deterministic, ie does it happen for every document of the installation, every time you save-and-publish?
Makes me think about some try {...} catch {...} blocks in Umbraco, that catch the exception, and do nothing of it, So it seems that the save-and-publish went well, but actually only part of it took place--and you don't know it. Not 100% sure about it, but we faced similar issues in the past. You'd need to run a debug build of Umbraco, in Visual Studio debug mode, to track the exception...
I have experienced the same thing a couple of times with v4.5.2 (and I think also with 4.0.3). Somehow a node gets corrupted and then publishing/sorting and other things may not work on itself and other nodes on the same level and below. I use the term "may not" because sometimes it may only be half of the nodes on the same level that gets affected.
I have thought it being dependent on which order they are present in the xml - but this is not something I know for sure.
As Thomas Kahn states you can fix the problem with a manuel unpublish/publish on the corrupted node.
The problem has been difficult to pinpoint, because you doesn't notice the problem untill next time you want to update the nodes. If it can help anyone looking more thoroughly into the problem, I have experienced it once when I copied a node and the copy turned up corrupted. I immediately afterwards deleted the corrupted node and did another copy on the same node, and it worked perfectly. Very odd indeed.
/Rune
It sounds like this is something that should be submitted as a bug on Codeplex(?) But as you say, it's difficult to pinpoint these types of weird errors.
/Thomas
This reminds me of an issue I had a couple months ago.
The client had deleted a bunch of nodes, which of course unpublished those nodes. They recreated the nodes with the same name, and then accidentally somehow managed to publish some nodes from the recycle bin. They must have been copying and pasting or something.
Anyway, this resulted in the recycle bin nodes being published. Even if you hit publish on the non-bin node, you'll still see the content from the bin node.
I think recycle bin nodes should be disabled from any edits, saving or publishing.
ps. Oh and what was also interesting was the client deleted some of the new nodes but the pages remained viewable. It took some thinking to figure out what the hell was going on.
is working on a reply...