{{ 'events'|page }} vs {{ url('events') }}

What’s the difference between {{ 'events'|page }} and {{ url('events') }} ?

<a class="{{ activeNavLink == 'events' ? 'active' }}" href="{{ 'events'|page }}">Events</a>

and

<a class="{{ activeNavLink == 'events' ? 'active' }}" href="{{ url('events') }}">Events</a>

I have a situation where all other links in the menu are fine except the events link in the menu - when I am on a page like https://myProject.test/daily/soundarya-lahari-class the events link on the menu is https://myProject.test/events/soundarya-lahari-class when it should be just https://myProject.test/events - why aren’t the other menu links having the same issue ?

So I had to change it to this :

<a class="{{ activeNavLink == 'committee' ? 'active' }}" href="{{ 'committee'|page }}">Committee</a>
<a class="{{ activeNavLink == 'events' ? 'active' }}" href="{{ url('events') }}">Events</a>
<a class="{{ activeNavLink == 'offerings' ? 'active' }}" href="{{ 'offerings'|page }}">Offerings</a>
1 Like

The difference is:

  • {{ 'events'|page }} - Looks up a CMS page by filename and returns its URL. If the page has URL parameters, it tries to fill them from the current request context.
  • {{ url('events') }} - Just generates a literal /events path with no CMS lookup or parameter substitution.

Why you’re seeing the bug:

Your events.htm page probably has a URL pattern with an optional parameter like:

url = "/events/:slug?"

When you’re on /daily/soundarya-lahari-class, the |page filter sees the :slug parameter and tries to be helpful by filling it with the current slug from the request, giving you /events/soundarya-lahari-class

Your other pages (committee, offerings) likely have static URLs without parameters, so they don’t have this issue.

You could pass empty parameters explicitly:

<a href="{{ 'events'|page({ slug: '' }) }}">Events</a>

I’d recommend separating your pages:

  • events.htm with url = "/events" for the listing

  • event-detail.htm with url = "/events/:slug" for individual events

This option is the cleanest approach since it avoids parameter inheritance entirely and makes your intent clear.