diff --git a/CHANGELOG-fixes.md b/CHANGELOG-fixes.md index cc5c3b4d..6107f3b9 100644 --- a/CHANGELOG-fixes.md +++ b/CHANGELOG-fixes.md @@ -137,6 +137,9 @@ This fork (`chodeus/folder.view3`) is a maintained continuation of `VladoPortos/ | # | Change | File(s) | Version | |---|--------|---------|---------| +| 247 | Uninstall left `/var/log/packages/folder.view3--x86_64-1` behind, which broke every subsequent install. The remove block ran `removepkg &name;-&version;` — without the `-x86_64-1` suffix the package has carried since 2026.07.07.1 (f61dac6 standardised the name everywhere *except* here) — so removepkg aborted with `No such package: folder.view3-. Can't remove.` while the following `rm -rf` lines still deleted `&plugdir;` and the flash config. The orphaned DB entry then made `upgradepkg --install-new` report `Skipping package … (already installed)`, so reinstalling the same version never extracted the files and the plugin returned dead (plugin-manager reported success). Remove now globs `/var/log/packages/&name;-*` and `removepkg`s each basename, so it is version-agnostic and self-corrects after any future drift; `folder.view`/`folder.view2` do not match the glob. Install gained `--reinstall` so a stale entry can never suppress extraction again. Both patterns match Community Applications' own `.plg`. The drift itself is now unrepresentable: a new `&pkgname;` entity (`&name;-&version;-x86_64-1`) is the single definition of the package name, referenced by the pre-install prune, the install `FILE`/`URL` and the post-install keep-check, so no site reconstructs it by hand any more (resolved output verified byte-identical for `FILE Name`/`URL`; the two deltas are substring→full-name tightenings on sets already prefixed `folder.view3-`). No rebuild was needed — the `.plg` ships separately and is not inside the `.txz`. Users already stuck are repaired by installing this version (different package name → upgradepkg extracts; post-install prunes the stale entry). | `folder.view3.plg` | 2026.08.14 | +| 246 | `syncContainerOrder()` decided folder membership differently from `docker.js`, so the autostart file could disagree with the screen. Docker labels were missing entirely — `docker.js` assigns a container to a folder when its `folder.view3` label matches the folder name, but the PHP had no label handling, so a label-assigned container rendered inside its folder yet was ordered as unassigned. Labels are now read from `getDockerJSON("/containers/json?all=1")` (the endpoint `readInfo` already uses; `getDockerContainers()` carries no `Labels` key), and the read fails closed — an unavailable or partial Docker response aborts before the order is written rather than emitting labelled containers as unassigned. The regex gate also diverged in both directions: `empty("0")` is true in PHP, so a regex of `0` was dropped while `docker.js` applied it, and a whitespace-only regex was applied here while `docker.js` skips it. Gated on `is_string()` + `trim()` to mirror the client and to keep a non-string regex from fataling `trim()` on PHP 8. Explicit-vs-label precedence when a container is claimed by both is tracked in #55. | `server/lib.php` | 2026.08.14 | +| 245 | Import Everything rejected any file without an `fv3_export_version` wrapper, so a folder.view2 backup dead-ended on "Not a valid FV3 backup file." despite being importable via the dedicated Import Docker / Import VM buttons. It now detects a bare folder export (single folder object, or `id => folder` map) and offers Docker/VM buttons, reusing the same import path. The choice uses real buttons rather than confirm/cancel because sweetalert reports ESC and Cancel identically, and they are bound with `addEventListener` because an inline `onclick` inside sweetalert's own markup compiles but never fires. `fv3ImportFolderMap()` is extracted so the docker, vm and folder-export paths share one loop, and single-folder mode is selected with `fv3IsFolderShaped()` rather than a truthiness check on `content.name` — an empty name is legal and would otherwise post the folder's own keys as folder ids. | `scripts/folderview3.js` | 2026.08.14 | | 244 | Organizer registry cleanup and writes are gated on a successful registry read (`regOk`) — a failed/unreachable registry read no longer risks running rename/delete cleanup against empty state or overwriting the stored registry with a freshly-adopted set. | `scripts/shared.js`, `server/lib.php`, `server/read_organizer_registry.php` | 2026.08.01 | | 243 | Folder names `root` (case-insensitive) rejected client-side (folder.js swal) and server-side (updateFolder 400) — the name is reserved by Unraid's Docker organizer (`createFolderWithItems` throws on it), so a same-named FV3 folder could never mirror. All Autostart-tab form fields gained unique `name` attributes (`fv3-as-pos-/autostart-/wait-`), clearing the DevTools "form field has neither an id nor a name" violations. | `scripts/folder.js`, `server/lib.php`, `scripts/folderview3.js` | 2026.08.01 | | 242 | Organizer mirror: ownership registry (`organizer-registry.json` on flash) records the organizer folders FV3 created/manages; deleting or renaming an FV3 folder now deletes its organizer twin on the next sync (children return to the organizer root via `deleteDockerEntries`). Only registered folders are ever deleted — user-created native folders are untouched; pre-registry stale folders (e.g. an already-orphaned twin) are deliberately left alone. Registry adopts current FV3-named folders each pass and is only rewritten on change (no per-pageload flash writes). Sync failures now emit an unconditional `console.warn` — the previous debug-only logging is how a fully broken mirror shipped unnoticed for two weeks. Live-verified: create FV3 folder → twin created+registered; delete FV3 folder → twin removed, registry pruned. A missed create self-heals on the next page load (observed one lazy-persist race with the API). | `scripts/shared.js`, `server/lib.php`, `server/read_organizer_registry.php`, `server/update_organizer_registry.php` | 2026.08.01 | diff --git a/archive/folder.view3-2026.08.14.1-x86_64-1.txz b/archive/folder.view3-2026.08.14.1-x86_64-1.txz new file mode 100644 index 00000000..27cafc1b Binary files /dev/null and b/archive/folder.view3-2026.08.14.1-x86_64-1.txz differ diff --git a/folder.view3.plg b/folder.view3.plg index 53b32de9..a1ee3c1a 100644 --- a/folder.view3.plg +++ b/folder.view3.plg @@ -6,8 +6,9 @@ - - + + + ]> @@ -15,6 +16,11 @@ After updating, hard-refresh your browser (Ctrl/Cmd+Shift+R) and clear its cache if the page doesn't display correctly — before submitting a debug .json. +###2026.08.14.1 +- Fixed: uninstalling left the plugin's package entry behind, so the next install skipped the files and left the plugin broken — installing this version repairs it +- Fixed: Import Everything now accepts a folder.view2 backup file instead of rejecting it as invalid (#53) +- Fixed: the container autostart order now uses the same folder membership the Docker page renders, including containers assigned by docker label (#54) + ###2026.08.01.7 - Fixed: organizer folder-registry cleanup and writes are skipped whenever the registry can't be read @@ -710,13 +716,13 @@ After updating, hard-refresh your browser (Ctrl/Cmd+Shift+R) and clear its cache - rm -f $(ls /boot/config/plugins/&name;/&name;*.txz 2>/dev/null | grep -v '&version;-x86_64-1') + rm -f $(ls /boot/config/plugins/&name;/&name;*.txz 2>/dev/null | grep -v '&pkgname;') - - https://raw.githubusercontent.com/&github;/beta/archive/&name;-&version;-x86_64-1.txz + + https://raw.githubusercontent.com/&github;/beta/archive/&pkgname;.txz &md5; @@ -725,7 +731,7 @@ After updating, hard-refresh your browser (Ctrl/Cmd+Shift+R) and clear its cache for p in /var/log/packages/&name;-*; do [ -e "$p" ] || continue - case "$(basename "$p")" in *&version;-x86_64-1) continue;; esac + case "$(basename "$p")" in &pkgname;) continue;; esac rm -f "$p" done mkdir -p /boot/config/plugins/&name;/styles @@ -776,7 +782,12 @@ After updating, hard-refresh your browser (Ctrl/Cmd+Shift+R) and clear its cache - removepkg &name;-&version; + # Match the installed DB entry by glob — the package name carries an + # -x86_64-1 suffix, and it may not be the version this .plg is at. + for p in /var/log/packages/&name;-*; do + [ -e "$p" ] || continue + removepkg "$(basename "$p")" + done rm -rf &plugdir; rm -rf /boot/config/plugins/&name;