I’ve been trying to put together my website with hugo.
I made a small “news-feed”, when you press “Read more”, it opens a “modal” with the content, set via javascript using innerHTML.
The title and subtitle are straightforward put inside a h-tag or p-tag.
However, the content should support markdown-syntax.
I tried different things:
From setting "{{ "+content+" | markdownify }}" via innerHTML, to searching for classes or shorcuts, which content inside. I haven’t found anything by myself.
The general code can be found on codeberg:
The javascript function can be found here:
The news shortcode here:
If the approach I’ve chosen is not possible, is there any other way to achieve my goal?
Hm, that’s not what I’m trying to avoid.
It’s more like, I want to inject HTML using innerHTML.
In most cases it’s not that big of a deal, but when having a variable data which has markdown as value, while then putting it via innerHTML and markdownify it would still render markdown to html.
e.g.
In JS it would look like this:
let data = "# Test"
let box = document.getElementyById("box")
box.innerHTML = "{{ "+ data +" | markdownify }}"
In html, it would look like so:
<div id="box">{{ "# Test" | markdownify }}</div>
Which ends up converting the markdown using a hugo-function to html.
Though it is confusing, perhaps I just don’t understand what you want…
markdownify is available at build time, in Hugo. Never in the browser.
innerHTML is available at run time, in the browser. Never in Hugo.
You can’t use both at run time nor at build time. Have cake, don’t eat it. Or the other way round.
And you should not use an onclick attribute in your HTML. Not in 2023. HTML should be about content, JavaScript about behavior/interaction and CSS about presentation. Separation of concerns, clear design, all that.
I see, so it seems that I had an error of thinking, when trying to achieve this.
So perhaps, it would actually be better, what @nternetinspired kind of suggested.
Converting Markdown to HTML directly via JS using an external library.
Well, when thinking about the UX, you’re right.
But I guess that means, for each “news-entry” I’d have to make a separate .md file with the content.
Which in my eyes is a horrible UX for the Social Media Manager, not having like a GUI to write their posts. Instead, needing a text-editor and git pushing the news to the git-repo
WHY? Forgive my shouting, but why don’t you convert your MD once at build-time instead of burdening the browser everytime at run-time? You can have your HTML generated by Hugo and incide it with an iframe (even at run-time). Or have it all in the page and turn in on/off with CSS classes… there are a lot of possibilities, but converting the same MD over and over again at run-time is a Bad Idea™.
But I guess that means, for each “news-entry” I’d have to make a separate .md file with the content.
Yes, this is how Hugo works.
…not having like a GUI to write their posts. Instead, needing a text-editor and git pushing the news to the git-repo
There is nothing to stop you putting a front-end on it and using a CMS to store content in .md files. In fact, I’d say it’s preferable in such a case, as you can strictly limit the type of content they can add/edit/delete.
Well my original plan was using strapi in the background as headless-cms, but this cms serves the data as json afaik. That’s why I have been struggling with this problem.
But since it seems not possible, I have to look out for a cms (or headless-cms) which saves data (or blog-posts) as .md