Deprecate markdownify?


  1. You can accomplish the same thing with the RenderString method

  2. As of v0.93.0 the markdownify function calls site.Home.RenderString. It adds no value by itself.

  3. RenderString provides greater functionality, specifically an option to determine if the result should be a block or inline.

  4. The markdownify function does not markdown-ify. It never has.

    • plainify returns… plain
    • jsonify returns… json
    • markdownify returns… html

Maybe it should have been called html-ify or markup-ify.


Trigger happy? Hehe.

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.





Agree with this. I think we need to wait until page template function merged.

Then we can warn User:

markdownify is deprecated, please use page.RenderString

User can safely replace markdownify with page.RenderString


We think alike.


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?

1 Like

See first post in this thread, please.

I did. But .RenderString throws an error. RenderString is not a method but has arguments.

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 :wink:

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 :stuck_out_tongue:

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.


We have always had plans for multiple outputs from Goldmark, so the above would certainly be a bad move.

1 Like

As to the main question,

  • 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.

This might be related to the error I get when using .RenderString in my image render hook.

Scratch that. $.Page.RenderString works! No need for markdownify now on my end.

Do you have an issue I can subscribe to follow progress? I saw Hugo updates are frequent and I might miss it. :grin:

There is an issue, but you might as well search for it – to save me to work of doing the same.


See post #4 above; by @pamubay