I’m trying to build a page with blocks, on which one block is able to link to another (as in an anchor link with scroll into view).
Using the block’s id would be the best solution I guess. But as far as I can tell, there’s no way to copy that Id from the UI, only in the code. Would it be possible to add an option to this context menu for reading/copying the block’s id?
Hmm, I think I understand your use case here, but I don’t think the block’s internal ID is the safest way to do this for public use (like in HTML anchors). That a block has an internal ID at all is just a side effect of how they are represented in our internal database, but normally it’s safer to think of blocks as just embedded parts of their parent record. Because the IDs aren’t really part of the block’s content, they could become “detached” or orphaned or if you copy blocks, etc. And if you have a bunch of links to non-human-readable block UUIDs like at4YWxNgRPeYrCz7HTMyZQ and dc5wWYOeRp-S4DVWqhbgQQ, it can become pretty confusing quickly and you might lose track of what points to what.
Instead, can you maybe add another single-text field inside that block, like “HTML ID”, that your editors can manually define? On the frontend you just have to render that as <a name={block.htmlId}/> or <div id={block.htmlId}/>. And in the Dato UI, you can link to it by that ID, like #myfirstblock. This might also be better for SEO and sharing links. Would that work for you?
Yeah, I figured it wouldn’t be ideal, but in my case I think it’s preferable, just because there are multiple types of blocks that are candidates for target sections, and I don’t want to keep adding this field to each block (specially since it will be seldom used).
As for the html id, once I know which block is which, I can base the actual html id on some more meaningful field.
I guess since this is not a great solution it’s unreasonable to expect it to be added to that context menu, so I guess I’ll end up getting the Ids from the CDA. It won’t change to frequently, so it’s ok if only engineers can add it…
I see, thank you for explaining, @thiago. Hmm, given all that you said… maybe there is a way to use a plugin to expose the ID and make it easier to copy? Let me poke around the SDK for you and see if I can find anything appropriate. Please give me a day or two on that.
That’s what I’m looking for, too… that may be a hook we’re currently missing (and if so it’d be a good feature request on its own), but in the meantime there might be something close enough that we might be able to use (like maybe adding a menu item to the structured text field’s dropdown instead of each block’s; it would have to enumerate all the blocks within that field and let you choose one to copy an ID for). Or maybe there’s a way to put it next to one of the fields within a block… I’ll look and see!
Yes, you should be able to just use navigator.clipboard.writeText(). Our plugin iframe is instantiated with allow='clipboard-write', so it should just work.
And try it on this demo project (invitation in your email).
For now it’s just a simple field addon. Unfortunately, there doesn’t seem to be a way to override each block’s dropdown menu. There IS a way to override the field’s menu, but that currently has a separate bug (reported to the devs) that prevents sub-menus from displaying correctly.
But at least this gives you the basic functionality of being able to easily see & copy IDs.
Great, glad you got that working! That should work fine for a single level of blocks (no nesting). If you need submenus (for blocks within blocks), that’s currently bugged… I’ll let you know if that gets fixed.
Hi, Roger, I still haven’t been able to make the copy to clipboard work.
navigator.clipboard.writeText()
Results in the following error messages on devtools:
dato-customization.vercel.app/:1 Uncaught (in promise) NotAllowedError: Failed to execute 'writeText' on 'Clipboard': Write permission denied.Understand this errorAI
QMVcyMp7RHa8lnRo249nBw:1 ClipboardReadWrite permission has been blocked because of a permissions policy applied to the current document. See https://goo.gl/EuHzyv for more details.
The iframe does have allow='clipboard-write'. I’ve tried deploying the plugin, so that the URL would have https, but the same error remains. The link that chrome directs to also doesn’t work. Do you have any clues?
Ah, good catch, sorry =/ There’s a few issues with that approach:
The dropdown actions are not inside their own iframe, so the content security policy doesn’t matter
There’s a focus issue, as you saw
Some browsers have an additional restriction on clipboard.writeText() that requires a user interaction (like a click) before you can do that
The workarounds I could think of are:
Using my plugin demo above (shows a nested list below the field) in post #9, which is all inside the iframe and solves the focus/interaction problem by requiring the user to click in the tree itself
You can pop up a modal with a button that does the copy, like: