-
-
Notifications
You must be signed in to change notification settings - Fork 10.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
{{#foreach}}{{else}} fails inside {{#get}} statements with no results #7242
Comments
Hey @hbaughman. Sorry to hear you're having trouble.
@ErisDS |
This is interesting, and one of the reasons why we still consider the The So, in the case where you have wrapped it with the get helper, the I can see that this is potentially confusing, and this behaviour is definitely up for debate. I'm not sure if it is any clearer to not have an else template for the get helper though and it would certainly be weird if we only execute the get helpers else template if there is an error as then you would have the same problem in the case of an error. Perhaps the best thing here is to update the |
@kirrg001, @ErisDS Thanks so much, that solves it!
Once you'd explained how To be clear, this is not my current usecase, but I can easily imagine a partial that sometimes gets used within a {{! partials/some_partial }}
{{#foreach posts}}
{{title}}
{{else}}
no posts
{{/foreach}} If you call that from here you'd get the titles or "no posts" as appropriate. {{! index.hbs }}
{{> some_partial}} If for some reason you later chose to invoke it from within a {{! page.hbs }}
{{#get something}}
{{> some_partial}}
{{else}}
no posts
{{/get}} Conceptually, I feel like the partial should function identically in the two different scenarios. For this reason, I think I prefer removing {{#get id="1234"}}
{{#post}}
{{title}}
{{else}}
no post found
{{/post}}
{{/get}}
A quick googling didn't discover an RFC for the |
Reopened this because, at the bare minimum the docs do need updating. I'm also starting to think that the behaviour should be changed. Mulling it over for the pros and cons 😁 |
closes TryGhost#7242 - before this, the get helper's else was used for empty resultsets - the argument was made that we should fall through to a foreach or with helper's else instead - I agree that this is the more natural, consistent approach, and so would like to change it for Ghost 1.0 E.g. as of this PR we now have: {{#get "posts" filter="tag:doesnt-exist"}} {{#foreach posts}} {{else}} this ges executed because there are no results {{/foreach}} {{/get}} instead of {{#get "posts" filter="tag:doesnt-exist"}} {{#foreach posts}} {{else}} {{/foreach}} {{each}} this ges executed because there are no results {{/get}}
closes #7242 - before this, the get helper's else was used for empty resultsets - the argument was made that we should fall through to a foreach or with helper's else instead - I agree that this is the more natural, consistent approach, and so would like to change it for Ghost 1.0 E.g. as of this PR we now have: {{#get "posts" filter="tag:doesnt-exist"}} {{#foreach posts}} {{else}} this ges executed because there are no results {{/foreach}} {{/get}} instead of {{#get "posts" filter="tag:doesnt-exist"}} {{#foreach posts}} {{else}} {{/foreach}} {{each}} this ges executed because there are no results {{/get}}
I'm working on a Ghost Theme and am having trouble getting the
foreach
helper to respect theelse
condition (or negation) in conjunction with#get
.Steps to Reproduce
Expected Result: "fails to show up" appears 4 times (once for each reference).
Observed Result: "fails to show up" never appears
Notes
#get
works as expected when the tag does exist. In the above code block, you'd seefoo
appear twice per post found.{{#foreach}}...{{else}}...{{/foreach}}
works as per the documentation when used outside a#get
helper. I had no difficulty reproducing their example:Technical details:
The text was updated successfully, but these errors were encountered: