mirror of
https://github.com/Vateron-Media/XC_VM.git
synced 2026-10-09 20:02:34 +02:00
Divarion-D
f8a37947b1
The panel is deeply coupled to TMDb (VOD import, player metadata, admin search, two crons), so shipping it as an uninstallable module only added failure modes: after the move to hash-suffixed dirs (tmdb_f4e6e) every hardcoded `Modules/tmdb/lib/...` require broke, and 2.3.3 crons died with "Failed opening required TmdbClient.php". tmdb -> core: - Vendored \TMDB client -> src/Infrastructure/Tmdb/lib/; the only loader is TmdbApiService::requireLibrary() (now public, also loads Release.php). - TmdbApiService -> XcVm\Infrastructure\Tmdb — composer-autoloaded in every bootstrap context, no module boot required (player scope never booted modules, so module-namespace classes were unreachable there). - TmdbCron / TmdbPopularCron -> XcVm\Domain\Vod; cron jobs -> Cli/CronJobs (picked up by the console.php scan; command names cron:tmdb and cron:tmdb_popular are unchanged). - TmdbController -> Public/Controllers/Admin; tmdb_search / tmdb api actions registered in routes/admin.php (same dispatchApi fallback). - Domain/Vod services and player_functions.php load the lib through TMDbService::requireLibrary() instead of hardcoded module paths. - tmdb removed from config/bundled_modules.php. ModuleLoader gains CORE_PROVIDED_MODULES: released watch/plex archives still declare "dependencies": ["tmdb"] — such deps are stripped during manifest normalization and in ModuleManager::listModules(). - syncBundledModules() purges stale on-disk tmdb module dirs and their config/modules.php state on upgraded panels, so the old copy cannot boot alongside the core implementation and collide on command names. Standard-set provisioning fix (root cause of the "Undefined variable $db" errors from watch/plex settings views on 2.3.3): - Production still ran watch_e6c86/plex_20cd9-less legacy copies migrated from 2.3.2 with generated hash_ids; provisionStandardSet() treated any same-name directory as "already on disk" and never fetched the pinned 1.0.2/1.0.1 releases that contain the fix. A same-name directory whose identity does not match the pinned hash_id is now considered stale: it is deleted and the pinned release is installed in its place. - installModuleFromSource(): when the module is already recorded as installed (files re-provisioned over a stale copy), run updateModule() (incremental from->to migrations) instead of re-running the initial install.