I would say organise so that markdownify is an alias for RenderString. This markdownify is so much used in every single theme that deprecating it will lead to chaos. I would expect for instance support requests for the next years with recently removed functions that were deprecated for the past 2 to 4 years.
I am not saying that we should keep two identical functions, but killing them will lead to more chaos than aliasing them. maybe add a note in the CLI output that markdownify has to be changed into RenderString, but completely removing it even in 2 years time will lead to an increase in issues about this.
Also (didn’t completely check) I have the feeling that it’s markdownify and .RenderString. Is there anything of consequence in the way those functions are used or can they just be exchanged? The dot sounds like a context issue in the making (so an “exchange with RenderString” might not really help in the CLI).
My opinion. Deprecation yes. But very, very, very slowly. With maybe eternal fallback.
I use markdownify in a partial and an image render hook). I need markdownify in the partial to render markdown links in some entries in a JSON file. If it is to be deprecated, what is the alternative?
It depends on the scope/context. In most cases I use pipes like {{ .Whatever | $.Page.RenderString }} in partials and shortcodes. But I’m not an expert. Just happy if it runs then
If you’re in a page scope/context {{ .Whatever | .RenderString }} should work also
I will have to find it in my code, but there are currently some cases where you cannot use .Page.RenderString where you can use markdownify. It’s rare, but has come up for me. .Page.RenderString has some additional expectations (intentional or otherwise) than markdownify.
And yes, the context is correct in those cases
However I didn’t try site.Home.RenderString and my builds haven’t broken with 0.93+ so perhaps there is something about the page’s context that was problematic. Will dig further.
I kind of agree, but I think we need to do a “soft deprecation” (remove it from the docs and mark it deprecated int the code), because it’s pretty widely used …
Also, markdownify's big upside is that you can use it without any Page reference, so I think we also need to wait for my planned page global function.
{{- with .Params.gearlist }}
{{- range $index, $kit := . }}
<p>{{ . | markdownify }}{{- if lt (add $index 1) $len }}<em> and</em> {{- end }}</p>
{{- end }}
{{- end }}
I guessed {{ . | markdownify }} would work first try, I couldn’t get the RenderString version after many tries after reading the .RenderString docs.
{{ . | site.Home.RenderString }} works but makes no sense I am parsing a bit of front matter, no relation to site, no relation to home? It also wasn’t documented for RenderString. I happily absorb as much as I can reading the docs but having to have knowledge of the source code is asking a bit much.
I’d personally leave in markdownify (or markdownparsify or whatever is a better alias).