I'm in the process of upgrading an installation of 4.7.2 to 4.11.8 and have run into some issues, one of them being that nodes are being misrepresented in the tree - some are appearing as unpublished (with greyed out text) when they are not. I can make changes to these nodes and publish them (with the changes being reflected on the front-end), but they still appear greyed out. Has anyone run into this issue at all?
I've done a couple of upgrades to 4.11.8 and have not seen this yet.
However I've done the upgrades incrementally going from 4.7.2 to 4.8 and onward to 4.9, 4.10 and then 4.11.
I know there was a weird issue with this in 4.9 I think, which was fixed for good in 4.10 - So I'm a bit puzzled about this. But could you tell us a bit more about the upgrade path you took and wether or not you have merged the config files in the /config/ folder?
Sometimes you also need to clear cookies and try to delete the templ files in the /app_data/TEMP/ClientDependency folder and increment the version number in /config/ClientDependency.config file as well.
Hope these pointers help - Looking forward to hearing from you.
Thanks for you reply. I've upgraded straight from 4.7.2 and followed the instructions for upgrading from the Documentation section of Our. I did read about the issue in 4.9 and got my hopes up that this could have been the issue, but yeah, as you say, it's been fixed!
I've cleared the temp files from the temp ClientDependency folder and that's not made a difference. I'm going to have a dig into to the logs to see if there are any oddities there.
I'm reluctant to go through the database and manually update the records for each node, but I'm not sure what else I can do? Has anyone else come across this issue?
So to get around this problem I just ran a simple linqpad script against my database:
var DimNodes = CmsDocuments.Where(x=>x.Published && x.Node.Trashed).Select(x=>x.Node);
foreach(var Item in DimNodes) { Item.Trashed = false; }
SubmitChanges();
This retrieves all pages that are marked as trashed as well as published and then marks them as not being trashed.
Interestingly, in the backup of the database these nodes are still marked as published and trashed but did not appear as unpublished in the tree. I've done some digging in the source of 4.11.8 and have found that a Document publication status is determined by a method called 'HasPublishedVersion', which checks to see if the cmsDocument is published, and the umbracoNode is not trashed. As my nodes were marked as published and trashed, they were not seen as a 'published version' by Umbraco, and as a result when the node was being rendered by the BaseContentTree class, it was being marked as unpublished. I guess that the way the publication status (and subsequent node style in the tree) was figured out differently in 4.7.2!
The only thing I'm unsure of now is how my nodes got to be published and trashed at the same time in the first place?
Node names appearing greyed out in 4.11.8
Hi,
I'm in the process of upgrading an installation of 4.7.2 to 4.11.8 and have run into some issues, one of them being that nodes are being misrepresented in the tree - some are appearing as unpublished (with greyed out text) when they are not. I can make changes to these nodes and publish them (with the changes being reflected on the front-end), but they still appear greyed out. Has anyone run into this issue at all?
Thanks,
Braydie
Hi Braydie
I've done a couple of upgrades to 4.11.8 and have not seen this yet.
However I've done the upgrades incrementally going from 4.7.2 to 4.8 and onward to 4.9, 4.10 and then 4.11.
I know there was a weird issue with this in 4.9 I think, which was fixed for good in 4.10 - So I'm a bit puzzled about this. But could you tell us a bit more about the upgrade path you took and wether or not you have merged the config files in the /config/ folder?
Sometimes you also need to clear cookies and try to delete the templ files in the /app_data/TEMP/ClientDependency folder and increment the version number in /config/ClientDependency.config file as well.
Hope these pointers help - Looking forward to hearing from you.
/Jan
Hi Jan,
Thanks for you reply. I've upgraded straight from 4.7.2 and followed the instructions for upgrading from the Documentation section of Our. I did read about the issue in 4.9 and got my hopes up that this could have been the issue, but yeah, as you say, it's been fixed!
I've cleared the temp files from the temp ClientDependency folder and that's not made a difference. I'm going to have a dig into to the logs to see if there are any oddities there.
Thanks,
Braydie
I've found that I have the same issue as noted here: http://our.umbraco.org/forum/ourumb-dev-forum/bugs/38072-After-upgrade-published-nodes-appear-as-unpublished
I'm reluctant to go through the database and manually update the records for each node, but I'm not sure what else I can do? Has anyone else come across this issue?
So to get around this problem I just ran a simple linqpad script against my database:
This retrieves all pages that are marked as trashed as well as published and then marks them as not being trashed.
Interestingly, in the backup of the database these nodes are still marked as published and trashed but did not appear as unpublished in the tree. I've done some digging in the source of 4.11.8 and have found that a Document publication status is determined by a method called 'HasPublishedVersion', which checks to see if the cmsDocument is published, and the umbracoNode is not trashed. As my nodes were marked as published and trashed, they were not seen as a 'published version' by Umbraco, and as a result when the node was being rendered by the BaseContentTree class, it was being marked as unpublished. I guess that the way the publication status (and subsequent node style in the tree) was figured out differently in 4.7.2!
The only thing I'm unsure of now is how my nodes got to be published and trashed at the same time in the first place?
We just had this issue, in the following circumstance:
What happened:
The items were marked as Trashed in the DB even though they weren't in the recycle bin. They had a valid position on the content tree.
Solution:
is working on a reply...