Changing a LESS variable does not seem to affect derived variables

I have followed the steps described in Inheriting from Barceloneta to create a theme that inherits from Barceloneta. Now I want to change some colors.

Currently, my LESS file looks like this:

@import "++theme++barceloneta/less/barceloneta.plone.less";
@plone-sitenav-bg: green;

As a result, my website looks like a Barceloneta-styled website, except that the navigation bar is green.

The variable @plone-sitenav-bg is defined to be @plone-link-color in variables.plone.less. So if I changed @plone-link-color, it should also affect @plone-sitenav-bg. Let’s try with the following LESS file:

@import "++theme++barceloneta/less/barceloneta.plone.less";
@plone-link-color: green;

Unfortunately, the navigation bar does not show up in green this way, but in blue, like in the Barceloneta theme.

There is something else that is strange. When setting @plone-link-color as described above and also when not making any custom definitions at all, the generated CSS contains the setting background-color: #007bb3 for .plone-navbar, although the original value of @plone-link-color is #007bb1, not #007bb3.

When generating the CSS outside Plone using lessc, everything works as expected: When setting @plone-link-color to green, the background-color value for .plone-navbar becomes #008000, and when not making any custom definitions, it becomes #007bb1, not #007bb3.

Can anyone please explain what is going on here? Is this because of bugs in Plone’s LESS compiler? What LESS compiler is Plone using actually?

Did you recompile the LESS to CSS?

Also if you're not running your instance or client in fg you will need to toggle the theme (deactivate/reactivate it or activate another theme then activate this one).

You may also see caching if you're running behind varnish etc. in which case you may need to force reloading of the css by appending something like ?v=234 to the CSS files in your manifest.cfg

Yes, I rebuilt the CSS. When talking about the settings for .plone-navbar above, I meant the settings in the generated CSS.

I also cleared the cache and checked how the page was looking. In the case of setting @plone-sitenav-bg directly, the color of the navigation bar did change to green, but when changing @plone-link-color, it did not.

Actually, I found out meanwhile where the #007bb3 is most probably coming from. The file at, which is imported by barceloneta.plone.local.less sets @plone-link-color to #007bb3, while variables.plone.less in the Barceloneta theme sets it to #007bb1. Actually, the Barceloneta setting should take precedence. I guess it does not, because of exactly the bug that also makes my @plone-link-color: green have no effect. Apparently, Plone’s LESS compiler does not always use the last definition of a variable.

Might help if you posted your theme files here. Maybe someone will spot the issue.

The index.html file is just a copy of the one from Barceloneta. The other relevant files are as follows:

  • manifest.cfg:

    title = Barceloneta-based
    description = A theme based on Barceloneta
    doctype = <!DOCTYPE html>
    development-css = ++theme++barceloneta-based/style.less
    production-css = ++theme++barceloneta-based/style.css
  • rules.xml:

    <?xml version="1.0" encoding="UTF-8"?>
    <rules xmlns=""
        <xi:include href="++theme++barceloneta/rules.xml" />
        <rules css:if-content="#visual-portal-wrapper">
  • style.less:

    @import "++theme++barceloneta/less/barceloneta.plone.less";
    @plone-link-color: green;

Maybe the problem is not with the LESS compiler, but with the way Plone handles the toolbar variable definitions. Apparently, when compiling the LESS code in Plone, the toolbar variable definitions are imported automatically, while you have to to additionally import them when compiling locally. Could it be that Plone puts the toolbar variable definitions after the LESS code of the theme? Then they would always win, which would explain the color #007bb3 for the navigation bar background winning over the setting from Barceloneta (#007bb1) and also over my own setting (green).

maybe related with:

Yes, I seem to experience Problem 2 described in this proposal.

I am very much in favor of not allowing theme-specific LESS variables to be customized through a dedicated GUI. They should be configured by editing variables.less or whatever the relevant file in the respective theme is.

I really do not like the definition of the visual appearance been split over several places. Currently, we have the theme files, the resource registry, and the logo setting as such places. This partitioning is just arbitrary. For example, the link color can be configured in the resource registry, but the width of the search box cannot.

Even worse, closely related definitions are spread across different places, which makes it more difficult to keep them consistent. Furthermore, some settings are site-specific (resource-registry, logo), while others are not (theme files). For example, the height of the logo must agree with the position of the search box, but the former is determined by a site-specific setting outside the theme files, while the latter is determined by a site-independent setting inside the theme files.

In my opinion, it would be best if everything related to the visual appearance would be part of the theme and therefore configured through the theme files.

+1 to that!