topbar: edit button supports page editURL param before site one

[maxatome]

The rationale is that sometimes a page could be edited using a different URL than the declared site schema.
With this PR, a page can override the global URL schema giving its own already complete URL.
It also allows not to set the site editURL param, but only set it in a few pages that can be edited.

The docs have to be changed, but I wanted to check whether the idea is worth it or not before doing it.

[McShelby]

I am willing to merge this and provide the necessary docs.

Nevertheless I am interested in hearing more about your use case. In case of the global config, the file path will be (necessarily) automatically appended to the editURL.

Users expectation may be the same for the editURL in the frontmatter. This also would have the advantage of being able to copy the frontmatter setting to other files without editing and als moving the whole .md file around without the need of adjusting the editURL afterwards.

[maxatome]

The site I am handling is automatically generated with files from different foreign repositories and for each of them different tags. In addition only files originated from master (and no from any tag) are editable.
So there is no common edit URL schema + some pages are not editable at all (in my case, I don't even define the site editURL param).
Perhaps this new page param could be renamed from editURL to editFullURL (or something similar) to eliminate the confusion for the user?

[cagix]

I thought the suggestion was interesting. I have built a repo structure that follows the logical structure of my lecture and is intended to be read directly by humans (GitHub preview w/o any "bling bling"). In order to be able to build a nice lecture website from this, I have to convert this structure into the typical Hugo structures in a pre-processing step.

This is why the usual editURL links no longer work for me - these links would point to the temporary structures after preprocessing. One approach would actually be to specify the original URL in the repo in the files or to provide at least a variable per file. I could then fill this dynamically via a Makefile :)

[McShelby]

@cagix @maxatome Thanks to both of your for the input.

In both cases, it makes sense to define the full URI in the frontmatter.

Nevertheless I am thinking about to provide a replacement parameter for the file path, so you could either define a full URL like editURL="https://example.com/my-page.md?edit" or a URL template like this editURL="https://example.com/$(FilePath)?edit".

As there isn't any text replacement yet in the theme or in (as far as I know) in Hugos API, I am open for the syntax of this replacements.

[cagix]

@McShelby That actually sounds pretty neat! Thank you!

In my use case, I wouldn't need any replacements - I would just set a variable in the YAML header of each Markdown file with a custom (externally calculated) URL as part of the pre-processing step. So it would be sufficient for me if I could access a corresponding variable in each document.

[McShelby]

Sooo many to choose from...

As there not seem to be any reference in Hugo or theme context, where this is already implemented, I'll choose the JavaScript syntax.

[cagix]

i'd give no. 4 (javascript) a go, too - that reminds me of the good old Makefile syntax 👌

[maxatome]

@McShelby, as @cagix I don't need the replacement feature, but who can do more, can do less :)
That said, I prefer $variable case as it is simpler/shorter and close to golang template vars.
Thanks!

[McShelby]

@maxatome I don't like the $variable syntax as it makes it unclear where a variable name ends and just text proceeds. This is not an issue in golang as a variable is always delimited by whitespace.