-
-
Notifications
You must be signed in to change notification settings - Fork 7.7k
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
Remove canonifyURLs support #4733
Comments
Currently sites that have See this test page (best viewed in widescreen so that the nested frame can be seen side-by-side). The said example image link works with
|
@kaushalmodi #4457 should solve the Markdown part. But why do you have to use canonifyURLs = true to get your example working? Note the boldness in my "have". There is an obvious workaround when you say that an URL in Markdown with a leading slash is relative to the host. You have a similar challenge with languages. So, #4457 solves the Markdown part for both sub-paths and languages in a much cleaner and effective way. So what you lose by this is the canonification of the URLs inside the templates. And that, my friend, is work for (#4457 will only work for BF and possibly MMark). |
Exactly! I am aware of that workaround.. but portability is a big reason I am not going that route. Tomorrow if a site moves from subdir-domain to regular domain, the needed refactoring, while possible, is still an ugly job.
I prefer to use regular Markdown links as much as possible.
I'll subscribe to that issue (You obviously meant #4574 :)). I'll definitely try it out once you have a PR for that.
Yes, I am fine with that. The real-world usage is mainly linking to figures in content Markdown files, which look like the example I posted above. |
I use |
If i use markdown syntax for images, but we removed yaml config:
content.md
output html: // 404 error https://www.example.com/dir1/dir2/image.png
// should be https://www.example.com/dir0/dir1/dir2/image.png
<img src="/dir1/dir2/image.png"> // 404 error Updated: image render hooks: <img src="{{ site.BaseURL }}{{ .Destination | safeURL }}"
{{- with .Text }} alt="{{ . }}"{{ end -}}
{{- with .Title }} title="{{ . }}"{{ end -}}
> |
You can enable Hugo's embedded link and image render hooks: Note that these are enabled by default with multilingual single-host sites. There is never a good reason to use |
Would like to thank XhstormR for providing an actual solution to the problem! I have to admit, that how Hugo manages paths for images, well and apparently links is strangely fustrating and obtuse, especially for something that should really just work. I expect that the "static" folder is likely causing more problems then it solves. Here is a subtly alternate to XhstormR solution, not using the apparently bad BaseURL
|
I've written about this many times, with a detailed description here. The short answer is to use link and image render hooks that resolve markdown destinations regardless of site configuration and front matter (e.g., The easiest way to handle this is to enable Hugo's embedded link and image render hooks:
You can examine the source code here: |
See gohugoio/hugoDocs#469
This is also related to #4574 -- and we should make sure to do this and that in the same release.
We currently have a fair amount of (some of it slowish) code to support
canonifyURLs
, and there are several issues with it. Issues that are very hard to fix in a simple way. I don't usecanonifyURLs
, and I'm not willing to spend time fixing/maintaining it.So until someone steps up to the plate with some magic, we are removing it.
/cc @spf13
The text was updated successfully, but these errors were encountered: