Different behavior for CSS with gitpages on github.com vs. an enterprise github server

[MartinSteffen]

Select Topic Area

Question

Body

Hi,

I have a probably very simplistic question (and I am not sure if it's the
right forum here anyway, apologies in advance if not...)

Now, I am using github/gitpages in combination with Jekyll, and it's all
fine. My setup is that I simply a "bundle exec jekyll build ...." copying
the generated files to the repos and the commit them. Recently, I tried to
set-up a new page, and ran into a problem.

Resp. I ran into a problem if I have it hosted at a specific
github/gitpages server.

More precisely: If I commit the generated pages at github.com (resp. the
gitpages there), it's fine. If I use the local enterprise github server
instead, it's not.

Now I could just put the pages to github.com, and the problem would be
solved. Unfortunately, I have no choice in the issue, I need to use the
local github enterprise server, and I have no influence on the
configuration there (and limited assistence with issues I have).

So, I poked into the problem myself. First I suspected that perhaps
Jekyll's generated setup uses advanced features, not covered by the
enterprise github server. Seems that this is not the root course.

I was able to pinpoint it to something quite simple. It's the way cascading
style sheets are referenced (maybe there will be more problems down the
road, but the very simple CSS-thing is what prevents the pages from being
rendered properly).

The generated index.html at the ``root'' of the directory structure for the
web-page contains a line

<link rel="stylesheet" href="/assets/css/main.css"> (***)

and sure enough, there's a file ./assets/css/main.ccs that contains some
style sheet specifications. It turns out that this works fine on
github.com. It also works fine when I want to check the result of my page
design locally under http://127.0.0.1:4000/, i.e., outside from
github/gitpages (jekyll supports that, doing something like

bundle exec jekyll serve -d   ./../../localwebpage/

But: the very same thing does NOT work on the
github.-server. The index.html itself is accessible and
surfable after committing, so the content in the body of the index.html is
there, but the style file is not used or referenced. If I do instead of
line (***) from above the line

<link rel="stylesheet" href="assets/css/main.css">

i.e., without the leading "/", then the css-file is referenced and the page
rendered properly also at the enterprise server.

While I was able to pinpoint it to that line, where it seems the enterprise
server is less tolerant wrt. the leading "/", I don't know what to make out
of it.

I don't know enough html/css etc to know whether (***) should be allowed
according to some standard. If so, I could come back with that info the the
administrators of that enterprise server hoping that they accept that as a
problem and address it. Or whether the server can be configured either to
tolerate it or not. Or whether I can customize my own github-pages settings
(absolute paths tolerated: yes/no?)

I tried also the find out if I can tweak or customize in my own jekyll
setting (resp. the setting of the jekyll theme I use, which is minimal
mistakes) hopefully without touching any source code , so that the
index.html and other files are generated without leading "/" and thus
accepted.

Anyway, any hint is welcome, why the github-server is more tolerant than an
enterprise server (version 3.6), and whether it can be repaired by doing a
different customization github (either by the administrators or by me as
user).

Thanks, Martin

[nvspavankalyanch]

Hi Martin,

It seems like you're running into some trouble trying to host your web pages on an enterprise GitHub server. The issue seems to be with how the server is handling the reference to your CSS file in your index.html. You've noticed that this reference works fine when you're building and serving the pages locally or on the public GitHub server, but not on the enterprise server.

To resolve the issue, you can try the following steps:

• Modify the CSS file reference in your index.html by removing the leading "/" from the "href" attribute. This should allow the pages to be rendered correctly on the enterprise server.

• Check your Jekyll or GitHub Pages configuration for any settings related to absolute paths. You may be able to tweak these settings to allow the pages to work correctly on the enterprise server.

• Reach out to the server administrators of the enterprise GitHub server for assistance. They may be able to help you understand the problem better and provide a solution.

• If you are using a theme, check if the theme itself has any setting or configuration that may be causing this.

• Another possible solution is to use a plugin like jekyll-relative-links, it will convert all the relative links in your site to be relative to the root of your site, this should work with the enterprise github server.

Note: It's worth noting that, if none of the above steps work, you may have to consider a different hosting solution or work with the enterprise server administrators to find a solution that works for you.

I hope this reply helps you to resolve your issue.

[MartinSteffen]

>>>> "N" == N V S Pavan Kalyan ***@***.***> writes:

N> Hi Martin, N> It seems like you're running into some trouble trying to host N> your web pages on an enterprise GitHub server. The issue seems to yes, indeed. N> be with how the server is handling the reference to your CSS file N> in your index.html. You've noticed that this reference works fine N> when you're building and serving the pages locally or on the N> public GitHub server, but not on the enterprise server. N> To resolve the issue, you can try the following steps: N> * Modify the CSS file reference in your index.html by removing N> the leading "/" from the "href" attribute. This should allow the N> pages to be rendered correctly on the enterprise server. That's true. However, it's a brittle solution. Indeed, the webpage contains many html-file etc. By focusing on one file, the top-level index.html and narrowing down the longish content to some barebones lines, it became clear that removing / for the reference to the main.css file get's me one step further. I fear that there's multiple other instance of the same or a similar problem throughout the pages. And each time I would regenerate the pages from the markdown sources, I would have to repair it new. I could write a script (once I have an overview, how many instances of the problem are contained in the pages), but also that sounds brittle. N> * Check your Jekyll or GitHub Pages configuration for any N> settings related to absolute paths. You may be able to tweak N> these settings to allow the pages to work correctly on the N> enterprise server. Ok, I check again. N> * Reach out to the server administrators of the enterprise GitHub N> server for assistance. They may be able to help you understand N> the problem better and provide a solution. I asked the people administering the server but got no help N> * If you are using a theme, check if the theme itself has any N> setting or configuration that may be causing this. I guess so. I asked also around in the forum for that theme, if there's something, but I still wait if someone knows anything. The theme is complex and has loads of things to tweak (minimal-mistakes), but I have found no silver bullet there either. N> * Another possible solution is to use a plugin like N> jekyll-relative-links, it will convert all the relative links in N> your site to be relative to the root of your site, this should N> work with the enterprise github server. I tried that one, thanks. It may work for specs like ``permalink: /path'', but it seems not to affect the href to the cascading style sheet. Even with the relative path plugin, the offending line reads <link rel="stylesheet" href="/assets/css/main.css"> N> Note: It's worth noting that, if none of the above steps work, N> you may have to consider a different hosting solution or work N> with the enterprise server administrators to find a solution that N> works for you. I might do that (though I guess my organization will insist on their local enterprise server). Thanks, Martin