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

Wrong Permalink for resources in sites with baseURL with sub-path and canonifyURLs=true #5226

Closed
tadeboro opened this issue Sep 18, 2018 · 11 comments
Assignees
Milestone

Comments

@tadeboro
Copy link

hugo versions up to and including 0.42.2 used complete baseURL URL to create absolute permalinks for resources. Later versions use only host part of the config, which breaks sites that use path in the baseURL config.

The change that introduced the breakage is this: dea7167#diff-237662eaccac0a9acb0b64febadb5b5aR690

Official documentation on the other hand still states that baseURL should be (quote from docs): Hostname (and path) to the root.

Was this done on purpose and hugo does not support having path parts in the baseURL?

@kauron
Copy link

kauron commented Oct 15, 2018

Hi, I'm also affected by this issue, is this going to be corrected or is it a feature?

@bep
Copy link
Member

bep commented Nov 15, 2018

I have added a PR with some tests in this area. I expected them to fail, but they don't.

If this is still an issue, I need a concrete and failing test case to be able to fix this.

/cc @onedrawingperday

@onedrawingperday
Copy link
Contributor

onedrawingperday commented Nov 15, 2018

I need a concrete and failing test case to be able to fix this.

Here is the Hugo Bootstrap Premium Theme that was recently removed from the Hugo Themes Showcase due to missing CSS and JS assets.

In its templates this theme uses .Permalink for Hugo Pipes resources. Like over here

On themes.gohugo.io this theme's CSS would not load because .Permalink created a URL directly under themes.gohugo.io and not under themes.gohugo.io/theme/hugo-bootsrap-premium/

Steps to reproduce locally

git clone https://github.com/gohugoio/hugoThemes
git submodule add https://github.com/appernetic/hugo-bootstrap-premium.git
cd _script/
./generateThemeSite.sh http://localhost:1313 && hugo server -w=false -s hugoThemeSite/themeSite

As a fix we have been recommending that theme authors should use .RelPermalink for their Hugo Pipes Assets because .RelPermalink produces the correct URLs on the Hugo Themes Site.

CC / @digitalcraftsman

@bep
Copy link
Member

bep commented Nov 15, 2018

OK, I see what's going on here. This happens when canonifyurls = true is enabled. This is obviously a bug, but since the workaround(s) are easy (either don't use canonifyURLs or use RelPermalink) and I'm planning to eventually remove the "canonifyURLs" support, I will not spend time fixing this now. If others have time, feel free.

@digitalcraftsman @onedrawingperday I will update the theme builder script to disable canonifyurls for the demo sites.

@bep bep modified the milestones: v0.52, v0.53 Nov 15, 2018
bep added a commit to gohugoio/hugoThemes that referenced this issue Nov 15, 2018
@bep
Copy link
Member

bep commented Nov 15, 2018

I may look at this later; I have turned off "canonifyURLs" on the theme site, but that may have other side effects.

@bep bep modified the milestones: v0.53, v0.52 Nov 15, 2018
@bep bep changed the title Permalink function on resource ignores path part of the baseURL Wrong Permalink for resources in sites with baseURL with sub-path and canonifyURLs=true Nov 15, 2018
@onedrawingperday
Copy link
Contributor

onedrawingperday commented Nov 15, 2018

I may look at this later; I have turned off "canonifyURLs" on the theme site, but that may have other side effects.

Actually @bep it does cause problems. But since canonifyURLs is marked for removal I suppose that we have to fix these problems in the Themes Repository and also remove canonifyURLs from the Hugo Basic Example.

Now a theme like the Hugo Bootstrap Premium that you re-added with commit gohugoio/hugoThemes@2d9f912 works fine.

However themes that either have an Example Site like Hugo Fresh or rely on the Hugo Basic Example like Tale Hugo that have committed their Hugo Pipes Resources and use a ToCSS tranformation no longer have their demos generated due to the following ERROR

ERROR 2018/11/15 17:05:44 error: failed to transform resource: TOCSS: failed to transform "style.sass" (text/x-sass): this feature is not available in your current Hugo version

ERROR 2018/11/15 17:06:00 error: failed to transform resource: TOCSS: failed to transform "scss/tale.scss" (text/x-scss): this feature is not available in your current Hugo version
FAILED to create exampleSite for tale-hugo

It seems that now with canonifyURLs turned off in the Build Script Hugo cannot find the committed Hugo Pipes resources either with .RelPermalink or .Permalink used in the templates.

I don't know how to fix this and it seems like a catch 22.

Don't know if you have the time @bep maybe try executing the Build Script with these 2 themes that I mentioned above. May be canonifyURLs should be enabled in the Build Script again or maybe something else is going on.

@bep bep closed this as completed in 5df2b79 Nov 15, 2018
@onedrawingperday
Copy link
Contributor

Ok. I just saw that as I posted the above comment you made a new commit that closed this issue.

I will take a look again and see if the problems I mentioned above are fixed.

@bep
Copy link
Member

bep commented Nov 15, 2018

I have reverted my changes in the themes repo. Please don't make this issue into a bigger issue than it is.

  • This was a bug. It will be fixed with Hugo 0.52. Until then, the very valid workaround is to use .RelPermalink for CSS resources etc. (which I kind of prefer myself, but that is a matter of taste)
  • CanonifyURLs will not be removed before I implement an alternative.

@neilmispelaar
Copy link

Hello,

This is probably a fringe boundary use case that only I would run into but I thought I would throw it out there in case it helps anyone else:

Issue:

When using hugo --server --bind x.x.x.x and leveraging hugo pipes:

<link rel="stylesheet" href="{{ $style.Permalink }}">

Hugo will write in the path for the resource as //localhost:1313/scss/sdr.css as opposed to //x.x.x.x:1313/scss/sdr.css

All other paths (such as live reload, images, etc) are correct using the bound IP address.

Fix:

As @bep pointed out above, one way to address is to use .RelPermalink as in:

<link rel="stylesheet" href="{{ $style.RelPermalink }}">

Additional Note:

Perhaps the documentation on this page https://gohugo.io/hugo-pipes/introduction/ could have a mention of the .RelPermalink method (as opposed to just the .Permalink)

rainwoodman added a commit to rainwoodman/compose that referenced this issue May 18, 2020
See: gohugoio/hugo#5226

This allows ignoring baseUrl (supporting multiple deployments).
@abulka
Copy link

abulka commented Sep 19, 2020

I'm still having problems relating to all this, e.g. deploying a site with images to GitHub pages when it is a Project Page based site. Unless I turn canonifyurls = true I get image paths generated by hugo which are missing the sub-path component of the baseURL.

E.g. The first image url refers to an image inside content/blog/images, and the second image url refers to a static image in /static/images.

![png your image](/blog/images/fred.png)
![png your image](/images/fred-uml.png)

Assuming baseURL = "https://user.github.io/projectname/" after static site generation I get paths which are missing the essential projectname path:

<img src="blog/images/fred.png" alt="png your image">
<img src="images/fred-uml.png" alt="png your image">

This only happens with images, all other links e.g. cross-references are generated ok. Seems this is also related to #5736 however the fix of removing the leading / doesn't work at all for images. I'm new to hugo so perhaps am missing something - or is this a new issue - or an undetected variant of this current closed issue?

@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants