From 676fd8bc896ad442779210dc08a13d8fecf38cec Mon Sep 17 00:00:00 2001 From: magges Date: Sun, 12 Jul 2026 23:17:08 +0000 Subject: [PATCH] Fix cache-busting entirely: __DIR__ resolves wrong under Unraid's eval() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit podman_asset_version() has never actually cache-busted anything, all session — found live: it kept returning '0' for every asset regardless of a hard browser reload OR a full php-fpm restart (both ruled out explicitly before looking further), which meant the mechanism itself was broken, not caching around it. Root cause: Unraid's PageBuilder runs every .page file's PHP through eval() (webGui/include/DefaultPageLayout/evalContent.php literally does `eval($evalContent)`), and __DIR__/__FILE__ inside eval()'d code resolve to the eval() CALL SITE's own directory, not to Podman.page's real location — a standard PHP gotcha. So `__DIR__ . $relPath` was always pointing at a nonexistent path under webGui/include/DefaultPageLayout/, is_file() always failed, and the function always fell back to '0'. Every "do a hard refresh" instruction given throughout this session worked only because Ctrl+Shift+R bypasses the browser's cache directly — completely unrelated to this (non-functional) query-string mechanism. Likely also the real explanation for containers getting stopped unexpectedly during live testing just now: a stale, mismatched cached JS/HTML combination made a "Start Podman" click actually run as a full restart cycle (confirmed via plugin.log: a complete, uninterrupted stop-then-start at that exact timestamp) — restarted manually afterward. Fixed by hardcoding /usr/local/emhttp/plugins/podman instead of __DIR__ — consistent with the rest of the codebase already assuming this exact install path elsewhere (include/Config.php, plugin/podman.plg's event hook paths). Co-Authored-By: Claude Sonnet 5 --- webui/plugins/podman/Podman.page | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-) diff --git a/webui/plugins/podman/Podman.page b/webui/plugins/podman/Podman.page index 1ee7649..b9f009f 100644 --- a/webui/plugins/podman/Podman.page +++ b/webui/plugins/podman/Podman.page @@ -23,14 +23,28 @@ Icon="podman" * Cache-busts every static asset with its own on-disk mtime. Unraid's * webserver sends no explicit no-cache headers for /plugins/ static * files, so without this, browsers can keep serving a stale app.js/ - * podman.css for a long time after a plugin update — verified live: a - * bugfix to app.js's CSRF handling silently kept failing in a real - * browser after redeploy until this was added, even though the deployed - * file on disk was byte-for-byte correct. + * podman.css for a long time after a plugin update. + * + * Deliberately a hardcoded absolute path, NOT __DIR__ — Unraid's own + * PageBuilder runs every .page file's PHP through eval() (see + * webGui/include/DefaultPageLayout/evalContent.php: "eval($evalContent)"), + * and __DIR__/__FILE__ inside eval()'d code resolve to the eval() CALL + * SITE (that file's own directory), not to Podman.page's real location — + * a standard PHP eval() gotcha. Confirmed live: this made + * podman_asset_version() return '0' for every single asset, always, + * completely independent of any browser or PHP-FPM caching (ruled both + * out first: neither a hard-reload nor a php-fpm restart changed the + * result) — the version query string was never actually cache-busting + * anything all session; every "hard refresh fixed it" moment was the + * browser's own Ctrl+Shift+R bypass, not this mechanism. The rest of + * this codebase already hardcodes this same install path elsewhere + * (e.g. include/Config.php's $bootDir, plugin/podman.plg's event hook + * paths) — Unraid plugins always install to /usr/local/emhttp/plugins/ + * , so this isn't a new class of fragility. */ function podman_asset_version(string $relPath): string { - $full = __DIR__ . $relPath; + $full = '/usr/local/emhttp/plugins/podman' . $relPath; return is_file($full) ? (string) filemtime($full) : '0'; } ?>