We have moved to GitHub Issues
Created by Mads Krohn 04 Dec 2013, 13:47:33 Updated by Martin Fenton 08 Sep 2015, 14:59:44
Relates to: U4-2108
Relates to: U4-7076
When you unpublish a page that has descendants and afterwards want to publish that page again, the descendants will not be re-added to the xml cache, instead showing the message "Oops: this document is published but is not in the cache (internal error)". The odd thing is, that this is only true for descendants, not immediate children. It seems somewhat similar to an error I reported back in version 6.0.4 -> http://issues.umbraco.org/issue/U4-2108 The xml cache can be re-synced by either publishing all documents again or by publishing the entire site from the root content node.
Experiencing this issue too with v6.1.6
Reproduced on 7.1.1.
In Umbraco.Web.Strategies.Publishing.UpdateCacheAfterPublish we do hit PublishingStrategy_Published. If we manually change e.IsAllRepublished to true, then descendants are back in the cache, else they are not.
So it's down do DistributedCache.Instance.RefreshPageCache(...) not doing its job? Goes to DefaultServerMessenger.PerformRefresh
Ends up in content.Instance.UpdateDocumentCache... and there, PublishNodeDo does NOT add the node to the XML.
Because it cannot find the parent in the XML? Aha! If we're re-publishing A, in A>B>C, then the instances we try to refresh are C,B in that order, so C's parent (B) is not in the XML so it all fails. Instances from from ToArray in UpdateCacheAfterPublish.UpdateMultipleContentCache, which applies to an IEnumerable
Which ends in ContentRepository.GetByPublishedVersion() which orders by version date, sort order BUT not by path => fails.
private void UpdateMultipleContentCache(IEnumerable
And it works.
The Path ordering should be done after descendants are found, right? It sounds like you want to sort by path in the repository, but that doesn't make sense as its fetching the version of a single content item. The sorting before publishing/cache update sounds right though :)
I actually thought ContentService.GetPublishedDescendants was doing this type of ordering as it would make sense to get an ordered list of descendants returned from that method. Maybe that is where the regressw lies?
@Morten: think you're right, we should make sure that ContentService.GetPublishedDescendants returns the descendants in the proper "xpath" order. That's what I wanted to do but: it relies on repository.GetByPublishedVersion(query) which sorts by (VersionDate(desc), SortOrder). I'd rather modify that method. Its output is used by GetAllPublished (would make sense to get the tree in the proper "xpath tree" order too), GetPublishedContentOfContentType (same) and that's all. OK, going to change GetByPublishedVersion returned order - if you know of some place where we expect it to return the "most recent" nodes first, let me know.
Real "document order" is depth first, with the children of a node being sorted by sortOrder. Can do in SQL with: ORDER BY substring(path, 1, len(path) - charindex(',', reverse(path))), sortOrder
For the sake of simplicity I'd vote for (level, sortOrder). Votes?
Doesn't GetByPublishedVersion return the specific (published) version of a single document? I'm not sure if I'm missing what you are trying to say, but sorting by Path within GetByPublishedVersion just doesn't make sense to me when we are dealing with a single document. However, sorting within GetPublishedDescendants makes perfect sense to me.
I dont remember anything about additional usages of the top of my head, so will have to get to that on Monday or Tuesday.
Level, SortOrder sounds reasonable.
Okay, just looked it up and realized I was confusing the repository.GetByPublishedVersion with service.GetByVersion. Sorry!! My bad.
The repository method should at least have the Level included in the sorting. I'm not sure what impact the Path will have?
I can't really think of anything that Path would give us that we can't archive with sorting by Level...?
Yes at one moment you got me confused ;-) Going with level+sortOrder then.
Thank you for looking at this issue guys #h5yr !
Pushed 7ae522b511ba2e768f06e7f45512aa7c441207e1 in 7.1.2 and backported as 3bf1041041487d56dbd2b4fb24ef719d44efaa19 in 6.2.0.
Backwards Compatible: True
Affected versions: 6.1.5, 6.1.6, 7.1.1
Due in version: 6.2.0, 7.1.2