I am trying to use handlebars to accomplish a simple task that I prefer not to do with javascript. In short, if on a specific url, then do this. I have an urge to do something like this but the syntax is obviously wrong. If anyone can give me a crash course, I would appreciate it.
{{#if page.url=“/about/”}}
html code
{{/if}}
Note: the reason why I prefer to use handlebars is because javascript is slowing down the site.
This is definitely doable with handlebars, but a few things to consider:
page.url is an absolute URL – so this approach could work, if this is for a Ghost site that you know the static URL for (so not for a theme you’d use on multiple different sites, for example).
Instead of the #if helper, we need to use the #match helper. #if tests very simple conditions, whereas #match can do proper comparisons. Here’s more on the helper.
So, combining these two bits, we’ll end up with this code (replace http://localhost:2368 with your domain):
{{#match page.url "=" "http://localhost:2368/about/"}}
html code
{{/match}}
An alternative, and in my opinion more flexible approach, would be the following:
{{#post}}
{{#has slug="about"}}
html code
{{/has}}
{{/post}}
We need the {{#post}}...{{/post}} snippet to check whether we are in a post context. A post context also stretches to pages, so all we’d need to make sure is that the URL we want to check is either a post or a page (if you expect it to be a tag or author page, you’d need to change the context accordingly).
Then, once we’re sure that we’re in the right context, we use the #has helper to check if the slug of the page is “about”. Yeah, yet another helper – but pretty useful in this case. Here’s more on it.
Personally, I’d prefer the second approach to solve this, as it is versatile and doesn’t rely on the absolute URL 
Hope this helps!
Awesome! Thanks! I got as far as figuring out that {{#match url “=” “/about/”}} code {{/match}} is what I want, but it would not work for me. I tested {{url}}, and it outputs /about/, so I was confused.
Will there be speed improvements anytime I opt for handlebars over javascript? If so, is this because the server is quicker at generating the static pages than it would be if there was some render blocking code present, such as javascript? EDIT: Also, would combing inline javascript with handlebars be quicker than a defer script attached? In which scenarios would combining the two be preferable?
I’m essentially trying to highlight a button after a page load, but javascript gives it like a two second delay. Seems so trivial, but, hey, the aesthetic of the button and the speed at which it loads is important.
Yes, absolutely!
When you use handlebars, Ghost serves them from the server rather than the client, which means that the button should be rendered immediately, as the user opens the page.
For your specific use case, using handlebars should indeed remove the delay you are experiencing
Neither approaches are working for me. If I am using a custom-{slug}.hbs, file that means I am on a page. Right? If it’s not a post, author page, or tag, then it must be a page. This is bizarre. I will double check some things. Thanks. Oh, it is happening on a custom file called sidebar-truth.hbs in which I have it rendered in another file titled custom-truth.hbs with {{> sidebar-truth }}.
Just to make sure I am understanding you correctly:
You have a custom-truth.hbs that is using a sidebar-truth.hbs as a partial?
If that is so, the custom-truth.hbs works as a custom template, which can be used both as a post or a page.
The context really depends on how you are using the template. Generally, the {{#post}} handlebar covers both page and post contexts though.
It would definitely help to see more of the custom-truth.hbs and sidebar-truth.hbs to determine where exactly the problem lies.
That is completely correct. I am using custom-truth.hbs as a template for a page. If I remove the partial and port that code directly to custom-truth.hbs., then it works fine. Not sure why though.