Our gitbook documentation must have crosslinks to other documentation hosted on the same server at different location.
We have these links:
API Reference
[API Reference](/stuff/documentation/api-reference.html)
Both of these links are converted by Gitbook to links relative to current page (this is for a page nested 1 level deeper than index page):
API Reference
And If page with link is nested deeper:
API Reference
What we need is Gitbook to keep relative URLs in links exactly "as is", so they will lead to correct path on final docs server:
API Reference
So far the only solution which works is to put JS code to navigate to desired relative path in HTML <a> tag inside markdown but this is a really ugly workaround.
Related
Gitlab Markdown has support for references to files in the repository structure, like:
[README](doc/README)
or
[README](doc/README#L13)
But are there ways to reference files and lines in these files, but from a given commit, at least in the Wiki ?
Maybe something like:
[README](1ab3fa71:doc/README#L13)
or using the file hash id like:
[README](9a27b101#L13)
To use relative links from wiki to the repository (or wise versa) is not supported officially according to Gitlab's documentation (cited from v11.5, still valid for v15.3):
Note: Relative links do not allow referencing project files in a wiki page or wiki page in a project file. The reason for this is that, in GitLab, wiki is always a separate Git repository. For example, I'm a reference-style link will point the link to wikis/style when the link is inside of a wiki markdown file.
There is, however, a syntax which seems to work currently:
[[README|/../blob/1ab3fa71/doc/README#L13]]
But be aware: all text of the same paragraph will just be lost!
I work around that by phrasing like this, which renders like expected for Gitlab CE v11.3.0 at least:
Here you see xyz:
* [[README|/../blob/1ab3fa71/doc/README#L13]]
The root-anchored link (/../blob/<version>/<path-to-file>) ensures that it works from every Wiki page independently from their nesting depth.
For sure this syntax also works for branch names or any other relative link like /../tree/1ab3fa71/doc for example.
Maybe long after the battle, but I found a workaround : Simply make a link to a page where the README.md is. And that's it !
To get the link simply go to a page which displays the document, copy the URL, make a link to that address, append #L with the line number.
Exemple :
[Readme Pelargos](http://192.168.80.250:10080/project-root/android/Pelargos/blob/develop/README.md#L47)
One way I've found that, for the most part, works is to mouseover the line of code that you want to reference in the relevant file. While doing that, click the link icon that appears in the lefthand-side gutter to copy the line reference. With it copied, you then use a slightly revised version of the path in the copied URI.
Here is an example of a link copied using the gutter icon:
https://gitlab.com/settermjd/mezzio-sms-sender-api/-/blob/main/src/App/src/Handler/SMSReplyHandler.php#L23
This is the revised path that I used in a commit. Note the parent directory reference prior to main/:
/../main/src/App/src/Handler/SMSReplyHandler.php#L23
I realize that the file reference in the gitlab wiki, references files from the wiki repository itself and not from the project repository (source code repository).
However, when you make a reference to a hash, it knows if the hash refers to a commit or a file, so you can make references to a specific file from the project repository.
I have this little piece of KML code which shows an image when clicked on the placemark, all images i have are store locally, and it works fine when using the .kml file it self.
Once the file is compressed into .kmz i'll get a warning (yellow marked) on the first line of the CDATA, covering some of my text.
It says: "This balloon may be using incorrectly formatted image URL"
All of my images works fine, they are not missing, and the relative URL is correct, but the syntax is not.
Anyone out there know of a solution to get rid of that hardcoded message ? or even better how to "tune" the code, so this warnings don't show :)
I've seen a couple of examples, stating it should help, but none suits my need, unfortunally.
This was some of the solutions i've looked at, but still not got it working.
Option 1: Fix the URLs
Your base URL is one directory down from where you thought it was, so you can simply add “../” to the beginning of each offending relative URL. This works fine in earlier versions of Google Earth as well, because older versions will look in both directories (and as a bonus, your content will render faster in older versions).
To fix the above example, we’d change:
<img src="images/image.png”>
to
<img src="../images/image.png">
Option 2: Add a <base> tag
As with any other browser, you can add a <base> tag to your HTML to set the base URL of that content. The href parameter of the <base> tag must be an absolute URL, so you’ll have to hard-code your server name and path. Adding the <base> tag to your BalloonStyle can fix all of your URLs in one go.
To fix the above example, we’d add: <base href="http://host.example.com/kmz/somelayer/"> to the BalloonStyle (or description, if we only have a few affected placemarks).
Option 3: Move the files
If you can’t change the balloon content, you can still correct it by moving the resources it points to into the correct locations. Depending on the URL, there are a couple of ways to do this. In our example, you’d move or copy the “images” folder and its contents to the KMZ archive. If the offending URL was “../files/another_image.png” (which should have been “../../files/another_image.png”), you could move or copy the files folder into the somelayer folder to fix the problem.
In many cases, though, there will be many layers all referencing the files folder, so moving the files folder into each layer folder can get tedious. If you have access to the web server configuration, you can solve this by adding an HTTP redirect from each incorrect location that redirects up a directory. You could also move the KMZ file up a directory, but this will change the URL that people must use to access your KMZ file.
I wanted to look at your KML to see if it was properly formatted and test it on my end.
I'm using the Node.js version of TiddlyWiki, and I'd like to link to images on my filesystem.
The documentation listed here doesn't work; in the [img[path]] tag, for the path part I put something like /Users/documents/ken/path_to_image.jpg yet nothing shows up in the tiddler.
My wiki exists in /Users/documents/ken/wiki.
I know this is an old post, but zacts stated that you can use a macro plugin or simply use the [img] tag to point to the relative path of the image from the tiddlywiki.html file, but the op is using the node.js version, and zacts apparently didn't read that. There is no tiddlywiki.html file for TiddlyWiki on node.js. That only works with the static .html version of tiddlywiki, not the node.js version.
Currently there is no way to point to a local file through the node.js version of Tiddlywiki as node.js is not a webserver, therefore it does not see subfolders like /images/ off of the root url. The only way is to run a parallel web server on the same machine and use the full web url to the images served up from the web server.
In case someone else stumbles across this problem:
I could not find this documented anywhere, but what seems to work is to just copy the image in the tiddlers directory, then restart the nodejs server, and search for the image title from tiddlywiki. There will be a tiddler that contains that image, that you can edit at your leisure.
Alternatively, copy the image as image_name.png (or image_name.jpg) into the tiddlers directory, and create a image_name.png.meta text file with the following contents:
title: image_name
type: image/jpeg
Upon restart of the tiddlywiki nodejs server, a tiddler with title image_name which contains the image will be there.
If you are using the Node.js version, you can simply put it in the ./files folder, and then use [img[. /files/xxx.jpg]] to reference it.
I had this same issue recently, and I found a neat little solution for it. Let me send you the links, and I'll post the snippets here.
I happened to stumble across this tiddlywiki image gallery homepage that linked to a macro plugin that lets you link in local images. Here is the link to the tiddler for the plugin: http://www.richshumaker.com/tw5/tw-photo.html#External%20Image%20Path. Here is the original TiddlyWiki google groups post of the plugin for this: https://groups.google.com/forum/#!msg/tiddlywiki/ChRV6sjQpn4/bCm35_XhGmkJ.
I hope this helps! =) (note: when I get more time I may clean up the formatting of this post).
It is very simple, you use _canonical_uri field
_canonical_uri field
The field value is something like "./wiki/path_to_image.jpg" (mine is "./files") in the same level as the tiddlers folder. I did not experimented with files outside the root folder of the wiki. The dot in the path might be ommited.
The content type might be "audio/mp3" "image/jpg" look at the "parser" shadow tiddlers. Your Browser might support more content types like "audio/wav" but you would have to add this line to "$:/core/modules/parsers/audioparser.js" For example. Might be the same thing for images. Check your browser support.
I really do not know why this fact is so obscure, but it work wonders.
Hello Stackoverflow this is my first post, but you have already helped me alot of times!
However, I have made a Footer as a library item on my site. The problem is that, when I add the library item into my site, every links and images get "library/" before.
Example: In the library item the link to my image is "images/about-us.png", but it turn so "library/images/about-us.png" when I drag the library item into my site. This results in that the image can't be find and doesn't show up.
Any ideas is very helpfull!
/Rasmus (DW CS5.5)
Did you originally have a folder in the root of your site called 'library'? If so, that may have confused Dreamweaver, as by default, they store all library items in a root-level folder called 'Library' (with a capital L). And if that folder doesn't exist, Dreamweaver should try to create it.
I am using the Hyperlink / Picture column type within a Document Library.
When entering the hyperlink, I am using a shortened path. However, after exporting this site to an stp, I realized that it was being stored as the full path (it was failing when the stp was used in another Site Collection).
As an example, I entered the following path: /SC/Images1/AdministratorUsers.png
However, when viewing the entered docuemnt library item, I see this path: http://servername:port/SC/Images1/AdministratorUsers.png
How do I get around this limitation?
This is a bug, sharepoint saves only full urls. I circumvent this by storing all css and images etc in the root site(collection)'s style library.
Even a publishing page's pagelayout url is stored as a full url, we had to create a tool to update all references when the site was moved to a new url / server...