Forem: Rockdove

I moved my website to Umbraco Cloud, this is how I got on

Joe Glombek — Mon, 21 Dec 2020 05:00:00 +0000

One weekend. One website. One rebuild.

I have a confession to make. Up until this weekend, my website was hosted on Squarespace.

This may seem counter-intuitive, for a software developer to use a service like Squarespace, but it made a lot of sense at the time. I needed a website fast while I was working full-time and didn't have the time or energy to build a site from scratch.

I've mentioned in the past how I'm not opposed to using third-party services where it makes sense, and this was certainly one of those occasions.

Squarespace is, however, not without its faults: accessibility is poor and there aren't many ways to improve it; the drag and drop designer is a pain when you want consistency and repetition; and my CV on the Squarespace site never looked quite right on mobile. So, combined with the fact that I'm an Umbraco developer without an Umbraco website, it was time for a change.

Trial signup

Investing evenings and weekends in building something I do for my day job has never really appealed to me, so I thought I might try out Umbraco Cloud. I like the idea of patch upgrades happening automatically and other upgrades possible without cloning locally. This means that going forwards I have less admin to do to keep my site up and up-to-date. Using Umbraco Cloud also meant that I'd have more recent practice using Cloud, so I was at least learning something from my endeavour (I haven't used Cloud since it was in preview and called UaaS!)

Signing up for the trial was fairly easy and promised 14 days to get my site in order before launching and paying for it. I had a repo up in no time.

Developing locally

Although Cloud allows fully-online development (more on that later), I'm stuck in my ways. So decided to try out developing the Umbraco site locally. Developing locally enables compiled libraries for custom helpers and extension methods and installing packages via Nuget (sorry, Umbraco Packages!) which is all good practice as far as I'm concerned.

Cloud is built around Git. Any changes you make are committed to Git and this automatically triggers a deployment to the Cloud site. In theory, this means working locally is as simple as cloning the URL Cloud provides and hitting run. But it's not quite that simple because Cloud runs ASP.NET Websites rather than their Web Application counterpart, meaning there is no Visual Studio Solution that's source controlled. Umbraco, therefore, provide UaaS.cmd to help simplify this process.

Foolishly, I initially only skim-read the documentation here before diving in. But after following the official guidance, this process was actually quite simple.

Then, after configuring my two (that's how it works!) git repos (and also setting up a mirror for the Umbraco Cloud repo because, although not necessary, I couldn't help feeling it was better practice somehow), I hit the run button...

Well, that didn't work. It's at this point I'd usually document the steps I went through to get it working properly but, in all honesty, I had no idea what I did to get it happy again. It was a bit of trial and error and likely specific to my setup, so we shan't dwell on this! The important thing is that it's working now!

Project setup

Let's take a moment to discuss the setup when developing locally.

UaaS.cmd sets up two Git repositories, one at the root (that you need to source control yourself) and one in *.Web (where * is the name of your project).

*.Web contains your Umbraco site as an ASP.NET Website (not Web Application - there is no .csproj file).

The root directory contains the solution file as well as a folder and csproj file called *.Core which, according to the docs, is where controllers, models, data access and extension methods should ideally live.

Models!?

Using ModelsBuilder is a bit of a pain. To get Intellisense working, the docs recommend using ModelsBuilder mode AppData (classes are generated upon request) or AppDataLive (classes are generated automatically when models change) and then overriding the path to place them in the App_Code folder, where they'll get compiled on the fly. This is quite clever. Visual Studio can pick these up automatically as ASP.NET Websites include files automatically (some of the time... it involves a lot of hitting the "Refresh" menu option) and they're compiled dynamically meaning you can change models on Umbraco Cloud (not developing locally) and they'll update dynamically.

However, this means that the *.Core project has no access to any ModelsBuilder models, which makes writing some of my common extension methods difficult. Normally I'd create a SiteSettings() extension method on IPublishedContent to get the settings node but, without access to models, I resorted to a generic method GetSite<Settings>() where Settings is the model for my Settings node.

public static T GetSite<T>(this IPublishedContent page) where T : class, IPublishedContent
{
    return page.Root().FirstChild<T>();
}

There are other options here but they all have their own downsides. You can the *.Core project altogether and put all your code in the ~/App_Code folder, but this means you miss out on any compilation ahead of time. You can also set your models to be generated within the *.Core project, but then you won't be able to utilise the ability to develop on the live site (more on that later). A third option may be (I've not yet tested it) to use the Dll or LiveDll ModelsMode (in the full version of ModelsBuilder) and reference the generated DLL in your *.Core project. This allows for development on the live site, but means you'll have to either manually generate models (Dll) or have site restarts every time you change a document type (LiveDll).

Website vs. Web Application

As indicated above, a website is mildly annoying to have as opposed to a web application. I've always seen applications as more superior, but the only reason I think this would be is because an application can generate DLLs, while websites can only have C# in the App_Code folder, where it's only compiled on application startup (think of it as the opposite of precompiled views).

Being a git about Git

And now, lets get onto the Git setup. This is a little weird. If you want to use Visual Studio to build your Umbraco site, the docs suggest you'll need two git repositories (although if you're feeling brave I'm sure you could use one and then use subtree or submodules and mirror to the Cloud repo... but that's a story for another day!): one for the *.Web folder, and one for everything else. The *.Web repo is hosted by Cloud (and is where it deploys from), while you'll need to create your own repo for the rest. Although I'm sure it's unnecessary, I also decided to mirror the Cloud repo because it feels like the right thing to do!

It's not really an issue, just a mild niggle. I'm sure someone more confident with Git than I could find a nicer way to handle this setup, but this one will do for now.

Umbraco Deploy

I've heard bad things about it but so far, for me, Umbraco Deploy has just worked. When Umbraco releases Deploy for non-cloud projects, I'm sure I'll have to do a full comparison between Deploy and uSync.Publisher, but for now I'm happy to use Deploy for Cloud and uSync for everything else.

Ability to develop on the live site! 🤠

I've always found the Settings area of Umbraco a bit odd, personally I'd rather do all my development within my IDE not partially in the browser. Working in a CI/CD world, I'd also have to disable the Settings section in any environment except locally.

But in Cloud, the Settings section makes so much sense for the simple reason that any changes you make on your Cloud environments and committed to the Git repo automatically. This makes my inner "cowboy coder" very happy. If I need to hotfix a live site, I can! If I want to tweak code from my phone, halfway up a mountain, I can! If I'm too lazy to open up Visual Studio to make a minor change to my personal site, I can!

Cloud is where Umbraco seems most at home, largely because of this.

Domain configuration... AKA 9 hours of downtime

I assume due to how Umbraco Latch works, domains will need to be configured to point to the Cloud site before an SSL certificate is generated. Unfortunately for existing sites, this means there will be a short moment of downtime while your domain points to a site with an invalid HTTPS certificate. However, in my case, basic authentication was not automatically disabled when I purchased my Cloud license (and by the time I realised it was too late!)

I decided to leave the setup overnight in the hope the problem would resolve itself with time, which it, unfortunately, did not. Support was, however, very helpful and resolved the issue quickly after I notified them of the issue.

Azure Web Apps allow domains to be preconfigured (with DNS text records) prior to mapping the domain, which may mean as Umbraco Cloud moves to Web Apps and uses Cloudflare in place of the existing Latch process for HTTPS, we may see an improvement here.

Umbraco cloud issues

I don't think it's unfair to say that Umbraco Cloud has a bit of a reputation when it comes to stability... and not a good one. And so far, I'm not helping that reputation, having already detailed an issue I had with my site not coming out of trial mode.

I did also experience a short amount of downtime on Saturday night.

But that's it so far. And support has been great at fixing the issues I have had.

I also had an issue with a bug in Umbraco Forms, which the support team fixed without having to delve into the database myself.

The price is right... sometimes

So who is this for? It's a question that's asked again and again. And I wasn't sure until I tried it properly myself.

I think the answer is, Umbraco Cloud is great for me. My use case is that I have a small low-traffic site which I don't want to have to invest huge swathes of time keeping patched and up to date, but I do want to quickly develop and launch new features.

It's not ideal for complex custom setups, or sites requiring "four-nines" of uptime. It might also outprice individuals or small charities. But for those in the middle, it seems to suit quite well. I won't be recommending Cloud to every client, but I think I now know who the target market is, and will recommend to those clients going forwards.

It will be interesting to see how the new planned infrastructure for Cloud will affect this target demographic and whether we'll see a more stable platform going forwards.

As for the relatively high cost vs self-hosting, I think this comes down to the quality and speed of the support team. If you consider the month price as a time-saver, it's easily worth it in my opinion.

How to set Windows Terminal as GitKraken's default terminal

Joe Glombek — Fri, 11 Dec 2020 06:34:00 +0000

GitKraken allows you to open the current repository in the terminal by hitting Alt + T but by default, this won't be the new Windows Terminal.

The new Windows Terminal has many benefits over the Command Line or Powershell applications but you won't find Windows Terminal as an option for the default terminal in GitKraken's settings.

There is a simple fix, however. Open up GitKraken's preferences (File > Preferences) and scroll down to and check "Use Custom Terminal Command" (below "Default Terminal" dropdown). Then, in the "Custom Terminal Command" field that appears above, enter:

wt -d %d

wt is the command for Windows Terminal, to which we're passing the -d directory parameter. The value of %d is then swapped out by GitKraken for the directory of the current repository.

It's as simple as that!

At the time of writing, there is a bug in GitKraken which launches the terminal twice when using the File > Open Terminal option, but Alt + T works just fine.

Easily open uSync Sync-Pack files

Joe Glombek — Tue, 16 Jun 2020 11:38:03 +0000

uSync Sync-Pack files (with the .uSync extension) are simply ZIP files and can be viewed in any ZIP viewer, including the one built into Windows.

One option is to rename your Sync-Pack to have a .zip extension and then open it as you would any compressed folder.

The other option, however, which is very useful if you’re looking inside uSync files more often, is to let Windows know that the .uSync file is a ZIP file and to treat it as such.

There’s no point-and-click setting for this like there is for associating a filetype with a program, because we’re doing something subtly different: telling Windows this file is a ZIP file.

All you need to do, though, is open a command prompt as administrator and run:

assoc .uSync=CompressedFolder

Integrate, don't imitate - when an API beats rolling your own

Joe Glombek — Wed, 06 May 2020 22:14:30 +0000

It wasn’t long ago that every agency and freelancer had their own custom CMS they’d use for client projects. We decided that was a bad idea. But we’ll often be seen writing custom code within that standardised CMS. Are we making the same mistakes again?

This blog accompanies my talk at the Thames Valley Umbraco User Group on 30 April 2020. I also have the slides for my talk available.

Let’s start with a couple of scenarios.

Scenario 1: John the roller coaster enthusiast

Meet John. He’s a rollercoaster enthusiast and he’s decided that he wants to ride a roller coaster at least once a week. He’s got a good budget and money is no object.

How could we solve his problem?

Option 1: Build a roller coaster in John’s back garden

We could recommend to John that we build a roller coaster in his back garden. This could be quite fun and he could ride the roller coaster as often as he liked, with no need to queue. But on the downside, the estimated cost of this solution is £2.5 million to £25 million (source: BBC).

Option 2: Go to a theme park

Alternatively, we could just recommend that he goes to his local theme park. He’d have his choice of various rides with no build-time, planning permission, health and safety, insurance, etc.

As for cost, a “premium season pass” at a well known theme park costs £85 (notice the lack of the word “million” as a suffix), plus the cost of fuel (which, no matter how far you’re travelling is negligible, again due to the lack of the “million” suffix).

I’ll let you decide which option to pitch to John.

Scenario 2: National Bushcraft Association website

Some of you may know about the time I lived in the woods for 6 months and taught wilderness survival skills to school children. So, I've created a scenario around the fictional National Bushcraft Association, a membership organisation for bushcraft instructors.

Members pay an annual fee to gain benefits such as networking, client referrals, news sharing capabilities and the obligatory newsletter. They want a Content Management System (CMS) with member management functionality to manage membership fees, expiry of unpaid memberships and mass mailing.

So the obvious solution?

Umbraco! That’s my go-to CMS, and I love working with it. Of course simply being my favourite CMS doesn’t justify the choice on its own, Umbraco is open source with an enthusiastic community meaning its free and actively developed. Umbraco will easily cover the requirement the Bushcraft Association has for content management. It also has a highly extensible membership management system.

The membership management functionality in Umbraco by default, however, is comparatively basic. So we’d need to build custom functionality to allow sending newsletters, membership payment and expiring members who haven’t paid.

But wait! Isn’t this the theme park scenario all over again; are we building a roller coaster? And if so, what are our other (“season pass”) options here?

As for membership management, there are dozens of pre-built systems available that have this down to a tee, and many of them have an API we could integrate with. A third party system would handle the membership fees, expiry and renewal reminders in the requirements, but also take GDPR off our hands and give us extra functionality to, for example, allow members to manage their own details and upgrade their membership tier as they need to, without phoning up the office team.

Similarly, a newsletter sending platform would handle sending newsletters and managing subscriptions and unsubscriptions as required while also handling GDPR and providing the Bushcraft Association with analytics.

In this scenario, I think building a basic CMS site and integrating with some third party services is the clear winner.

The problem solver mindset?

But where does this “backyard roller coaster” attitude in developers come from?

Personally, I think it’s due to the problem solver in us. We’re in this career because we like to solve problems and when someone gives us a brief we like to find an “ideal” solution, built exactly the way we think it should work.

As well as this, as a premium service provider, we might feel it’s our duty to build everything bespoke rather than “cheating” by using other people’s work.

It seems to take some maturity as a developer to realise we’re not taking the easy way out by using other people’s work, but standing on the shoulders of giants.

We’re all too keen to use open source packages to speed up development and provide our users with a better experience, so why not complete services too?

Benefits of integration

For us developers, integrating makes life less repetitive, I get to spend more time writing new code rather than making poor imitations.Being honest, I just find building integrations more fun; I don't get too excited about another document type or building another news page. Writing more in depth C# is more interesting to me!

But how do we sell an integration to higher ups, project managers or the client?

Over-delivery and extra features

Integrating with more complete systems can result in over-delivery. Third party systems likely have more features built into them over the years than you could do with the budget, the client’s going to get an industry-standard application, rather than the bare minimum.

Not to mention the fact that the client may get extra features “for free” as the third party developer continues to improve their application over time.

Less scope creep

Since a client is buying into an existing system, chances are they can trial that system before they commit to using it. Since the client knows exactly what they’re getting and has already taken part of the system for a test drive, the requirements are less likely to change, reducing scope creep.

Less support

Since you’re building less, it means you handle less of the support after launch. There can be positives to this for the client too such as a reduced retainer cost and perhaps a better response rate than your team could provide. This also means that the client is less reliant on you or your company in the future, which could go a long way towards easing their minds!

A solid platform

By buying into an existing ecosystem, some of your application has been built and tested already.

A balancing act

Of course, it’s not always as simple as integrating. If nobody built their own roller coasters, there wouldn't be a theme park to buy an annual pass for!

It wasn’t long ago that every agency and freelancer had their own custom CMS they’d use for client projects. We decided that was a bad idea. But equally, not every website should be built with Wix, Squarespace or Shopify. There’s often a trade off between bespoke and prebuilt. Every project needs an evaluation. Integration may not always be the answer, but it should always be considered.