Unexpected behavior when an asset linked on a page is an unsupported file type

[johnjkr]

When am internal link points to an asset whose file type is not natively supported or mapped to a specific application, the client machine's file manager/explorer/finder opens, regardless of client OS - I tested against Windows, Mac, iPad, and iOS. This seems unusual to me, as the files are expected to be on the server, not the client, so the client machine should not be trying to find the asset file.

This may be a Windows 11 issue on the machine we are using as the server. That machine does not have suitable default "open with applications" configured for files types - m4a, .mov - which are common to Apple though not native to Windows.

I am going to work around this by converting all those Apple-esque file types to Windows friendlier mp3 and mp4 types. All of my testing to date shows that mp3 and mp4 files work as expected for now by opening a new tab with a player for that file type. I saw for now because I have a separate issue/idea open that discussed support for embedding audio and video players into a Leafwiki page.

The ask there would whether there ways under consideration to define and embed a player for different file types within Leafwiki without relying on the OS? Or at least stop a read-only user from having a file manager dialog open up to find a media file that should be read-only and only on the server.

[perber]

Hi @johnjkr,

could you please provide the markdown you’re using along with a screenshot of the behaviour? From my perspective, this seems a bit unusual.

I think we should dig a bit deeper to resolve the Problem.

One possible cause could be that there is still a local file path (e.g. C:...) in the markdown. That could lead to exactly this kind of issue, where the client machine tries to resolve the file locally instead of loading it from the server.

Another possibility is that the server (or LeafWiki) is not returning the correct MIME type for the asset, which would prevent the browser from handling the file properly.

I would also recommend using HTML5-supported formats where possible, as this is likely the most stable long-term solution. Otherwise, you would need to rely on external players, which can introduce additional dependencies, updates, and potential conflicts.

If this is just a standard link, I wouldn’t restrict it to specific file types, since users may upload and reference a wide range of assets.

LeafWiki now supports HTML5 audio and video playback, but currently only via explicit HTML, for example:

<audio controls src="/assets/-fEG_jANR/file-example-mp3-1mg.mp3"></audio>
<video controls preload="metadata" src="/assets/-fEG_jANR/file-example-mp4-480-1-5mg.mp4"></video>

Embedding via markdown like this is not supported at the moment:

![Embedded Vid](/assets/-fEG_jANR/file-example-mp3-1mg.mp3)

Thanks for raising this — it’s really helpful feedback for improving LeafWiki.

[johnjkr]

So I had converted all the media files to either mp3 or mp4 before I backed up everything to update to the new release. So I don't have the .md files with the internal links to the m4a and mov files. I can tell you that once I converted the files, I updated the links simply by changing the file extension. Something like [2022-10-01 - New VP message](/assets/QUc48J5Dg/2022-10-01-new--vp-message.m4a)

After converting the files to mp3 / mp4, when the link is clicked a new tab opens with a player and the audio/video auto-plays, which is the behavior we expected.

We will focus on using HTML5 supported formats, especially mp3 and mp4, converting as needed.

We tried out the HTML5 code for embedding a player - works great!!

Feel free to close this unless you want to consider supporting m4a, mov and other file formats.

[perber]

Great to hear that your data import was successful!

Supporting mp3 and mp4 formats should cover the main use cases well, so I agree that this is a solid approach for now.

There is still one feature pending - properties and tags - which is planned for a future release of Leafwiki.
The good news is that the frontmatter is already being preserved, so the foundation is in place.

Before starting work on properties, there are a few higher-priority items to address:

• versioning
• conflict handling
• localization preparation

Once those are implemented and released, the focus can shift to supporting frontmatter-based properties and tags.

Thanks again for the update!

[perber]

@johnjkr - How is it going?

Any issue so far?
I thought I share a little time frame, so you know when I will start to implement the frontmatter things. My plan is to start with the implementation in May and hopefully a first version shouldn't take much time.

[johnjkr]

No issues when the files are mp3 and mp4 formats. Thank you for the updates. Look forward to trying out the changes.