Support partial paths in config:show (#39610)

[lbajsarowicz]

Description

bin/magento config:show rejects partial configuration paths. config:show catalog/frontend fails even though the path resolves to a perfectly valid subtree, because ConfigShowCommand::execute() runs the path through Magento\Config\Model\Config\PathValidator first, and that validator only accepts complete field paths registered in the system.xml structure.

This removes the pre-validation and instead reports an unknown path from the resolved value, so partial paths print their subtree while a genuinely unknown path still fails with ValidatorException.

This PR continues #39711 by @rogerdz, rebased onto current 2.4-develop. Their commits and authorship are preserved. The PR was approved by @Den4ik in March 2025 and then never picked up by triage — it never received a Progress: label.

Changes made on top of the original

A stored "0" is a value, not a missing path. The original replaced the validator with an empty($configValue) guard. Every disabled flag in the config tree is stored as "0", so that would have made config:show web/seo/use_rewrites — and everything like it — fail with "The path doesn't exist". ConfigSourceInterface::get() is documented as returning string|array, and returns '' or [] for a missing path, so the check is now explicitly against null/''/[]. Added a regression test for it.

PathValidatorFactory is retained. It is now unused, but the constructor parameter stays so the signature remains backward compatible; the class-level @SuppressWarnings(PHPMD.UnusedPrivateField) documents why.

Test coverage tightened. The shared mock now asserts PathValidator is never invoked, so a future change cannot silently reintroduce the pre-validation, and testConfigPathNotExist mocks the resolution explicitly instead of relying on PHPUnit's implicit null return.

Fixed Issues

Fixes #39610

Manual testing scenarios

1. bin/magento config:show catalog/frontend
   Before: The "catalog/frontend" path doesn't exist. Verify and try again. After: the subtree under that path is printed.
2. bin/magento config:show web/seo/use_rewrites on a store where rewrites are disabled — confirm it prints 0 rather than reporting a missing path.
3. bin/magento config:show some/made/up/path — confirm it still fails with The path doesn't exist.
4. bin/magento config:show web/secure/base_url --scope=websites --scope-code=base — confirm scoped lookups still work.

Questions or comments

One deliberate behaviour change for reviewers to weigh: config:show no longer validates the path against the system.xml structure at all, only that it resolves to something. A path that is not a declared field but happens to have a stored value in core_config_data will now be printed where it previously errored. That is the direct consequence of supporting partial paths, and matches what the issue asks for, but it is a real widening of what the command accepts.

Gates run locally on 2.4-develop (Warden, PHP 8.3):

• Unit: Config/Test/Unit/Console/Command/ConfigShowCommandTest.php — 8 tests pass.
• PHPCS Magento2: clean. PHPStan level 1: no errors.
• Negative check: 6 of the 8 tests fail against the unpatched command and all pass with the fix.

ConfigShowCommand is @api, but only method bodies change — no signature is touched.

Contribution checklist

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• All automated tests passed successfully (all builds are green)

[lbajsarowicz]

@magento run all tests

[m2-assistant]

Hi @lbajsarowicz. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.
❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

---

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.