CMS nodes Not holding on to updates. Change not showing in Umbraco.config v6.16
Environment:
Our client is running an Umbraco v6.16 instance configured for Web Forms in
IIS. The site is not load balanced.
Problem: When we make changes to a node in the CMS and then save and publish it, we
see the message that it has been saved and published successfully, but the node
doesn’t always show or hold on to the updates.
Additionally the changes do not show up in Frontend
of the site. We tried several “Republish Entire Site” commands, “Reload Nodes” commands,
logging out and logging back in, and even clearing our browser cache but to no
avail.
The only thing that seems to work is if we “leave it
alone”. Eventually the changes show up in Umbraco.config. Nodes will show and hold on to the changes in the CMS
and then show up in the front end of the site.
What we know is happening: We were able to confirm the changes show up in the Examine Indexes, we unable
to confirm if they show up in the database yet, but that will be our next check
once we get access.
We grabbed a copy of the umbraco.config and were able
to confirm that the changes were not being written there.
Possible Suspicion: We're having our client’s server admin check the permissions to umbraco.config and
App_Data folder as described in this
stackoverflow article as it seems
very similar to what we are experiencing.
Anyone have any thought on what could be causing this or items we should check?
Are you by any chance running a multisite setup where the changes that don't appear are made when logged in using the url for site A and you're changing something on site B?
EDIT: Have you checked the /App_Data/Logs file to see if it reveals any entries marked with ERROR or WARNING?
I am thinking since you don´t getting the changes written into the umbraco.config, could it be a permission issue on the files. Make sure that you have the right permissions on the folder and files in your Umbraco installation.
Yeah, I actually thought you were already aware of potential issues with permissions since you mentioned what you had asked your hosting provider to check already.
In general the network service and iusr accounts should have modify/full permission on the root folder containing the Umbraco installation inheriting all the way down.
IIS 7.5 should not be an issue.
Btw...Is it a MSSQL database server the site is running on? Or is it using CE SQL?
Our client's server admin said that IIS 7.5 has a different security model and that he "added the app pool user to the IIS_IUSRS security group". This seemed to resolve our issue for content related changes not saving.
However we are still seeing this happen, but only in relation to role based protection on individual nodes.
We have two groups members can belong to, Group A and Group B. Our nodes are locked down to role based protection.
If we have a node that is visible to both groups, we then will attempt to change the setting so that only the Group B can see it, and then save the node.
Not only can the Group A members still see the node after we’ve saved the setting, but when we reload the node list and look at the groups for that particular node, it has "reverted" to Group A and Group B setting again.
Is this something also that is kept track of in the umbraco.config? Where could I view this in the back end to confirm what is or is not being set when we modify the groups allowed to view a node? I've already checked the Umbraco Logs and see nothing relating to the role based protection during the times we see these issues occur.
Okay so I have some more information to augment my last post.
I found that access is set in the access.config under ~/App_Data. I was able to confirm that once the Public Access is set on a node to Role Based protection that does indeed get updated correctly in this file.
However when you try to navigate back to that same node and choose “Public Access”, instead of bringing up “Role Based Protection” modal, it again asks you “Choose how to restrict access to this page” as if it were never set in the first place.
We’ve implemented a lot of different caching techniques on this site (server and client side). Is it possible one of those cofigurations is causing this strange behavior we are seeing in the CMS for content and node access not “sticking”? I’ve never seen this issue with one of our Umbraco instances before.
Ok, seems like you're still having permission issues.
What users is running the app pool? And have the hosting company setup permissions as I suggested in my previous response? What server software is being used?
The other instances...are they hosted at the same place? If so you could ask them to look what differences there are in this setup and another setup that works without any issues. If permissions, frameworks etc. are not correct then Umbraco will not work as expected. And I'm confident it's still down to permissions so it would be a really good idea to double check.
If it is possible could you then ask them to give full access to the everyone role just to see if that fixes it? If it does then we know for sure it's a permission issue and you will of course need to ask them to remove access for the everyone role again and then ask them to setup permissions for the network service and the iusr (Not the group) and it needs to be set on the root folder containing Umbraco and be inherited all the way down to the deepest level.
Also make sure that the application pool is being run by the network service.
We sent our client's server admin the information on the permissions, and he verified that the all of the Umbraco folders should have the correct premissions set on them.
Before I go back to him and have him check the permissions yet again, I wanted to provide a few more details. I spent some time recreating this and digging through the Umbraco Logs to try and get a better understanding and provide more details here.
1. Save and Publish node 6772
This results in the following logged in Umbraco Log:
2015-01-20 13:02:55,249 [9] INFO Umbraco.Core.Publishing.PublishingStrategy - [Thread 75] Content 'Test Resource' with Id '6772' has been published.
2. Navigate to a different node
3. Navigate back to node 6772.
Everything Looks fine, Properties are still set correctly and the URL for the node has generated fine
4. Navigate to a different node
5. Navigate back to node 6772.
Now, Some of the Properties of that Node do not appear anymore, or appear empty
When this happens, the "Opps this content is published but not in the cache (Internal Error)" Message appears, and the following gets logged in the Umbraco Log:
2015-01-20 13:05:06,359 [5] WARN Umbraco.Web.Routing.DefaultUrlProvider - [Thread 55] Couldn't find any page with nodeId=6772. This is most likely caused by the page not being published.
6. Navigate to a different node
7. Navigate back to node 6772.
Everything Looks fine, Properties are still set correctly and the URL for the node has generated fine
Basically whenever I navigate back to node 6772. I'll get different behavior, sometimes the properties are there, and sometimes they are not. There seems to be no rhyme or reason to when it decides to show them.
I can still confirm that the values I selected when I originally Saved and Published are indexed. It seems that they are not presented/loaded every time I look at the node though. Nothing else in the Umbraco Log looks like it might pertain to this.
With these additional details, does this still sound like it could be a permissions issue?
Ok, thanks for the detailed information. I don't think that this is a permission issue so no need to contact the admin again.
So this node with the id of 6772...is there anything special about it? Does it make use of a custom datatype that you have developed yourself? Or from a 3rd party package? Have it been set to be published / unpublished at a specific date?
Perhaps it's worth try to do this
1: Go to the App_Data/TEMP directory and delete the files in it
2: Go to the /config/ClientDependency.config and increment the version number attribute
3: Recycle the app pool
4: Login to the backoffice and go to the developer section and use the "Examine" dashboard to the upper right to rebuild the indexes
5: Finish of by publishing the node again and then going to the "Republish entire site" option when right clicking the default "CONTENT" node.
Does this help? I'm just making sure that everything is cleared - it's not sure that any of the steps work but it's worth trying I think.
So with the exception of incrementing the version number attribute in ClientDependency.config, we coordinated with our client's server admin and did the following a couple days ago:
Stopped website in IIS.
Emptied contents of the App_Data/TEMP folder
Deleted Umbraco.config
Rebooted the Server
After Server Reboot and site came back up we published a node
Rebuilt all Examine Indexes Manually in Developer Section
Executed "Republish entire site"
Would it be worth trying this process again just to set the version increment in Client Dependency, even if that folder has been entirely rebuilt?
Node 6772 does have a custom datatype property, an Xpath Checkbox List with CSV as the storage type. However this behavior is happening across all nodes and even text field datatype properties, so we did not think it was related.
Are there any other details I can provide you?
Thank you very much for all your assistance on this.
Sorry if I have suggested this before or if you have already done this. But I think that you should just try to increment the version number in the /config/ClientDependency.config file on the live server and recycle the app pool since you have already tried all the other stuff.
However the issue might be related to the custom datatype somehow. Don't know if it's possible for you to debug the live environment somehow? Or perhaps make a dump of the database and try running an exact copy of the live site on your local instance in order to see if you can reproduce and then debug locally?
So I just wanted to follow up on this with some more details, just in case someone else has a similar issue. Seems like the issue is still occurring, but we were able to trace the start of issue back to some configurations our client's server admin made in the web.config.
Our client has a custom app also running on this server. The server admin added some location settings to the web.config so that Umbraco wouldn't conflict with their custom app. Whatever they added ended up blocking ClientDependency, which broke the umbraco backoffice. We were able to login, but the backoffice styling was shot and essentially unusable.
The client's server admin took those changes out of the web.config and the backoffice was restored, but then we started experiencing the saving issue, seems like it was never the same after that. At this point we don't believe it's directly Umbraco related.
I know this is a really old post, but it might help someone else in the future. I had nearly exactly the same faults, right up to the last few bits, and I did find the cause and a fix. Please see the post below.
CMS nodes Not holding on to updates. Change not showing in Umbraco.config v6.16
Environment:
Our client is running an Umbraco v6.16 instance configured for Web Forms in IIS. The site is not load balanced.
Problem:
When we make changes to a node in the CMS and then save and publish it, we see the message that it has been saved and published successfully, but the node doesn’t always show or hold on to the updates.
Additionally the changes do not show up in Frontend of the site. We tried several “Republish Entire Site” commands, “Reload Nodes” commands, logging out and logging back in, and even clearing our browser cache but to no avail.
The only thing that seems to work is if we “leave it alone”. Eventually the changes show up in Umbraco.config. Nodes will show and hold on to the changes in the CMS and then show up in the front end of the site.
What we know is happening:
We were able to confirm the changes show up in the Examine Indexes, we unable to confirm if they show up in the database yet, but that will be our next check once we get access.
We grabbed a copy of the umbraco.config and were able to confirm that the changes were not being written there.
Possible Suspicion:
We're having our client’s server admin check the permissions to umbraco.config and App_Data folder as described in this stackoverflow article as it seems very similar to what we are experiencing.
Anyone have any thought on what could be causing this or items we should check?
Hi Robbievgb
Are you by any chance running a multisite setup where the changes that don't appear are made when logged in using the url for site A and you're changing something on site B?
EDIT: Have you checked the /App_Data/Logs file to see if it reveals any entries marked with ERROR or WARNING?
/Jan
Hi robbievgb,
I am thinking since you don´t getting the changes written into the umbraco.config, could it be a permission issue on the files. Make sure that you have the right permissions on the folder and files in your Umbraco installation.
You can see an overview over file and folder permissions requirements here: http://our.umbraco.org/wiki/reference/files-and-folders/permissions and the miniums requirements for Umbraco 6, is also met http://our.umbraco.org/documentation/Installation/system-requirements
Hope this helps,
/Dennis
Hi again robbievgb,
I have found this thread http://stackoverflow.com/questions/13643493/umbraco-config-file-is-not-being-written-published on StackOverflow, that perhaps could help you, I can see in a vanilla Umbraco 6,1,6 the umbracoContentXMLUseLocalTemp set to false in the web.config file.
You could try to change the value to true, and see if it solve your issue like it did for the people in the post from StackOverflow.
Hope this helps,
/Dennis
Thanks! I'm working on Checking the Logs. I'll review the permissions and send them over to our client's server admin.
Also I've learned that this is running under IIS 7.5 if that makes any difference.
Hi Robbievgb
Yeah, I actually thought you were already aware of potential issues with permissions since you mentioned what you had asked your hosting provider to check already.
In general the network service and iusr accounts should have modify/full permission on the root folder containing the Umbraco installation inheriting all the way down.
IIS 7.5 should not be an issue.
Btw...Is it a MSSQL database server the site is running on? Or is it using CE SQL?
/Jan
Thanks everyone for your replies.
Our client's server admin said that IIS 7.5 has a different security model and that he "added the app pool user to the IIS_IUSRS security group". This seemed to resolve our issue for content related changes not saving.
However we are still seeing this happen, but only in relation to role based protection on individual nodes.
We have two groups members can belong to, Group A and Group B. Our nodes are locked down to role based protection.
If we have a node that is visible to both groups, we then will attempt to change the setting so that only the Group B can see it, and then save the node.
Not only can the Group A members still see the node after we’ve saved the setting, but when we reload the node list and look at the groups for that particular node, it has "reverted" to Group A and Group B setting again.
Is this something also that is kept track of in the umbraco.config? Where could I view this in the back end to confirm what is or is not being set when we modify the groups allowed to view a node? I've already checked the Umbraco Logs and see nothing relating to the role based protection during the times we see these issues occur.
Okay so I have some more information to augment my last post.
I found that access is set in the access.config under ~/App_Data. I was able to confirm that once the Public Access is set on a node to Role Based protection that does indeed get updated correctly in this file.
However when you try to navigate back to that same node and choose “Public Access”, instead of bringing up “Role Based Protection” modal, it again asks you “Choose how to restrict access to this page” as if it were never set in the first place.
We’ve implemented a lot of different caching techniques on this site (server and client side). Is it possible one of those cofigurations is causing this strange behavior we are seeing in the CMS for content and node access not “sticking”? I’ve never seen this issue with one of our Umbraco instances before.
Hi Robbievgb
Ok, seems like you're still having permission issues.
What users is running the app pool? And have the hosting company setup permissions as I suggested in my previous response? What server software is being used?
The other instances...are they hosted at the same place? If so you could ask them to look what differences there are in this setup and another setup that works without any issues. If permissions, frameworks etc. are not correct then Umbraco will not work as expected. And I'm confident it's still down to permissions so it would be a really good idea to double check.
If it is possible could you then ask them to give full access to the everyone role just to see if that fixes it? If it does then we know for sure it's a permission issue and you will of course need to ask them to remove access for the everyone role again and then ask them to setup permissions for the network service and the iusr (Not the group) and it needs to be set on the root folder containing Umbraco and be inherited all the way down to the deepest level.
Also make sure that the application pool is being run by the network service.
Hope this helps.
/Jan
Thank you Jan.
We sent our client's server admin the information on the permissions, and he verified that the all of the Umbraco folders should have the correct premissions set on them.
Before I go back to him and have him check the permissions yet again, I wanted to provide a few more details. I spent some time recreating this and digging through the Umbraco Logs to try and get a better understanding and provide more details here.
1. Save and Publish node 6772
This results in the following logged in Umbraco Log:
2015-01-20 13:02:55,249 [9] INFO Umbraco.Core.Publishing.PublishingStrategy - [Thread 75] Content 'Test Resource' with Id '6772' has been published.2. Navigate to a different node
3. Navigate back to node 6772.
Everything Looks fine, Properties are still set correctly and the URL for the node has generated fine
4. Navigate to a different node
5. Navigate back to node 6772.
Now, Some of the Properties of that Node do not appear anymore, or appear empty
When this happens, the "Opps this content is published but not in the cache (Internal Error)" Message appears, and the following gets logged in the Umbraco Log:
2015-01-20 13:05:06,359 [5] WARN Umbraco.Web.Routing.DefaultUrlProvider - [Thread 55] Couldn't find any page with nodeId=6772. This is most likely caused by the page not being published.6. Navigate to a different node
7. Navigate back to node 6772.
Everything Looks fine, Properties are still set correctly and the URL for the node has generated fine
Basically whenever I navigate back to node 6772. I'll get different behavior, sometimes the properties are there, and sometimes they are not. There seems to be no rhyme or reason to when it decides to show them.
I can still confirm that the values I selected when I originally Saved and Published are indexed. It seems that they are not presented/loaded every time I look at the node though. Nothing else in the Umbraco Log looks like it might pertain to this.
With these additional details, does this still sound like it could be a permissions issue?
Hi Robbie
Ok, thanks for the detailed information. I don't think that this is a permission issue so no need to contact the admin again.
So this node with the id of 6772...is there anything special about it? Does it make use of a custom datatype that you have developed yourself? Or from a 3rd party package? Have it been set to be published / unpublished at a specific date?
Perhaps it's worth try to do this
1: Go to the App_Data/TEMP directory and delete the files in it 2: Go to the /config/ClientDependency.config and increment the version number attribute 3: Recycle the app pool 4: Login to the backoffice and go to the developer section and use the "Examine" dashboard to the upper right to rebuild the indexes 5: Finish of by publishing the node again and then going to the "Republish entire site" option when right clicking the default "CONTENT" node.
Does this help? I'm just making sure that everything is cleared - it's not sure that any of the steps work but it's worth trying I think.
/Jan
Jan,
So with the exception of incrementing the version number attribute in ClientDependency.config, we coordinated with our client's server admin and did the following a couple days ago:
Would it be worth trying this process again just to set the version increment in Client Dependency, even if that folder has been entirely rebuilt?
Node 6772 does have a custom datatype property, an Xpath Checkbox List with CSV as the storage type. However this behavior is happening across all nodes and even text field datatype properties, so we did not think it was related.
Are there any other details I can provide you?
Thank you very much for all your assistance on this.
-Robbie
Hi Robbie
Sorry if I have suggested this before or if you have already done this. But I think that you should just try to increment the version number in the /config/ClientDependency.config file on the live server and recycle the app pool since you have already tried all the other stuff.
However the issue might be related to the custom datatype somehow. Don't know if it's possible for you to debug the live environment somehow? Or perhaps make a dump of the database and try running an exact copy of the live site on your local instance in order to see if you can reproduce and then debug locally?
/Jan
So I just wanted to follow up on this with some more details, just in case someone else has a similar issue. Seems like the issue is still occurring, but we were able to trace the start of issue back to some configurations our client's server admin made in the web.config.
Our client has a custom app also running on this server. The server admin added some location settings to the web.config so that Umbraco wouldn't conflict with their custom app. Whatever they added ended up blocking ClientDependency, which broke the umbraco backoffice. We were able to login, but the backoffice styling was shot and essentially unusable.
The client's server admin took those changes out of the web.config and the backoffice was restored, but then we started experiencing the saving issue, seems like it was never the same after that. At this point we don't believe it's directly Umbraco related.
Hi Guys,
I know this is a really old post, but it might help someone else in the future. I had nearly exactly the same faults, right up to the last few bits, and I did find the cause and a fix. Please see the post below.
https://our.umbraco.org/forum/using-umbraco-and-getting-started//76922-umbraco-not-updating-correctly-after-a-save#comment-245893
Happy hunting.
is working on a reply...