-
-
Notifications
You must be signed in to change notification settings - Fork 7.5k
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
Add Page.Markup with scope support #12759
Conversation
64550ae
to
2a97e48
Compare
Looking at the above, I like most things about it; we greatly reduce the amount of methods on the giga But I don't like the main name ... {{ .Contents.Render }} The above does not read well, and I think {{ .Markup.Render }} Or ... {{ with .Markup }}
{{ .Render }}
{{ end }} Which is what we do, we render the markup (Markdown, HTML, Pandoc ...) to one or more output formats. Also, if we could somehow get the /cc @jmooring |
3d65276
to
412e1e3
Compare
6005ca2
to
92178b4
Compare
I've tested this a bit. It works as expected except for I did not play with the scope as described above because:
Both of these are documentation issues. And while I appreciate grouping related items, I believe most users would prefer to do this:
Instead of this:
I also think the former is easier to understand. So your intention to leave existing methods as-is makes sense to me. |
7b9a8b5
to
cbf0dfc
Compare
@jmooring I have now pushed a version that passes all tests, including
So,
There are others and better examples, I'm sure, but those are recent ones. So, when doing something like this in the home page template: {{ range site.RegularPages | first 20 }}
{{ with .Markup "home" }}
{{ .Render.Content }}
{{ end }}
{{ end }} The home page will get a fresh render of all of those 20 pages ( There's a performance cost to the above, of course, so it should be ... used with care. |
12f294d
to
462f9e0
Compare
I will keep these top level Page content methods for now, but at some point it may be a question about the cost of maintaining these in relation to what "users prefer". The motivation behind this grouping isn't primarily cosmetic. |
f4d12ba
to
b030963
Compare
Note that this also adds a new `.ContentWithoutSummary` method, and to do that we had to unify the different summary types: Both `auto` and `manual` now returns HTML. Before this commit, `auto` would return plain text. This could be considered to be a slightly breaking change, but for the better: Now you can treat the `.Summary` the same without thinking about where it comes from, and if you want plain text, pipe it into `{{ .Summary | plainify }}`. Fixes gohugoio#8680 Fixes gohugoio#12761 Fixes gohugoio#12778 Fixes gohugoio#716
b030963
to
fe6c323
Compare
Edit in 2024-08-16. I have revised my take on this after talking to @jmooring and thinking a little. The (original) primary motivation behind this PR (for me, anyway) was to make it possible to render different versions of a given page's content on, say, the home page. But we also want to make room for further improvements in this area without blowing the scope of this PR out of proportions. I have always wanted to create a map of the rendered content, but that would only be practical for Goldmark (and hard even there, I guess). I think that and similar extensions should be fairly simple to fit in the below.
ContentWithoutSummary
, which I know many have asked forFuzzyWordCount
has been around for a decade and has become a brand by now.Type
discriminator that is either "auto" or "manual" or "frontmatter"Page
, e.g..Content
,.WordCount
etc.With this you can do:
You can also give it its own scope:
Fixes #8680