Markdown render hook for video

feature
1

We use render hooks for images (_markup\render-image.html) to modify the path of the image so that it is compatible with the editor we use (Typora). The goal is that the path is correct, both in edit mode within Typora and of course later on the published page.
Typora is set up to copy images to ./media when an image is pasted in edit mode. On the published page, the image path must be altered depending on the page being a .IsNode or not.
We also add a no-scale class to the rendered image if #ns was added to src in edit mode.

Here’s the code sample

{{ $pathPrefix := "../" }}
{{ if .Page.IsNode }}
	{{ $pathPrefix = "" }}
{{ end }}

{{ $ts := split .Destination "#" }}
{{ $tDestination := index $ts 0 }}
{{ $class := index $ts 1 }}
{{ if eq $class "ns" }}
	{{ $class = "no-scale" }}
{{ end }}

<img src="{{ .Page.Permalink }}{{ $pathPrefix }}{{ $tDestination | safeURL}}" {{ with .Text}} alt="{{ . }}"{{ end }} {{ with $class}} class="{{ . }}"{{ end }} />

This works great for images.

We’d love to have the same for videos. There is currently no need for adding additional classes. But src is broken and must be altered on the published page.

Is there currently a way of doing that? There is no render hook (Markdown render hooks | Hugo) for video. Can this be added in the future?

I wanted to discuss here before adding a proposal in GitHub.

2

(In the meantime, See this issue).

3

@Arif THX for pointing me to that. I changed the code of my render hook. Works :+1:

4

Given that markdown does not have its own syntax for embedding videos, a markdown render hook for videos is nonsensical.

5

@jmooring THX. You are absolutely right. I did not see this correlation.

Do you have an idea how I could fix the src for production in the published page. When our editors work with Typora, they just paste the videos into the current article. We’ve configured Typora to put all media (images, videos) into ./media folder of the current “file branch”. That’s really convenient because the editors actually see the full content in edit mode.
Because of our file structure the src must be “fixed” in publish mode. I cannot fully remember why we chose this structure. There was a caveat back then when we decided to do so. Changing the structure now is not an option.

File structure
my-site/
├── media/
│ └── img-01.png
│ └── vid-01.mp4
│ └── img-02.png

└── 01-article.md
└── 02-article.md

published:
my-site/
├── media/
│ └── img-01.png
│ └── vid-01.mp4
│ └── img-02.png

└── 01-article
│ └── index.html

└── 02-article
│ └── index.html

6

That’s unfortunate. My view is that every asset related to content should be a page resource, a global resource, or a remote resource. You can build anything on top that foundation.

1 Like
7

@jmooring THX. I’m afraid I don’t understand. Could you go into more detail?

8

Start here:
https://gohugo.io/content-management/page-resources/

9

Once again: thanks. Think I got your point.

We have designed the structure primarily with the editor / content creator in mind. We believe if its easy for them (non technical users) to add content, we do us all a favor.

The site being created is a knowledge base. We have different sections, for different products, with sub-sections for functions of the product.

Media is located in the ./media folder of a sub-section which contains n articles. Images (the same image) from the ./media folder may be used in multiple of the articles.

The editor knows where all images for the sub-section are located and can choose from there. If something is missing, he just pastes the image (mainly screenshots) in Typora Editor where he wants the image to be and it will automatically be added to ./media by Typora. That makes editing really easy.

Even though the structure may not be ideal from a technical perspective, it is ideal for the editor / content creator. The left side navigation menu in Typora reflects the structure of the website. It’s super easy to locate content and corresponding media. The downside is, that we have to fix src for images and videos for rendering / publishing. I believe the trade off is ok.

Changing the structure now is not an option.

That is, because we have a big knowledge base today and a trusted and established “system” for our editors. If we were to start again, we could rethink the structure. But today, it is not an option. I am sure there is a solution to “fix” the video src - maybe not ideal - but there is one.

On pasting a video in Typora, this is the code Typora adds:

<video src="media/2310-Bug.mp4"></video>

How could I “hook” into that? If you have a starting point, I am very thankful if you could share.

10

Use a regex replacement when rendering .Content, but… yuck.

1 Like
11

So,

Markdown has syntax for (hyper)links and image links, both of which Hugo has render hook support for.

Markdown has nothing special for videos, so what I would probably do is to use the image link syntax for both videos and images, and then in the render hook determine what to do (either by extension or by passing down some Mardkdown attributes).

1 Like
12

But if “editor experience” is driving the architecture, they will lose the preview. If that’s acceptable, then great.

13

Thanks for your replies so far.

@bep I’ve thought of and tried that. But @jmooring nailed it: the preview is lost. It’s sub optimal, but may be a solution. As I started this thread, I was not seeing the correlation between hooks and Markdown syntax.

Give me some time to think and try some things out, like regex (even though it’s “…yuck” :-)). I’ll get back and report.

14

Yea, wel, any Markdown editor that want to support videos should be able to preview Markdown images with a video MIME type.

1 Like