What type of hardware are you using: Old laptop or computer
What YunoHost version are you running: 12.1.39
How are you able to access your server: The webadmin
Describe your issue
Environment:
YunoHost: 12.1.39
yunohost-admin: 12.1.14
System fully updated (apt update && apt upgrade)
Debian Bookworm
PHP versions installed: 8.3 and 8.5 (apps currently using PHP 8.5)
Browser tested: multiple (Chrome, Firefox, incognito mode)
Issue:
All boolean fields in the YunoHost webadmin interface appear enabled (true) by default, even when the application manifest defines them with default: false.
This issue is not limited to a specific app: it affects all applications and all boolean fields in install/config forms.
Example (WordPress install form):
The manifest correctly defines:
{
“type”: “boolean”,
“id”: “multisite”,
“default”: false,
“yes”: 1,
“no”: 0
}
However, the webadmin UI displays the switch as enabled (Yes) by default and the value cannot be trusted visually.
Behavior observed:
The issue affects all boolean fields, not only multisite
Happens consistently across:
different domains and subdomains
direct IP access (bypassing Cloudflare)
multiple browsers and incognito mode
CLI installation behaves correctly:
passing multisite=0 installs a non-multisite WordPress correctly
Therefore, backend logic and manifests are working as expected
Investigation performed:
Verified manifest values via CLI → default: false confirmed
Inspected frontend JS bundle (configPanels-*.js)
boolean values are parsed via string matching (“1”,“yes”,“true”), ignoring yes/no fields
Confirmed issue is not related to:
Cloudflare (tested via direct IP)
SSL configuration
Nginx configuration
PHP version (frontend issue independent of PHP-FPM)
System had previous APT issues (Sury repo conflict, Yarn GPG key missing) but those were resolved and do not affect the behavior
Temporary CSP adjustments (unsafe-inline) did not change the issue
Recent changes before issue appeared:
System fully updated (including YunoHost and dependencies)
Installed and uninstalled multiple WordPress apps
Created and deleted domains and subdomains
No manual changes to YunoHost core or frontend assets
Conclusion:
This appears to be a regression or bug in yunohost-admin frontend, where boolean fields are incorrectly initialized or rendered as true regardless of the manifest default value.
The issue is reproducible and affects all applications, suggesting a global problem in boolean handling within the webadmin UI.
Share relevant logs or error messages
Relevant evidence collected:
- The app manifest/API returns boolean fields correctly. Example for WordPress:
{
"type": "boolean",
"id": "multisite",
"default": false,
"yes": 1,
"no": 0
}
-
In webadmin, the corresponding boolean switch is rendered as enabled (
Yes) by default. -
This is not limited to WordPress: it affects boolean fields across applications.
-
CLI/backend works correctly. For example, installing WordPress with:
sudo yunohost app install wordpress --args "domain=test1.ticmed.es&path=/&admin=ticmed&language=es_ES&init_main_permission=visitors&multisite=0"
results in a correct non-multisite install.
-
This strongly suggests a frontend issue in
yunohost-admin, not a manifest/backend issue. -
We also inspected the frontend asset and found boolean parsing logic in:
/usr/share/yunohost/admin/assets/configPanels-CDIl9NW8.js
Relevant snippet:
function le(e){let a=e.value??null;return ... e.type==="boolean"?a!==null?a=["1","yes","y","true"].includes(String(a).toLowerCase()):e.default!==null&&e.default!==void 0&&(a=["1","yes","y","true"].includes(String(e.default).toLowerCase())) ...}
Environment:
- YunoHost 12.1.39
- yunohost-admin 12.1.14
Tests already done:
- multiple browsers
- incognito mode
- direct IP access
- multiple domains/subdomains
- reproduced across multiple apps