Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

topbar: edit button supports page editURL param before site one #762

Merged
merged 1 commit into from
Jan 27, 2024

Conversation

maxatome
Copy link

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.

Signed-off-by: Maxime Soulé <btik-git@scoubidou.com>
@McShelby
Copy link
Owner

McShelby commented Jan 23, 2024

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.

@McShelby McShelby added feature New feature or request needsfeedback Further information is needed labels Jan 23, 2024
@maxatome
Copy link
Author

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
Copy link

cagix commented Jan 24, 2024

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
Copy link
Owner

McShelby commented Jan 24, 2024

@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
Copy link

cagix commented Jan 24, 2024

@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
Copy link
Owner

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.

grafik

@cagix
Copy link

cagix commented Jan 24, 2024

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

@maxatome
Copy link
Author

@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
Copy link
Owner

@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.

@McShelby McShelby merged commit 7954509 into McShelby:main Jan 27, 2024
1 check passed
@McShelby McShelby self-assigned this Jan 27, 2024
@McShelby McShelby added this to the 5.24.0 milestone Jan 27, 2024
@maxatome maxatome deleted the edit-url branch January 27, 2024 14:37
@McShelby McShelby removed the needsfeedback Further information is needed label Feb 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants