Need affordance to url-encode a post's permalink.

[popham]

I'm integrating a couple of social apis into Ghost, but I see no affordance to url-encode a post's permalink. Am I overlooking the existing functionality? If not, I like the prospect of an additional parameter to the url helper along the lines of encoding="url". But have I correctly intuited from #1089 that encoded and url-encoded are synonymous in themer-space? Would a url-parallel helper called encodedUrl find a home in core?

[popham]

I think that encode would need generalizing to handle promises and the post model would need extending to expose permalink computation (/:slug/ is just a default route). Further, I need an absolute url, so any extension would closely parallel the url helper's interface (if accommodating my needs is high-priority). Piping the output of the url helper to encode works, but Handlebars provides no way to compose two helpers (I've seen a couple inelegant workarounds that would expose yuck-machinery to themer-space).

I added to core to achieve the composition. My gut says that this functionality will find heavy use in apps.

[ErisDS]

encode is the tool we have for encoding things, so if anything is going to do it, it should be this.

How that could work, is another question, as you say it is not possible to compose to helpers together.

However, encode takes 'a thing' and encodes it, what that thing looks like could be a lot of things.

One idea would be to use

{{encode helper="url" absolute="true"}}

If encode gets a helper passed to it, it executes the helper with other given arguments first, and encodes the resulting string. Otherwise, it does as it does now, and encodes the context it is given.

This is just an idea mind, I'm not saying this is the right solution. Just trying to come up with some ideas to push the discussion forward as I agree that this is necessary.

[popham]

Preface: Latest version of Handlebars has subexpressions functionality. Done with {{encode (url absolute="true")}}.

I don't have a strong opinion here. I've been coding under Python 3 lately, so I'll probably be biased toward an analogue. Based on your comment, the current encode is just a stub? I'll look at extending it to cover more than the text -> text use case. I was pondering on composing many helpers into a pipeline, but handling the parametrizing arguments makes that a nonstarter--it should just encode the output of a single helper, and any extra compositions should be handled by apps or extension/modification of core. Also, it needs to go asynchronous if it's to handle any old helper.

I must say I find the term "helper" too vague, but any alternatives that come to mind are way to mathy. I'll mention and reject the obvious candidate: "filter." It's fitness doesn't justify overloading the term.

Alternatively, I'm new to Handlebars. I expect to use something like {{#with image}}{{encode}}{/with} soon. I know that we're trying to support (or poach) themers from the Wordpress community, but are PHP idioms intruding here? Where are the block handlers? Maybe:

{{#with newContext}}
  {{#apply helper="url" absolute="true"}}
    {{encode}}
{{/apply}}{{/with}}

The lurking limitation here, though, is the single context getting filtered. Subexpressions can build a DAG of filters all pouring into a final result, while the blocks above are linear (maybe not, but messy nonetheless).

I prefer the {{encode helper="url" absolute="true"}} spec as a stopgap awaiting subexpressions.

[popham]

Express-HBS just moved to the most recent Handlebars (support for subexpressions). Anybody have a handle on changes between v0.5 and v0.6? I'm going to drop the maintainer a line and upgrade locally, but I'm not running a production site. Anybody else interested in seeing subexpressions?

[ErisDS]

@popham if you can find / create some documentation for what has changed in handlebars that would be awesome. We should be updating to the latest very soon: #2017

[ErisDS]

This would be working if it wasn't for TryGhost/express-hbs#56

[ErisDS]

Closing against #4362 which explains the existing issues with the {{encode}} helper in depth.