I've added my baseurl to the config for Jekyll, but every permalink is not appending it. I'm using Jekyll version 2.5.3 and Apache.
This is what the config looks like for all relevant content:
baseurl: /blog
host: 0.0.0.0
permalink: /:year/:month/:day/:title
destination: /var/www/html/blog/_site/
The directory structure is the way it should, but the link request all show localhost/2015/06...
Does the routing need to be adjusted by Jekyll or Apache?
You have to explicitly use site.baseurl. Jekyll doesn't automatically prepend it to urls.
<a href="{{site.baseurl}}{{post.url}">
I understand this question might be outdated, but I also ran into this issue while hosting a Jekyll blog on GitHub pages.
You can use the relative_url Liquid Filter provided by Jekyll to automatically prepend any url with the baseurl configured in _config.yml.
Example:
{{ post.title }}
Relative URL
Prepend baseurl config value to the input to convert a URL path into a relative URL. This is recommended for a site that is hosted on a subpath of a domain.
Related
I'm try to configure traefik with file backend to contact a grafana server in a LXC container.
This is my configuration file:
[file]
# rules
[backends]
[backends.backend2.servers.server1]
url = "http://192.168.255.250:3000"
[frontends]
[frontends.frontend2]
entryPoints = ["http"]
backend = "backend2"
passHostHeader = true
[frontends.frontend2.routes]
[frontends.frontend2.routes.route0]
rule = "PathPrefixStrip: /grafana"
Grafana backend listen on /
So, I can contact http://example.com/grafana but I have a redirection to http://example.com/login which does not work. But http://example.com/grafana/login responding (without css, certainly because grafana seems to use relative url).
According to the documentation :
Use a *Strip matcher if your backend listens on the root path (/) but should be routeable on a specific prefix. For instance, PathPrefixStrip: /products would match /products but also /products/shoes and /products/shirts.
Since the path is stripped prior to forwarding, your backend is expected to listen on /.
If your backend is serving assets (e.g., images or Javascript files), chances are it must return properly constructed relative URLs.
Continuing on the example, the backend should return /products/shoes/image.png (and not /images.png which Traefik would likely not be able to associate with the same backend).
The X-Forwarded-Prefix header (available since Traefik 1.3) can be queried to build such URLs dynamically.
It seems that I have to use the X-Forwarded-Prefix header but I do not know how to use it (I did not see anything in the documentation). Maybe you can help me solve this problem ?
Regards
jmc
In fact, the problem does not come from traefik. I just forgot to specify the path in /etc/grafana.ini (root_url field). I thought it was not necessary since the incoming query does not contain the path /grafana (because we use PathPrefixStrip). But in fact, grafana needs it to indicate effective url to client.
Regards.
jmc
I'm hosting my git-hub pages website (peps09791.github.io) using a custom domain (https://thebotspeaks.com) with Cloudflare.
To enable HTTPS, I have done the following configurations:
In my _config.yaml file
I have set the URL key accordingly
url: "https://peps0791.github.io"
From my cloudFlare dashboard, I have enabled option of HTTPS rewrites to prevent mixed content error.
I have also enabled Flexible SSL from CloudFlare.
I haven't enabled default HTTPS-redirection because the website breaks over HTTPS. On HTTP, it works fine.
Right now, when I try to access my website using HTTPS, I get mixed content error:
Mixed Content: The page at 'https://thebotspeaks.com/' was loaded over HTTPS, but requested an insecure image 'http://thebotspeaks.com/assets/images/bio-photo.jpg'. This content should also be served over HTTPS.
09:54:45.323 (index):1 Mixed Content: The page at 'https://thebotspeaks.com/' was loaded over HTTPS, but requested an insecure stylesheet 'http://thebotspeaks.com/assets/css/main.css'. This request has been blocked; the content must be served over HTTPS.
09:54:45.785 (index):1 Mixed Content: The page at 'https://thebotspeaks.com/' was loaded over HTTPS, but requested an insecure script 'http://thebotspeaks.com/assets/js/main.min.js'. This request has been blocked; the content must be served over HTTPS.
From console, I can see this:
<script src="https://peps0791.github.io/assets/js/main.min.js"></script>
<link rel="stylesheet" href="https://peps0791.github.io/assets/css/main.css">
How do I resolve this issue?
The problem here is that your assets (i.e. your CSS or JavaScript) are redirecting to the HTTP version of your site. This is because your assets are referencing directly to your GitHub site instead of the Cloudflare-enabled domain.
For example; your HTML references your CSS files at https://peps0791.github.io/assets/css/main.css instead of https://thebotspeaks.com/assets/css/main.css
In order to fix this it looks like you'll need to update your _config.yaml file to have the following URL key:
url: "https://thebotspeaks.com"
More general advice on fixing a variety of Mixed Content issues can be found in the following article on the Cloudflare Knowledge Base: How do I fix the SSL Mixed Content Error Message?
Adding this helped me to deal with the Mixed Content error on GitHub pages on a custom domain secured with enabled HTTPS:
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
Apparently for me. The website inside CNAME file in Github repo did NOT had https prefix. So I added https://. and it worked.
Cheers
P.S: Fixed this problem after 1 year, can you believe.
I noticed when accessing a site using HTTPS I get errors in the JS console when trying to include CSS or JS files from a relative path such as this:
<link rel="stylesheet" type="text/css" href="css/demo.css?id=14" />
Mixed Content: The page at 'https://mysiste.com/' was loaded over HTTPS, but requested an insecure stylesheet 'http://mysiste.com/css/demo.css?id=14'. This request has been blocked; the content must be served over HTTPS.
What's the ideal solution for this scenarios?
Should I just force all the HTTP accesses to be redirected to HTTPS?
Or is there a way to tell the server to serve all relative paths using HTTPS?
Relative links will use the protocol and host from the base URL. The base URL is usually the one which can be seen in the URL bar. But it is possible to change the base URL explicitly using the base tag.
This means if you have a base URL with http as protocol set in your page it will still use http instead of https even though you've accessed the site with https and the reference is relative, i.e. like this:
<base href="http://example.com/">
To fix it either remove the base tag or change it to use https instead of http:
<base href="https://example.com">
I want to use CSSs, JSs and images over https on http pages on apache.
How and what sould I configure for use the some link on HTTPS as well as HTTP like...
src='//www.site.com/_js/script.js'
And what is the right directory structure for this kind of use? Right now I'm using this...
/domain.com
/private_html
/js
/images
/css
/public_html
/index.html
On a page with the url of proto://host/some/file.ext, the following link src='/_js/script.js' will be processed by browser as if it was src='proto://host/_js/script.js'.
Let's say you have the following setup.
You have a server with the basepath set to the normal webroot.
The server has files in the following structure
/projects
/some-unique-id
/index.html
/images
/some-unique-id
/index.html
/images
Is it possible to have a .htaccess file somehow redirect the paths so if index.html has absolute paths they work.
For example if index.html contains /images/foo.gif can this magically become /projects/some-unique-id/images/foo.gif
The equivalent of the base html tag.
This is part of a CMS deliverable previewing system so I am restricted to not changing the HTML code.
Is there anyway to address this in an .htaccess file?
If each index.html contains <img src="/images/foo.gif"/>, the browser will request that URL and there will be no way for the server to know which page caused the request since the requests will be identical regardless of the originating page.
There is no way to do this with mod_rewrite unless you try to check the Referer header, which would be unreliable at best.
You will have to change your HTML markup to solve this. Using relative URLs seems like it would solve your problem.