You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 21, 2019. It is now read-only.
With the use of the relURL function, we can determine the URL path of an element and we should be able to use that to decide which event, year, etc it is instead of this same copy-pasted code we keep using:
{{ $path := split $.Source.File.Path .Site.Params.PathSeparator }}
{{ $event_slug := index $path 1 }}
{{ $e := (index $.Site.Data.events $event_slug) }}
{{/* end site data query */}}
I already do this a little bit; for example, in partials/head/seo/schema.html there is this code:
This might sound pedantic, but it has a far-reaching effect; it removes the need for a Windows-specific config file, because we are not splitting on filesystem paths anymore.
TBH, I'm not 100% sold that the PathSeparator value is really truly needed anyway; we have places in the code where it doesn't need it. Although that night be that Go is using some OS callbacks for us in the function. For example:
You would think that would NOT work on Windows, because the paths it is checking for with readDir are not Windows-friendly, but I am guessing readDir knows how to handle this.
The text was updated successfully, but these errors were encountered:
The thing I wonder about is that it bases itself on Permalink, which I think behaves oddly when we have baseURL set to "/", so we'll need to fix this with the other stuff related to baseUrl in the builds.
With the use of the
relURL
function, we can determine the URL path of an element and we should be able to use that to decide which event, year, etc it is instead of this same copy-pasted code we keep using:I already do this a little bit; for example, in
partials/head/seo/schema.html
there is this code:This might sound pedantic, but it has a far-reaching effect; it removes the need for a Windows-specific config file, because we are not splitting on filesystem paths anymore.
TBH, I'm not 100% sold that the
PathSeparator
value is really truly needed anyway; we have places in the code where it doesn't need it. Although that night be that Go is using some OS callbacks for us in the function. For example:You would think that would NOT work on Windows, because the paths it is checking for with
readDir
are not Windows-friendly, but I am guessingreadDir
knows how to handle this.The text was updated successfully, but these errors were encountered: