Press Ctrl / CMD + C to copy this to your clipboard.
This post will be reported to the moderators as potential spam to be looked at
Is anyone else of the opinion that Umbraco 8.1 is unusually unstable? I have been getting quite a few errors, and even full site crashes in 8.1, even in a brand-new Umbraco Cloud environment with literally no content. Even basic things like creating member types are just... broken.
This is quite unusual, especially given that I have been working with 8.0 since its release and had far fewer issues with it. I feel like 8.1 may have been rushed out the door due to pressure to get the migration tool out and give people their 'first point release' security blanket, but in the process the CMS actually regressed.
I have confidence that all this will be ironed out in time, but I am on a deadline to launch a multilingual site, and constant errors and crashes are making the process quite painful.
I'm having major issues after the upgrade as well..
Content deeper than level 3 won't get a url assigned "This document is published but its url cannot be routed" no errors when i republish, just same message.
all sorts of crazy shit...
I've also seen this one ...Content deeper than level 3 won't get a url assigned "This document is published but its url cannot be routed" no errors when i republish, just same message.
And also a few error messages telling us to panic when saving:
Message: Unhandled controller exception occurred for request '"https://_______.s1.umbraco.io/umbraco/backoffice/UmbracoApi/Content/PostSave"'
Exception: System.Exception: panic: failed to get next child with id=-1
at Umbraco.Web.PublishedCache.NuCache.ContentStore.GetLinkedNode(Int32 id, String description)
at Umbraco.Web.PublishedCache.NuCache.ContentStore.RemoveNodeLocked(ContentNode content)
at Umbraco.Web.PublishedCache.NuCache.ContentStore.SetBranch(Int32 rootContentId, IEnumerable`1 kits)
at Umbraco.Web.PublishedCache.NuCache.PublishedSnapshotService.NotifyLocked(IEnumerable`1 payloads, Boolean& draftChanged, Boolean& publishedChanged)
at Umbraco.Web.PublishedCache.NuCache.PublishedSnapshotService.Notify(JsonPayload payloads, Boolean& draftChanged, Boolean& publishedChanged)
at Umbraco.Web.Cache.ContentCacheRefresher.Refresh(JsonPayload payloads)
at Umbraco.Core.Sync.ServerMessengerBase.DeliverLocal[TPayload](ICacheRefresher refresher, TPayload payload)
at Umbraco.Core.Sync.ServerMessengerBase.Deliver[TPayload](ICacheRefresher refresher, TPayload payload)
at Umbraco.Core.Sync.ServerMessengerBase.PerformRefresh[TPayload](ICacheRefresher refresher, TPayload payload)
at Umbraco.Web.Cache.DistributedCache.RefreshByPayload[TPayload](Guid refresherGuid, IEnumerable`1 payloads)
at Umbraco.Web.Cache.DistributedCacheExtensions.RefreshContentCache(DistributedCache dc, TreeChange`1 changes)
at Umbraco.Web.Cache.DistributedCacheBinder.ContentService_TreeChanged(IContentService sender, EventArgs args)
at Umbraco.Core.Events.TypedEventHandler`2.Invoke(TSender sender, TEventArgs e)
I have compliant customers who do what they are told. They panic.
This happened when moving code (not content) between enironments on Umbraco Cloud. Sometimes a browser refresh (in the back office) is enough, one time I had to restart the environment to get the site back.
My Guess is your issue is related to mine - it arises if you have a node which is varying by culture, with a child invariant by culture, then child nodes of the invariant which varies by culture will fail.
Good news it's been fixed, and should be ready for next release which afaik is scheduled for tuesday next week
I have huge problems with the new multilingual system in 8.1.0.
If you create a document that 'Allow varying by culture' and then create a document under it that do not 'allow varying by culture' and then set the culture to that document, then you can't get it by culture.
And you can't create a multilingual document from ContentService and SaveAndPublish it.
// Cannot save content with an empty name.
var content = _contentService.Create("contentName", 1025, "contentTypeAlias");
So i have to go back to the old way of creating a tree for each language, because not each document have both cultures.
not sure if it's related to the bug i talked about further up:
But i had that issues at one point where i had to call:
Works for me in 8 and 8.0.2, not tested in 8.1 as the bug discussed further up has made us hold back on 8.1 until fixed
Sometimes you stare yourself blind in the code you are making, i will try the SetCultureName :)
Sometimes it happens and there no need to stress.
Since most of the process/code was remade from scratch there might happen bugs. Developers are brave to remade/rethink almost whole cms.
I understand guys your point and maybe a bit patience and no need to rush and update? Still, U7 is latest and stable and I suggest to do not rush and update on u8 ( at least on production/live website since is most important keep alive production websites and not use always latest software, still have few websites on u6 :D ).
Patience is the key to a successful website.
It all depends on the customer. If they hear Umbraco 8 is out, they wonder why you are makeing a new site in version 6 or 7 and possibly lose the order to your competitors.
We also have websites in u4, u6, u7 and u8.
That's why developers should explain that it's kinda raw version and customer should decide what more important and in priority - stable or modern website. After all, I'm suggesting to update til u8, but if there exist pre-production hosting and website updates not too frequently to avoid crashing.
Anyway, I don't think so, that u7 and u8, for now, might give a great advantage to competitors ( only a headache... not always, but in the question of migrating/updating it give a small number of problems, especially in time sense ).
I agree that generally 'don't rush to update' is good advice. In this case, however, we are in the process of migrating a large v7 site to v8. v8.1 came with additional breaking changes, so it didn't make sense to continue migrating to 8.0, as it would mean redoing work to account for 8.1.x breaking changes very soon after. Also, 8.1 is the release that brought database migration from v7.14+, a feature that many were waiting a long time for. 8.1 was a critical update, and it's disappointing that it was released with the number of issues it has.
For what it's worth, I was getting a lot of crashes on the site before I put any content on it. I read somewhere that there may be a bug related to no-content sites, so I added one node, but that didn't seem to help. When I added a lot of content later, though, most of the issues seemed to go away, so maybe the issues were related to the lack of content in some way.
8.1.1 also brought some important bug fixes, and that release seems to be of normal stability, which is great.
FWIW, I am still getting this type of error in 8.1.3
Often if a node was created during dev with the URL of localhost... now in production I have to unpublish it and republish it to clear the This document is published but its url cannot be routed error.
Unpublishing invariably results in a
An error occured
panic: failed to get next child with id=-1
An error occured
panic: failed to get next child with id=-1
But all seems to go well if I ignore that error and plow on.
* I have subsequently found that the published/unroutable nodes were all of a doctype where one of the properties was not set to *allow varying by culture
is working on a reply...
Write your reply to:
Image will be uploaded when post is submitted