Hugo: Hugo 0.17 regression with page names that contain dot

[miltador]

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.

[bep]

By "name of page" you mean what exactly?

[miltador]

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

[tphalp]

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]

@abourget I believe this is your logic.

[vyuh]

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](https://github.com/spf13/hugo/commit/708bc78770a0b0361908f6404f57264c53252a95#diff-11ef8f3d3393d6df7b93de219441eeb2L127)).

• 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]

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 ?