Page MenuHomePhabricator

Provide custom themes, skinning, or custom CSS
Open, WishlistPublic

Assigned To
Authored By
Dec 7 2013, 5:14 PM
Referenced Files
F887640: symbiants.com_2015-10-17_21-53-11.png
Oct 17 2015, 6:54 PM
F887605: symbiants.com_2015-10-17_21-35-16.png
Oct 17 2015, 6:41 PM
F88001: Screen_Shot_2013-12-07_at_8.25.08_AM.png
Jun 18 2015, 8:22 PM
F88003: Screen_Shot_2013-12-07_at_8.25.55_AM.png
Jun 18 2015, 8:22 PM
F88002: Screen_Shot_2013-12-07_at_8.25.31_AM.png
Jun 18 2015, 8:22 PM
"Love" token, awarded by ideasman42."Love" token, awarded by tomekj2ee."Like" token, awarded by oysterFAKE.


General discussion of themes, skins, and other customization.

Phabricator has very limited support for customizing themes / skins. Broadly, there are two separate technical approaches here, and our thinking differs on them:

  1. Custom Themes: One approach is to provide support for user-defined custom themes, where, e.g., users write CSS and have full control over how Phabricator looks.
  2. Prebuilt Themes / Non-CSS Customization: Another approach is for us to prebuild specific themes, which you can select in the UI. These would not be user-defined.

Custom Themes

It is unlikely that we provide any support for writing custom CSS for a very long time, and may not ever formally support it. The major reason behind this is that Phabricator's UI changes very quickly. Here are some screenshots from about a little more than a year ago:

Screen_Shot_2013-12-07_at_8.25.08_AM.png (360×648 px, 147 KB)

Screen_Shot_2013-12-07_at_8.25.31_AM.png (359×648 px, 134 KB)

Screen_Shot_2013-12-07_at_8.25.55_AM.png (359×652 px, 161 KB)

Although much of the basic layout hasn't changed, almost every UI element has. The changes beneath the skin (to the CSS and HTML) have usually been more dramatic than the surface-level changes, to support things like responsive design and UI standardization.

If we'd had theming support a year ago, everyone who had written custom CSS would have had their theme completely broken multiple times. If we provided support today, everyone's themes would almost certainly break a dozen times in the next year. There's no way we can avoid this while still moving the software forward as quickly as we do: providing custom CSS support basically makes all of our CSS and HTML a public-facing API, but an API which is highly unstable, has huge surface area, and is impossible to document or version effectively.

Prebuilt Themes

We can provide prebuilt themes, or let users customize the UI by setting options instead of writing arbitrary CSS, without creating these hazards. However:

  • Many requests for theming support are motivated by wanting custom themes ("I want Phabricator to look like my company's other tools"), which is especially not well supported by pre-built themes.
  • The primary use case for pre-built themes that we've received requests for is differentiating between multiple installs (e.g., production and development), not changing aesthetics.

Overall, the value of prebuilt themes is unclear. They also create some ongoing costs: if an element supports themes and needs to be updated, every theme needs to be updated too, or at least tested. This adds another variable to the test matrix for UI elements (which are already variant across browsers, and across devices).

The Way Forward

We are unlikely to provide custom themes any time soon (e.g., very unlikely in 2014, still quite unlikely in 2015). If you want fully custom themes, your best bet is to maintain local patches on top of Phabricator which change the CSS. This will be a hassle (if they're extensive, your themes will break, frequently), but whatever pain you encounter is a million times less than the pain we're avoiding by not supporting these, and we can use that time and effort to build applications and features instead. Some installs, like Blender, maintain local patches today and seem successful. Many other tools in this space, like Atlassian's suite and GitHub Enterprise, do not appear to offer significant support for fully custom theme development. Presumably, they've arrived at the same conclusions we have about the cost/value tradeoff of supporting this.

We provide limited support for prebuilt themes and other option-based customization, starting with custom header colors in D7731. We may expand this over time, but are more likely to provide minor options (e.g., changing or adding a custom brand logo) than more extensive changes (e.g., "wood theme" to make everything look like it's made out of wood).

Event Timeline

epriestley raised the priority of this task from to Wishlist.
epriestley updated the task description. (Show Details)
epriestley added a project: Design.
epriestley added subscribers: epriestley, chad, btrahan.

After T4222, it's possible (but very complicated) to add CSS without writing local patches, by putting assets in a separate library and then getting them included through events or subclassing.

It's also much easier for us to provide a custom/ resources directory which can build into a map without conflicts.

Could the images be updated to reflect the recent changes to phabricator. since it looks much modern then that.

@paladox, please read the description carefully. The images are helping support the main point of the section, which is that Phabricator changes very quickly. Having old images which are very different from the modern UI helps reinforce this point.

i've tried to change config->user interface, but all i got there is a ui.header-color
and in fact a white background for all texts is a disaster.

is there a way to switch it to some kind of emacs - solarized theme?
i think it's not so hard to define #main_text #main_background, but al i see in css.mess is a lot of background-color:fff - so it's a no-go

in fact a white background for all texts is a disaster.

Can you give more details on your accessibility needs?

We have no plans to support an "inverted" theme given the great cost and near zero benefit. However there are high contrast and font accessibility options in your settings. We may offer a "dark diff" option, but no one has requested yet.

symbiants.com_2015-10-17_21-35-16.png (921×1 px, 92 KB)

just adding in core.pkgs.css gives me this image - it's not what i want, but it's not white
what i need - is a change main preview (current settings on ths img) background not those of menus and buttons

+background : #363737;
+color : #fff

the better look

symbiants.com_2015-10-17_21-53-11.png (465×1 px, 47 KB)

.phui-object-box .phui-object-item-list-view .phui-object-item{
color: white;
background : #363737

Well a dark theme seems to require much more effort than this and be painless to support.
However I think after @epriestley works on high contrast theme, you can do the same as extension., if you want to code it.

Basically you can take exemple from /src/applications/celerity/postprocessor/CelerityHighContrastPostprocessor.php

There is no simple or easy means to supporting or building an inverse theme without some sort of more full featured CSS post processor. We just rely heavily on white and rgba for layering and swapping these colors over would require lots of testing and time to support. The upstream doesn't have any interest in solving these problems. At the end of the day, there will always be more impactful things to build into Phabricator.

i see that there are some kind of expressions


so maybe just add some expression for $def-bg-color and $def-font-color instead of #fff and #000?

so maybe just add some expression for $def-bg-color and $def-font-color instead of #fff and #000?

Like I mentioned above, there is no simple solution or "free" solutions here. The upstream isn't going to support this out of the box. You're welcome to maintain a fork or patch if these features are important to you. T8227 also explains our general feelings on providing "options" in general.

thank you for pointing to
i've added a new variable $itembg in
CelerityHighContrastPostprocessor.php and CelerityDefaultPostprocessor.php

then in few .css replaced #fff with {$itembg} now it should be changed, when i switch between highcontrast and default
but it's not, now i got grey background, but cannot swith to white

i've purged cache + phd restart + nginx restart + php5-fpm restart + browser clear cache - it's still not changing back

  1. what i want to ask is how to properly reload .css engine and clear variables
  2. also how to add another CelerityDarkPostprocessor.php in DisplayPreferences->Accessibillity submenu?

UPD: 2 - cloned one of posprocessor.php, changing values, adding to /src/_phutil_library_map_.php - got a menu entry can change layouts


It seems to me that exposing a few classes for regular html colors, and a config form for editing them would not be such a killer big deal.
Form -> Header Color #______
Phabricator CSS -> .header_color { color: YOURCOLORFROMFORM};

And it is customarily simple to allow logo uploads as well.

I think those 2 alone would be good enough for 80% of the people 80% of the time.


Otherwise, just started with Phabricator. Impressive. My compliments.

It seems to me that exposing a few classes for regular html colors, and a config form for editing them would not be such a killer big deal.

You can subclass CelerityPostprocessor and do whatever you like locally. We already provide a few for accessibility.

Specifically CelerityPostprocessor will let you globally change probably 99% of colors, backgrounds, and fonts. Then your local users can either select the built in default or the optional one you just built.

Hopefully I can use this to repair the broken icons while still blocking foreign font files. At first I thought I had to create a custom mapping from CSS class names to Unicode characters, or even icon sprites in cases where I can't find a nice Unicode character for the meaning.

Turns out I can just change the font to "font-family: FontAwes0me" in the DOM browser, or (later in my install) extend the "@font-face" declaration to include my trusted local copy of the "FontAwesome" font when the blocked one isn't available.

We only serve a local trusted copy, is that your main concern?

My concern is that I can't tell Firefox which fonts from which sites with which checksums it shall trust, so I block all of them and rely on my locally installed fonts.

When you think of it, it's also a waste of bandwidth to even transfer FontAwesome when I have a working copy in my system's fonts folder.

It's a one time cost, and cheaper than a sprite, is it not?

Overall, we include all fonts locally, which are trusted. We also actively participate in HackerOne, a security bounty program.

But if you can easily work around, great!

It would be cool if in Phabricator will be implemented a Pre-Build Dark theme.