Go Figure 8
Written by @marcemarc on Sunday, 12 May 2019
"If you can grab a circle in your hands and twist it, that's an eight..."
... Well it feels a lot like that's what has happened to Umbraco 7.. twisted into an 8!... everything is familiar, but whereas before you knew you would be always going 'left' or always going 'right'... now you've got going 'left' for a bit, followed by a 'straight on', and whoa, now we're going 'right'... 'straight on' again (aaaaag what's happening!) ... ahh ok back to going 'left' again. If you are old enough to have played Scalextric** in your youth then a figure 8 track was much much more fun than an oval, but well, your car would fall off the track more often...as you tended to misjudge the bends...
sorry, what we talking about?
I'm not sure it can be described as a surprise, but the 'ready when it's ready' new major version of Umbraco: v8; has been released, after, is it 3 years? and seemingly...caught everyone by surprise... well maybe not surprise exactly but maybe off-guard. I've heard a lot of people not using V8 and speculating that it 'isn't ready'... 'there is no documentation', 'nucache isn't stable', 'I don't need variants, - that's so niche', 'I thought there was going to be a phase of community engagement', 'I thought there was going to be a database migration script', 'I've just got a bad feeling about this', 'let's wait until it's proven more stable'...
... I sort of think these statements, whilst some possibly true, share the same undertow of fear, fear of change, and stems perhaps (although I'm not qualified to say) from a feeling, which I'll openly admit I kind of subscribe to, that personally, I was not really ready for this - despite the huge run-up. The narrative is convenient therefore if V8 isn't ready then I don't have to admit that I'm not ready! - that doesn't also mean I think V8 is ready... and also ready for what? context is everything.
... the truth is we're now in a period of transition ...
The same has happened before with Umbraco V6 -> v7, there isn't going to be a definitive 'switch over' point (How about Oct 10th everyone?)... it's a transition... more people use V8, they find problems, HQ fixes them, they share their knowledge, packages emerge, more people use V8, more problems are found, HQ fixes them, etc etc... which is actually exactly what's been happening with V7 over the last five years... but you wouldn't start a new site on V6 now because of it.
So everyone just use V8 right? trust in HQ, is it that simple?
Well ok, but what do you advise a client?
"We're going to start building a new Umbraco site this week, you are the experts, should we use V8?"
If you are building a site yourself then you can afford to trust, and take any risks of any unforeseen setbacks, because, you build Umbraco sites, so the sooner we are all out of this transition period the better, and you understand the quickest way for that to happen is for more people to build with V8, but that doesn't necessarily serve the interest of the client.
All you can responsibly do is be honest...
That a project built on V7 leverages your knowledge for the last few years + a raft of community plugins and packages that solve common problems, but a V8 project has unknown risks, we hope there are none, but nobody knows 'for sure' only time will tell, but if you start on V8 you will save a migration later.
The biggest risk is probably NuCache in terms of impact and size of change... all you can point to here is the 'NuCache "Panic"' issue on github, which illustrates the type of unknown, and the speed at which Umbraco are moving to fix such issues. You can keep an eye on the issue tracker for all open issues with NuCache in the title.
The next risk, is probably death by hundreds of small issues, lots of small things that aren't quite right, that are fixed in the next release, but over the length of a project, block when you least expect it...I've done this before, it adds weeks to a development schedule and finally there is just the plain annoyance of there being a package in V7 that would just 'do this' but it's not available now in V8.
Every client, I've spoken to about this has opted for or steered towards the V8 option, some have wanted to know 'when' all the packages will be moved across (Oct 10th right?) and one was a bit annoyed, that 'maybe never' was an answer... (uCssClassNameDropdown is first in the queue ok!) but on the whole clients see the value of being on the latest major version, but perhaps don't appreciate the richness of all that is available in V7, nor the scale of the change in v8.
Working with V8
Anyway, this strange set of circumstances found me last week in a position of working with V8 for the first time on a real project - creating a wireframe of a site structure. initial doc type design, virtual content, custom IContentFinder, UrlProvider as a jumping off point for an in-house development team to run with along with some team training of how to work with Umbraco - the theme for the first iteration - 'is V8 up to the job?'. The 'working out how the site should be structured work' is easily portable back to V7, but by starting out on V8, it gives the best opportunity to assess what problems there may turn out to be or what short term compromises need to be made...
The site is not small, they will have around 8,000+ content managed Umbraco pages and experience around 70,000 page views per hour, so importing this amount of content into a V8 build and simulating a lot of traffic is part of the process to alleviate any NuCache concerns... (the workaround is presumably to tap into events and store everything in one big Xml file in memory.... :-P)
I'm sure you are much more interested in the results of this test than what I'm about to go on to talk about, but that's for another day...
First impressions
The main thing I wanted to share was a list of some random first impressions of working with V8, in quite an adhoc manner, just to get them out of my head and because once you've used a system for a while you tend not to notice stuff like this.
Documenting V8
I'd have been screwed on this project if I hadn't spent the last couple of months trying to understand and document changes in V8 - I started out just trying to answer questions in the forum (people using Umbraco for the first time, think V8, is Umbraco, they don't understand why documentation isn't 'just there' or why nobody seems to know the answers to their getting started questions - but like in the old days, you can, of course, work things out from the source!). Then based on my replies I decided to update any samples in the docs that included ApplicationEventHandler (replacing with Composition/Composing examples...) - it's taken me ages, and I'm not finished, as each update reveals something else that has subtly twisted... needs, working out, testing and explaining - but in doing this, I've learned a tremendous amount, and have been able to quickly action and wire things up in this last week, injecting all the things, composing all the things! You can see the status of the V8 docs here: https://our.umbraco.com/documentation/v8documentation and create issues here
UI
Working with the Umbraco Backoffice, designing document types, and moving things around has been great with infinite editing, it seems a notch faster than working with V7, you really feel the UI improvements.
Editing content - the 'publish' action has disappeared from the content tree, meaning you have to click on a node, find it's green publish button, and choose from the white arrow menu 'publish with descendants' to publish a section - maybe that is V7 learned behaviour, but it's absence annoyed me a lot! - along with PR of the year functionality: Change Document Type as here, I've designed categories:, different category type, different document type, different icon - I expected editors would be able to change these... but without 'Change Document Type' - I'll need to either create a custom thing here, or keep them all the same Document Type with a dropdown property to indicate type, which might turn out to be better... it's just the thing I knew wasn't there anymore.
Content Apps - so if you switch to the 'info' content app, and are looking at the published Url / History etc and want to switch back to the Content to edit further - bizarrely your eyes can't find it! - you look first to the left of the Url Name (like you are seeking to 'go back home') and the actual 'Content' content app icon, is not necessarily in predictable place on the screen, unless you are hovering over the info tab... then it's easy to switch back and forth... but I found myself clicking the item in the tree to load the Content view time and time again... weird ... I guess this will become leaned... I think from a UI perspective the content app switching is 'behaving like tabs', and with the tabs metaphor, you always have the first tab on the left... and the 'Name' field is there instead!
Tabs
There was a bit of a hoo-har over the dropping of tabs in V8 for document type design - in V7 I had been having, on average, about 5 tabs on a content item, but no more - as they'd start to wrap... moving towards an Atomic Design approach and using compositions/molecules to only apply the groups of properties a page might need (rather than inheriting everything) the average for me has come down to around 3... so I wasn't too worried about the change in paradigm for V8, I could see it would open up possibilities for preview etc, and maybe the tabs metaphor wasn't perfect anyway, maybe a 'new way' might emerge after this reset.. what I've discovered this week, is I can have more than 5 property groupings!.... with one long list it's totally ok to have as many groupings as make sense, they no longer need to be represented on a 'tab' and so there is no artificial horizontal limit! - you can use longer text for the grouping names too, and group properties together by how the Editor relates to them rather than putting them in 'similar' places to just avoid the problem of 'too many tabs...' - I'm not saying 'therefore no-tabs is good', I'm just saying it's an outcome I hadn't considered in the weighing up of their disappearance.
I still have a feeling there is a need to somehow interact differently within the UI for properties that do not have a visual page outcome as opposed to those that control metadata/routing - we used tabs for that purpose in V7, and now, in my new wireframed-out set of Doc Types I've grouped them at the bottom of the content item. It feels like it would be lovely to indicate with colour and/or icon each property grouping in the list, to make them stand out more when the editor scrolls up and down, and then you'd have the flexibility to test the theory and indicate meta property groupings slightly differently to content ones (welcome to the grey zone...)
Implementation
I can't stop myself typing Model.Content.GetPropertyValue - but that is more ingrained in me and my touch-typing fingers, I will get used to Model.Value I will... the new syntax for reading properties, @Model.Value("title", fallback: Fallback.ToDefaultValue, defaultValue: Model.Name) and <h1>@Model.Value("siteName", fallback:Fallback.ToAncestors)</h1> takes a bit of getting used to, but is much better than the stupefying range of options in Umbraco.Field, it's just working out how to do, via intellisense, what you used to know how to do - without thinking.
Configuration
I can't see the configuration!, I can't look in a config folder and see a .config file and know what's configured! I can configure things in code, that is fine, but I can't then see what's configured on a site that is running... ? Again I think this is just a learned 'first place to look' when troubleshooting, someone has moved my cheese type of problem, but it threw me trying to work out where the Examine indexes were configured to be located on the server. Deploying code to change configuration is a pain (fine if you know what you are doing I guess... :-))
Problems
Publishing super large amounts of content (5000) or copying a section of the tree, locked the NuCache.db (we're running 8.02 with the cache fixes in), and this stopped content trees from loading in the Backoffice - this is almost certainly because the SQL server was maxed out, I know effectively it's a DOS against the SQL db!, and more digging to be done here to try and report the issue coherently on the tracker, but in V7, if the db was maxed out, there wasn't quite such a catastrophic effect on the site... anyway in this project people won't be publishing that amount of content on a regular basis... and getting the Publication Queue in place for V8 would be worthwhile if they did.
Another issue during the import using the ContentService, calling Save and Publish on the imported item would intermittently fail - the item under which that was being published, had somehow reverted back to being unpublished in NuCache (although published in the db) - each time rebuilding the NuCache from the Backoffice enabled the import to run again for a bit - the import is just a one-off though, and we were using Chauffeur, so plenty could be rogue here in this instance.
With a ton of content imported, changing the name of the homepage and re-publishing - can time out, it's changed in the backoffice but the change is not Publlished - my guess is the name change effects all the Urls of the site, looking at the logs, it's a SQL execution timeout, so maybe we don't have something setup correctly (S2 in Sql Azure).
I did appreciate the irony of not always being able to view the logs and being told in the error message to see the log for full details!
It's strangely not clear in the Backoffice if an item is unpublished, we unpublished sections, and found underneath the items, the pages were still 'published' in the db, and were not greyed out in the tree - clicking on the item reported the item was published, but not visible due to a parent node being unpublished. weird.
Conclusion
I'm not sure I can answer the question "Will some of my content ever disappear from the site?" yet... but I do quite like the improvements in V8 and would really like to be using it here and moving forward, it's a great starting point for 'future Umbraco' - but I can't let that cloud judgement for someone else's business - really the conclusion is I'd really really like us to get out of this weird transition phase as soon as possible!
It's going to take more than HQ to do this, I don't think I'm being naive in saying this, and the recent increase in slickness and professionalism in the Umbraco outfit, might have led you to expect some different outcome but ultimately it needs people with an invested interest in Umbraco continuing to be a good platform, to engage with V8 and feedback... (I declare this the 'Community Engagement Phase') - the more people, the shorter this phase will be - and it's kinda in all our interests for this period to be as short as possible - and I don't necessarily mean blindly building with V8 on every new client project and just hoping that it'll be fine, but instead chip away at the knowledge gap, have a look at the forum - see if you can work out an answer to someone based on your V7 expertise, look at the source, get a version of v8 running locally or in the cloud for your experiments - maybe take a page of the documentation, is it valid for V8? read the issues on GitHub - read core team blog posts and slides, take the official training - is that in the docs? can I add it in? blog your experiences - tiny tiny little things, but I promise they'll make you a better developer too - if really really lots of people do so then we'll shorten this weird intermission period we find ourselves treading water in.
"that's the way you skate...when you figure eight"
Scalextric tip: replace the brushes under the car with some pure copper mesh for an older-brother-beating acceleration boost..