Consider making GetMatch etc. smarter for bundled resources

[bep]

See #4582

Which made this work:

{{ .Page.Parent.GetMatch "myimage*" }}

However, it would be nice if we could just do this in both cases:

{{ .Page.GetMatch "myimage*" }}

The bundled page does not have resources on its own and if it ever will, we can just expand the definition of GetMatch.

/cc @onedrawingperday

[bep]

/cc @kaushalmodi @regisphilibert and gang

[kaushalmodi]

I think {{ .Page.Parent.GetMatch "myimage*" }} is a better syntax. That allows people to understand that resources of page kind cannot have their own resources. Also the .Parent is useful for fetching other Parent page properties too (in case that's ever needed).

So instead of having 2 ways of doing the same thing, the .Page.Parent. .. method seems more versatile, and correct.

[bep]

I think {{ .Page.Parent.GetMatch "myimage*" }} is a better syntax.

It is obviously there to stay.

But from a shortcode, there is currently no simple way to say "give me the resources in this bundle". I cannot always look in .Parent, so what do I do?

[regisphilibert]

I tend to agree with @kaushalmodi here. By leaving the resources method on the .Parent, which is intuitively identified as the Page Bundle (mother of all resources), it avoids a complexification of the doc.

Those two informations are not intuitive and will have to be detailed in the doc.

• Every page resources inherit the bundle resource methods (.Match, .GetMatch).
• The .GetMatch path passed as attributes must be relative to the bundle rather than the page itself (which can be nested inside bundle structure).

The current state is very intuitive and doesn't need any explanation. Proof is that someone readily brought up #4582

[regisphilibert]

But from a shortcode, there is currently no simple way to say "give me the resources in this bundle". I cannot always look in .Parent, so what do I do?

You mean $.Page.Parent.GetMatch would/does not work from a shortcode ?

[bep]

You mean $.Page.Parent.GetMatch would not work from a shortcode ?

It works fine, but the shortcode then needs to know where to look. And that is currently impossible. From index.md it should not look in .Parent (it would potentially get some totally different images).

[regisphilibert]

Yes I get it now.

Even if we were to add a special test function for that we shouldn't have to add the following for every shortcode needing resources.

{{ if .HasParent }}
{{ $.Page.Parent.GetMatch }}
{{ else }}
{{ $.Page.GetMatch }}

So yes I agree this is needed, thanks for clarifying.

[kaushalmodi]

And that is currently impossible. From index.md it should not look in .Parent (it would potentially get some totally different images).

Makes sense. Then we need to make sure that the documentation of .GetMatch and everything that gets affected with this change is updated.

[regisphilibert]

I wanted to write my comment in #4582 but as it has been closed.

But if I understand correctly to get a parent section we now need to use (from a page resource) .Parent.Parent.Title ?

We will also have to update Page Variable's .Parent definition:

A section’s parent section or a page’s section.

I'd rather we introduced a new dedicated Page Variable called something like .Bundle but it is too late as I understand.

[bep]

Sorry but I juste realised what .Parent is.

What .Parent was. It is the page's parent page, but up until now that has been either 1) a section or 2) the home page.

[regisphilibert]

I see, as long as a given page is included in another's page .Data.Pages collection, such parent page is referred to, in the page context, as .Parent.

For a page resource though, the logic is a bit different, as .Parent refers to its Page Bundle's index.md.

I think it is a bit confusing that a page resource follows the same "family line" as conventional pages. But I cannot come up with any problematic scenario.

So I'll concede it's just a matter of updating the doc :)

[bep]

I think it is a bit confusing that a page resource follows the same "family line"

Maybe, but I think it would be even more confusing if we invented .SomeOtherParent concept.

[github-actions]

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.