docsify
docsify copied to clipboard
How to add images from root?
For example, I have 2 folders in the root directory. There is a picture in the first folder (images).
The second folder (docs) contains the markdown file.
How do I insert an image into this markdown file that is located in the folder (images).
If I put it this way:

He tries to add it like this:
/docs/images/testimage.jpg
Use https://docsify.js.org/#/configuration?id=relativepath
This changes the links but not the path to pictures. Am I doing something wrong?
Hmm, it’s maybe a bug
I confirm this is a bug. When you use

it doesn't work, but when you use
<img src='/img/img.png'></img>
it works
Hmm .. this bug is fixed?
Yes, now it works (with a workaround)
Hey @LemarkNova , Thanks for reply.
I am confused about the img tag compile result.
my markdown content is :

The docsify compiled result is :
<img src="/foldername/subfoldername/myimg.png" alt.../>
my expected result is :
<img src="/myimg.png" alt.../>
because my all static img file is just in a single folder.
I found that this 「long path」is not caused by "marked" —— docsify compile markdown file by it,
It seems caused docsify ?
Something could be config ?
No finally it isn't fixed, I remember that I just use a workaround to use image in markdown:
I use ../picturefolder/picture.jpg. So the real problem is that docsify doesn't compile correctly the markdown image. I don't know how you compile the markdown, but the problem is in the compilation of the markdown like in your previous comment.
Does Docsify use the latest version of marked? But I just try with marked and it work.
Thanks for your help. I note the workaround way.
I do nothing about the compilation of markdown files, just do some steps from the official documentation.
I am not sure the version of marked, but the docsify I installed is the latest version.
No finally it isn't fixed, I remember that I just use a workaround to use image in markdown: I use
../picturefolder/picture.jpg. So the real problem is that docsify doesn't compile correctly the markdown image. I don't know how you compile the markdown, but the problem is in the compilation of the markdown like in your previous comment.
Hi, could you please help me? #936
I've the same problem :(
It's quite difficult to cover all the cases with a single syntax. I will try to look around this soon.
@anikethsaha the behavior should be in function of relativePath? Currently even if this parameter is false, img path generated still is in relative.
@anikethsaha the behavior should be in function of relativePath?
Yes
Currently even if this parameter is false, img path generated still is in relative
Need an investigation about this.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This is still an issue.
hook.beforeEach(function(content) {
return content.replace(new RegExp("/images", 'ig'), "../images");
})
or
hook.afterEach(function(html, next) {
let reg = new RegExp(vm.config.basePath + ".*/images", 'ig');
html = html.replace(reg, vm.config.basePath + "images");
next(html);
})
or
markdown: {
// https://marked.js.org/#/USING_PRO.md#renderer
renderer: {
image: function(href, title) {
return `<img src="${href}" data-origin="${href}" alt="${title}">`
}
}
}
In core/render/compiler/image.js
import { isAbsolutePath, isRelativePath, getPath, getParentPath } from '../../router/util';
...
if (!isAbsolutePath(href)) {
url = isRelativePath(href) ?
getPath(contentBase, getParentPath(router.getCurrentPath()), href) :
getPath(contentBase, href);
}
In core\router\util.js
export const isRelativePath = cached(path => {
return /^[^\/]/g.test(path);
});
If your image is in GitHub repo, Use 'img src' instead of markdown and attach "?raw=true" to end of image's URL.
<img src="https://github.com/your/repo/blob/master/docs/images/img.png?raw=true"</img>
I don't know why, but it works.
I come up with the same problem, i think the most convinent way is to turn ![]() syntax into <img src="" alt="">.
same issue here!
Bug acknowledged. Tracking with #1891.