umbPublisher 1.7.4
umbPublisher 1.7.4: descriptions, settings search and a tidy up
TL;DR. Two releases in one post. 1.6.0 added an optional Description property, so the description: in your note's frontmatter lands in the Umbraco property of your choice. 1.7.4 rebuilds the settings tab so every setting shows up in Obsidian's settings search, signs the release files, and tidies up a handful of things the Obsidian plugin review flagged. It needs Obsidian 1.14.4 or later. This post was published with it.
<img src="owain.codes" alt="umbPublisher 1.7.0 mapping" width="500"/>
Why
For anyone who hasn't come across it, umbPublisher is an Obsidian plugin that pushes your notes into Umbraco 15+ as content, using the Management API. I write everything in Obsidian, so being able to publish from there rather than copy and paste into the backoffice is the whole point.
Back in 1.5.0 I added tags. The tags in your frontmatter get mapped to an Umbraco Tags property, and that's been working nicely. But most blog document types have another field that's crying out for the same treatment: a description. Whether it's used for a listing page, search results or the meta description, it's a short summary that I'd already written in my note and then had to copy into Umbraco by hand after publishing. Not any more.
Descriptions (1.6.0)
Add a description to your note's frontmatter:
---
title: My post
description: A short summary of the post.
tags:
- Umbraco
---
Then in Settings > umbPublisher:
1. Click Fetch properties to load the properties from your document type.
2. Pick your property from the Description property dropdown. It sits right under Tags property, in the Optional properties section.
That's it. Next time you publish, the description goes along with the note.
If you don't want to use it, leave the dropdown on [None] and nothing changes. Notes without a description are fine too. The property just gets left empty.
Your property, your choice
Tags were easy because Umbraco only has one way of storing them. Descriptions aren't like that. Some sites use a plain text area, some use a markdown editor and some use a rich text editor. So rather than forcing one, the plugin looks at the property you picked and sends the value in the shape that editor expects:
| Property editor | What gets sent |
|---|---|
| Text area or text box | the description, exactly as written |
| Markdown editor | the description, exactly as written |
| Rich text editor | the description, HTML escaped and wrapped in a paragraph |
One thing to be aware of is that the description is always treated as plain text. If you write markdown or HTML in it, it isn't converted. Sent to a rich text property, a < or an & shows up as exactly that, rather than breaking your markup. A description is meant to be a sentence or two, so I kept it simple on purpose.
It works whether you're using Property Editor, Block List or Block Grid mode. It always goes on the document itself, never inside a block, the same as the title and tags.
A couple of gotchas
- Text box length. Umbraco's text box property has a 512 character limit by default. If your descriptions run long, map them to a text area instead, otherwise Umbraco will reject the document.
- Don't double up. You can't choose the same property for the description as you've used for the title, content or tags. The plugin checks this before publishing and tells you if you have.
Settings you can actually search for (1.7.4)
Obsidian 1.13 introduced a new way for plugins to describe their settings, and with it came a warning on umbPublisher: its settings wouldn't appear in Obsidian's settings search. Fair enough. Type "client secret" into the search box and you'd get nothing, which isn't great when that's exactly the thing you're hunting for.
So I rebuilt the settings tab on the new API. Every setting is now searchable, including a few extra search words so "credentials", "frontmatter" or "description" all find the right row. The settings are also grouped under headings now:
- Umbraco connection. Website URL, client ID and client secret.
- Content location. The parent node and the document type to create.
- Content mode. Property Editor, Block List or Block Grid.
- The settings for your mode. Title and content for Property Editor, or the block property, element type and content property for Block List and Block Grid.
- Optional properties. Tags and description.
Everything works the way it did before. The Fetch buttons, the dropdowns and your saved settings are all exactly where you left them, just easier to find.
A tidy up from the plugin review (1.7.4)
The Obsidian plugin review turned up a few things worth fixing, so I fixed them.
- Signed release files. Each release now comes with GitHub artifact attestations for main.js, manifest.json and styles.css. If you like to check what you're installing, you can verify a download with gh attestation verify main.js --repo OwainWilliams/umbPublisher.
- No more scanning your vault. To find the images in a note, the plugin used to fall back to listing every file in your vault. It now asks Obsidian to resolve the link, the same way Obsidian does when it displays the image, and only ever looks at the images you've actually embedded.
- Better GUIDs. The IDs for new documents and blocks are now generated from proper cryptographic randomness rather than Math.random. There was even a helper sitting in the code for this that was never used. Oops.
- Housekeeping. I swapped out a deprecated Obsidian API and cleared out some unused code, so the linter is finally happy too.
Upgrading
Update the plugin and you're done. Your existing settings are kept, and the Description property starts off as [None], so nothing changes until you pick one.
The one thing to know is that 1.7.4 needs Obsidian 1.14.4 or later. If you're on an older version of Obsidian, you'll stay on umbPublisher 1.6.0, which still has the description feature. Update Obsidian and 1.7.4 will be waiting for you.
Thanks
If you're using umbPublisher, I'd love to hear how and please give it a star on GitHub . If there's another field you'd like mapped from your frontmatter, or something isn't working, open an issue on GitHub. That's genuinely how features like this one end up getting built.
Mentions
umbPublisher 1.7.4 umbPublisher 1.7.4: descriptions, settings search and a tidy up TL;DR. Two releases in one post. 1.6.0 added an optional Description property, so the description: in your note's frontmatter lands in the Umbraco property of your choice. 1.7.4 rebuilds the settings tab so every setting shows up in Obsidian's settings search, signs the release files, and tidies up a handful of things the Obsidian plugin review flagged. It needs Obsidian 1.14.4 or later. This post was published with it. <img src="owain.codes" alt="umbPublisher 1.7.0 mapping" width="500"/> Why For anyone who hasn't come across it, umbPublisher is an Obsidian plugin that pushes your notes into Umbraco 15+ as content, using the Management API. I write everything in Obsidian, so being able to publish from there rather than copy and paste into the backoffice is the whole point. Back in 1.5.0 I added tags. The tags in your frontmatter get mapped to an Umbraco Tags property, and that's been working nicely. But most blog document types have another field that's crying out for the same treatment: a description. Whether it's used for a listing page, search results or the meta description, it's a short summary that I'd already written in my note and then had to copy into Umbraco by hand after publishing. Not any more. Descriptions (1.6.0) Add a description to your note's frontmatter: --- title: My post description: A short summary of the post. tags: - Umbraco --- Then in Settings > umbPublisher: 1. Click Fetch properties to load the properties from your document type. 2. Pick your property from the Description property dropdown. It sits right under Tags property, in the Optional properties section. That's it. Next time you publish, the description goes along with the note. If you don't want to use it, leave the dropdown on [None] and nothing changes. Notes without a description are fine too. The property just gets left empty. Your property, your choice Tags were easy because Umbraco only has one way of storing them. Descriptions aren't like that. Some sites use a plain text area, some use a markdown editor and some use a rich text editor. So rather than forcing one, the plugin looks at the property you picked and sends the value in the shape that editor expects: | Property editor | What gets sent | |---|---| | Text area or text box | the description, exactly as written | | Markdown editor | the description, exactly as written | | Rich text editor | the description, HTML escaped and wrapped in a paragraph | One thing to be aware of is that the description is always treated as plain text. If you write markdown or HTML in it, it isn't converted. Sent to a rich text property, a < or an & shows up as exactly that, rather than breaking your markup. A description is meant to be a sentence or two, so I kept it simple on purpose. It works whether you're using Property Editor, Block List or Block Grid mode. It always goes on the document itself, never inside a block, the same as the title and tags. A couple of gotchas - Text box length. Umbraco's text box property has a 512 character limit by default. If your descriptions run long, map them to a text area instead, otherwise Umbraco will reject the document. - Don't double up. You can't choose the same property for the description as you've used for the title, content or tags. The plugin checks this before publishing and tells you if you have. Settings you can actually search for (1.7.4) Obsidian 1.13 introduced a new way for plugins to describe their settings, and with it came a warning on umbPublisher: its settings wouldn't appear in Obsidian's settings search. Fair enough. Type "client secret" into the search box and you'd get nothing, which isn't great when that's exactly the thing you're hunting for. So I rebuilt the settings tab on the new API. Every setting is now searchable, including a few extra search words so "credentials", "frontmatter" or "description" all find the right row. The settings are also grouped under headings now: - Umbraco connection. Website URL, client ID and client secret. - Content location. The parent node and the document type to create. - Content mode. Property Editor, Block List or Block Grid. - The settings for your mode. Title and content for Property Editor, or the block property, element type and content property for Block List and Block Grid. - Optional properties. Tags and description. Everything works the way it did before. The Fetch buttons, the dropdowns and your saved settings are all exactly where you left them, just easier to find. A tidy up from the plugin review (1.7.4) The Obsidian plugin review turned up a few things worth fixing, so I fixed them. - Signed release files. Each release now comes with GitHub artifact attestations for main.js, manifest.json and styles.css. If you like to check what you're installing, you can verify a download with gh attestation verify main.js --repo OwainWilliams/umbPublisher. - No more scanning your vault. To find the images in a note, the plugin used to fall back to listing every file in your vault. It now asks Obsidian to resolve the link, the same way Obsidian does when it displays the image, and only ever looks at the images you've actually embedded. - Better GUIDs. The IDs for new documents and blocks are now generated from proper cryptographic randomness rather than Math.random. There was even a helper sitting in the code for this that was never used. Oops. - Housekeeping. I swapped out a deprecated Obsidian API and cleared out some unused code, so the linter is finally happy too. Upgrading Update the plugin and you're done. Your existing settings are kept, and the Description property starts off as [None], so nothing changes until you pick one. The one thing to know is that 1.7.4 needs Obsidian 1.14.4 or later. If you're on an older version of Obsidian, you'll stay on umbPublisher 1.6.0, which still has the description feature. Update Obsidian and 1.7.4 will be waiting for you. Thanks If you're using umbPublisher, I'd love to hear how and please give it a star on GitHub . If there's another field you'd like mapped from your frontmatter, or something isn't working, open an issue on GitHub. That's genuinely how features like this one end up getting built.