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
Prevent image source path from breaking #367
Conversation
This change prevents image source path from breaking. It prefixes content rootpath the image sources. It excludes the sources that starts with http:// or https:// or /. If image source starts with './' i.e. image is in the same folder as content, then it will replace ./ with content directory path and then adds the rootpath. Once image source is fixed, it should not break, no matter from where content is accessed i.e. index or individual page.
Ah excellent, this addresses a common issue right now. |
Although this address image source issue while rendering posts/pages on the site, @jonbullock do you think, we should make them fully qualified path instead of relative? eg. http://example.com/content/a.jpg instead or content/a.jpg? |
@manikmagar Yeah I agree we should make them fully qualified for the feed for this release. We can review this in subsequent releases. |
@jonbullock Feed just loads the content already parsed into HTML source code. To make feed paths working, we have two options -
Do you have any thoughts or suggestion? |
👍 for full qualified domains. The ConfigUtil rewrites the site.host property when running with jetty. You need to run with -b option too. For a clean workflow, say running a server in background with -s while editing content, we would need a mechanism to detect a still running jetty instance launched from jbake to do the same thing. |
When file is parsed, the rendered html content is stored in
May be a simple fix? What do you think about this? @jonbullock |
I didn't fully understand the complexity of this when I suggested FQDN for the feed. I'm undecided whether adding an additional variable is better or worse than post-processing the XML output to make image references use FQDN instead of just relative. Adding a new variable just for use in the feed seems overkill but post-processing a rendered file doesn't feel right either. |
I was looking at img srcset attribute that was added with html5. It is used for the responsive image set, browser first tries to load image from srcset and if that is not available then it falls back to src attribute. I am thinking to add relative path in srcset and FQDN in src. Except feed, browser should always then use relative path and when feed is rendered in reader, FQDN would be used. I'll give it a try. |
Replace rootpath with site host Changed the implementation to prefix the site.host property before images. Relative paths were breaking in feed.
So, srcset did not work as expected. As @ancho said (btw thanks for that), ConfigUtil rewrites the site.host property to localhost when ran with In case of local baking, if For releasing site, when just This should solve the feed problem too. Eg. For site rendering - check this post (it is the same as in feed above) |
Thanks @manikmagar any chance you can have a look at why the tests have failed after your latest commit? |
Ah! Sure. I will check and fix it. |
Corrected JSOUP api method call to prevent empty body during test execution. This would also prevent extra body element in parsed fragment.
Corrected JSOUP API method call to prevent empty body during test |
Excellent thanks @manikmagar |
Linking mailing list discussion on this: https://groups.google.com/d/topic/jbake-user/64MiZRTl_3I/discussion |
This change prevents image source path from breaking. It prefixes
content rootpath to the image sources.
It excludes the sources that starts with http:// or https:// or /.
If image source starts with './' i.e. image is in the same folder as
content, then it will replace ./ with content directory path and then
adds the rootpath.
Once image source is fixed, it should not break, no matter from where
content is accessed i.e. index or individual page.