A familiar CMS editing pattern is one where the editor selects or enters a link, and adds a handcrafted text label.
But what is the type of link?
It could be a link to an existing page in the CMS, an external URL, an email, or a document download.
A naïve interpretation would be to have an optional field for each of these types, and for all of these fields to be displayed at the same time.
But then how does the CMS editor know which one is going to be used in the output?
The wrong way
A quick and dirty implementation would be to display all of the fields at once and then add some help text, explaining which link type would be prioritised if multiple values were available.
But this would just add cognitive load onto the editor, when we as developers should be anticipating and coding around such ambiguity.
The right way: show one value at a time
Instead of showing all available fields at once, we should allow the CMS editor to select the link type, and then complete the associated value (e.g. an external URL, or selecting another page in the CMS).
Once we have the ability to capture all of the valid link type values in the edit screen, we can magic away the HTML template implementation out of sight (e.g. adding mailto: to email links, or getting the url property of the internal page object).
Link editor in its default state, waiting for the link type to be selected
It’s pretty easy to do this using something like ACF in Wordpress - there’s a built-in field type that allows you to show and hide options based on another selection.
At the time of writing, however, this kind of functionality is not available out-of-the-box with Wagtail, so we need to roll our own.
It’s not a huge task though, just a little subclassing of Wagtail’s BaseCompositeEditHandler and the associated FieldPanel template to handle the edit screen JS interactions.*
Now we can select an internal page, and not worry about other value types
Or we can change our mind, and select an external URL. The page selector interface has been replaced with the URL field
A little goes a long way
It’s our job as developers to guide the CMS editor, whoever she may be, through the maze of content editing - and not to lay any unnecessary traps along the way.
I think it’s worth writing a little extra code to make everyone’s lives that little less complicated.
This post is part of a series: UX for the CMS user
* It’s a bit too much code for me to add to a simple blog post like this, but I’m happy to share some examples if you’re interested.