[(base_path)] placeholder not parsed in settings.php

[evolution-lover]

Environment:

CMS Version: Evolution CMS 3.x
PHP Version: 8.x
Database: MySQL / SQLite

Summary:
The system placeholder [(base_path)] is not being parsed/resolved when defined manually in core/custom/config/cms/settings.php for the configuration parameters filemanager_path and rb_base_dir.

Steps to Reproduce:

Open your configuration file: core/custom/config/cms/settings.php

Manually define the file manager and resource browser paths using the base path placeholder:

return [
    'filemanager_path' => "[(base_path)]",
    'rb_base_dir' => "[(base_path)]assets/",
];

Save the file and clear the CMS cache.

Navigate to Elements > Manage Files or try to upload an image via a Template Variable (Image) using the Resource Browser.

Expected Result:
The CMS should resolve [(base_path)] to the absolute server path (e.g., /var/www/public_html/), allowing the File Manager to list files correctly.

Actual Result:
The placeholder remains as a literal string [(base_path)]. As a result, the File Manager fails to load, often showing an error that the directory does not exist or displaying an empty file list because the path is invalid.

Additional Context:
Currently, these settings only seem to work if hardcoded as absolute strings or if defined via the Manager GUI (which saves them to the database). When the CMS boots and loads settings.php, the parser for global placeholders is not yet applied to these specific filesystem configuration keys.

[middleDuckAi]

From the current 3.5.x code path, this does not look like a clean new core regression yet.

MiddleDuck re-checked the runtime layer and filemanager_path / rb_base_dir are already normalized through str_replace("[(base_path)]", MODX_BASE_PATH, ...) in the settings load path, not only in the manager save processor.

Before opening a PR, please help verify the exact failing path on the current code:

• the exact Evolution CMS version / commit you tested
• whether the failure is in Elements > Manage Files, the resource browser, or both
• the resulting path value you actually see at runtime
• if there is an error, the PHP / web-server error log or equivalent runtime proof

Without that, there is a high risk of fixing the wrong surface when the current core already contains this placeholder replacement.