Is custom CSS not allowed in Confluence Cloud?

[RobertP]

I don't see this option as listed in the help documentation.

[Mark Allen]

I'm raising a support ticket to ask how to change link colours in Confluence spaces that appear in service desk portals.

Guess the cutting support thing doesn't work entirely.

[Simeon Cheeseman]

It seems that in the current cloud you can put this into the footer code and it works.

{style}
  code {
    color: #c0341d;
  }
{style}

This is kinda hacky - I would very much prefer the unsupported macro warning to be on the footer input form in admin, not when it's rendered, but I can hide that for now and kinda understand why it's there.

FYI; I've omitted that code to hide the warning, if you know what you're doing you'll find it yourself - if you don't know enough to be able to do that I'd wager you're probably in the group that caused this feature to be disabled with support requests...

[Cristian Rosas [Tecnofor]]

Hi!

Using the footer to hide the sidebar doesn't work for me, but if it works for you I'm sure I did something wrong. Can you verify that it works?

[Simeon Cheeseman]

I can confirm that it does work, though if you do this any issues arising from it are going to be all your own fault and Atlassian support probably will be less helpful when they spot that. I would definitely not recommend you do this, hiding the sidebar will cause all sorts of pain for your users in addition to the above.

That said, I played around a bit and found the following;

It will depend on the particular template that you used to create the page - I noticed that new pages seemed to work but some older pages don't seem to have the Footer/Header rendering at all.

Recommend that you check with some text that your page template is rendering the Footer.

You also get a nice warning message if it's being rendered telling you exactly how much support you'll get if you do this.

[Richard Hodsdon]

Thanks for this!

So I suggest you add in this part too. It will hide the warning message you get.

I posted this into the Footer.

{style}
[class^='SpaceCustomSettingsBlockComponent_unsupportedMacros'] {
display: none;
}

code {
font-family: Monaco,Menlo,Consolas,"Courier New",monospace!important;
font-size: .75rem;
line-height: .75rem;
white-space: normal;
color: #e01e5a;
padding: 2px 3px 1px;
-webkit-font-variant-ligatures: none;
font-variant-ligatures: none;
tab-size: 4;
-moz-tab-size: 4;
-o-tab-size: 4;
-webkit-tab-size: 4;
background-color: #f7f7f9;
border: 1px solid #e1e1e8;
}
{style}

[Hsiang]

Hi @Richard Hodsdon

I tried you solution but I'm afraid it's not working.

[Simeon Cheeseman]

I actually omitted that part from my comment for the exact reason of not wanting people to ask about why it's not working (and I think an admin may have deleted my comment when I included the code)

It may be different in your case based on the page template and a whole load of other variables. I don't really recommend trying to hide the warning unless you are familiar with and are willing to figure out the CSS selectors on your own. It's not really something anyone can help you with - you'll have to figure it out yourself why it's not working (though stack overflow may help with figuring out the CSS/styling problems - also in chrome "Inspect Element" from the right click menu)

[Richard Hodsdon]

As Simeon above says, it could be different for an installation.

@Simeon Cheeseman I only saw your FYI after I had posted it :) But thank you for at least getting me in the right direction.

[Hsiang]

I was able to make it work. I think I was expecting it in the editing mode as well. My bad. Thanks!

[Benjamin Weinheimer-Erben (mgm-tp)]

It seems that CSS in the header/footer does not longer work in the new layout.

Does anyone have a solution for this instead adding the css-macro to every page?

[Philip Schlesinger]

Possibly: in talking with some managed hosting providers, one mentioned they would theme our site based upon this add-on -- which is compatible with Atlassian Confluence Cloud: https://marketplace.atlassian.com/plugins/com.refinedwiki.confluence.cloud.refinedtheme/cloud/overview

[Paul Stringer]

Kerching.... $$$

[Stephen Deutsch]

There is no official way to use custom CSS, but there is a workaround. As part of the Content Formatting Plugin (included in Confluence Cloud), you have the CSS macro. You can embed this in one particular page, or you can also include this for all pages in a space/instance by including it in the space/instance header/footer options in the following format:

{css}
//CSS code goes here
{css}

[Milo Test]

You can also add CSS to the Styles field of some macros instead of using the CSS macro.

[Philip Schlesinger]

Didn't work for me; I put the following in my header and footer and it apparently gets overridden by something in Confluence Cloud during page load; element.style goes back to #515151

{style}#title-text{color: red}{style}

[Philip Schlesinger]

{css} is no longer a valid macro in Confluence Cloud

[Stephen Deutsch]

If you want to change the title color, then the following should work on Confluence Cloud which hasn't been upgraded to the new style:

{style}#title-text a{color: red}{style}

If you've been upgraded to the new ADG3 style, first of all, header and footer text doesn't appear to be working (as of this moment) at all. Secondly, even if it was working, the content of the page is now displayed in an iframe, so the style macro will only affect page content and can no longer affect anything outside of the page content frame.

[Philip Schlesinger]

We must be using the new ADG3 style.

WHY ATLASSIAN WHY?????

LET MY CSS WORK!!!!

[Nic Brough -Adaptavist-]

Ask them how many support calls they've had that ended in "client has messed up".  Wouldn't you want to shut those down?

[Philip Schlesinger]

@Nic I would agree but they support site-wide and Space-wide stylesheets with self-hosted configurations.

[Nic Brough -Adaptavist-]

That's got nothing to do with supporting Cloud.  Different beast entirely.

[Brad Goss]

Now they get bombarded with support requests "How do i customize my site?". I will be opening a ticket to figure out how I can do some customization. I understand it may be a security thing, but they should then allow other ways to customize the site without using CSS... I don't see many options to change my formatting styles, so this is a half baked word processor. I want my documents to look pretty, because that means it will be easier to parse as a human trying to digest the document. Using the 'standard' styles just doesn't create enough contrast from section to section. Simply adding a horizontal rule to the H1 style is almost enough (obviously I want more control)... But I have to add the ruler to each H1 manually.. Kinda ridiculous, and IMO a requirement for any word processor to be able to style the document. I am still in trial, so likely will keep looking for another solution...

[Nic Brough -Adaptavist-]

Your instinct is correct - see https://confluence.atlassian.com/confcloud/restricted-functions-in-confluence-cloud-734070955.html for the list of things that are restricted on Confluence Cloud (custom css is buried in the middle)

[Paul Stringer]

Why are these things restricted ?

Is my money somehow worth less than a corporate blue-chip ?

[Nic Brough -Adaptavist-]

Most things that are restricted in Cloud are restricted because Atlassian support do not have the time, money or will to support it when a user gets it wrong.

A lot of the restrictions have been implemented based on the volume of support calls received that lead to lots of time chasing down configuration mistakes on server.  CSS was one of the more expensive ones.

If you find apps which do theming and allow CSS, that's fine for support, because Atlassian have low-cost routes to fix it - they turn off the app and if the problem goes away, it becomes the customer and app vendors problem, not theirs.

[Paul Stringer]

Then perhaps I should cancel my subscription entirely and seek an alternate online cloud solution.

Any content tool such as this should at the very least provide custom CSS support and configurable classes placed on elements.

Seems to me like the excuse of "excessive support" simply suggests that cloud solutions are not viable. You can't simply remove functionality because user's get confused. It just needs better documentation to allow the users to not get in a mess to start with.

[Nic Brough -Adaptavist-]

I'd point out that Confluene is a tool for collaboration, not being pretty.  Personally, I'd like a little more control over the look and feel, but if I'm going down to css level, I'm probably going too far.

When you have users who are confused and likely to make a mess that costs you time to fix for them, you have two options - charge them more so you can afford to fix their problems, or stop them doing making a mess somehow.  In this case, Atlassian chose the latter.

The problems they've burnt support time on in the past are because of the users who don't read the documentation or learn css properly.  It doesn't matter how wonderful your docs are if they're ignored.

[Paul Stringer]

"not being pretty"... ok... I give up... you win...

[BFN Astrydax]

Confluence is just an example of a company that cuts features to save money. If you feel you can find a product that suits your needs, and if you feel that confluence is missing core features that your money should cover; then stop giving confluence your money. It's your right as a consumer to vote with your buck.

[Nic Brough -Adaptavist-]

I'm afraid your statement about cutting features is completely wrong.  It's about support, as already discussed above.

Voting with your wallet - yup.  I'd challenge you to find a SAAS competitor to confluence that lets you break it and hence impose support costs at a similar or lower price though.

[jsobell]

I have to agree with Paul, that is a quite ridiculous statement.

Customising the appearance of a system does not open that system to being 'broken'. To deny that as a feature means people simply look for an alternative product, not an alternative hosting solution. My self-hosted Confluence allows me to customise the layout and styling, and that is supported by Atlassian.

Championing a product and justifying shortfalls with inappropriate excuses are not the same thing. For tech-support to not support user customisations is commonplace, and it's normal to instruct a customer to revert to the default 'style', and if an issue can't be demonstrated there then it's their own issue. Given that the self-hosted solution does support these features seems to invalidate this whole argument.

Confluence does let your solution look pretty, and it does it very nicely indeed! It's a fantastic editor environment, and we can add a new example or information snippet at any time online, whereas with something like Help'n'Manual we'd have to load up a Windows application, edit content, then generate output.

The issue we have is that while we have fantastic content, we have a dogs-dinner of a default presentation template, with a dreadful left banner area and a locked Confluence logo at the top. So instead of winding people up by suggesting they are somehow requesting inappropriate features, perhaps you could suggest solutions or workarounds?
The 'Instant Websites' plugin supports these features on the cloud platform, but it seems like extortion to make users pay $25/month simply to add custom CSS or change a layout on a $10 hosted site!
If they're not cutting features to save money, perhaps they're deliberately excluding them to force people to buy expensive addons and taking their percentage from the marketplace? It certainly appears to be one or the other.

[Nic Brough -Adaptavist-]

No, you've completely missed the point I'm afraid.

Let me rephrase it.  You look after a system that allows the user to break it.  Do you really want to spend time and money fixing it when they do?

[jsobell]

So, given that argument, why does the system allow me to embed hyperlinks? You could argue that allowing hyperlinks can cause people to "break the system". Is this because you think any attempt Atlassian made to allow custom styles would be riddled with security loopholes?

Just assume I'm ignorant with regards to some basic feature of css styling... can you explain to me exactly which aspect of allowing custom css on my Space would break Atlassian's Confluence system on the cloud based platform?

Also, if it's likely to break the system, how do I prevent the same thing happening on my self-hosted deployment?

[Simeon Cheeseman]

From my point of view I'd imagine something like the following happens a fair bit;

1. Admin A gets a request to hide the Sidebar for some users and so does it with custom CSS. (There's a guy further down the thread that actually has asked this)
2. Less technically able Admin B gets a complaint from other users that the sidebar has vanished and hasn't been informed/talked to Admin A.
3. Admin B logs a support ticket with Atlassian about their broken system...

Assuming the above holds true (I could have a bad assumption here). If you have a self-hosted system it makes sense that any problems with the system would go through Admin A (or whoever the tech support team is) so they would be aware of this kind of changes or how to figure it out. In this case, the first line of troubleshooting/support isn't Atlassian for self-hosted deployments so more customization is OK (This is just my assumption though, I'm only a cloud user).

In the cloud system, you just go straight to Atlassian support when you have a problem, so preventing the above kind of scenario when you have a lot of users makes sense.

[Cristian Rosas [Tecnofor]]

In this case I'm against Atlassian decisition.

Confluence is a tool that NEEDs customization. Put warnings in every colour and size you want telling the user that if he enables customization he will lose support and make it clear that is only for advanced users.

Use case:

Recieves an incident? First, disable customization. It works now? Then we don't support your problem. Hire a better developer

[Nic Brough -Adaptavist-]

Or, better, stop them doing it, so you never have to field any support.

>You could argue that allowing hyperlinks can cause people to "break the system".

How?  You could link to a bad thing, but that would be outside the system you're supporting, so you don't care.

>Is this because you think any attempt Atlassian made to allow custom styles would be riddled with security loopholes?

More usability than security.

>Just assume I'm ignorant with regards to some basic feature of css styling... can you explain to me exactly which aspect of allowing custom css on my Space would break Atlassian's Confluence system on the cloud based platform?

>Also, if it's likely to break the system, how do I prevent the same thing happening on my self-hosted deployment?

I've spent weeks having to remove css that hid things, re-rendered things incorrectly and then needed to be updated because Confluence changed.  It can be a nightmare for an admin, but that's what I was paid for at the time, and it was part of the job.   There's nothing to stop you getting it wrong on server, but you're choosing to support it yourself.  Atlassian's choice for Cloud is "prevent the problem completely, so we don't have to support users who break it". 

Note the point about upgrade too - Confluence on Cloud can be changed week to week (although it's usually more like 3-6 weeks), and do you really want to have to handle a swathe of support calls because someone has done something that breaks because of your deployment every 6 weeks?  Not at the price Atlassian sell Cloud systems for.

This is not about allowing customisations or forcing people to get add-ons.  It's about not having to support other people breaking stuff.  If you don't want someone to shoot themselves in the foot and then cost you for the medical help, then it is easier and cheaper to not give them the gun in the first place.

[jsobell]

Wow, given this type of justification it's amazing users are allowed to type their own content at all, rather than restricting content to selection from a predefined list of phrases!

Seriously though, Confluence Cloud is possibly the only web based service I've ever used that refuses to allow custom CSS. It's such a weird argument to suggest that every other web based system out there suffers under a deluge of profit destroying (or even effecting) support calls related to an unexpected piece of CSS.

I think you need to climb down and view things from a more realistic perspective. Confluence is the tail, not the dog. I'd like to hear from Atlassian themselves the reason these unique Atlassian restrictions exist, and I don't believe they have anything to do with the reason you mention.

Oh, and we have licenses for Confluence with support agreements, and we run on EC2 instances. I can edit the templates and the CSS, as can my staff, and if one of us accidentally added a `display: none` to an element I can contact support and ask them to help me. Is this in some way different to the Cloud hosted situation?

[Ben Bohn]

@Nic Brough -Adaptavist- This is is a complete cop-out. While CSS does have the power to break the user's portion of the site, it can be easily negated with an option to switch views to the default CSS at any time. This allows the users to help themselves rather than rely on support (which most of us would prefer anyhow).

As someone who has worked on SaaS platforms for several companies, I know there are probably 100 different ways to make this work for clients while minimizing the risks to Atlassian. Unfortunately, this is a systemic problem with Atlassian in general believing it knows better than its users, and as better products come along the market will shift towards those products.

In the last few years I've run into a number of Jira and Confluence bugs and feature requests for relatively basic functionality that Atlassian has either ignored or attempted to excuse (poorly) such as this one. As usual, in the end the users are left to find hacks and workarounds.

Add me to the list of people voting with their wallet. I will no longer recommend Atlassian products (with the exception of OpsGenie, if you manage to not screw that up too bad), and will instead work to find solutions for my clients and businesses that have a track record of fixing issues instead of arguing why they aren't issues.

[Matt Grist]

I'm going to support Nick here. If you want a system you can customise then fine, use Confluence server. If you want a cloud solution where you don't have the hassle of supporting it then this is the trade-off.

Yes, it's unfortunate that that people who know what they're doing (like the people on this thread, presumably) have to suffer because of people who don't know what they're doing. But these people exist and you can't make them go away. It's one system for everybody. That's what the cloud is.

[jsobell]

This implies people only want a cloud based system because they are unskilled and want a reduced feature product.

People want cloud based solution to avoid the cost and complexity of setting up a dedicated server. They also do so to ensure all security updates are auto-rolled-out by Atlassian, suggesting that forcing people to run a server version is actually reducing security as they are very unlikely to always be up to date.

As @Ben Bohn says, that is a complete cop-out of a reason. Forcing users to implement CSS is very different to preventing them completely, and to suggest that enabling CSS customisation is a security risk or introduces bugs is just plain ridiculous.

You're also missing the point in that customisation is possible, but for a cost. It's like "pay to win" games, but in this case it's "pay us to remove our crippling restrictions". Or are you suggesting Atlassian will refuse to sell those modules to "unskilled" users?

I'd suggest you not bother trying to defend the position, as the arguments given are just bizarrely irrelevant. If someone posts a valid argument I'd be very interested to hear it and might change my point of view, but other than a way of fleecing customers for a basic feature, I'm lost for any other logical explanation.

[Matt Grist]

You've had a valid argument. You've just chosen to ignore it.

[Nic Brough -Adaptavist-]

You won't be surprised to hear I agree with Matt - you're arguing the wrong point.  I was not "copping out" I was simply repeating the point made several times before that you are still ignoring. 

If you could argue that point, that would be a useful conversation, but I suspect you are ignoring it because you actually can't, because it's broadly right.

[Mark Allen]

I broadly agree, but would say that this requirement would unlikely be needed if there were basic customisation options available - such as colours and typography.

I suspect those are the main things people want to edit most of the time and can be controlled with options/settings. If that's covered, then deeper customisation can be argued as the realm of own-hosted systems.

As it stands, I want to change very basic attributes, that are incredibly unlikely to ever break anything, ever, but can't. - And no, I don't want to edit them in place everywhere, that's far to much effort and maintenance to be practical.

[Роман Копаев]

The question for CSS might not have arisen at all if Atlassian had bothered to hire normal designers who understand that the text should be indented, and the titles should be clearly distinguishable from each other. But no ... The design was done by a schoolboy who just learned what HTML is...