[Settings] Keep admin settings and config listings usable with a settings-store read target

[kingjia90]

Problem

The symfony-config write target is read-only once debug mode is off (docs), so the documented way to keep Appearance & Branding editable in production is to point both targets at the settings store:

pimcore_studio_backend:
    config_location:
        admin_settings:
            write_target:
                type: 'settings-store'
            read_target:
                type: 'settings-store'

Doing exactly that still leaves the screens unusable, in two independent ways.

1. The symfony configuration is discarded as soon as read_target: settings-store is set

SettingRepository::loadConfig() assigns the tuple returned by LocationAwareConfigRepository::loadConfigByKey() ([$data, $dataSource]) to $data and only destructures it in the caller. !$data is therefore testing a two-element array and is never true, so the settings-store fallback to the container configuration is dead code — and, as written, it would also have returned the wrapper array (['admin_settings' => [...]]) instead of the settings themselves.

The settings store only holds an entry once the settings have been saved through the UI at least once. Until then getConfiguration() resolves to null, and everything configured under pimcore_studio_backend.admin_settings is silently dropped.

Verified on 2026.x, APP_ENV=prod, debug off, with

pimcore_studio_backend:
    admin_settings:
        branding:
            brand_color: '#ff0000'
            background_shade: '#123456'
        assets:
            hide_edit_image: true

config	GET /settings/admin
write_target only	"backgroundShade":"#123456","brandColor":"#ff0000","hideEditImage":true — but "writeable":false (the data source is symfony-config, the write target is not, so isWriteable() refuses)
write_target + read_target	"backgroundShade":"","brandColor":"","hideEditImage":false, "writeable":true — the whole branding configuration is gone

So today a project can have its branding read from the (git-versioned) YAML or have it editable, never both.

2. A single perspective/widget in the symfony configuration 404s the whole listing

PerspectiveConfigRepository::listConfigurations() and ElementTreeWidgetConfigRepository::listConfigurations() collect their keys with fetchAllKeys(), which merges the settings-store ids with the container configuration keys, while getConfiguration() loads through the read target and throws NotFoundException for anything the read target cannot see.

With studio_perspectives.read_target: settings-store and one perspective defined in YAML:

GET /pimcore-studio/api/perspectives/configurations
404 {"message":"Perspective with ID: yaml_perspective not found","errorKey":"error_element_not_found"}

The perspective editor is then completely unusable — which matches the "perspectives are also not writable" part of the report.

Fix

• SettingRepository::loadConfig() destructures the tuple, so the intended fallback to the symfony configuration actually runs, and it returns the admin_settings node rather than its wrapper. The data source deliberately stays null, so the settings remain writeable and the first save goes to the settings store (which then takes precedence, as before).
• Both listConfigurations() implementations take their keys from the read target via fetchAllKeysByReadTargets() when one is configured, and keep using fetchAllKeys() when none is (in that case both locations are read, so both key sets belong in the listing).

Verification

Live on a 2026.x project with APP_ENV=prod / debug off:

• write_target + read_target = settings-store: GET /settings/admin now returns "backgroundShade":"#123456","brandColor":"#ff0000","hideEditImage":true and "writeable":true; POST /settings/admin/save returns 200 and the saved values are read back from the settings store.
• GET /perspectives/configurations returns 200 instead of 404.
• Default configuration (no config_location): unchanged — admin settings still come from the symfony configuration with "writeable":false in production, and the perspective listing still contains both the settings-store and the YAML perspectives.

vendor/bin/codecept run Unit → OK (594 tests, 1321 assertions), vendor/bin/phpstan analyse → no errors.

No regression test is included: all three repositories construct LocationAwareConfigRepository internally, which reads SettingsStore and therefore needs a database, and this bundle only ships a Unit suite. Making this testable would mean introducing a factory seam for LocationAwareConfigRepository across the three repositories, which felt out of scope for a bugfix on a patch branch — happy to add it if you would rather have it.

Closes https://github.com/pimcore/service-operations/issues/1225
Related: #1653, pimcore/studio-ui-bundle#3473

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

Copilot review overview

🟢 Approved

The focused changes correctly resolve both reported configuration-loading failures without altering default behavior.

Review effort: Balanced
Findings: None

What changed in this PR

Fixes settings-store read targets so admin settings retain Symfony defaults and perspective listings remain usable.

Changes:

• Falls back to Symfony admin settings when the settings store is empty.
• Lists only configurations available through the configured read target.
• Preserves existing behavior when no read target is configured.

File	Description
src/​Setting/​Admin/​Repository/​SettingRepository.php	Correctly handles repository tuples and admin-setting fallback.
src/​Perspective/​Repository/​PerspectiveConfigRepository.php	Aligns listed perspective keys with the read target.
src/​Perspective/​Repository/​ElementTreeWidgetConfigRepository.php	Aligns listed widget keys with the read target.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.