Placeholders inside URLs in templates

I’m trying to generate URLs that contain the \event-date placeholder so that I can easily link to where the minutes of a meeting will be stored and to a wordclock link for the event like so:\event-date(start: yyyyMMddTHH)&ah=1

Unfortunately, the placeholder doesn’t seem to get processed when it’s within a URL. Am I missing something or is this not supported?


Are you trying to embed the timeanddate URL into the agenda link in some way? I could imagine you may be best to use shortcuts or a script to first get the date using that link, and take the result, and embed that into the Agenda link.

To clarify, I’m just trying to generate the URL, not get data from it.

So essentially what I would like is for the following text to be generated:

[See meeting time in your timezone](

Which renders as: See meeting time in your timezone.

But what I get instead is:

[See meeting time in your timezone](

Which renders as: See meeting time in your timezone

Ah, so this is an problem with the web site, not Agenda directly. Is that right?

Perhaps you need more escaping of the arguments or something. Eg.

\event-date(start…) may need to be %5Cevent-date%28start%3A+yyyyMMddTHH%29

ie with percent encoding throughout the argument.

(Here is a good tool for doing that:

Ah, so this is an problem with the web site, not Agenda directly. Is that right?

No, it’s very much an issue on the Agenda side. Text Actions that appear in the URL portion of a link aren’t ever converted.

That’s indeed correct, in most cases we wouldn’t want to accidentally change links into something that no longer works. The example you give might as well be a valid link the user doesn’t want us to touch. We feel it’s safer not to touch those. Not sure if it makes a difference but have you tried inserting the link like this?

[Worldclock](\event-date(start: yyyyMMddTHH)&ah=1)

Worth trying as I don’t know the order of parsing from the top of my head. But it could be that it too ends up with the same result, in case there’s no good workaround as it stands I’m afraid.


Sorry for the belated follow up.

Yes, I tried the markdown option, but that didn’t work either.

You actually wouldn’t be damaging any URLs in existing notes, only in newly created notes, as the parsing happens at note creation time, not every time the note is displayed.

As such it doesn’t strike me as a huge issue, especially given that URLs that would unwantignly trigger an action are probably extremely rare (the whole sequence is really uncommon in URLs).

OTOH, being able to generate dedicated URLs like this is really useful for a lot of things.

Either way, thanks for your time!

Apologies for the confusion, what I meant is that we wouldn’t want to accidentally recognise placeholders in links that were legitimate parts of a link that shouldn’t be replaced (although I appreciate that would probably be a non-issue). At the moment, it’s not an “easy” fix though as it also has to do with the order in which we parse the content, and changing that might have other unwanted side effects.

At the moment, it’s not an “easy” fix though

Yeah, I would never claim something is an easy fix on someone else’s codebase. :slight_smile:

I do have opinions about content parsing on top of markdown, though, as I’ve been involved in similar projects used at W3C and WHATWG to edit standards. Web standards are edited using markdown and additional syntax to allow for defining terms, automatically cross-referencing terms of other specs, including in code blocks, EBNF grammar, etc.), so the problem space is fairly similar.

Feel free to ping me if you’re interested in discussing this further; I’d be happy to learn more about your constraints and discuss the tradeoffs between the architecture you’ve chosen and other available options.