Hugo: Deprecate and then rename/remove Page.URL

[bep]

I cannot think of one valid use case for it, and I see it used in the wild all the time when RelPermalik or Permalink is the correct choice.

URL returns the front matter value for regular pages, if set, else it return the RelPermalink.

[onedrawingperday]

I am not in favor of removing Page.URL.

For example
if eq .URL "/some-url/" provides an easy way to add an active class to page links that live outside Hugo's menu configuration (for various reasons) Also this is handy in cases where it's difficult to do a .Permalink or .RelPermalinkcheck, like in Nested Sections list pages.

But if you really think these are not valid use cases. Go ahead and remove it. I'll look into what can be done to replace its functionality... like I always do...

[Jos512]

.URL and .Permalink are indeed much the same, although the first returns a string value and the second a template.HTML value. So even though they return the same data, they behave differently:

~~~plain
{{ if in .URL "hugo" }}
...
{{ end }}

{{ if in (.Permalink | string) "hugo" }}
...
{{ end }}
~~~

I agree there's some redundancy. And on one hand I think Hugo template code might become easier when there's no two variables that return the same data. But on the other hand the required conversion to string of .Permalink might be more odd to newcomers than two variables are.

That latter might also make explaining how people can update from .URL to .Permalink somewhat confusing. Assuming we use a terminal message for this like Hugo did with previous depreciations. Would a terminal message like this be something people with little knowledge of Go/Hugo understand?

~
WARN: .URL has been deprecated. Replace .URL with
.Permalink, but when comparing .Permalink against a
string, first translate .Permalink to a string value
with the 'string' function.
~

Even though I wrote this without using programming lingo (like 'casting' or 'type incompatibility'), I still doubt if this is clear enough. (Or should we assume people read the release notes, where this can be explained more fully?)

So to summarise: I don't know what wisdom is for this issue. 😆

[onedrawingperday]

Or should we assume people read the release notes, where this can be explained more fully?

If the recent release of Hugo 0.32 is any indication I would say that people don't bother with the release notes. The forum is full of posts regarding index.md

A Warn like @Jos512 proposes is the way to go.

And possibly an example of the .Permalinktranslation to a string value, in the Release notes.

You cannot assume that every user of Hugo has used every one of its functions or that he/she knows what to do in advance. Not all of us are from a Dev background.

[onedrawingperday]

{{ if in (.Permalink | string) "hugo" }}

I just want to say that the above approach would not work with .FirstSection list pages because obviously the string is also present in the Nested Sections of that section.

For example let's say that I have a section called /women/ and a nested section called /women/backpacks and I want to have each custom menu entry of these links have a selected class when the user is in their corresponding URL. With the above both menu entries would have the selected class under both URLs.

But thanks to Hugo 0.45.1 and .FirstSection here is how I finally managed to do this.

{{ $currentURL := .Permalink }}
{{ with .FirstSection }}
<a {{ if eq .Permalink $currentURL }}class="selected"{{ end }} href="...">...</a>
{{ end }}

And then for other list pages within that Section I do the following simple check:

{{ if eq .Permalink $currentURL }}class="selected" {{ end }}

So at this point, I am fine with .URL being deprecated from Hugo, since I can have the functionality I need with other simple means.

[onedrawingperday]

Actually if .Page.URL is deprecated and removed it will break several older themes that are currently in the Hugo Themes showcase.

And that is not a bad thing.

Since it will force theme authors to update their themes or if they don't we can always clean up the showcase from unmaintained themes.

So +1 for this issue.