So when I say I work with Umbraco, people kind of always go, "ahh Umbongo Umbongo, they drink it in the Congo" referencing the TV advert jingle for sugar and fruit flavoured drink 'Umbongo' from the mid-nineteen eighties; which I can't deny is a particulary catchy jingle, but one I've always felt slightly self-concious singing along to. On the other hand, the Kia-Ora jingle of the same vintage and ouvre is as catchy as a rash, and I'm much more comfortable with it in the sing-a-long stakes. So when I had to name my blog which would largely concern Umbraco subject matter and I HAD to pick an eighties fruit based tv advert to reference, I chose the Kia-Ora one. Now I could have gone with the ad strapline 'We all adore a Umbraco' but somehow 'Umbraco, too orangey for crows' made more sense (nonsense). So sorry for wasting your time with this explaination, but I think it gives a fairly good indication about whether it's worth reading any of the blog posts...

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 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: and create issues here


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!


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...)


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.


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... :-)) 


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.


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..

Any plans to update for V8 yet?

Written by @marcemarc on Friday, 12 April 2019

With Umbraco v8 fresh out of the release traps like a hungry greyhound, never can it be said that I don’t surf the bleeding edge of new things in Umbraco… as in the last few weeks, I’ve released not one, but two Umbraco Healthchecks for ummm V7, totally taking advantage of the whole V8 release thing to bury the news, …,, (sorry ok!,  I have a bit of a backlog and I’m working through it in order… clearly, I’m only about two years behind the curve…. but hey who can hardly wait for the content apps I must be gestating ready for release in 2021?)

Anyways Healthchecks…  been around for a bit ain’t they?, and although they’ve become the ‘must run’ thing for a new launch, probably because their ‘origin story’ stems back to the old ‘go live checks’ dashboard - I find there are lots of checks for specific configuration - but not so many checking the ongoing health of an Umbraco site - or if there are (I can’t find them!)...

… Paul Seal is curating a collection of community checks here and I’ve contributed a check to keep track of content versions - which I’ve blogged about here on the Moriyama site.  


Be nice if there were more checks for stuff that can go wrong over time… but that’s for another post, probably circa 2020…

You said two healthchecks - what’s the other one?

The other healthcheck is a bit of a diagnostic one… and it’s for checking Flexible Load Balancing configuration - I’m sure if you’ve ever read the documentation on Flexible Load Balancing, you’ve immediately, read it again. Slowly, line by line… and said “does that mean that the master election server needs to have an umbracoApplicationUrl… help”... 

The irony of the complication of flexible load balancing is that ‘it just works’ - if you don’t put firewalls in the way or have weird Url rewriting rules in place, or multiple domains, staging environments sharing live database, it just works, Umbraco guesses everything, and it works - and out of the box that’s quite a nice achievement. 

Anyway for your weird setup scenarios there are a few advanced techniques, implementing in code IServerRegistrar2…  to enable you to have full control specifying each server’s Role, and even setting the UmbracoApplicationUrl… and I’m not blogging here about how to set this up, it’s in the documentation, ( ) you just have to read it twice, the second time a little bit more slowly. 

What I’m blogging about here is when you start down this route, testing whether you’ve got it can be a pain. 

Not least because when you are making changes like this in code, you’ve usually got to push them out to your load balanced servers to test, and hey, you’ve probably only noticed it’s ‘not working’ after the 'go live', so well, you’re probably trying to frantically get this to work in a live environment, because someone in Marketing has published a page, and it was all ok, but an hour later it’s reverted back to the old version, but it’s still ok in Umbraco etc and hand-on-heart, there are sooo many contributing factors, which you don’t quite fully comprehend yet, ...even after a third read through - and you just want this to work, it’s meant to ‘just work’, why won't it 'just work'? - it seems unjust! - you are even trying again things you know you've already tried, in pure hope, that somehow the 'passage of time' will resolve the problem. 

Well, I don’t mind telling you dear reader, I’ve found myself in that frustrating situation on a number of occasions, and I HAVE remembered to recycle the app pool, before you ask...and if you find yourself agreeing, well I don't think you are in the minority…regardless of how many people you might hear saying "yeah you 'just' blah de blah de blah" etc 

On a particular occasion, last year, the situation was compounded by assisting in the troubleshooting of a Flexible Load Balancing scenario on a client’s site, without access to servers or source control, and only able to ask questions of the developer, like a Victorian parlour game and because the answers did not fit with what we were observing and my knowledge of Flexible Load balancing setup, I was not necessarily 100% sure that the answers were, well, correct - What is the UmbracoApplicationUrl set to? Right, but in /config/umbracoSettings/web.routing what is the value of the setting umbracoApplicationUrl=”” … are you there, Moriarty?

 it all should have ‘just worked’ but as we were getting nowhere, and getting frustrated, going through the multiple things over and over, I put together some code to response.write out on each server instance, what Umbraco was using as the umbracoApplicationUrl, and how it had been set - to stop us going through the ritual of asking the same questions again and again, but mainly to prove I was right. 

… but I wasn’t right … 

It wasn’t ‘just working’… but it was all configured correctly! 

Desperately looking through the source code I found this: 

//by default we'll use the db server registrar unless the developer has the legacy
// dist calls enabled, in which case we'll use the config server registrar
if (UmbracoConfig.For.UmbracoSettings().DistributedCall.Enabled)
ServerRegistrarResolver.Current = new ServerRegistrarResolver(new ConfigServerRegistrar());
else if ("true".InvariantEquals(ConfigurationManager.AppSettings["umbracoDisableElectionForSingleServer"]))
ServerRegistrarResolver.Current = new ServerRegistrarResolver(new SingleServerRegistrar());
ServerRegistrarResolver.Current = new ServerRegistrarResolver(
 new DatabaseServerRegistrar(
new Lazy<IServerRegistrationService>(() => ApplicationContext.Services.ServerRegistrationService),
new DatabaseServerRegistrarOptions()));

ooh a hidden feature, I like a hidden feature, they make you seem clever if you know about them - but just what is this mysterious umbracoDisableElectionForSingleServer setting?

Well it’s used on Umbraco Cloud, as you can’t flexible load balance on Umbraco Cloud, there is no need to make an initial database request at startup to see what servers are registered in the flexible load balancing pool, so turning off the election process for Umbraco sites makes a good amount of sense across the entire cloud, saves 1 database call per site, so this setting is present by default on all Cloud sites… but the client is on Azure - the site had been migrated from Umbraco Cloud (in order to take advantage of more flexible scalability of Azure in their niche circumstance) - but the darn setting remained in their solution! 

Removing the secret setting allowed everything to ‘just work’! 

We’ve added details of the setting to the docs - 

But it made me think you are not going to search for that if you don’t know it exists, the documentation doesn’t necessarily need to mention it, as it’s not part of setting up flexible load balancing, what we need is some sort of troubleshooting guide / diagnostics for Flexible Load Balancing that can check everything…. So I spent a Saturday morning and put what I had into a healthcheck and made a PR to the core, and it was nearly considered for a sprint! 


But this was pre-PR team, and so my PR along with others became lost in backlog purgatory - but in a way that is a little like natural selection, only the strongest and fittest PRs survive! 

Anyway over the year I’ve used it a few times to quickly get to the bottom of a flexible load balancing issue or two - so it sort of has it’s uses - and when I came across the old PR a few weeks ago and messaged to close, there was still interest but it turned out nobody really knew if my health check was checking the right things, in the right way, or providing the right information to diagnose problems...  But fortunately, there is one person who does know… Jeavon Leopold to the rescue! 

Jeavon runs the popular official Umbraco Training Course: you've probably thought about going on it, you should! 

And whether he believed in the idea, or just wanted to cheer me up, (I'm not quite sure which) he helped run through all the settings and of course knew a few more little things that could also be checked too, and he announced it on twitter too…


… anyway thanks to Jeavon’s input, this is now a standalone package, and if you are having difficulties troubleshooting the setup of Flexible Load Balancing, or just want to validate your setup - then you can install the package from our.umbraco or Nuget - and get some diagnostic information - do let us know how you get on and if this helps! 


The Health Check will display the value of the UmbracoApplicationUrl, and importantly how this has been determined by Umbraco. If the UmbracoApplicationUrl has been manually set that it follows the correct pattern and can be 'requested' by the server. It will check and display the values of some key Load Balancing configuration settings, eg Distributed Calls, ElectionDisabledForSingleServer, LocalTempStorage. Finally it will display the Current Server Role, Identity and if DatabaseRegistraar is in use a list of the active servers in the Flexible Load Balancing Pool.

It's in the backlog of things to update for V8... behind uCssClassNameDropdown

Nobody really cares if you don't go to the party

Written by @marcemarc on Sunday, 11 November 2018

I’m never normally one to write up a post-festival blog post covering my experience at an event, and today I make no exception, but as the dust settles on another fabulous Umbraco UK Festival, it’s time to reflect on a great couple of days of a gathering of the Umbraco brethren...

This year the festival was held at The Barbican in London, which is a vast amazing myriad of corridors and stairs which don’t quite connect, part crystal maze, part nineteen-seventies high school… (if you like your architecture it’s well worth a visit) - fortunately, signposts and friendly faces guide you to the Umbraco Zone, congregating in the jungle-esque conservatory.


Day 1 of the festival is a Hackathon…

Because Umbraco is opensource, well developers around the world contribute, when they can, to fixes and improvements to the codebase, but often there is little chance to discuss or work with others in ‘real life’ - sometimes having a whiteboard, animated hand gestures, and just a combination of brains is the better way to discuss and resolve a problem.

The hackathon, which was amazingly well attended this year, is a great place to work alongside like-minded fellow Umbraco devs, sharing discussions on problems/approaches. There is a purpose, and so somehow it’s easier to talk to people than at the conference, where everyone is ‘just on the way to the next talk’ etc… There are tasks, some easy and not so easy,  that are up-for-grabs, and members of the Umbraco HQ development team are on hand to provide guidance. It can be great to pair up with someone (yes, even someone you don’t know) to try and tackle and work through an issue together. It’s all orchestrated by Anthony Dang’s infamous gorilla agile post-it-note driven backlog.undefined

This year, there were tasks to help out with V8, along with fixes to V7 issues (fixes to V7 are still rolled into the V8 branch, so it’s definitely still worth focussing on fixing things in V7). But it wasn’t just about code! - this year, people also took the time to ‘hack’ the Umbraco Documentation repository, fixing up grammar, removing duplication and providing information on TagQuerying…

During the day, I worked upon an ‘up for grab’ issue in the UmbracoDocs repo about providing a tutorial on ‘how to build a google xml sitemap from scratch’, progress here, it needs some more work to polish it up and add some screenshots which I’ll try to do in the coming weeks.

If Day 2 of the festival is all about announcing what is ‘just about to happen’ in the world of Umbraco, then the hackathon… sort of gives you an insight, beyond that… eg what is in the HQ development pipeline for the next year. I can really recommend the hackathon as an experience, just being there is a great learning experience and no need to feel introverted, about it being called a hackathon, it’s very relaxed, nobody is standing behind your laptop - shouting ‘hack hack hack’.

Day 2 - talks, talks, talks

The festival day proper kicked off with Mr Callum Whyte, he off-of the umbraCoffee program on the youtube, telling us all about the festival, welcoming, and stirring up the excitement for the day ahead. There was a ‘uMatchMaker’ game where every attendee had a card with either young or old pics of Umbraco luminaries on and you were encouraged to find the other attendee who had the card with the matching older or younger photo of the luminary in question, all designed to get people talking… or at least introvertedly mumbling… new and old… breaking the ice!


The program was split into three ‘tracks’, the Theatre and Main Room, were the home to the longer talks, and the Community Space, amongst the jungle for shorter ‘lightening’ talks and panel discussions.

I didn’t see the start of Jeffrey Shoemaker’s talk on ‘Security - Let’s have some fun with Umbraco’ at Codegarden earlier this year, but he showed some great insights into how to ‘hack’ and in turn how to defend from ‘hacking’ Umbraco installations. Little nuggets you think you have covered by locking down the ‘Umbraco’ folder, but the realisation there are other files that can be requested and downloaded that can identify a site as ‘being Umbraco’, eg /config/grid.editors.config.js…. clever stuff.

I would have liked to have seen Jacquie Steele’s 100 Days of Code lightening talk on at the same time as Jeffrey’s security deep dive, as that seems to have been the most inspiring talk of the day, following her route into becoming a developer, setting goals and actioning a plan, sparked lots of conversations amongst attendees, about learning development and change.

Which leads into Emma Burstow’s talk about ‘Developing Talent’ in the Theatre, Emma is a compelling speaker and insightful thinker, she spoke about how teams can nurture talent, with practical ideas - mentoring, helping Juniors develop (bad pun) dispelling the myth that it’s only natural talent that makes a developer great.


A wonderful lunch is always provided, and people spoke about the day so far, the talks are great, but sometimes it’s just being there that matters, listening in to the friendly conversations and general hubbub, you start to feel it is ok to talk to people that you follow on the twitter or Github, you get over the fact that they do seem to exist in real life!

Now I’m not saying it wouldn’t be an Umbraco festival without a talk from Pete Duncanson, he must be ‘one of the best’ around, laid back, funny, but making serious technical points, and not afraid to go against the grain to make a point. After lunch, he was talking about the query language for APIs, known as GraphQL which by golly does seem to be the obvious missing link between ‘Umbraco Headless’, and what frontend development needs for umm, querying data. There is an experimental github project: started by Rasmus John Pedersen, that others in the Umbraco community have been contributing to, all very interesting… also Pete told a good joke about Mix Tapes.

Next up ‘Umbraco - we’re in this together’, Umbraco HQ’s ‘Head of PR (pull requests)’ Sebastiaan Janssen - talked about how in opensource, we’re all in this together and can help each other, and how contributions, don’t just involve providing code changes to Umbraco, even just attending the UK Festival was a way of ‘contributing’! - Bug reports, forum answers, packages, documentation, feature requests etc - all great ways to contribute, he then went through the lifecycle of a PR, and showed the latest status of community PRs, and how the new Community PR teams (although anyone can help!) are involved to help process PRs to the core and to documentation.

Kicking myself for not being around for Emma Garland’s talk on ‘When Umbraco and Mobile App development combined’ I always seem to make the wrong decisions over what to see and miss the really good talks, that everyone else rates.

Finally the keynote...

Niels Hartvig the Chief Unicorn, fresh with Brexit jokes, talking enthusiastically about the state of Umbraco, it’s growth and V8 (it will be ready when it’s ready) - some of the new features of V8, like Content Apps (companion apps to particular content page) and side by side comparison/preview of content, will really make a big difference to editors - more screen space to enter content too. (There was a panel on V8 earlier in the day). Niels reminds us too, that it’s all about humans communicating to humans really, and finishes up, inspiring, and leaving people leaving smiling.

Close, Drinks, Hugs, Trains to catch, the UK Umbraco brethren have quenched their Umbraco thirst for another year, and disperse, mumbling about variants and content apps and possibilities, enthused…

… already looking forward to next year.

Thanks to the @cogworks for all their hard work in putting the UK festival together, you'd be a fool not to attend!

The Lee and Marc Show - Atomic Design in Umbraco

Written by @marcemarc on Friday, 01 June 2018

Soooo, it's that 'can I have the slides for your talk?' season... post codegarden2018, and I'm never sure if outside the context of the presentation, whether the slides from the talks I'm involved in, make any sense. (nor, to be honest, during the talk itself either) - But for 'Lee and Marc' completists - they are here.


Some explanations may be in order..

The use of sock puppets came from an anxiety dream, I had about giving a talk at Codegarden called:

"Marc e Marc’s Sock Puppet Orchestra Presents: too orangey tales of empathy and engagement with content editors in Umbraco"

heavily influenced I think by watching The Nightmare of Milky Joe.

When out of the blue, Lee and I were asked to do a talk about 'Atomic design in Umbraco', and we weren't really sure why... Why us?, Why Atomic design?, well it then became a bit of a challenge to see whether we could work sock puppets in there somehow...

... and well, I've discovered that Lee is the sort of person that 'goes along with stuff'...

We wrote the show containing the sock puppets, knowing it would only work if they demonstrably looked like Matt and Lee - but with two days to go, we didn't have any... So Helen in the early hours of the morning leading up to the CG Retreat, worked her magic, and glue gunned heavily researched, beard, hair and eye combinations to miraculous effect, the hot glue slightly painful on my hands through the sock material, but I wasn't complaining, we had a show! -  On the last night she insisted on creating the mini marcemarc puppet (even though there was no marcemarc puppet in the show, and well... I still had to pack), but, hey, that is the level of commitment, we are talking about here.


What was it about anyway?

The gist of the talk, well, we wanted people to think about the shift from inherited document types to compositions, and how there was little proactive communication at the time of the introduction of compositions, as to how you might organise them and whether the principles of front-end Atomic Design, could help people make decisions and organise their document types and compositions in the backoffice.

This led to the notion of a Periodic table of Umbraco Property Editors - and the thought that well, we might not have found yet ALL the elemental property editors in the core yet... We should think more atomically and not just use Nested Content for everything.


Stretching the science analogy further we introduced the notion of an 'Atomic Number' for organising the order of properties from different compositions on the same tab, and highlighted other improvements to the core that could make this atomic composition approach more compelling.


Finally, asking how often people revisit, listen to editors and refactor backoffice editorial experience?

You can read more about the examples glossed over in the talk here:

Editing Crops in the content section
Media Picker - List View 
Editor Journey Times
Redirect Url Management from a Content Item -  (now an exciting PR in the core)

So remember make your backoffice interactions 'S O C K', Simple, Obvious, Composed and Kick Ass!

And the end was filmed by Jeavon:


Also if anyone has any pictures of the puppets on stage, it would be ace to see them!

How can it be? Redirects, It's a RUM do Part Two...

Written by @marcemarc on Wednesday, 31 January 2018

So we've inherited a new client, they have two sites, it is a travel company, and as is so often the case, one site is an obvious clone of the first site, and you know somebody has just said we just want that again but with a different logo... and they are so close... twins almost, and although people still talk about the 'main' site... like it was a favourite child - well you still wouldn't expect them to have any major differences...

Redirects are important for this company. SEO is everything. the 301 redirect is king (or queen).

"we want to be able to have the same 'redirects thing' on this one, as we have on the main site"

"Sure.. no problem",  I figure I just install whatever package is used on the 'main site' on the twin site, it all should just work...

".. and actually the tracking thing's not setup properly on the main site, it works on the second site though, you know automatically creating a redirect if we rename a resort.."

"ahh...", alarm bells begin to ring...

So the 'main site' has Simple 301 redirect package installed the 'second site' doesn't.

...On the one hand, I can see how the lack of symmetry might really annoy some people...

So the 'second site' without the Simple 301 package relies on the Core Redirect Url Management dashboard for it's 301 Redirecting powers, and the editors have fathomed the 'rename-rename-remove' method from 'part 1' to create redirects.

(They have no connection though with the other company, how do editors pass these secrets across organisations?... it's like whale song or something).

If I install, as requested, the Simple 301 package on the 'second site' it will turn off the Redirect Url Management tracking functionality and any redirects already created with that mechanism will fail...

... I can make the core Redirect Url Management tracking happen on the 'main site' but only by uninstalling the Simple 301 package, and losing all the redirects that have been already created with that package...

... what? ...

I said it was a RUM do... Part Two...

Why don't existing 301 and Tracking packages play nicely with the RUM dashboard?

When we squeezed the Redirect Url Management tracking functionality and barebones dashboard into the release of 7.5 at that retreat, I mentioned in Part 1 -  we had a horrible, 'end of day' thought... What if?

What if somebody already has installed one of the many existing 301 redirect management packages, and they upgrade to Umbraco 7.5 and their site suddenly has two redirect mechanisms... what will happen?

Well, if one contains a redirect to a nice url of /about-us from a not-so-nice url /aboutus and the other mechanism contains a redirect from the not-so-nice url /aboutus back to the nicer url /about-us ...well...


...a redirect loop will create a continuous game of redirect tennis™ between the two mechanisms until well, I guess, well the server melts... creates a mini black hole, unicorns die etc... the internet is broken.

How, How can this be?

It all depends on the incoming request pipeline of Umbraco and where the different redirect mechanisms choose to look up and try to perform the redirect.

The Umbraco request pipeline is a series of IContentFinders... individual rules to find Umbraco content based upon the incoming url ... executed one after another in a queue, until content is found.


A butterfly representing the a content request flies through the Umbraco ContentFinder incoming request pipeline, each ContentFinder represented by a butterfly net, tries to find the content associated with the request

(and you can add your own custom rules too, by implementing an IContentFinder, and using the ContentFinderResolver to insert your custom content finder rule into the pipeline)

...and what we didn't know, at the very last minute, is quite where in the request pipeline each individual plugin/package/redirect mechanism was plumbed, in relation to our new ContentFinderByRedirectUrl implementation...

so very pragmatically this code was added...

// if any of these dlls are loaded we don't want to run our finder
var dlls = new[]

// assuming all assemblies have been loaded already
// check if any of them matches one of the above dlls
var found = AppDomain.CurrentDomain.GetAssemblies()
.Select(x => x.FullName.Split(',')[0])
.Any(x => dlls.Contains(x));
if (found)

Essentially if you have one of the existing redirect plugins/package dlls in your site, the core Redirect Url Management dashboard, does not want to play, it is turned off, it goes home in a sulk... and removes itself from the content finding pipeline...

... on the upside, nobody's servers melted after upgrading to 7.5! - but quite a few people were puzzled about this new functionality that plainly did not work... which was a shame, especially for those whose motivation for upgrading to 7.5 was the thought of 'ditching their reliance on a 3rd party tracking package and taking advantage of this new core thing' ...


So now you understand my dilemma for the twin travel sites? (two sites remember! -  not a single site dedicated to travel destinations for twins)...

... and why installing simple 301 or any other package to service their SEO fueled 301 redirect cravings will break the core tracking functionality and vice versa...

So I figured I needed to do some investigation... just where in the request pipeline does each of these packages kick in?...was there really a problem or just a last minute 'what if'?

Why don't you just use UrlTracker mate?, it does tracking AND redirects...

If you do have UrlTracker installed, please make sure you either have 404 tracking turned off, or ignore common 404 requests in the app settings, or have a maintenance plan to remove entries if you are not going to redirect them...  or... this will happen:


basically, the 404's are tracked in the same db table as the 301s, each tracked 404 is a new row, which if you are not careful, build up over time, and cripple the speed of the dashboard. (UrlTracker appears not to be actively maintained but secretly it is! - You can find it here: there are later versions on Nuget than on Our.Umbraco)

It has the ability to 'force redirects' which then occur before the Umbraco pipeline has its turn, and 'un-forced' redirects that occur after the Umbraco pipeline has executed, and it has regex pattern matching too - but it wouldn't run nicely alongside the Redirect Url Management dashboard... we'd have Url changes tracked in two locations. and we could have the potential 'redirect loop meltdown problem', we're so worried about... it doesn't currently use an IContentFinder to hook into the Umbraco request pipeline but runs instead using a HttpModule on every request...

... if you have UrlTracker installed then it makes sense to turn off the core Redirect Url Management functionality but...

... but that's part of the core now, and the nub of this is people want to use the 'core thing', regardless of whether it fulfills their needs, simply because it is in the 'core' ... There is encouragement that this will always be maintained, work with Umbraco deploy, Umbraco Cloud etc, and there is the expectation it will evolve... but yes, stop reading, just use UrlTracker, it isn't my point not to!

What about Simple 301? 

It's simple - it doesn't try to do any automatic tracking of changes... and it's built in angularJS, which makes its UI fit with the paradigms of Umbraco 7 neatly, although the colours are wrong... also it's using an IContentFinder to register itself in the pipeline, looking good! ... but oh wait... the IContentFinder is registered at the beginning of the pipeline, so on every content request, redirects are being looked for, albeit the database request is being cached...but..

... I don't understand why this IContentFinder is being registered first?

for me you shouldn't be using a redirect system to override an existing Umbraco Url?, the redirects should occur after attempts to find genuine published content have been made... and having this IContentFinder for Simple 301 execute first and importantly before the RedirectUrlManagement IContentFinder is unfortunately just the set of circumstances that would enable a set of redirect tennis™ to be played between the two... I tried it...


Not quite the end of the internet, no black holes, unicorns still exist, but pretty annoying for anyone visiting the URL and having the 301 loop cached in their browser... so I guess this is a no go too, am I going to have to write my own? [Insert link to part 3]

...and then I thought, but hang on, I've got access to the source of this, this is opensource...

... so as an experiment I've forked Simple 301, and changed where the IContentFinder is registered, and now it's plumbed in after the ContentFinderByRedirectUrl finder...


... now the redirect loop meltdown cannot occur...


if we think about the /aboutus -> /about-us -> /aboutus example - the Simple 301 can still redirect /aboutus to /about-us, and there can still be a redirect in the Redirect Url Management dashboard from /about-us but this can ONLY be to a published content item, and therefore the content finding content finders ahead of the redirect finders in the content request pipeline will find that published item first, no loop can occur, if the item being redirected to is subsequently un-published, the redirect is removed from the Redirect Url Management dashboard, so again no loop!


But why isn't the core tracking turned off by the presence of the dll?

... umm, well I changed the dll name in the fork... 


So the world of 'pragmatism' cheers and drowns out the orbiting satellites of 'best practice' and 'common sense' and I have the RUM edition of Simple 301 running on the twin travel sites, editors can add custom SEO driven 301 redirects to their hearts content, and any re-names of published content are automatically tracked and 301 redirected to the new name by the core Redirect Url Management,

everything is more symmetrical... the twins are a little more identical...

... am I meant to say 'for the win' here?, I've seen other people say that kind of thing, so try to imagine I have seamlessly done so too.

You can find the fork and RUM edition here.

So Part 2

So Part 2, not what you expected? it is hard in a trilogy, for the middle episode, to keep the plot moving of the overarching story arc and yet still manage to work as a standalone ep.

What I'm trying to say here in all this is: should this kind of redirection always be outside of the core? and if so, can we find a way to adopt one of the packages to work in harmony with the core tracking mechanism, we could then extend and improve the package if necessary, and just avoid the confusion of it not being clear why everything stopped working on one thing, when we installed another thing, because of its name?

Do we even need the additional level of redirection? would the additions in Part 1,  being able to add to the Redirect Url Management dashboard manually, cope with most redirection scenarios that editors need to manage via the CMS?

Where should our 'sorting out redirection in Umbraco' development energies lie? Core or Package or... there a third way? There is a Part 3...[add link to part 3]

NB: thanks to Wade Kallhoff for creating the simple 301 package, and apologies for experimenting with it like this. 

301 Redirection in Umbraco - It’s a Rum Do

Written by @marcemarc on Saturday, 13 January 2018

So silly things, although it’s easy to blame…

… And I’m going stupid once again, but I left it up to you.

Could these obscure ‘indie dance’ lyrics from the Paris Angel’s UK top 55 ‘hit’ in 1990 have been written specifically about the current situation for redirects in Umbraco?

No of course not, but it’s getting harder and harder for me to shoehorn a musical reference into my blog posts, and pick an appropriate youtube video to suit the subject matter or at least a bad pun of the blog post title, that well now, hmm, now, I’ve started picking the song first, and then I try to weave the blog post subject nonsense around the tune…

Let’s see how I get on, in theory there will be a series of posts about redirects here, reflecting the redirect related events in my life over the last three months, it seems like I nearly have enough for e-book.

But it is my New Year's Resolution to be more direct, and stop these whimsical digressions and observations, that make people forget what the original blog post was intended to be about by the time they reach the end of the article.

Let’s see how I get on.

Redirection Url Management

You may have noticed the introduction of the Redirection Url Management dashboard in Umbraco 7.5.x - (I accidentally had a hand in it, it sort of only exists (or at least the dashboard appeared in this version) because I was somehow invited to the Umbraco HQ retreat, and as a way of hiding during the 2nd day, I suggesting I’d be working on it, as we went around the group in the morning standup, as it sounded like a thing, even though it wasn’t a thing. and it’s fun to see how very little of what I built made it into the actual dashboard…

but apparently the fact I had started it and work was in progress, was why it was polished up to squeeze into the release, every little helps, but maybe its genesis explains a little why the next question in your head is probably. 

Why can’t I manually add redirects ? 

The whole addition of the tracking was built as a minimum viable product in 48hrs, what was the smallest thing that could be built, and still make an improvement, for the single issue when the CMS knows a published url, has been changed, to issue a 301 redirect to the new url. The dashboard wasn’t part of that, the 301 redirects that get setup by this tracking of changes were going to be invisible… I figured that if Umbraco was going to start adding these redirects automagically, making them visible somehow to editors, would at least let people know what was going on…but mainly I’d have something to demo at the end of day two. 

Adding redirects for a mechanism that only tracks changes doesn’t makes sense, especially when the day is ending and people had already started to mix rum cocktails - That doesn’t mean there isn’t a real need to add that kind of mechanism to the core of Umbraco, it’s just it wasn’t addressed then, or kind of since. [Add link to Part 3 here] 

Ironically the presence and visibility of the dashboard, is the exact thing that places the thought in people’s mind ‘how do I add new things here?’ 

So where is this going?

Well, when I’m on my travels delivering sublime Umbraco Editor Training, or workshops helping Content and Developer teams work together to get the best out of Umbraco and at such reasonable rates too. I am fascinated by the tricks and workarounds that people who use a system everyday come to adopt, not because they’ve been told about them (often the reverse), but well, because they’ve discovered a way to bend the system to work for them, no harm done. 

And it feels good if you find a way, 'that works', that’s not supposed to… and it’s a secret. 

Like nudging in two identical fruits onto a win-line in a fruit machine, if the next spin you are offered to hold the reels - you don’t hold anything - let all the reels spin for a guaranteed win! It makes no sense, but it works and that feels good. 

So the content team at this company were told to email any redirects they wanted to set up to the developers via IT, who explained they needed a bit of notice to set them up, and they’d add them to a rewrite map in IIS, but nobody could really remember what had already been set-up, it wasn’t easy to manage. (and a duplicate entry caused a ysod - which triggered the crisis discussion). 

The redirects are content, editors need full control of them. 

When I was explaining about redirect options in Umbraco, one editor put his hand up and  said, 

“ahh, but if you rename a page in Umbraco to the redirect you want, and then name it back again, then switch to the Redirect Url Management tab, and remove the one from the list you don’t want, then you’ll see Umbraco has created a 301 redirect for you - let the reels spin and you are guaranteed a win!”...

 Have a look at what I am dubbing the rename-rename-remove redirect method, or rrrr for short.

.. .And next time I visited them, they were all doing it!

Life, uh, finds a way

(if I did giphys there would be a Jeff Goldblum one here right?, sorry to disappoint.)

The dashboard gave the visibility that enabled people to find a way, and people always will, find a way. And if they are doing this already, and you can’t stop them -  then it becomes an editor journey in the CMS, ...and you perhaps are familiar from earlier tales in this blog, I’m all about reducing editor journey times and making tasks simpler… responsibly. 

So I added a form to enable the editors to add redirects to the dashboard, but only to content in the cms that they could pick and only for relative Urls - so it was only a shortcut to repeating the ‘rename-rename-remove’ hack….

Here is the Rum Do version of the Redirect Url Management dashboard, same task:

A stopwatch task that had taken minutes to complete, and a bit of tomfoolery, was now down to under a minute, and it felt less arduous, less faff, especially for multiple redirects, it had removed the “do I really have to do this crazy thing, sigh” factor. 

But is that it?

not quite...remember the second question in the discussion?

What redirects have already been setup for this page?

With the current Redirect Url Management dashboard you can search for redirects that have been set up, that’s because it’s designed to let you find errant redirects and remove them, but it doesn’t let you search by the target page, it doesn’t answer the question, what redirects actually exist for this page?, and if you have a content item open, why would you switch to the dashboard to search... if we've learnt one thing during these posts, it's that 'context switching' has a big impact on mental agility and how 'quick' a task feels to accomplish... 

 ... so I added an action menu item - Manage Redirects, and now from within any content item in the content section you can click ‘Manage Redirects’ and a slidey-out panel will reveal a list of all the redirects from the Redirect Url Management dashboard for that particular page... without having to switch contexts...

...and then because at that stage I was a bit giddy with RUM (redirect url madness) I allowed the editors to create the redirects from the context of this slidey-out panel… 

... same task - the journey is even quicker.,. but more importantly, it feels more intuitive...

… this is wrong, I know this isn’t what the Redirect Url Management dashboard is supposed to be used for, the editors have been warned, there are better redirect strategies out there, but if you install them then that in turn disables the redirects already created on the Redirect Url Management dashboard… [Link to part 2]

It’s A Rum Do

I haven’t released this as a package, and I'm not sure whether it would be a helpful short-term addition to the core dashboard (it again is not trying to address the bigger picture of redirects in Umbraco)... what do people think?

...but in the meantime... should you work with editors who have mastered the ‘rename-rename-remove’ trick (rrrr), and you want to just let them do it can make use of this dashboard addition and slidey-out panel from the git repository here:

Oh no, here come the onions

Written by @marcemarc on Tuesday, 10 October 2017

Skip Waffle

"Is he done talking about picking media yet?"

No, I’m not done... and is anything ever done? Each small change influences the experience and tramples over what next...


”ooh, what would be good if...”

In short a butterfly beating its wings in New Mexico can cause a hurricane in China, so who knows what global natural disasters have been triggered by the affects of our tinkerings, prototyping and implementing of the small changes I’ve been detailing in this ‘no longer a trilogy’ of blog posts...well hopefully it’s not just wind.

Keen followers of the series will know we are using light touches to speed up the editors’ ‘writing articles and picking images’ experience in Umbraco, as they switch and learn to adjust to Umbraco 7 - we want them to feel like the wind is behind them and they are not having to fight gusts of outrageous cms implementation. Umm It’s time to switch analogies:

I’m thinking that when you cook with an onion, perhaps you are making a Lasagne or French Onion Soup (see the recipes section of this site for further inspiration), there comes a point when you remove the first papery layers of the onion and are ready to slice and dice, but underneath there is perhaps revealed another wrinkly layer, or a strange black mark, and well, you don’t quite fancy it, and you peel off the next layer in the hope that underneath is something pure and unblemished that you can happily slice into... you may need to buy more onions to conjure your French Onion soup to perfection (p9 of the tooorangey cook book), but in your opinion it will be worth it to serve at your sophisticated dinner party later on - however if you are on a budget, well, the aim is perhaps simpler, to peel the layers. really, to just get to something that you don't think will kill you.

With software development similar levels of pragmatism can come into play when you consider project budget vs features vs time. If you have agreed to deliver a feature for a certain amount of money - it is open to interpretation when that feature has been delivered, you may work for much longer on that feature than you had considered, because as the feature begins to be realised, the client (and also the developer) starts to have/spark off ideas and sees what the potential of the feature could be. This can lead to a problem where the developer just wants to be finished, and get paid, and the client just wants the feature to be like they now in hindsight understand they would like it to be, and this isn’t the best atmosphere for creativity or fun.

Digression: Software development isn’t similar to the process of building a house, as people are often keen to suggest

- maybe it would be, if the thing you were building was something you and your client had had a lifetime of experience living in / visiting other people's houses to eat French Onion Soup in or even had just watched several episodes of Grand Designs back-to-back together on the telly so had some shared understanding of what was possible, oh and that the new eco light aluminium window frames from Germany might arrive late -

in good software, like cooking, you may follow a recipe but ultimately if it needs more salt, you don't argue the toss about the salt being out of scope for this phase of the soup... 

development by definition is an event constituting a new stage in a changing situation.

So however you approach it, software will ‘develop’ incrementally, but how can you enable this so the client and developer know when a feature is done without falling out? - since pretty much everything you look at can be improved upon in some way? I sometimes wonder if development is just a seesaw of embarrassment between client and developer, and the development stops when the client is too embarrassed by the effort gone in to suggest any more changes, and the developer is not embarrassed by the quality of what they have shipped.

The first one to mention "Is that a showstopper, perhaps we could revisit this in Phase 2" is the first party to realise they never want to work with the other person again. The client changed their mind, the developer didn't understand.

I've talked at length before about managing expectations, and how under promising and over delivering is kind of much better than the other way around, and it's ok to 'not know'.

But there is another way to trigger a different atmosphere on a software development project, and that is to identify a common enemy, that the developer and client can unite against, and my favourite common enemy to use of late is time.

Having some kind of limiting reign over ‘what can be done’ within a software project may feel restrictive, but actually is really helpful for ensuring some pragmatism and stimulating clever and creative solutions, more importantly though it can keep the client - developer harmony intact, because they are ‘in it’ together, to try and get something delivered 'within the time'.

(Tip: Don't use money as the common enemy - nobody enjoys being told the don't have enough money, and people can always unexpectedly find extra money, and then people get upset if they don't get what they thought they were getting for their money - so use time, time is the best common enemy - it is not controversial and it's easy to understand… "the Dinner Party is at 7pm, I do not have time to peel twenty onions" - "we are effectively homeless next Tuesday unless the roof is on". (a waterproof covering of some devising is therefore much better here than half a perfect roof, or indeed the bowl of French Onion Soup the project plan said you would deliver on Tuesday).

The conversation becomes not “When will feature x be ready?” but “On x-day what features will we have?”.

Against the common enemy of time, it’s easy for the developer to show they are doing their best within the timeframe, and easy for the client to understand how long things take - particularly if you have a daily show and tell of the progress, and plot together against the common enemy.

It feels wrong, but once freed from the constraints of perceived perfection, and architecting 'the whole thing' you can start to enjoy working with your client comrade on delivering simpler smaller things quickly that focus on the immediate needs, stepping stones to where you want to ultimately get to, but with the flexibility to get somewhere else if it seems like a better place to go along the way.

"This is a lot of waffle...normally in these posts, we skim read and put up with some of the waffle, but then there is a link to some code we can sneak a look at and perhaps repurpose - when is that bit happening?"

Well, let me try to illustrate the above with an example.

We upgraded a magazine site to Umbraco 7, 250,000 media images, I’ve mentioned a bit about it in previous posts. After the upgrade two weeks were put aside for ‘other improvements’ - and the immediate concern they had was the speed of the ‘Uploading and Picking of Images’ journey, it was slow in Umbraco 6, and the upgrade hadn't really altered this perception.

The first thing to note here is we’re not ‘implementing a feature’, we’re improving a process, we’ve not agreed exactly ‘how’...

... we thought about architecting a new kind of Super Media Picker, building something from scratch to address any problems, perhaps working with examine, but in 2 weeks?

... instead we investigated:

Upload speed - at trade shows it was taking 12 minutes to upload an image, which was frustrating as the client were trying to cover ‘what was happening now’ as events unfolded... and not what happened 15 minutes ago. I immediately assumed this was something to do with mobile device connectivity at the event. So we set about proving this, I uploaded a file from my mobile, in an area of good reception and noted how long... umm it was 12 minutes - so I tried from my desktop, err 12 minutes - it was nothing to do with the shows!  Back in the office they uploaded images in batches of 8+ to use within an article, so accepted this would be slow… and went off to make a cup of tea - they didn’t experience the single image upload problem until they were at a show.

This was weird, never seen nothing like this in an Umbraco site before...had we missed something in the upgrade?… we set up a vanilla install of their version of Umbraco, and pointed it at their database, and attempted to upload: 12 minutes again. The images were stored in blob storage... we turned off blob storage temporarily, 1 minute upload…. 250,000 images, would blob storage deteriorate with that number of images? (that’s not how the cloud is meant to work!). Darren stepped through the upload process, and found, the image upload part was actually really quick... but have you ever wondered where the number comes from in your media url: /media/12345/yourfile.jpg ? - well this was the cause of the stupid ten minute delay. It's calculated by looping through all the directories in the media folder and finding the one with the highest number:

_folderCounter = 1000; // seed
   var directories = GetDirectories("");
   foreach (var directory in directories)
    long folderNumber;
    if (long.TryParse(directory, out folderNumber) && folderNumber > _folderCounter)
    _folderCounter = folderNumber;

This performs reasonably well for a file system on a server even for 250,000 folders, but in blob storage the performance is awful (blob storage is not designed to be queried in this way).

(The good news is now that media in Umbraco has a guid, the latest versions of Umbraco can use this in the calculation of the unique media url, and this iteration won’t need to occur.)

To work around this in the meantime, in the simplest way, we created a hybrid File System Provider, that used Blob storage for storage, and the file system, for the calculation of the next number.

So the nice thing here was it was really easy for the client to understand the problem, we showed them the code above, and they could get why it might be slow with 250,000 images.

Did this mean the File Upload and Media Picking journey was quick enough?

No, we had just peeled off one layer of the onion, the client could see some more blemishes.

Picking Images

Images were now uploaded in a comparatively astonishingly quick time but ‘picking them’ was still slow..

We looked at the Media Picker and found, it was slow,  the client had tons of images arranged in Alphanumeric folders, and subfolders eg

[Article Images] - [B] - [BR]

And each click along the breadcrumb to drilldown to the images gave no indication that the media items were loading, encouraging further 'impatient from waiting' editor clicks, resetting the request and slowing things down further.

We added a loading indicator, so at least the editor knew to wait…


(this is now coincidentally been added to the core in 7.6.x)

This meant that although it was no quicker, it felt quicker, because the editor had feedback something was happening. (My favourite kind of small fix).

But why was it slow on each folder request?,  we found that all the images for a folder were being requested without paging (although this looks to have been addressed in v7.7)... for each folder click, there could be hundreds of images, and for each image, along with the generation of a thumbnail, all of the Media Type's properties were being returned (when the media picker perhaps only really needs Image, Name and Id?). This particular site compounded the problem though - in an attempt to use the Media Section as some kind of Media Library the default Media Type Image had an additional 23 properties (instead of just width, height, size type etc)



Each of these additional properties were being retrieved in the blob of Json for the Media Picker to display the images to pick (all via the MediaService, eg db requests), this additional unrequired data on the request was overwhelming the browser (Over 2mb of Json)...

...again we were thinking, stop, new Media Picker + Examine/Azure Search, but again a bigger task than the common enemy time would allow.

Understanding this the client agreed we could drop some of the media type properties, (you can see from the screenshot they weren't filled in very often), and we figured we could scale up the database a notch in Azure, it would cost more but the trade off was faster picking, it would be worth it, but whilst looking at the queries that were being executed, Tom Pipe had a hunch that the database wasn't performing as quickly as he'd expect (it was already scaled up, it shouldn't be this slow).

Digging into SQL he found a thing, which we all remember from the old days, but as we're not DBAs anymore we'd collectively forgotten about:

Heavily fragmented SQL indexes 


(And we’ve since found this on many of the Umbraco sites we support, particularly those upgraded from 6 to 7)

The advice from Microsoft is to rebuild your sql indexes if they are over 30% fragmented, and reorganize if they are greater than 5% but less than 30%.

Tom being Tom, built a custom healthcheck to test for fragmentation and allow you to rebuild/reindex as necessary from the backoffice:


Which he says he's definitely going to release, so why not remind him once a day on twitter: @toepimp until he does.

Anyway you can see the result of rebuilding the indexes on database performance generally, and the speeding up of the MediaService Api’s GetChildren:


We didn't need to scale up the db, in fact two weeks later we scaled it down a notch!

So are we there yet?

Has the final layer of the onion been peeled?

… not quite.

Media picker in a Macro

One editor was reporting the media picker was slow, when used via a Macro to insert an image into the Rich Text Area. What could be different about using the Media Picker as a Macro Parameter we thought? We investigated and found no difference, we arranged a screenshare for the editor to demonstrate and the bottleneck was obvious:

When the editor hit the Insert Macro button, the macro selection dropdown appeared:


However the site only had one Macro! the slowness being reported by the editor was caused by the obvious frustration of having to pick the macro from a list of 1 in order to get to the Parameter Options that included the Media Picker... It felt clunky and slow, why doesn’t the insert Macro option go straight to the parameter options if they exist and it’s the only Macro defined on the site?

My first thought was shall we add a second Macro to insert something else, so it doesn't feel so pointless making the selection :-)

...but instead the workaround here was a new TinyMce Custom Plugin, that fired the opening of the Insert RTE Image, (and then the actual Media Picker overlay) so the editor had a quick way of getting to the insert image part, when they wanted to insert the image instead of faffing around with pointless dropdowns of annoyance making the picking process feel slow. 

So tell me we can start cooking this Onion Soup now?

Nearly there...ready to peel another layer?

Media Picker List View

The final issue the editor reported having difficulties was an interesting one, essentially their articles might contain seven or eight images, all focussed on a specific technical aspect, and typically the images would be named:

Long and complicated feature picture 1.jpg
Long and complicated feature picture 2.jpg
Long and complicated feature picture 3.jpg

Which they would upload as a batch to the media section or on first pick via the media picker.

The problem here is that the images all sort of look a bit alike, with subtle variations, the media picker presents images to be picked, as umm thumbnails of those images, the editor knew the filename to insert where, but could not necessarily pick this image out of an identity parade. But you can hover over the image in the media picker and reveal it’s filename right? yes but..

Two problems, firstly you only see the first part of the name, so the distinguishing bit ...picture 3.jpg or ...picture 4.jpg was cut off - and secondly the images aren’t displayed in alphabetical order - their order is determined to best fit the image thumbnails into the picker overlay - and so you’d be hovering and guessing between each one trying to guess, if the next one, was the one, waiting for the hover to kick in.

I couldn’t really determine if this is a really niche problem or something that affects editors more generally, how common is it? it came up in conversation from the client that you’d think you’d be able to switch the picker to use a List View like in the Media Section.

And I'm a great believer in 'what you would expect to be able to do' to be perhaps what you should be able to do...

... but to do so would mean custom media picker, which we didn't have time to create, or could we tread lightly upon the existing picker?

intrigued, I started with the existing Media Picker, views and controllers and directives, and I created a prototype custom media list picker to explore the idea - attempting to change as little as possible, essentially creating only a custom Media List Directive to replace the umb-media-grid directive, so it had the same functionality as the grid view, but with a toggle to switch to a list view.

At any point in the media picking journey you can switch to see the ListView version, and the names of the images appear in full, and most importantly in alphabetical order, which is exactly what this editor needed. It speeds up their picking of media jouney when they don't know exactly what the image looks like, and less mistakes are made - anecdotally it's just less frustration, so again feels quicker.

You can examine the repo of the prototype here:

It isn’t really something that will work as a package, as the Media Picker evolves in the core, you’d have to keep evolving this, but if more editors might benefit from this feature,  and it would be great to hear if people think this is a good idea - you could imagine it being added to the core Media Picker as an option?

Have added an issue to the issue tracker to gauge any interest.

It’s a prototype, the editors are using it on the site, and feeding back (could we hover over the list item and see the image etc. can we have an option that shows the last 20 uploaded images - we always pick what we’ve just uploaded etc)

This small change is already sparking off different ideas for future improvements, and I know I ended up creating a custom media picker in the end - but it's very different to the one I would have architected at the start of the two weeks, and that prescribed version probably wouldn't have addressed any of the actual issues above, although it would have used examine/Azure search, and been ace in different ways, it would have been problematic in others...

Does this illustrate what I'm trying to say? 

Peeling away the onion layer by layer, working with the client, beating the common enemy of the two week timebox to deliver something useful? The difference is the client is eager to do more, we're not arguing over the over-promised "Super Media Picker" being late, and that it turns out to also feel slow within a Macro, because of the dropdown... etc etc

Summary: If you want to choose a trade based analogy for software developers,  I don't think that we're builders, nor architects, we are much more akin to gardeners, working with and against the changing seasons, we have experience, we know certain plants won't grow well in that soil, we work with the client, it's their garden, we advise, reflect on what's happened, each time we come, we listen, plan and improve the garden, but it's never finished.

... and we plant our own onions.

Here's Where The Story Ends

Written by @marcemarc on Sunday, 13 August 2017

“... and then we publish from Umbraco and one final check, the blog post is there, and we are done” 

“Great, I’ll stop the watch, how do you celebrate? A nice cup of tea?” 

“.. yes, no, well not quite yet, I’ve just got to tweet this out, it’s a pain, I’ve got to logout of my twitter, log into the twitter account for this blog, cut and paste the url, compose the tweet, tweet it, then remember to logout of the company account and back into my twitter, else I’ll be posting pictures of my lunch on the company blog account, which I actually did once by accident” 

“A-ha, I’ll keep the stopwatch running then”. 

So I’ve found myself writing what has become a series of blog posts, dubbed, in some of the most unfashionable areas of the internet as the ‘working with editors, not against them trilogy’, and they are all following a common theme - the short recap of which is, at Moriyama we’re helping several groups of editors in different companies adapt their editing workflows within their freshly upgraded shiny Umbraco 7 environments, and at the same time becoming slightly fascinated with the human interactions, reactions and thought processes involved. 

Today, I’m kind of highlighting a specific nuance of the flick-flack of editor-developer interaction that is sooo subtle, it might not even exist, so bear with me. 

In the illustration above, the editor is expressing a specific problem, “the switching of twitter accounts between personal and work accounts”, to send a company tweet about the blog post they created. 

Interestingly earlier in the project one of the backlog items had been a vague creation of a ‘complete social media sharing platform’ which had been sized as a fairly large T-Shirt(XL) and been dropped out of the scope for the set of ‘upgrade’ sprints. 

As a developer though, given a real problem, you immediately start to think of how you might solve it, and as you read this you are probably thinking yourself of a number of different really neat solutions... but when handed a ‘specified solution’, for example: in the case of the ‘complete social media sharing platform™’, you’ve got nothing to go on… you haven’t got the ‘Why?’,  there is no spark of an idea, the problem solving part of your brain isn’t triggered… and consequently, more importantly, your enthusiasm has evaporated, it already feels like a slog, and that’s just reading about it here and imagining you might have to implement it one day. 

If we’re honest, one of the main drivers for a developer is 'to be the person who solved the problem', you take more ownership of the solution, it’s your idea at stake, so you know you might even ‘test it’ before you show it off on the client demo… it's a giddy exciting feeling when you've made a difference. 

I’m not a great fan of 'ego driven' development because it tramples over teamwork (and my teamworks is the best! much better than yours) but there does appear to be some truth in the maxim: 

present developers with problems to solve, not solutions to implement. 

(Notice I’ve pluralised developers) -  I think you end up with better solutions, but even if you don’t, everyone appears a lot happier and excited working on the thing, when it feels like it's 'theirs' - albeit I have no empirical data to prove this. 

I said it was subtle, and might not actually exist.


The other interesting thing here is the dissonance between what ‘is Umbraco’ and what isn’t… the tweeting part of the journey was perceived as a ‘thing not worth mentioning’, because it was outside of Umbraco, but is actually still a really key part of the whole editor journey. I only seem to uncover (or stumble upon) this kind of information, tangentially, when in conversation with an editor, perhaps during a training/orientation session or in a show and tell progress demo call, I think in those situations it's easier to be empathetic - however it's hard to sell the concept to the client that really they should pay for a developer to 'just watch them’,  that's apparently 'a bit too creepy'.... 

Anyway, Sorry I’m doing that thing of going on about stuff I'm not sufficiently professionally trained to wonder upon publically and you just want me to get to the bit about what we did… and link to some sort of code I must have hacked together.

What we did… 

Ok, so the crux of the problem here is the company blog twitter account is owned by the blog - not by the individual, so what can we do about that? 

With the wonderful SkyBrud.Social for Umbraco 7, all the hard work of authenticating a Twitter account using OAuth is done for you (Facebook,Google and Instagram too). 

It’s ace, Install it now! 

With this installed we can then add an ‘Authenticated Twitter Account’ option on the blog homepage: using the Twitter OAuth, DataType that comes with the SkyBrud package.


You’ll also need to create an ‘app’ with Twitter, to tell them that you are about to start programmatically authenticating and doing stuff with the API, it’s easy to do here: and they’ll give you a ‘Consumer Key’ and ‘Consumer Secret’ that you’ll need to cut and paste into the configuration for the SkyBrud Twitter OAuth DataType.


And if we’re logged into Twitter with the account we want to authorize, we just press the ‘authorize button’  and accept the following message:


And if you authorise the app, you now have an Authenticated Twitter Account associated with your blog:


So great, can we tweet every time something is published? 

No! - I mean you could but I think you have confused a twitter account with an RSS Feed.. (and there are services that will schedule tweets from an RSS feed)  - tweets should be mildly interesting, have some personality and be written for engagement, in my opinion... 

… but we DO want to shave some time off that 'logging out logging in cutting and pasting' journey discussed earlier, how best to send a tweet from here that isn’t automated?

How about a Custom Menu Item?

 We can make it only appear on the actions menu when a blog post is loaded and the editor can choose when to tweet


To add this custom menu item you have to write some c# code and hook into the Umbraco Event that fires when a Menu is rendered: 

Create a class called ‘RegisterEvents’ that inherits from ‘ApplicationEventHandler’ (or maybe your project already has one) we need to override the ApplicationStarting to add the hook to handle the event:

Tip: Type TreeControllerBase.MenuRendering 

and then type: + = Tab Tab 

It’s an exciting Visual Studio shortcut combination that will stub out the handler for the event and you should have: 

public class RegisterEvents : ApplicationEventHandler
   protected override void ApplicationStarting(UmbracoApplicationBase umbracoApplication, ApplicationContext applicationContext)
        //register custom menu item in the media tree
        TreeControllerBase.MenuRendering += TreeControllerBase_MenuRendering;
private void TreeControllerBase_MenuRendering(TreeControllerBase sender, MenuRenderingEventArgs e) {
//implementation here }  }

This is great trick if you know the name of the event but there isn’t clear documentation of the event signature to hand… 

Anyway the code to add the menu item will look something like this, I’ve commented what’s going on. 

// we only want to add this option to the content menu
if (sender.TreeAlias == "content")
     // get details of the content item
     var umbracoHelper = new UmbracoUmbracoWeb.UmbracoHelper(UmbracoUmbracoWeb.UmbracoContext.Current);
     var nodeId = e.NodeId;
     var contentItem = umbracoHelper.TypedContent(nodeId);
     // if the content item is a blog post
     if (contentItem != null && contentItem.DocumentTypeAlias == "BlogPostAlias")
         // create the menu item called ‘Tweet This’
         var tweetThisMenuItem = new UmbracoUmbracoWeb.Models.Trees.MenuItem("tweetThis", "Tweet This");
         //assign an icon
         tweetThisMenuItem.Icon = "bird";
         //separate it from other menu items:
         tweetThisMenuItem.SeperatorBefore = true;
         // now this is where we wire up the functionality of what to occur when the menu item is pressed - we tell the menu item to open a slidey out panel (actionView) and load the ‘tweetthis.html’ angularJS view into it:
         tweetThisMenuItem.AdditionalData.Add("actionView", "/app_plugins/tooorangey.TweetThis/tweetthis.html");
         // insert it somewhere in the list of existing menu options
         e.Menu.Items.Insert(5, tweetThisMenuItem);

Great we now have a custom menu item, that appears on a blog post, and when you click it, causes a 404 error on the missing tweetthis view! 

We need to create the view, and because we’ll be wanting to add some further functionality we also need to create an angularJS controller and a stylesheet, and finally a package.manifest to tell Umbraco to load these assets whenever the view is loaded:


The package manifest just needs to reference the js and the css assets:


So now when the editor clicks the 'Tweet This' menu option, our custom view, the TweetThis.html is loaded into the action panel, and the package manifest file (simply because it's in the same folder as the custom view, loads the angularJS controller and css we need for our Tweet This Textbox). 

The textbox measures the number of characters and is preloaded with some suggested text, eg the title of the blog post, and a link to the blog post, (and the template for this default text can be tweaked via a property on the blog homepage)


Which produces something like this:



Notice how it's highlighted 'who you are tweeting as'!

The counting of the number of characters left in a Tweet isn't as straightforward as you would think, all links, in tweets are shortened using, so you can’t just count characters, so you have to adjust the total remaining to allow for this, so any urls entered > 23 chars will not use up anymore of your allowed 140. (23 is the maximum length of a shortened link in twitter, there is an api /help/configuration that will tell you whenever this number changes, but of course I’ve hardcoded this for now, as I like ticking time bombs) 

Now when the editor clicks Tweet This, their message is tweeted!

How do we send the tweet? 

We have a TweetThis action in an api controller (UmbracoAuthorisedApiController) that the text of the tweet is sent to and again SkyBrud does the hard part: 

public IHttpActionResult TweetThis(TweetInstruction tweetInstruction)
      //read authenticated twitter account details
      var twitterAccount = getTwitterAccount(tweetInstruction.ContentId);
      if (twitterAccount != null)
         //get twitter service using authenticated twitter details
         TwitterService service = twitterAccount.GetService();
         TwitterStatusMessageResponse response = service.Statuses.PostStatusMessage(tweetInstruction.Message);
         return Ok();
   catch (Exception ex)
     LogHelper.Error(typeof(TweetThisApiController), "Error Tweeting Message", ex);
    return BadRequest("Error");

And here is a successful tweet...


notice we’ve implemented 'Twitter Cards' on the site, so whenever the blog post is shared it get's a preview with associated article image. 

But it's not my Twitter account - what ‘has’ been tweeted out recently? 

Because this isn’t the editors usual twitter account, and on some blogs it’s shared with other editors we’ve kind of defeated the object of this improvement if the editor still has to remember the twitter account, switch to twitter, read the recent tweets, make sure they are not duplicating previous tweet content or style, then switch back to Umbraco to make the tweet. So now that we’ve got Skybrud setup and the Blog Twitter Account authenticated, it’s possible to list the recent tweets out via a custom property editor on each blog’s homepage perhaps on the ‘Social Tab’ in the backoffice:



So what’s the effect on the journey stopwatch?

It's hard to compare fairly the two complete journeys, since a certain amount of time is spent thinking about and composing the tweet, but if we consider 'time until point of composure', It takes a few minutes to switch twitter accounts, so the obvious gain, here is being able to click Tweet This and in 12 seconds you are at the point of composure. Having the 'default text' in place saves further time, but hard to assess, whether this affects the quality of the tweet message, eg does the editor have more time to think about the actual message, or is the default 'good enough' - I'm going to pretend it potentially does both, and focus on the fact that 'time to the celebratory cup of tea' is drastically reduced.

So small little tailored changes like this, might seem unimportant or be brandished as 'gold plating' but any task that involves faff, even if the duration of the task isn't very long, wears us down, and it's particularly draining when you have to switch context or systems, whilst keeping the original task held in your mind, so tiny improvements of this nature can have a big impact on editor happiness and their outlook on an upgraded implementation.

"Umbraco 7 is great, you can tweet from the blog editor page"

Anyway you can have a closer look at the moving parts in this gist of a git repository, if you are interested in the implementation details.

"I hate Umbraco 7, I've just lost all my content and I was saving as I went along..."

Written by @marcemarc on Sunday, 30 July 2017

So I think as I explained before in an earlier post, here at Moriyama we've been working recently on 2-3 coincidentally similar projects, involving upgrading super-large Umbraco 6 sites to Umbraco 7 and supporting the editorial teams in making that switch and adapting to their new editing environment, and I think we've established that it's the human element of an editor experiencing Umbraco 7 for the first time, from the context of years of Umbraco 6 ‘enslavery’ which has really peaked my interest. Well, that and making musical based puns on any solutions that 'make it' into the community as Umbraco packages.

When something changes that fundamentally affects how you do your day to day job (and this is magnified if the change is thrust upon you), there appears to me, to be series of ‘states of mind’ that an individual needs to pass through, before they successfully adapt to the change, until they stop calling it the ‘new’ system - a bit like the seven stages of grief.

During this journey of adapting to change there appears to be a common state of mind when an individual will ‘question everything’, which is probably a really common part of human nature, mistrusting something new is a good survival technique.

This can feel really tiring, almost like the person doesn’t want the new system to be better, but if you are tasked with introducing the new way of working to that person, avoid being defensive: patience and explanations of ‘why’, and lots of patience are required to get through to the next stage - do not tell them the new thing IS better, instead, respect them to come to their own decision given time and information, and learn yourself from their feedback and how they see the change with their fresh grumpy eyes.

Anyway the interesting thing about a person in this mindset is they can often stumble across a series of steps or contrive a situation to find a bug or a flaw, that can take you by surprise…

… let me give you an example.

Take the journey of creating a new document and updating it in Umbraco 7 - saving it as you go along.

You and I know - it's not possible to lose your editing work in that scenario, is it?

you've pressed Save, it saves, right? - Umbraco is pretty reliable at that, and we know if we click away to another part of Umbraco we'll get the:

Discard / Stay option


If we're honest, we get that message a little bit too often than we'd like, it's annoying, but we know it's trying its best to help us, so we tut a bit, but don’t begrudge its existence.

So clicking the wrong option here is not what the user did to lose their work…

(notice how the colours have changed in 7.5+ so the ‘safe option’ to stay is now highlighted in green - so tired editors don't accidentally click the previously emphasised 'Discard' option (often semi-consciously, when tired or in a hurry you will inadvertently click the highlighted option on a dialog, without really thinking))

... wait they lost their work? Yes, here's how, why not follow along at home?

Create a new document in Umbraco 7

Perhaps a blogpost

Type some content into the document, press Save, type some more, press Save, type some more press Save, etc now after your last Save, click away to another part of the Umbraco content tree, you don’t get the 'Discard / Stay' option, now try and get back to the article you were creating…. It has gone!

What? How?

Now if you were following along at home you might have without thinking added a ‘Name’ for the document at the top, but if you did not, then when you press save, the feedback to say that this is required, is really subtle, (just a red border around the name, not consistent with the rest of the validation error messages).


If you are coming from Umbraco 6 you are a little bit blind to this area of the screen. So when you press save, your document isn’t saved, but that’s kind of ok, because the Name hasn’t been filled in, and you can’t save without a ‘Name’ dummy! - it's just you won't notice the absence of a save confirmation if you are not expecting one - but here’s the bug - pressing Save clears all the angularJS IsDirty() flags, whether the document is saved or not!!!! And this enables you to click away without the discard warning… and then as it’s not saved anywhere, you lose the content you just entered!


The subtle difference is in Umbraco 6, you had to supply the name at the point of creation, whereas in Umbraco 7 you can start editing the document without it having a name.


So the answer to this is to just explain to the editor to fill in the Name at the top of a document before they start creating content - but for someone transitioning to Umbraco 7 from 6, this occurrence is frustrating and saps confidence in the ‘new system’.

“It’s worse, I never lost content like this in Umbraco 6”

It increases the length of the phase the editor is in of ‘mistrusting the change to the new cms’, they question everything more and more. It harms their productivity.

Here’s what we did.

  1. Thanked the editor for discovering this - where were you two years ago? When people were testing this, bet this has driven other editors mad over the last two years and nobody understood why - now you’ve pinpointed it!

  2. Raised this as an issue: and explained how reported issues get fixed and improve the product for everyone, look at all the issues reported, it won’t be fixed immediately.

  3. Provide a short term quick workaround that acknowledges the seriousness of the issue to the editor…

Short term fix

So if someone forgets to type into the Name box (as it’s outside the editor main screen and they are not used to having to fill this in) let’s make the assumption, that they will type into the ‘Title’ box, the first property on the document type for this site. 

Let’s create a custom property editor for the text box and have anything entered into the Title textbox  ‘sync’ into the Name box on 'first load'...

...(but not after it’s been saved once that would be annoying) - now it will be impossible to type a title and not have a corresponding name for the document, we can make the title a ‘required’ property, and now no work can be created and lost accidentally in the weird scenario outlined above.


The code is here on github if you are interested. No musical pun. (‘Sync me up before you go go’ would be very poor and even below my standards - yes! - I have standards),

Editor is happier, we have listened, acknowledged the seriousness and demonstrated how quickly we can respond to issues like this in Umbraco 7 and Opensource.

Fast-forward to one week later, follow up visit and the editor says:

“Thanks for that sync box thing, but I’ve just learned to type a Name in first, so we don’t really need it”

Result! - the editor has adapted!, but in a positive way, it feels like we were on their side all along - they are sharing their success with us, the custom property editor of course wasn’t the ultimate solution, just temporary stabilisers, to give the editor confidence and enabled them to move on to the next phase of adapting.

Admittedly I don’t have a ‘scientific control editor’ that we told to ‘just put a name in first’ - this is all spurious and anecdotal, but I mention it really to try and highlight ‘there is a lot more going on’ when people use systems for the first time, or things change, and often amongst fellow developers I get a vibe, that editors are somehow at fault, but we should recognise it’s not a binary or even linear curve that humans follow when they encounter change, and if you support editors through the transition phase, the long term outcomes will be more positive.

The developers job doesn’t stop when the code is shipped.


Club Cropicana... Crops are freeeee!

Written by @marcemarc on Monday, 17 July 2017

We have been working on two upgrade projects from Umbraco 6 to Umbraco 7 this month, and it’s thrown up lots of interesting responses from the editors involved in making the move and adapting to their new environment.

“It’s just the same with a different font”.... was my favourite grumpy observation.

You get a bit complacent knowing how much better Umbraco 7 is in terms of editor experience that you take for granted that editors will embrace the change, forgetting that if you’ve used a tool for 3-4 years, and change is forced upon you, there will be at least some resistance, it’s human nature.

But for me it’s a really interesting scenario, and the first thing you do is stop telling people how much better Umbraco 7 is to Umbraco 6, and you listen - and you do this because editors use the product every day to edit content and they are 'seeing with fresh eyes', it's gold-dust and seconds and minutes within a particular workflow are incredibly important to them - they are the experts. 

Media Picking

Take Media Picking for example:  On one site when we sat and benchmarked editor activities for picking media for articles in Umbraco 6, it was monumentally slow, either an editor needed to switch to the media section to upload their image, and switch back to the content section to pick it or they used Digibiz Advanced Media Picker DAMP - that enabled them to upload to the media section from within the content section and set particular crops - but was really really slow. 

“You’ll love Umbraco 7 for picking media",  we boasted, "it’s one of the biggest improvements, it’s really fast and you can upload and pick media from within the content section, no more switching between the two, your workflow will be faster”

In both scenarios, we replaced with a standard Umbraco 7 Media Picker - and both workflows when re-measured using Umbraco 7 were faster: (stopwatch method - complete the journey as fast as you can).

Switching between Content and Media Section to upload image and then pick:

Umbraco 6: 3 mins 44 secs

Umbraco 7: 1 min 3 secs

Upload within the Content Section and pick: 

Umbraco 6 - Upload via DAMP: 1mins 24secs

Umbraco 7 - Upload via media picker: 35 secs 

Upload within the Content Section, pick and define crops:

Umbraco 6 - Upload and Crop via DAMP: 2min 21secs

Umbraco 7 - Upload via media picker: 1 min 42 secs

So basically it’s a win all round right?

Well no…

...all is not as it seems.

The gains of using the Media Picker to upload an image and pick selected crops is not ‘that much faster’ than using DAMP - this is mainly because with DAMP, you can edit the crops without leaving the content section in a popup window...



...even though doing so is slower in actual terms of task time, it feels much quicker ‘mentally’ because you haven’t had to shift your focus to another screen,  switch context and switch back again. 

The editors reported the journey in Umbraco 7 as feeling slower. 

Also if you were in the middle of editing content at the time, clicking the pencil on the Umbraco 7 media picker to open the image in the media section to enable the crops, will have triggered the ‘you have unsaved changes’ dialog, which will cause you to think, jolting your mental process - and you’ll have to save your content item, switch to the media section, adjust your crops, and switch back to content to complete the journey. 

The paradox is this is still actually quicker than using DAMP! - but it is the exact workflow you boasted earlier that Umbraco 7 had solved! 

Essentially the excellent Image Crop facility of Umbraco 7 is not welcomed with open arms by this set of editors because it has broken their workflow! 

Even though in real actual time the speed of the Umbraco 7 backoffice makes the workflow quicker to complete - It exhausts the editor in terms of concentration, and this is why it feels slow and for me, this is the really interesting thing about analysing UX/UI, and measuring improvements, is that you can’t ever discount ‘how it feels’ to the person, even if the stats say otherwise!! (think of it as the windchill factor that makes a cold day feel colder than it actually is) 

Anyway Tom Pipe (@toepimp) and I figured that surely it must be possible to bring the existing cropping functionality from the media section into an overlay in the content section: 

And we knocked this together: 


This is only a prototype, but very usable - we’ve taken the approach to have a new property editor that targets a media picker by alias and adds an Edit Crop button underneath the picker, clunky perhaps, but pragmatic...


... well we don’t want to end up maintaining our own custom media picker - we can release this for testing quickly and immediately improve the editing experience for our customer, improving over time with their feedback.


Hopefully, this illustrates the issue too, and a kind of resolution, and we can use this as the basis to explain the problem to Umbraco HQ that might lead to a PR or maybe it’s a bit too niche for the core, and it’s better as a separate package.

in which case what on earth would we call it?

Moriyama.ClubCropicana ???


(Darren IS on holiday this week)

or more sensibly:

OutCrop ? 

Anyway, It reassures the client that we are listening, and that the upgrade puts them on a platform that quick improvements like this can be made easily, but hang on forget the platitudes! - what has it done to the stopwatch test? 

Upload within the Content Section, pick and define crops:

Umbraco 7 with Moriyama.ClubCropicana/OutCrop: 53secs !! 

(and importantly it feels ‘mentally’ faster)