Skip to content
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

Webpages titles case-registry inconsistency #152

Closed
n0rdy opened this issue Oct 27, 2023 · 2 comments · Fixed by #155
Closed

Webpages titles case-registry inconsistency #152

n0rdy opened this issue Oct 27, 2023 · 2 comments · Fixed by #155

Comments

@n0rdy
Copy link
Contributor

n0rdy commented Oct 27, 2023

Hello there, Luke! =)

Thanks again for the Poison, I like it more and more while diving deeper into it.

While trying to configure the theme for my personal blog, I noticed a tiny case-registry inconsistency within the webpages titles: as you can see from GitHub, my nickname is n0rdy (lowercase). Here is how it looks in the toml file:

[params]
    brand = "n0rdy"

If I go to the main page, the title looks as expected:
CleanShot 2023-10-27 at 21 11 18@2x

However, when I navigate to the About page or the Posts/any post page, my nickname's first letter changes to the uppercase:
CleanShot 2023-10-27 at 21 12 45@2x

This seems like an inconsistency, from my point of view.

I debugged the source code a bit, and it seems like I found the origin of this behavior:

{{ .Scratch.Set "title" $.Site.Params.brand }}
{{ .Scratch.Set "title" ($.Site.Params.brand | humanize | title) }}

If I remove the | humanize | title part, the described inconsistency is gone.

I was considering creating a PR, but looks like a breaking change (if I go with the removal approach), that's why I wanted to discuss it first.
If you agree that it's smth worth fixing, I can try to do it via the new boolean param that, by default, will keep the behavior as it is right now, but if provided, will drop the | humanize | title part.

Please, let me know what you think about this.

Have fun! =)

@lukeorth
Copy link
Owner

Thank you, @n0rdy! I agree -- the case should remain consistent.

I think removing the | humanize | title part without adding a boolean param would be just fine. It gives control back to the user, which is always good. I think adding another param would over complicate things too much.

Thanks for finding this and checking! If you want to open a PR, please have at it. Otherwise I can open one too. :)

@n0rdy
Copy link
Contributor Author

n0rdy commented Nov 24, 2023

Hey, Luke! Done, please, take a look

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants