Using the following in a module's less file:
```
@exports: {
@foo: "bar";
@number: 4;
@color: red;
};
```
will export the variables `@foo`, `@number` and `@color` into the global
scope. Though, exports are not able to override already defined variables.
That's still reserved for themes.
This is the successor of `Depends` and allows to
define dependencies for libraries and modules:
`Requires: <lib-name>[ (<ver>)][, <lib-name>[ (<ver>)]] ...`
or
```
Requires:
Libraries: <name>[ (<ver>)][, <name>[ (<ver>)]] ...
Modules: <name>[ (<ver>)][, <name>[ (<ver>)]] ...
```
The BINARY cast to make trailing spaces significant (#4030) also
made these queries case-sensitive. This wasn't identified at the
time because the query itself wasn't case-insensitive, but the
default collation on the `name` column. (Tests sometimes are the
perfect mitigation for this...)
fixes#4184
Creating a new url has the benefit that all framework params are
still there. `$this->url()` however returns a url that's already
mangled and parameter preservation does not work for framework
params.
This is not quite the correct fix. But the entire parameter
handling here is way too convoluted.
Because assets are not registered in the CLI context,
CLI actions cannot access the full style sheet.
This is necessary for Icinga Reporting though in order to send PDF reports.
We automatically detect whether the server supports server side sorting
and sort manually if that is not the case. But there are LDAP servers
which report that they support this feature in general but have it
disabled for certain fields.
If we send the server side control for any field that has server side
sort disabled, the LDAP server will abort the query.
With the new configuration option it is possible to disable server side
sorting and it has precedence over our automatic detection.
Since this is a very special LDAP server configuration, there is no GUI
option for this.