Umbraco.Community.Automate.DevTo 1.0.0-beta.3

Umbraco.Community.Automate.DevTo

A DEV Community (dev.to) connection and action for Umbraco Automate.

Cross-post your Umbraco content to DEV automatically when you publish it. Markdown, Rich Text, Block List and Block Grid content is converted to Markdown, relative links and images are made absolute, and the canonical URL points back at your site so search engines treat it as the original.

Works with Umbraco 17 and 18 (and Umbraco Automate 17 and 18).

Installation

dotnet add package Umbraco.Community.Automate.DevTo

No further setup required. The composer registers itself automatically via Umbraco's IComposer discovery.

Setup

1. Generate a DEV API key

On DEV, go to Settings → Extensions → DEV Community API Keys, give the key a description and click Generate API Key.

2. Store the key as a secret

Rather than pasting values into the backoffice, store them in the package's Umbraco:Community:Automate:DevTo section, split into Variables (non-sensitive values) and Secrets (sensitive values). The package registers both with Umbraco Automate's configuration allow-list, so no extra setup is needed; Secrets can only be referenced from sensitive fields such as API Key.

{
  "Umbraco": {
    "Community": {
      "Automate": {
        "DevTo": {
          "Variables": {
            "SiteUrl": "https://your-site.com"
          },
          "Secrets": {
            "ApiKey": "your-api-key"
          }
        }
      }
    }
  }
}

For production, use environment variables instead:

Umbraco__Community__Automate__DevTo__Secrets__ApiKey=your-api-key
Umbraco__Community__Automate__DevTo__Variables__SiteUrl=https://your-site.com

Reference these values from the backoffice with a $ prefix, e.g. $Umbraco:Community:Automate:DevTo:Variables:SiteUrl.

SiteUrl is only needed if Umbraco can't generate absolute URLs for your content (see URLs).

3. Create the connection

1. Go to Automate → Connections and create a new DEV Community connection.
2. API Key: $Umbraco:Community:Automate:DevTo:Secrets:ApiKey
3. Click Test connection. You should see "Connected as @yourname".

Posting to a different Forem community? Change Instance URL under Advanced.

Reference not resolving? The reference must start with $Umbraco:Community:Automate:DevTo:Variables: or $Umbraco:Community:Automate:DevTo:Secrets:, and the key must exist in configuration. If you previously used Automate's shared Umbraco:Automate:Variables / Umbraco:Automate:Secrets sections, move those values here; the Markdown preview only resolves Variables from the new section.

Cross-posting blog posts

Create an automation:

1. Trigger: Content Published, with Content Types set to your blog post type.
2. Action: Get Content, with Content Key ${ trigger.contentKey }. Only needed if you bind tags, a description or a cover image from the post's properties (below).
3. Action: Publish Content to DEV, with your DEV connection.

Title, Tags, Description and Cover Image take ${ } bindings, so they can come from the trigger, a Get Content step or any earlier step, with filters such as | truncate:100. Bound pickers and media arrive as JSON; the action reads the names (for tags) and URLs (for images) out of it.

Body Properties are properties rather than bindings on purpose: converting blocks, media and Markdown needs the content itself, which a binding (a JSON copy of the values) can't provide. Picked properties are stored with the document type they came from, so reopening the step shows their names and flags any alias the type no longer has (after a property is renamed, for example). Typed aliases are stored as a plain list (e.g. intro, contentRows).

Tags are lowercased and stripped to letters and numbers, as DEV requires ("Umbraco CMS" becomes umbracocms), and only the first four are used.

Updates, not duplicates

Before posting, the action looks through your DEV articles (published and drafts) for one with the same canonical URL. If it finds one, it updates it; otherwise it creates a new one. So re-publishing a post in Umbraco updates its copy on DEV, and a retried step never posts twice. No extra property on your document type is needed.

If you change a post's URL, the lookup won't find the old article. Set Existing Article ID to point it at the right one.

Leaving Publish immediately off never unpublishes. New articles are created as drafts, and an article you've already published on DEV stays published when it's updated.

Outcomes and outputs

The action produces a created, updated or notFound outcome (notFound means the content was unpublished before the step ran), so later steps can branch. For example, announce new posts on Mastodon only on created, so edits don't post again.

Its output is available to later steps:

Previewing

Click Preview… under Body Properties and pick a published item to see the Markdown and canonical URL the step would post, or the error it would fail with. DEV isn't called. Bindings only have values during a run, so the preview uses what a blank setting would for any that use one (Site URL, Culture, Canonical URL); $Umbraco:Community:Automate:DevTo:Variables:… references are resolved, secrets never are.

Finding the article on DEV

Once a post has gone out, its document's Info tab shows a DEV box with a link to the article, whether it was a draft or published when it was last posted, and when. Variant content gets a link per culture. The link is kept in Umbraco's key-value store, so your document type doesn't need a property for it. Automate's run history doesn't show step output, so this is the place to look.

The backoffice never calls DEV by itself. Click Check on DEV to ask DEV for the article's current state, using the connection it was posted with: it picks up an article you've since published (and its new URL), or marks one you've deleted as Deleted on DEV, with a button to remove the link. Publishing the page again posts a new article either way. Links saved by earlier versions of the package didn't record their connection; they're checked with your DEV connection if you only have one.

Reviewing before publishing

Leave Publish immediately off and publish on DEV yourself, or add Automate's Request Approval step followed by a second Publish Content to DEV step with Publish immediately on.

How content is converted

Relative links and image URLs are made absolute. Code samples are left untouched.

Custom blocks

If the built-in conversion doesn't suit a block, implement IDevToBlockConverter and register it:

public class CalloutConverter : IDevToBlockConverter
{
    public string? Convert(IPublishedElement content, IPublishedElement? settings, DevToConversionContext context)
        => content.ContentType.Alias switch
        {
            "callout" => $"> **Note:** {context.ConvertProperty(content, "text")}",
            "newsletterSignup" => "",   // leave this block out
            _ => null,                  // not mine: use the next converter / built-in conversion
        };
}

public class DevToConvertersComposer : IComposer
{
    public void Compose(IUmbracoBuilder builder)
        => builder.Services.AddSingleton<IDevToBlockConverter, CalloutConverter>();
}

DevToConversionContext gives you the same helpers the built-in conversion uses: ConvertProperty, ConvertElement (for nested blocks), HtmlToMarkdown, ResolveUrl and GetMediaUrl.

URLs

DEV needs absolute URLs for the canonical link, links and images. By default the action uses the absolute URL Umbraco generates for the content, which works when the site has a domain assigned (Culture and Hostnames) or Umbraco:CMS:WebRouting:UmbracoApplicationUrl is set. Otherwise, set Site URL on the step, e.g. to $Umbraco:Community:Automate:DevTo:Variables:SiteUrl.

Errors and retries

API failures are classified so Automate can decide what to do: rate limiting (429), timeouts and DEV being unavailable (5xx) are transient and retried according to the step's error behaviour; an invalid API key, a rejected article (422) or missing settings fail straight away with the DEV error message.

Compatibility

One build of the package supports Umbraco 17 and 18. It's compiled against 17 and every change is tested on both, including running the 17 build on 18 and checking every Umbraco API it calls still exists there. Umbraco 19 isn't supported until it has been tested.