The unified search modal was intended to be cleared when closed.
However, "UnifiedSearchModal" did not emit "update:query" when its
internal query value ("searchQuery") changed, so "UnifiedSearch.query"
was kept as an empty string. When the modal was closed "update:query"
was emitted with an empty string, which should have cleared
"UnifiedSearch.query" and that, in turn, should have cleared the modal.
However as "UnifiedSearch.query" was already an empty string the watcher
that updates "UnifiedSearchModal.searchQuery" from "UnifiedSearch.query"
was not triggered and the modal was not cleared.
As "UnifiedSearch.query" is now updated with the value of
"UnifiedSearchModal.searchQuery" the latter can not be trimmed when
updated from the former, as that would in turn also trim
"UnifiedSearchModal.searchQuery" and prevent to search for anything with
spaces at the beginning or end (even if those trailing spaces are just
temporary while writing something like "searched value").
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The configuration option, to accept self-signed certificates, is now also used when syncing address books.
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
For the overall OPcache size check, we currently compare used memory with free memory. However, `opcache.memory_consumption` is split into `used_memory`, `free_memory` and `wasted_memory`. When cached files change on disk, old entries are not replaced or removed, but remain as wasted memory, until the cache is actually full, and if their percentage is above `opcache.max_wasted_percentage`, which is 5% by default. When this happens, the engine is restarted, resetting the cache completely, like a `opcache_reset()` call.
As long as we do not consider wasted cache, recommendations based on free memory can be false. To solve this, we could count wasted memory as free memory, if it is above `opcache.max_wasted_percentage`, as the engine will be restarted as soon as needed, freeing up this wasted space. On the other hand, wasted memory below the threshold permanently blocks the OPcache, which supports counting it as used memory. Depending on the situation, instead of raising OPcache size, it could be also advised to reduce `opcache.max_wasted_percentage`. But too frequent cache resets break its purpose as well.
In my opinion, the matter is too complex to consider wasted cache correctly, and do precise recommendations, but we should focus on reducing false positives instead. What we know for sure is: if the cache is full (`$status['cache_full'] === true`), and the limit for cached keys has not been reached, the OPcache was too small to maintain free space, with wasted memory below the configured threshold, where it consumes memory permanently. Recommending to raise the OPcache size in this case, is hence as accurate as it gets. Even if 5% wasted cache could be freed, 95% used memory is still above the previous threshold for the setup check warning. And if `opcache.max_wasted_percentage` is above 5%, then the admin must have decided to change the default, deciding that system memory consumption has lower priority than preventing OPcache engine restarts.
`cache_full` can be true as well if the limit for cached keys has been reached, hence we need to merge both checks. In this case `num_cached_keys` equals `max_cached_keys` exactly, hence it is easy to differentiale whether `opcache.max_accelerated_files` or `opcache.memory_consumption` needs to be raised to address the `cache_full` state.
In practice, this change relaxes the checks: the respective limit needs to be reached 100% instead of 90%, to trigger a warning, eliminating also false alarms if a large share of the cache is consumed by wasted memory, which would be automatically freed once cache is 100% full.
Additionally, the recommendation for raising `opcache.max_accelerated_files` now says "a value higher than `max_cached_keys`", instead of "higher than `opcache.max_accelerated_files`". The actual limit, reflected by `max_cached_keys` from `opcache_get_status()`, [is a next higher value from a set of prime numbers](https://www.php.net/manual/en/opcache.configuration.php#ini.opcache.max-accelerated-files). E.g. if `opcache.max_accelerated_files` is set to 10,000 (PHP default), the effective limit is 16,229 OPcache keys. Recommending "higher than 10000" could hence lead to a settings change without effect. For an effective change, the new value needs to be "higher than 16229" instead, which is what the setup check will show in this situation, with this change applied.
Signed-off-by: MichaIng <micha@dietpi.com>
Fixes a regression from dropping the SCSS compiler that broke
font themes like OpenDyslexic. The old code relied on the SCSS
compiler to automatically correct the order of the CSS rules,
ensuring the @font-face declaration was always valid.
The server now correctly generates the `@font-face` rule at
the top level of the stylesheet, fixing the previously invalid nested CSS.
Introduced in : f1448fcf07
Signed-off-by: nfebe <fenn25.fn@gmail.com>
The Theming app injects the stylesheets for the different themes in the
"<header>" element of the page, and those stylesheets are then loaded by
the browser from a "Controller" (a plain "Controller", not an
"OCSController"). The stylesheets, in turn, may also get some images
(like the background) also from the "Controller".
When handling a request to "index.php" it is checked whether the user is
logged in and, if not, a login is tried. A disabled user is explicitly
seen as not logged in, so a login is always tried in that case, but
disabled users are also explicitly prevented to log in, so the login
also fails. Due to that trying to get any of the themed stylesheets or
images with a disabled account (to be able to show the "Account
disabled" error page) fails with an HTTP status 401.
To solve that, and to avoid touching this basic logic as much as
possible, the login exception is now ignored (if the user is disabled)
for some specific requests to the Theming app.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
