Feature request - add an easily modifiable "custom.css" to gitlab for those few cases where admin needs/wants to override a tiny part of the system

I just googled and this issue turned up, hehe. I'd really like to add custom CSS. IMHO the 1280px width is much to wide, looks bad and destroys the reading flow with such long lines of text (eg in README's or the Wiki). I'd much prefer a width of 900-1050px. That would be easily implemented with a custom CSS!

This would be hugely useful.

In fact, a simple:

custom.css
custom.js

That get loaded at the end of everything (and persisted between updates) would give 99% of the flexibility anyone needs to patch small issues with GitLab. Those patches, of course, can then be submitted to the main project for the core GitLab team to review/implement properly. (So this should help with contributions also by making it very convenient for a far greater number of people to hack on GitLab.)

For example, right now our iOS app’s ‘edit in Gitlab’ feature is broken (see https://gitlab.com/gitlab-org/gitlab-ce/issues/19226) ever since the Edit pages were recently changed to return 404 instead of forwarding to the sign in page (even for public projects). I could fix this with one line of CSS that unhides the Edit button on the File page – thereby giving people a way to sign in or edit the page but I don’t see how I can at the moment instead of forking GitLab (a very heavy solution that will hurt our ability to use the convenient omnibus updates.)

Added feature proposal label

Added frontend label

cc/ @jschatz1 @JobV

Thanks, @kelvinmutuma – hope you’re doing well, man. Have you had a chance to check out Better (https://better.fyi) and how we’re using GitLab? (See source: https://source.ind.ie/better). Need to find time to properly to chat to you guys about it ;)

This issue is related to #15661 (moved).

FWIW, Gitlab already has vendor/assets tree, but it's not included in the assets collection, so running rake assets:recompile skips it. I guess taking this tree into account would solve this issue in a very light manner.

Similarly the doc indicates that application/assets/pages can be used, but it suffers from the same flaw as vendor/assets. IMO better utilize vendor/assets.

We're unlikely to do this, as we prefer people to make contributions directly to GitLab that benefit everyone.

In addition, we want GitLab to be a stable environment, independent of where you use it. Customization would potentially make GitLab work in unpredictable ways, which can be confusing for users.

For instance, hiding parts of the interface, as @aral suggests, means that:

GitLab doesn't work as it's supposed to
Users using your instance get a bad experience using GitLab
You have to update your customizations with every new update of GitLab
You'd be less inclined to update, because of 3. GitLab ships fast and we expect and want to encourage people to always update to the latest version. We don't do security updates for more than 3-4 releases back, for instance.

@JobV I'm sorry to tell you you're being very short-sighted. Allowing people to customize their instance doesn't prevent them from sharing what they did. You're being patronizing and I really don't like it.

Customization would potentially make GitLab work in unpredictable ways, which can be confusing for users.

First, we're talking about stylesheets mostly, and most people here want to differentiate their instance of Gitlab with the instance of Gitlab.com, which is not the case now and already confuses the users. I'm not so much interested in discussing Aral's specific solution as to find a generic solution that satisfies everybody.

Second, this is not your call to make, but the users' call. And in this case, the "users" are system administrators and projects using your product to serve their own communities. It's not your call to decide what's best for them, because you simply don't know that.

I urge you and Gitlab team to reconsider your position and actually listen to what people have to say about a product they love and use everyday, instead of thinking for us.

Let's see each point individually:

GitLab doesn't work as it's supposed to

Indeed, it doesn't. Otherwise this discussion wouldn't happen.

Users using your instance get a bad experience using GitLab

They indeed complain about not being able to differentiate one Gitlab instance from another.

You have to update your customizations with every new update of GitLab

Why would that be? If Gitlab knows what to do, it can pick customization anywhere. Current situation is that with every single update, I have to go into the precompiled assets and hack them to restore my preferences. Custom parts are not affected by stock parts, in that stock parts ignore custom parts, leaving them in place, untouched.

You'd be less inclined to update, because of 3.

This is ridiculous. If Gitlab works as expected, updating cutomization will be a piece of cake. What you're talking about is a complete revamp of the interface that would bring conflicts with each upgrade. What we're talking about is a space for sysadmins to make enough difference for users to know where they are.

Nevertheless, if someone wants to revamp the GUI entirely, and take the time to patch the changes with every upgrade, it's their call, not yours. If you want your software to remain identical with each instance, you can forbid people from making changes and produce proprietary software. But you're not, are you? So well, you should let people choose for themselves.

@hellekin

You're being patronizing and I really don't like it.

I didn't mean to sound patronizing and am sorry I gave that impression.

There is a difference between differentiating GitLab instances and customizing the experience. I welcome suggestions that would make it easier to differentiate GitLab instances, such as the ability to color the side navigation right now.

What we're afraid of is that people customize GitLab in order to achieve a different type of functionality, workflow or experience. GitLab is made for everyone and we hope that rather than individual customizations, people work together to create a single experience that works for everyone.

With the rate of change and our speed, we can't guarantee stability of our styles, assets or other user-facing components. This means that your changes will certainly be undone with each new release, if not a part of them.

What we're talking about is a space for sysadmins to make enough difference for users to know where they are.

And that's acceptable and welcome. Custom stylesheets are not the way to do this though, as they open up to problems as described above. We welcome feature proposal that would make this easier and better.

Nevertheless, if someone wants to revamp the GUI entirely, and take the time to patch the changes with every upgrade, it's their call, not yours. If you want your software to remain identical with each instance, you can forbid people from making changes and produce proprietary software. But you're not, are you? So well, you should let people choose for themselves.

We want GitLab to be a great, stable experience for everyone. We can only guarantee that if we reduce the amount of configuration and therefore complexity to a certain degree.

That said, you're free to modify GitLab in any way that you like, it's just that we don't want to encourage you to do things that we believe are not beneficial to your users in the long run.

Of course, we're always willing to discuss these things further and no decision is final.

@JobV, thank you for your reply.

Why is there vendor/assets if it's not to use it?

Loading it into the pre-compilable assets pipe would work a long way to a satisfying solution. After all, it's Cascading Stylesheets.

@hellekin @JobV I’d love to keep my own build of the omnibus edition going. I just can’t afford to hire someone to do that as a full time job while Laura and I do what we do :)

So that’s the main reason. Today, in a two-person social enterprise, I maintain three GitLab instances (one for https://source.ind.ie an the other two are used by Better as part of the app itself – the Better iOS app actually gets data via Git from a GitLab instance and its content is – sorry, was – editable via GitLab from straight in the app; which is – sorry, was – a great feature).

I keep saying was because, due to the 404 errors on Edit pages combined with the fact that the Edit button is hidden at narrow viewports, means that the Edit interface is currently broken on narrow viewports (e.g., on an iPhone). If I had the ability to inject custom CSS, I could unhide the Edit button and our app would have the ability to edit pages. This would have meant a five minute hotfix.

Instead, I’ve had to remove the Edit functionality from the app and replace it with a View Source and submit a new app for App Store approval to Apple.

In time, if the web interface is fixed so that Editing files works on narrow viewports, we might reintroduce it.

I just want you to understand why we’re asking for this.

With this feature, we can fix small things quickly.

Without it, we either have to maintain a fork, and dive full-time into GitLab development just to use GitLab or wait X amount of time.

I would highly urge you to reconsider your stand on this.

@aral Thanks for the detailed explanation.

Can we please have this? Here is why I want custom.js:

I am writing a small custom programming language for which I'm hosting the tools and docs on a gitlab instance. I just need some quick way to inject some basic syntax highlighting, a purely cosmetic thing.

The alternative of adding something to Rouge is a suboptimal solution for me for various reasons, e.g.:

My language is a super experimental, super tiny and possibly incompetently written freetime fun project of mine and nobody wants a highlighter for this in upstream gitlab/rouge right now, trust me ;-)
I already have a lexer in JS
Rouge lexers are written in rather idiomatic and hard-to-read Ruby (unlike e.g. the coderay highlighter written in Ruby) so I would likely need someone else to assist me, and changing it would be a lot of effort which is bad for an evolving super-experimental language project
It is harder to find out how to inject a lexer file into the omnibus container somewhere into the Rouge library in the correct place, instead of just supplying a simple custom.js through the gitlab admin frontend which does the job.

If my project ever becomes more popular and less experimental I would be the first to assist with adding it to Rouge/Gitlab permanently and properly. However, right now this is just my hacky freetime experimental thing, and let's be honest nobody would want the highlighting file in gitlab upstream for some hacky freetime project that dies tomorrow and is written by a possibly incompetent language designer :-) it's really just a freetime fun project of mine at this point.

Therefore, some simple custom.js code that inserts the highlighting dynamically in the page seems like a much more reasonable approach for my use case right now and having this possibility would really help me a lot.

You are right, people will do bad stuff with this custom.js / custom.css feature. However, I hope you see that for some very specific rare corner cases which nobody else needs this could be a huge life saver for some people! Therefore, please add a simple way to add in a custom.js and custom.css file on all pages served by gitlab.

@JobV: Here is so much to your "we want to be consistent" argument: #19619 (closed)

I, your paying user, want my UI consistent over time. Before the release 8.9 you had me prefer scrollable code display. With 8.9 you had me now consistently prefer non-scrollable display. Our tickets are not readable anymore. But the UI is freaking consistent with other installations that I do not know, care or will ever hear about in my life. I do not care about synchronic consistency, and you do (for the reason of ease of support I think). I care about diachronic consistency, so what we entered into the system yesterday does not break today, but, putting that mildly, I do not see that you guys give it a least though.

Now, I could fix that with a 1-line custom CSS. Except that you explicitly do not want me to have the control, and messing with assets is too tedious.

I think your list of reasons is not simply patronizing, it is in a sense, hypocritical. The rate of change of user experience with GitLab is so great, that I am thinking of rolling back to 8.7 and freezing it for a year. My users cry for my blood already over the new mobile-style disappearing menu on desktops, thanks a lot for telling them what they consistently wanted. What consistency we are talking about here?

Sorry, the string of latest unwelcome UX changes had me venting. To the point of this ticket: wordpress allows custom CSS (aside from scheme). Wikipedia allows every registered user to have their custom CSS, with separate control per freaking skin. Crap, even thundering LiveJournal had (or has, if it's still around) custom CSS! What's wrong with giving us your users even a little bit of control over colors, layout etc.?

EDIT: After a little bit of cooling off, taking out “offensive,” because it is not, sorry. Had a bad day, and GitLab indeed contributed to it.

mentioned in issue #19619 (closed)

I love the new issue boards, but the horizontal scrolling happening as soon as you hit 4 lists (columns) was driving me crazy. I wanted something universal instead of having to add browser user scripts.

Since we are running Gitlab in a container, we were able to accomplish this by having Nginx running in another container and proxy it for us with the configuration:

server {
  # catch all setup
  listen       80 default_server;
  server_name  _;

  # if /custom/ is requested then we root at /etc/nginx/custom/
  location /custom/ {
    root /etc/nginx;
  }

  # everything besides /custom/ is caught here
  location / {
    # substitute just HTML items
    sub_filter_types text/html;
    # replace the closing <head> tag with our custom CSS and JS
    sub_filter '</head>' '\n<link rel="stylesheet" media="all" href="/custom/custom.css" />\n<script src="/custom/custom.js"></script>\n</head>';

    # proxy all requests to the host `gitlab` this might be the only thing that needs to be customize in other setups
    proxy_pass http://gitlab;
    # set the Host: header exactly how it was called
    proxy_set_header Host $host;
    # don't let gitlab serve Nginx compressed (gzip/etc) since it won't be replaced above since the mime type won't match
    proxy_set_header Accept-Encoding "";
  }
}

Being able to add a custom.css for the wiki pages would be great. Is this already doable in gitlab EE?

While it's a bit tangent to the current discussion, I'd like to throw in that I find the dynamic UI, where buttons and other elements get added and removed depending on how large the window is, extraordinarily annoying. Many times I look at the screen, wonder what happened to a UI element, and don't remember that it's not visible only because the screen is too narrow - for example, in the issues tab, the available filter dropdown menus come and go with how wide the window is. Other times I widen a browser window and find that doing so narrowed the relevant content, frex when widening the project wiki page causes it to inject a 370 px. wide, useless file browser / "clone repository" sidebar.

I'm getting to the point that I'll have to use some browser extension like Tampermonkey or Stylish to clobber on the CSS and scripts until I get a stable UI. I doubt that's going to influence the UI designers to do anything different but do be aware that I, and a number of other people in my organization I've talked to, have a very low opinion of this approach to UI. I'd prefer ugly but fully functional to pretty and not exposing needed functionality (though of course I'd prefer pretty and fully functional to either).

@JobV I understand you concerns about the consistent UI. But could a compromise be found for the css of wiki pages? It will not change the gitlab UI and it will allow to customize the reading experience of the wiki.

Since the wiki is contained in the .wiki class you can make sure that the custom css will only apply within the wiki scope. For example using scss you could do the following:

.wiki { 
   @import "wiki_custom.scss";
}

added ~874211 label

Any progress here?

mentioned in issue #29835 (closed)

I have approached the problem differently. It's possible to inject your custom JS via Nginx directly. FYI I'm using an unbundled Nginx with GitLab CE Omnibus.

I actually like this as I'm not messing around with the GitLab files directly.

This works for me quite well, I don't see why this wouldn't work for CSS files, same kind of idea.

http://stackoverflow.com/questions/19700871/how-to-inject-custom-content-via-nginx

location / {
    sub_filter </head>
        '</head><script language="javascript" src="$script"></script>';
    sub_filter_once on;
}

EDIT: Just realised Kenn Herman suggested this a while back, sorry everyone!

mentioned in issue #18364 (closed)

marked this issue as related to #34645 (closed)

mentioned in issue #34645 (closed)

moved to gitlab#4763

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue

Feature request - add an easily modifiable "custom.css" to gitlab for those few cases where admin needs/wants to override a tiny part of the system

Designs

Child items ...

Activity

Frequently Asked Questions

Admin message

Admin message

Feature request - add an easily modifiable "custom.css" to gitlab for those few cases where admin needs/wants to override a tiny part of the system

Relates to

Activity

Frequently Asked Questions