Hardening driven by a 2.3.3 panel error log (166 entries):
- TmdbClient: _call() returns an empty/error payload on network or API
failure — all 20 `$result['results']` accesses guarded with `?? []`
(was: hourly "Undefined array key results" + foreach(null) warnings
from the popular cron when the TMDb API was unreachable or the key
was invalid).
- get_rows()/get_row() return false while MySQL is briefly unavailable
(restart windows) — guarded with `?: []` in ServerRepository,
BouquetService, BlocklistService (all 7 sites) and SettingsRepository,
plus `?? ''` for the allow_countries / allowed_stb_types /
stalker_lock_images json_decode inputs (was: foreach(bool) +
"Undefined array key" bursts during DB restarts).
- ServersCronJob: @fsockopen — an unreachable node is an expected state
already handled via the return value; the warning only polluted the
panel log on every ping of an offline server.
- DiagnosticsService: send error reports to the xcvm.tech endpoint over
HTTPS instead of plain HTTP.
Apply 'make cs-fix' — 493 files. Mechanical, import-block only:
- sort use statements alphabetically (class/function/const grouped);
- drop imports left unused by the PSR-4 migration (e.g. classes referenced by
leading-backslash FQCN whose redundant 'use' the automated insertion had added);
- one blank line after namespace and after the import block; collapse stray
blank lines around use.
No logic changes. Verified: php -l clean; PHPStan no errors; PHPUnit 295/295; and a
temporary PHPStan pass over src/Public/Controllers confirms no still-referenced
import was removed (0 unresolved classes). 'use' after inline HTML in view
templates is valid and aliases correctly (verified) — those imports are sorted too.
Move the last two Core/Config classes into XcVm\Core\Config. SettingsManager
has the largest fan-out of the whole migration (referenced by ~224 files).
- Namespace SettingsManager (self-contained singleton, no class deps) and
SettingsRepository (\FileCache:: qualified).
- Add 'use XcVm\Core\Config\SettingsManager;' to 224 referencing files and
'use ...\SettingsRepository;' to 12 — call sites (SettingsManager::get(), etc.)
unchanged. Done with a token-based inserter (after namespace/declare/<?php,
idempotent, same-namespace files skipped).
- ToolsCommand::processRecaptcha: drop dead class_exists('SettingsManager') +
method_exists guard (always autoloadable now) → call SettingsManager::clearCache()
directly. This was the only string-literal class reference.
Core/Config is now fully namespaced (ConfigReader, DomainResolver, SettingsManager,
SettingsRepository); the procedural constant files (AppConfig/Binaries/Paths)
remain global by design.
Verified: php -l clean (226 files); PHPStan no errors (baseline unchanged — it is
line-independent so the added use-lines don't disturb it); PHPUnit 295/295; all
Config FQCNs resolve via Composer; sample Public referrers lint-clean.
Divarion-D