smd_copy_url: Copy article URL to the clipboard

Bloke · 2025-01-25 00:00:27

Making links between articles isn’t the easiest thing to do in Textpattern. Hopefully this plugin will make it easier. It could act as a companion to smd_wiki_link for cross-linking articles.

The smd_copy_url plugin does two things:

Adds a little link icon alongside the url_title in the Write panel.
Adds little link icons alongside the article titles on the Article list panel.

Clicking one of those will copy the current URL, based on the permlink scheme in force, to the clipboard for you to paste wherever you need it.

But wait, I hear you cry. Why bother with this feature on the Articles panel? After all, we can just right-click the value in the Status column to get the permlink. Two important distinctions between that and the links generated by the plugin:

The domain is not part of the link (for portability).
It’s independent of article Status. In Textpattern, links to Draft, Hidden and Pending articles are admin-only preview links. This plugin returns the final URL of what the article destination will be when published. Handy for making links in other articles in preparation for going live.

Caveats:

The plugin takes into account all permlink schemes except /breadcrumb/title (at the moment: ideas welcome on how to sanely handle it).
If you are creating a new article, you cannot use the copy URL link if you are using any permlink scheme that requires an ID (messy, /section/id/title, or /id/title). You must save the article first so it is assigned an ID.
There’s currently no feedback to know that you’ve copied the link (besides a notification in the browser console). Anybody who has ideas on how best to indicate the action has succeeded, please speak up.
The link icon SVG is the smallest one I could find and may not be the most logical choice. It’s also not aligned particularly well and I’m not good enough with SVG to understand how to make it better. If anybody has any improvements on this icon, please raise an issue with a better implementation and I’ll put it in the plugin. Thanks.

It’s not been tested in anything other than Firefox so it might fall apart on Webkit / Blink. Testing welcome.

Hope it’s useful to someone anyway.

Bloke · 2025-01-25 00:10:17

Ha, in fact I just tested it on Safari and it doesn’t copy the links, and breaks the ability to click through to the Write panel. Damn you, preventDefault(). Will issue a fix… sorry.

Bloke · 2025-01-25 02:33:49

Well, I’m baffled. I’ve spent the last hour or so faffing around with the JavaScript, even rewriting it to be less efficient and attaching event listeners to each icon instead of using delegation, all to no avail. The function that copies to clipboard (the fallback one, because my version of Safari reports it doesn’t have the navigator.clipboard API, even though caniuse claims it’s been there since v13) fails on the Articles panel, but succeeds on the Write panel. It’s the exact same function!

The fallback is quite dirty: it creates a hidden textarea, puts the text to copy inside it, calls focus() and then select() on the content before calling the copy command and then destroying the textarea.

The only thing I can see that’s different is that when you click on the link on the Write panel, nothing seems to happen. The link is copied.

BUT, on the Articles panel, clicking on a copy icon will briefly select the entire form and then try to create/focus/select the hidden textarea (which it does) but the copy command fails.

I’m guessing that the delay involved in selecting the form by triggering the default action inside the table is tripping the code up; maybe it’s not selecting the content in the hidden textarea in time for the copy process, so it reports failure? Alternatively, it could be a scope issue. Maybe the events inside the form/tr/td are clashing with other events?

At this point, I have no idea why it’s failing on Safari (and presumably Chrome, but I don’t have that browser installed to test it).

If anyone has any clues, I’d love to figure out why. It’s probably something super simple I’ve overlooked.

giz · 2025-01-25 16:36:00

‘dunno if it’ll help the fallback, but how about storing the string in browser local_storage instead? I suspect this may negate browser agent suspicions.

Last edited by giz (2025-01-25 16:37:30)

Bloke · 2025-01-25 17:45:52

Nice idea. If it can be copied out of there to the clipboard.

phiw13 · 2025-01-26 07:03:19

Bloke wrote #338894:

With version 0.1.0, freshly downloaded from you GH.

Clicking on the icon on the write panel seems to work on the Write panel
On the Articles panel that doesn’t work as well with Safari:

[Log] smd_copy_url: URL clipboard copy: unsuccessful (index.php, line 680)

Firefox and Brave: console message: smd_copy_url: URL clipboard copy: successful

With all 3 browsers: impossible to click on the article title link to edit. I had to create a new article to test the Write panel

The link icon SVG is the smallest one I could find and may not be the most logical choice. It’s also not aligned particularly well and I’m not good enough with SVG to understand how to make it better. If anybody has any improvements on this icon, please raise an issue with a better implementation and I’ll put it in the plugin. Thanks.

Your icon is OK, I think. I thought there was a link icon in the collection that ships with Textpattern, but I can’t find it¹. It could be a little bigger. For styling:

.smd_url_copy_icon {
  margin-inline-start: .5em;
  vertical-align: -.15em;
}

might work better (move it a little away from the text-string and vertical-align it a little lower).

–^–

¹ Else you could use the standard Textpattern ui-icon markup. List here.

Bloke · 2025-01-26 08:15:06

Thanks for trying it out. Yeah, the Safari thing is weird. The latest dev commit removes the preventDefault() so you can at least click the article links. But I’ve no idea about the unsuccessful message. It’s baffling.

I’ll see what I can do about the link icon, thank you.

phiw13 · 2025-01-29 08:51:51

Stef, did you try this on a live, https, site? In that case Safari 18 (and probably older versions, but not tested) uses you “modern code”. MDN states that the clipboard API is something that only works in secure contexts. Firefox and Chromium treat localhost as “secure“ but that is not a requirement.

On the Write panel, console log reports: smd_copy_url: URL copied to clipboard.

On the Article list panel, it still does not work though (Safari – Firefox and Chromium are OK).

Console reports:

[Error] smd_copy_url: Unable to copy URL
NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission.

At the moment I have no idea if that is possibly me (all extensions are fully disabled, private window) or some default Safari thing in that context.

Here is the additional stack the console reports:

writeText
copyTextToClipboard — index.php:680
(anonymous function) — index.php:765
c — jquery.js:2:25310
fireWith — jquery.js:2:26055
l — jquery.js:2:77794
(anonymous function) — jquery.js:2:80267
	(anonymous function) (index.php:683)

PS – Have you considered wrapping that SVG icon inside a <button class=txp-reduced-ui-button /> instead of that span? That would make it more accessible for keyboard users and AT users in general.

Bloke · 2025-01-29 09:20:50

Good shout on the button. I’ll do that, thank you.

I was testing on localhost in Safari, so that may account for the issue but it does seem still not to work on the articles panel properly. Thanks for the stack trace, I’ll do some more digging later.

phiw13 · 2025-01-30 02:17:35

Bloke wrote #338957:

Good shout on the button. I’ll do that, thank you.

Something like this, with added aria-label=copy URL:

<button class="txp-reduced-ui-button smd_url_copy_button" aria-label="copy URL"><svg xmlns="http://www.w3.org/2000/svg" class="smd_url_copy_icon" width="16" height="16" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path stroke="none" d="M0 0h24v24H0z" fill="none"></path><path d="M9 15l6 -6"></path><path d="M11 6l.463 -.536a5 5 0 0 1 7.071 7.072l-.534 .464"></path><path d="M13 18l-.397 .534a5.068 5.068 0 0 1 -7.127 0a4.972 4.972 0 0 1 0 -7.071l.524 -.463"></path></svg></button>

Some additional styling:

.smd_url_copy_button { color: var(--primary-text); margin-inline-start: calc(var(--txp-spacing) * 0.5);}
.smd_url_copy_button svg { vertical-align: -.15em; }

The default color on the button is the theme link color; I think it is better to use the default/main text color. This uses the standard Textpattern custom properties.

Example / demo on the article list panel: dev.l-c-n.com/txp-4.9/txp-content-list-articles.html

Bloke · 2025-01-31 12:12:36

I’ve tried to implement the button. It sort of worked but only if I used the svg. When I switched to using the .ui-icon .ui-icon-copy instead, it added blue borders and shoved the button down out of view, so I ditched it and have gone back to span for now, with phiw13’s styling and a cursor:pointer;. I’ll commit that soon.

In the meantime, I have determined that the copy does indeed work in Safari on the Articles panel if it’s triggered directly on an element outside the table. That discovery led me down a rabbit hole and then I stumbled across a random StackOverflow comment that may indicate why it’s failing:

If you have a specific use case of copy command not working only in safari, one of the things that you may want to check is if your copy command is being run inside an API callback or in some other similar asynchronous fashion. Also, copying in Safari will only work if it is coming from DOM event

On the Articles panel, the copy is being initiated when the asynchronous (server-side) call to my function that grabs the article URL finishes. The copy on the Write panel doesn’t do that and is wholly client-side code. Presumably then, Firefox (maybe Chrome?) somewhat lackadaisically doesn’t care where the call originated, but Safari is being cautious and forbidding the copy from being triggered if it wasn’t directly from a user action.

I’m really not sure how to proceed here. I’m trying some jiggery pokery like this:

Separate the act of copying from the asynchronous callback.
Make the asynchronous callback add an element to the DOM and start watching it for changes.
When the change occurs (i.e. when the plugin async returns with a URL) write the value to the hidden textarea.
The observer watching the textarea for change or input events fires, selects the textarea and initiates the copy function.

I don’t think this is going to work, for two reasons:

Adding the on change/input observer is still being initiated from an asynchronous callback.
The act of changing the text via the textArea.value = returned_text: doesn’t trigger the observer. Only the act of the user typing something triggers it. I might be able to fudge it by forcing it to be selected and then call blur() to simulate someone tabbing out of the box.

If that fails, what I may do is add a single, permanent, hidden textarea with a well-known (to the plugin) ID, and add an onchange/input listener to it at that point, crucially outside of the asynchronous call. So this event listener is waiting around and then when someone clicks a copy button, the plugin adds the returned text to the static textarea, triggers the blur() (if that indeed works) and the textarea listener wakes up, looks inside itself and does the copy function. Hopefully the browser thinks that is a user-level event.

It’s a lot of faff so if anybody has any better ideas how to get round this, please shout.

phiw13 · 2025-02-01 00:04:31

Bloke wrote #338978:

I’ve tried to implement the button. It sort of worked but only if I used the svg. When I switched to using the .ui-icon .ui-icon-copy instead, it added blue borders and shoved the button down out of view, so I ditched it and have gone back to span for now, with phiw13’s styling and a cursor:pointer;. I’ll commit that soon.

Did you try the markup + styling suggested in this post: forum.textpattern.com/viewtopic.php?pid=338965#p338965?

I’ll check later how to do something with .ui-button. Applying those classes directly to the <button /> might cause issues.

Textpattern CMS

Textpattern CMS support forum

#1 2025-01-25 00:00:27