I would like to request a feature, namely the possibility to use a shortcode within the definition of another shortcode.
Is this the right place to talk about this feature?
I would like to request a feature, namely the possibility to use a shortcode within the definition of another shortcode.
Is this the right place to talk about this feature?
You can start by explaining what you mean exactly.
You can call partials from a shortcode. So you could reuse that partial in different shortcodes. However, you cannot call a partial directly from the markdown file, it always then needs to be wrapped by a shortcode.
Was that were your idea was going?
That is no longer quite true. One can call a partial directly from a content file by enabling and using Inline Shortcodes
I defined a shortcode img
that works exactly like the HTML img
-tag ({{< img src='...' >}}
but then resizes the image to multiple sizes and outputs them into a srcset
. I want to reuse this snippet within other shortcodes that make use of images.
To discuss this, you’ll need to provide examples and more details on what you want. We are open to discuss, but so far no one can deduce what you are suggesting.
You are right, I though if it’s about reusing then a proper shortcode is the better approach, as the inline shortcode’s scope is only the content file itself.
I guess a partial will work quite well. Remeber about the dot .
and the possibility to pass variables in a dict
to a partial. Also partials can return a value. The best way is hard to guess without more information
One can always call a reusable partial through Inline Shortcodes in select content files.
On my end at least template partials have always felt way faster when publishing a project than when using plenty of shortcodes in content files.
But now Inline Shortcodes blur the line between the two and they’re interesting because one gets to use a partial in select content files without paying the performance penalty that typically comes with shortcodes.
The use case is the following: I want to create a gallery-shortcode wich takes a directory containing all pictures as a parameter {{< gallery my-pictures >}}
. Within the definition of the shortcode I want to reference the other shortcode ({{< img src='...' >}}
) because that way all pictures in the gallery would get proper srcset
-attributes and responsive images.
I believe in this instance the best scenario would be to copy the code you want from the img
shortcode into your gallery
shortcode.
I know it isn’t DRY, but I think it is easier to manage a shortcode that generates it’s own output. Down the line you’ll save yourself trouble when shortcodes start getting customized and messing with parsing all over the place.
That’s one opinion. It doesn’t really get into the nested shortcode use, but I’ve yet to see a case where it was a good idea.
I was hoping for a DRY-compatible answer – but hopes were shattered.
But maybe there can be new hope: Can we make this a feature-request?
Seems like this might be a major conceptual decision.
It would be good to get clarity/streamlining on the roles of : shortcodes vs. partials vs. templates (internal templates / Go templates ( both the Hugo “layouts” and the {{ template “name” }} … {{ define “name” }} functionality )) vs. blocks .
If we are honest, they are all doing very similar things. Are all still useful? in what instances? are some meant to be interfaces for end users or within a development context? are some a subset of others?
This could also just be a distilling of what is the most “Hugonic” way of doing things.
@HenrySkup: You’re absolutely right – the lines between those blur. For me, shortcodes have always been the only way an author should be able to structure it’s content. That’s why I would want to use shortcodes in shortcodes to create powerful tools for them.
Hi @dktue. If I’m understanding your question, you should be able to extract the code from your img shortcode into a partial, and then call that partial from your img and gallery shortcodes. (As others have mentioned/hinted).
If my understanding is off, then you need to share your code that way we can work with something concrete. Else we’re living in idea-land.