loosen page name validation to allow page names to end in dates

[stapelberg]

The validatePageName function prevents me from ending my page names with a date.

For example, I placed a file called “notes 14.11.2024.md” in my space.

I can link this page no problem:

But actually opening the page results in a 404:

Using cmd+k, I can see the page, but opening it by pressing Enter results in an error toast:

It would be good to make the name validation more consistent, but more importantly, I would suggest to loosen or entirely remove name validation.

I can’t find an explanation of what the validation is good for. What’s wrong with using page names that end in file extensions?

And even if validation must be kept for some reason, I think the special case of using a date as part of a page name should be considered reasonable enough to be added as a special case.

[mjf]

I also have no idea why is there such a restriction, because I would assume that if a page is named, e.g., /foo.txt that would mean SB would search for /foo.txt.md for that page. I can guess that's because SB does not restrict supported file extensions to some limited set. If so, there is no easy solution for this. Is that true, Zef? @zefhemel

Well, I dug into this because I also ran into exactly the same issue. I propose to limit what's an extension by replacing this regex with this one /\.[a-zA-Z][a-zA-Z0-9]*$/ for now. That consider an file extension to be everything but purely numeric chains (the change will probably break things for those who do use such file extensions). I can not remember of much file extensions consisting of digits only (well, manual pages, right, and perhaps rotated logs). Do you have some ideas on how to allow for literaly any page name? That will for sure be great improvement! @zefhemel Thanks.

---

Edit: We should utilize mime types for this. I do not really see any other way to workarround. Let SB assume that everything is Markdown except file extensions enumerated in the configuration (with some sensible defaults perhaps hardcoded or registered by plugs). Example:

mime:
  application/postscript:
    - ps
    - eps
  application/pdf:
    - pdf

We could then even consider some "mailcap"-like support in SB for the recognized mime types, so that one could specify what to do when such file is referenced, such as that referenced PDF file (![Example](example.pdf) or ![[example.pdf|Example]] etc.) should be embedded in the position (just for example) and if linked to only (without the leading exclamation mark) then SB will send the file to the client with the configured mime type so that the client (browser) will handle it or allow to choose what to do with it (most browsers behave like that, AFAIK). It also means that pages could be named without file extension on disk (which I will prefare personally, there is simply no need for file extensions if you can manage them). Example:

mailcap:
  application/pdf: embed

Like this etc.

See the embedded example below.

![Example](example.pdf)

Open the [[Example.pdf|example]] in the browser as PDF.

What do you think? Isn't it be a general solution to the issue? @zefhemel @stapelberg ?

[stapelberg]

To serve files with the correct MIME type, Go implements content-type sniffing, see https://pkg.go.dev/net/http#DetectContentType (click on the function name to see the implementation — the longest part are the various file signatures) — maybe such an approach would be available to silverbullet, too, making any sort of configuration unnecessary?

I don’t really understand what MIME types have to do with the restriction on page names, though? Can you explain the connection please?

[mjf]

I would like to raise some more attention to this issue, please. I started to document some large project in SB and I cannot have pages with hostnames and IPv4 addresses as names. I do not see any sensible workarround so I would like to beg for this issue to be resolved somehow (to at least allow the dots). Thank you.

My personal (strong) opinion on this is that there should be simply no restrictions at all. The resolution of this issue should at least allow name.like.this.one.md (resulting in file name.like.this.one.md.md of course). Would that be possible? What if somebody wanna name a page like ❤️ <a> || <b>? Try in any modern OS: touch '❤️ <a> || <b>.md' and ls. See? It simply works! Just let the underlaying OS and filesystem to decide.

[mjf]

I've found this line of code is the issue. Would changing the

/\.[a-zA-Z0-9]+$/.test(name)

to

/\.md$/.test(name)

as a quick and dirty fix do any harm? @zefhemel The chance that somebody would like to name a page with trailing .md is fairly low (my best guess).

I have also no idea why there is the leading dot restriction. Such page will just appear as "hidden" on unices. That's no harm at all. Or would it make any harm to anything if this rule was relaxed too? @zefhemel 😀

I would really like to know why there are so many restrictive rules in naming things everywhere. What is the exact reasoning behind these restrictions? @zefhemel

[mjf]

Thinking about it more further, to allow URL-specific characters such as ? or # in page names needs some urlEncode() and urlDecode() functions to "proxy" real filesystem names (unencoded) and the actual URL (encoded) back and forth.