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

Hugo 0.17 regression with page names that contain dot #2555

Closed
miltador opened this Issue Oct 11, 2016 · 6 comments

Comments

Projects
None yet
5 participants
@miltador
Contributor

miltador commented Oct 11, 2016

On Hugo 0.16 the pages with dot in name were rendering correctly.

With Hugo 0.17 pages with dot in their name won't render. With hugo server I get only

<pre>
</pre>

in output.
However when doing a build of site with hugo the name of page with dot get stripped down to the first dot. The content of the page is correct though.

@miltador miltador changed the title from Hugo 0.17 regression with paths that contains dot in it to Hugo 0.17 regression with page names that contain dots Oct 11, 2016

@miltador miltador changed the title from Hugo 0.17 regression with page names that contain dots to Hugo 0.17 regression with page names that contain dot Oct 11, 2016

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Oct 11, 2016

Member

By "name of page" you mean what exactly?

Member

bep commented Oct 11, 2016

By "name of page" you mean what exactly?

@miltador

This comment has been minimized.

Show comment
Hide comment
@miltador

miltador Oct 11, 2016

Contributor

@bep, I mean name of file e.g. 10.3.md won't work.

Contributor

miltador commented Oct 11, 2016

@bep, I mean name of file e.g. 10.3.md won't work.

@tphalp

This comment has been minimized.

Show comment
Hide comment
@tphalp

tphalp Oct 14, 2016

I'm on macOS 10.12, Hugo v0.17 BuildDate: 2016-10-07T08:42:05-06:00

I'm experiencing the same thing. I have post names that correspond to release version for a piece of software. Post names like, v5.2.4289.md, but when the site is rendered, all the links to the actual articles are v5. All of them, which breaks the site.

If I try to manually navigate to what I think should be the correct url for a given post, it exists, but it is not being referenced correctly on the main index page.

You can see this happening here: http://releasenotes-client.getweave.com/

UPDATE: For some odd reason, in my specific situation, the actual page for the first post doesn't exist, but it does for the second post. So, if you try navigating to http://releasenotes-client.getweave.com/post/v5.2.4295/, it doesn't exist, but http://releasenotes-client.getweave.com/post/v5.2.4289/ does.

UPDATE OCT 26: The above links are no longer broken, as I rebuilt the site using 0.16 on El Capitan.

tphalp commented Oct 14, 2016

I'm on macOS 10.12, Hugo v0.17 BuildDate: 2016-10-07T08:42:05-06:00

I'm experiencing the same thing. I have post names that correspond to release version for a piece of software. Post names like, v5.2.4289.md, but when the site is rendered, all the links to the actual articles are v5. All of them, which breaks the site.

If I try to manually navigate to what I think should be the correct url for a given post, it exists, but it is not being referenced correctly on the main index page.

You can see this happening here: http://releasenotes-client.getweave.com/

UPDATE: For some odd reason, in my specific situation, the actual page for the first post doesn't exist, but it does for the second post. So, if you try navigating to http://releasenotes-client.getweave.com/post/v5.2.4295/, it doesn't exist, but http://releasenotes-client.getweave.com/post/v5.2.4289/ does.

UPDATE OCT 26: The above links are no longer broken, as I rebuilt the site using 0.16 on El Capitan.

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Oct 14, 2016

Member

@abourget I believe this is your logic.

Member

bep commented Oct 14, 2016

@abourget I believe this is your logic.

@bep bep added exp/expert and removed exp/expert labels Oct 17, 2016

@vyuh

This comment has been minimized.

Show comment
Hide comment
@vyuh

vyuh Oct 20, 2016

Contributor

I investigated this behaviour on a recent version db86f48 by simple print-lining, relevant observations are listed below for a file named "moo.0.7.78787.md". It'll help if you refer to the code of funcs linked below while reading:

  • in v0.17 and later:
    • file hugolib/page.go, func permalink: t is set to a value returned by translationBaseName(). The value is "moo.0.7" (but it should be "moo.0.7.78787.md" to work correctly). The permalink returned by function ends with "moo.0" which is value of t after removing the 'extension' (".7").

    • file source/file.go, func NewFile: f.basename is set to "moo.0.7.78787", f.lang is set to "78787", f.translationBaseName is reduced to "moo.0.7" (this is set as t in func permalink()). f.translationBaseName excludes what hugo thinks is a lang code (".78787"), and it excludes the extension (".md") too. This incorrect value is returned to func permalink and ...
      This function must ensure that only file names ending with ".<valid_lang_code>.<extension_like_md>" are adjusted by removing only the ".<valid_lang_code>" part, ".<extension_like_md> "should be kept intact.

      Most probably this is the function which needs a FIX. Some Ideas:

      • translatedBaseName must keep the extension (".md") because it is removed when permalink is created from t in func permalink().
      • also, before setting a garbled translationbasename, it should perform some check to verify that the site ismultilinual or that f.lang is some valid language code the author has explicitly listed in config. (though it looks like such a check was removed in 708bc78).
  • in v0.16:
    • file hugolib/page.go, func permalink:t was "moo.0.7.78787.md", a value that came from _, t := filepath.Split( p.Source.LogicalName() ). Using this value of t generates correct permalinks in v0.17, by breaking multi language support of course. :P
    • file source/file.go, func NewFile: f.{basename,lang,translationBaseName} didn't exist.
Contributor

vyuh commented Oct 20, 2016

I investigated this behaviour on a recent version db86f48 by simple print-lining, relevant observations are listed below for a file named "moo.0.7.78787.md". It'll help if you refer to the code of funcs linked below while reading:

  • in v0.17 and later:
    • file hugolib/page.go, func permalink: t is set to a value returned by translationBaseName(). The value is "moo.0.7" (but it should be "moo.0.7.78787.md" to work correctly). The permalink returned by function ends with "moo.0" which is value of t after removing the 'extension' (".7").

    • file source/file.go, func NewFile: f.basename is set to "moo.0.7.78787", f.lang is set to "78787", f.translationBaseName is reduced to "moo.0.7" (this is set as t in func permalink()). f.translationBaseName excludes what hugo thinks is a lang code (".78787"), and it excludes the extension (".md") too. This incorrect value is returned to func permalink and ...
      This function must ensure that only file names ending with ".<valid_lang_code>.<extension_like_md>" are adjusted by removing only the ".<valid_lang_code>" part, ".<extension_like_md> "should be kept intact.

      Most probably this is the function which needs a FIX. Some Ideas:

      • translatedBaseName must keep the extension (".md") because it is removed when permalink is created from t in func permalink().
      • also, before setting a garbled translationbasename, it should perform some check to verify that the site ismultilinual or that f.lang is some valid language code the author has explicitly listed in config. (though it looks like such a check was removed in 708bc78).
  • in v0.16:
    • file hugolib/page.go, func permalink:t was "moo.0.7.78787.md", a value that came from _, t := filepath.Split( p.Source.LogicalName() ). Using this value of t generates correct permalinks in v0.17, by breaking multi language support of course. :P
    • file source/file.go, func NewFile: f.{basename,lang,translationBaseName} didn't exist.
@abourget

This comment has been minimized.

Show comment
Hide comment
@abourget

abourget Oct 28, 2016

Contributor

Good and thorough analysis @vyuh .. I think you're right, last time I had my head into this, very few places read and tweaked those fields.

Doing validity check on the lang section would be a great addition, as well as putting back that multilingual enablement check.

@vyuh do you think you could propose a patch for that ? It'd be a great contribution I think :) I'd gladly review.

btw, are you using Multilingual ? If not, then adding some simple checks for multilingual enablement, and sort of reverting to previous behavior when not enabled, would be a quick fix, wouldn't it ?

Contributor

abourget commented Oct 28, 2016

Good and thorough analysis @vyuh .. I think you're right, last time I had my head into this, very few places read and tweaked those fields.

Doing validity check on the lang section would be a great addition, as well as putting back that multilingual enablement check.

@vyuh do you think you could propose a patch for that ? It'd be a great contribution I think :) I'd gladly review.

btw, are you using Multilingual ? If not, then adding some simple checks for multilingual enablement, and sort of reverting to previous behavior when not enabled, would be a quick fix, wouldn't it ?

@bep bep closed this in #2653 Nov 1, 2016

bep added a commit that referenced this issue Nov 1, 2016

Fix page names that contain dot
changes:
    - in hugolib/page.go, `func permalink` and `func TargetPath`
      Fixed the attempt to *replace* the extension of something
      that was *already* a basename.
    - in source/file.go, `func NewFile`
      added check for allowed languages before translating filename

Fixes #2555

tychoish added a commit to tychoish/hugo that referenced this issue Aug 13, 2017

Fix page names that contain dot
changes:
    - in hugolib/page.go, `func permalink` and `func TargetPath`
      Fixed the attempt to *replace* the extension of something
      that was *already* a basename.
    - in source/file.go, `func NewFile`
      added check for allowed languages before translating filename

Fixes #2555
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment