-
-
Notifications
You must be signed in to change notification settings - Fork 7.4k
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
Featured request: Auto-ID helper function #7734
Comments
This has been discussed before -- and the big problem of such function, if you make it something global, is that there is no way to preserve the ordering of things. And getting new IDs every time you run the site is not very friendly. |
I think that can just be documented. "IDs subject to change on each build." Maybe to make people less likely to rely on the ID being the same spit out some hex gibberish, like |
@carlmjohnson said:
Please explain the pain points. Why is your existing solution insufficient? |
I thought I had a working page, but it turned out I was passing the wrong context to a partial, so the counter had reset itself in the loop. |
spotlightpa/poor-richard@de9720c...af7e3fc#diff-36cf9d21926ba6b11981f69cc4da1571 It got covered up by force pushes, but basically this dot needed to be a $ to fix a bug in a loop. It was sort of subtle. |
This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help. |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
I'll reopen this, because I find it better to write about these topics here rather than on the Discourse. So, we already have As you already experienced in https://discourse.gohugo.io/t/cachebuster-death-loop/45068/7 -- there are many reasons why you want this ID to be stable, for one, you would get massive change sets for your site on every build. So, for most practical applications something like this should be OK:
|
I don't see how making a hash of the page RelPermalink would address the problem at all. The issue to be solved is that I have form partials and I want to include that same partial an unknown number of times on one page. How does making up a semi-random ID once per URL address that? |
@carlmjohnson Are the forms included on the page via a shortcode that calls a form partial? |
Sometimes, yes. Also as plain partials. |
When inserted via shortcode, you can use |
Another answer is to use Alpine's magic ID helper, but I'd rather not require JS for this functionality. https://alpinejs.dev/magics/id |
If you don't mind unstable id's, bep's suggestion of |
I'm currently using a partial that adds one to a page.Store counter. It works but is apparently unstable. |
My only other thought for partials (you can use .Ordinal for shortcodes) is... layout/_default/single.html (or whatever)
And change it each time you call it. |
For some things, HTML requires unique-per-page ids. For example, a
<label for="xxx">
and<input id="xxx">
pair. If you have a partial for a form, you need each form on the page to have unique IDs. Right now, I'm solving this with a.Scratch
variable that just sets a counter per page. It works, but it's a little awkward because you have to pass .Page into a shortcode that needs an ID, and if you do it wrong you can accidentally reset the counter.I propose a template helper function called
autoid
that returns a new ID every time you call it. It could take a prefix argument to make the IDs prettier for developers. Could work like this:The text was updated successfully, but these errors were encountered: