20 minutes ago, chodeus said:

Are you talking about uninstalling and reinstalling the whole plugin?

Did you try hard refreshing your browser?

Any dev console errors in your web browser? (f12)

Yes uninstalling and reinstalling the whole plugin.
Yes. I hard refresh my browser. Also, tried different browser.
This is what it look like in the browser dev console:

When I install the plugin.

When I uninstall the plugin:

@chodeus Can you try this on your end? Uninstalling and reinstalling the whole plugin? Thanks.

BTW, these are the logs on syslog:

Aug 13 20:57:42 HHUBS plugin-manager: executing inline script: /bin/bash '/tmp/inline4-folder.view3.sh'
Aug 13 20:57:42 HHUBS plugin-manager: folder.view3.plg removed 
Aug 13 20:58:26 HHUBS plugin-manager: executing inline script: /bin/bash '/tmp/inline1-folder.view3.sh'
Aug 13 20:58:26 HHUBS plugin-manager: creating: /boot/config/plugins/folder.view3/folder.view3-2026.08.01-x86_64-1.txz - downloading from URL https://raw.githubusercontent.com/chodeus/folder.view3/main/archive/folder.view3-2026.08.01-x86_64-1.txz
Aug 13 20:58:26 HHUBS plugin-manager: checking: /boot/config/plugins/folder.view3/folder.view3-2026.08.01-x86_64-1.txz - MD5
Aug 13 20:58:26 HHUBS plugin-manager: running: upgradepkg --install-new /boot/config/plugins/folder.view3/folder.view3-2026.08.01-x86_64-1.txz
Aug 13 20:58:26 HHUBS plugin-manager: executing inline script: /bin/bash '/tmp/inline3-folder.view3.sh'
Aug 13 20:58:26 HHUBS plugin-manager: folder.view3.plg installed
Aug 13 21:02:49 HHUBS plugin-manager: executing inline script: /bin/bash '/tmp/inline4-folder.view3.sh'
Aug 13 21:02:49 HHUBS plugin-manager: folder.view3.plg removed
Aug 13 21:03:09 HHUBS plugin-manager: executing inline script: /bin/bash '/tmp/inline1-folder.view3.sh'
Aug 13 21:03:09 HHUBS plugin-manager: creating: /boot/config/plugins/folder.view3/folder.view3-2026.08.01-x86_64-1.txz - downloading from URL https://raw.githubusercontent.com/chodeus/folder.view3/main/archive/folder.view3-2026.08.01-x86_64-1.txz
Aug 13 21:03:09 HHUBS plugin-manager: checking: /boot/config/plugins/folder.view3/folder.view3-2026.08.01-x86_64-1.txz - MD5
Aug 13 21:03:09 HHUBS plugin-manager: running: upgradepkg --install-new /boot/config/plugins/folder.view3/folder.view3-2026.08.01-x86_64-1.txz
Aug 13 21:03:09 HHUBS plugin-manager: executing inline script: /bin/bash '/tmp/inline3-folder.view3.sh' 
Aug 13 21:03:09 HHUBS plugin-manager: folder.view3.plg installed
Aug 13 21:04:23 HHUBS plugin-manager: executing inline script: /bin/bash '/tmp/inline4-folder.view3.sh'
Aug 13 21:04:23 HHUBS plugin-manager: folder.view3.plg removed

.

Edited August 13Aug 13 by HHUBS
add logs

@HHUBS appreciate the logs! That makes it a bit more clear for me. If you want the plugin re-installed use this link and do a Force Install

https://raw.githubusercontent.com/chodeus/folder.view3/main/folder.view3.plg

The uninstall method will be fixed in the next release.

1 hour ago, chodeus said:

@HHUBS appreciate the logs! That makes it a bit more clear for me. If you want the plugin re-installed use this link and do a Force Install

https://raw.githubusercontent.com/chodeus/folder.view3/main/folder.view3.plg

The uninstall method will be fixed in the next release.

That did the trick, the "Force Install" option. Thank you.

3 minutes ago, HHUBS said:

That did the trick, the "Force Install" option. Thank you.

Glad it worked. I have just pushed an update so it wont be an issue going forward. Appreciate the report!

2026.08.14

• Uninstalling now removes the plugin cleanly after previous version improvements

• Import Everything now accepts a folder.view2 backup file instead of rejecting it as invalid

• Container autostart order fixes

Very minor issue:
I had a category called manual (lowercase) I wanted it initial capitalised as the others, got messaging about duplicate category name when renaming to Manual.
Worked around it by changing to manual1 then to Manual, seems some regex is case insensitive, should it be?

8 hours ago, the1_ts said:

Very minor issue:
I had a category called manual (lowercase) I wanted it initial capitalised as the others, got messaging about duplicate category name when renaming to Manual.
Worked around it by changing to manual1 then to Manual, seems some regex is case insensitive, should it be?

What do you mean by “category”?

Which page of the plugin are you on?

Hi, I had an issue, this is what my bot figured out. Thx!

Bug: a folder whose id is not pure base64 can never be deleted — and trying freezes the page

Plugin: Folder View 3 (folder.view3) 2026.08.28 Symptom: duplicate folders the UI refuses to remove, and a page that freezes behind a spinner when you try to delete one.

What I saw

Three folders named "LLM infra" on the Docker page. Two were empty and would not delete. The config held these keys:

grp_llm_infra          LLM infra   containers=[]                                    <- stuck
5xJlQxP162Ql9LjIXLs    LLM infra   containers=[llamacpp,ollama,LiteLLM,litellm-db]  <- the real one
yqzdeavmb0bCdsOQ3A     LLM infra   containers=[]

Root cause

generateId() mints ids from base64 with +, / and = stripped, so a folder id the plugin creates is always [A-Za-z0-9]{1,20}:

// server/lib.php:1547
function generateId(int $length = 20) : string {
    return substr(str_replace(['+', '/', '='], '', base64_encode(random_bytes(...))), 0, $length);
}

But three code paths validate ids against the full base64 alphabet, which allows the three characters generateId() removes and forbids everything else — including _ and -:

// server/delete.php:6
if (empty($id) || !preg_match('/^[A-Za-z0-9+\/=]+$/', $id)) { http_response_code(400); exit; }

// server/update.php:6
if (!empty($id) && !preg_match('/^[A-Za-z0-9+\/=]+$/', $id)) { http_response_code(400); exit; }

// server/lib.php:785 (updateFolderIds)
if (!preg_match('/^[A-Za-z0-9+\/=]+$/', $folderId)) continue;

So a folder keyed grp_llm_infra is unreachable by the plugin's own UI:

• Delete → HTTP 400, nothing happens.

• Edit / save settings → HTTP 400, nothing happens.

• Container membership → silently skipped, so the folder can never stop being empty. This is why the stuck folder showed containers: [] while its containerImages still named the containers someone had put in it.

It is a permanent, self-inflicted orphan: the one operation that would clear it is the one operation its id forbids.

The worse knock-on: deleting one of these freezes the page

Three of the four delete entry points await the POST with no rejection handling, after showing a full-screen spinner overlay:

// scripts/shared.js:700 — fv3RmFolder, used by the Docker tab (docker.js:801)
//                        and the VMs tab (vm.js:471)
// scripts/dashboard.js:816 — rmDockerFolder, used by the Dashboard (dashboard.js:1074)
$('div.spinner.fixed').show('slow');
await $.post('/plugins/folder.view3/server/delete.php', { type: type, id: id }).promise();
setTimeout(loadlist, 500);

The 400 rejects the promise, the await throws, and nothing catches it. So:

• loadlist is never scheduled,

• the swal stays open with showLoaderOnConfirm: true — buttons disabled, spinner running,

• and div.spinner.fixed, shown one line earlier, is never hidden.

The result is a full-screen overlay plus a locked modal with no way out but a page reload. It reads as "the browser hung when I deleted that folder". The page is not busy — it is covered by two spinners that nothing will ever dismiss.

Only scripts/folderview3.js:240 (the Folder View settings page) wraps the POST in try/catch, and that one correctly reports "Failed to delete folder: Bad Request". So whether this bug is a readable error or a frozen page depends purely on which of the four screens you happened to delete from — and the three that freeze are the three people actually use.

This is the fix worth taking first, independently of the id validation: every one of these callers needs the try/catch that folderview3.js already has, hiding the spinner in a finally. Then even an unexpected server error leaves a usable page.

The knock-on: "Remove ALL folders" deletes nothing

scripts/folderview3.js:276 loops every id inside a single try:

for (const cid of Object.keys(dockers)) {
    await $.post('/plugins/folder.view3/server/delete.php', { type: 'docker', id: cid }).promise();
}

The first 400 rejects the promise, the loop aborts, and the catch shows a generic "Failed to clear all folders". Object keys are in insertion order, so if the unreachable folder is early — mine was first — a bulk clear removes nothing at all and gives no clue why. That is what makes this look like "the folders cannot be deleted" rather than "one id is bad".

Suggested fix

Widen the three validators to cover any key that can legitimately be in the file, while still rejecting nothing the plugin needs to reject (the id is a JSON key, never a path):

if (!preg_match('#^[A-Za-z0-9+/=_-]{1,128}$#', $id)) { ... }

Then three behaviour fixes, the first of which matters most — it makes every failure readable instead of fatal to the page:

1. Handle the rejection in every delete caller (shared.js:700, dashboard.js:816), the way folderview3.js:240 already does, and hide div.spinner.fixed in a finally. This one turns a frozen page into a readable error, whatever the server says.

2. Never let a delete be refused for the id's shape. Deleting is the escape hatch. If any validation must stay, delete should be the one path that always accepts an existing key.

3. Do not abort the bulk clear on one failure. Collect the failures, delete the rest, and report which ids were refused — the current generic error hides the single bad key.

Repro

1. Add a folder to /boot/config/plugins/folder.view3/docker.json under a key containing _ or - (a UUID key does it, which is what automation tends to write).

2. Reload the Docker page. The folder appears.

3. Delete it from the Docker tab, the VMs tab or the Dashboard → the page freezes behind a spinner that never clears (400 in the network tab). Only a reload recovers it.

4. Delete it from the Folder View settings page instead → a readable "Bad Request" error.

5. Try "Remove ALL folders" → nothing is deleted at all, generic error.

Workaround until it is fixed

Edit /boot/config/plugins/folder.view3/docker.json by hand — back it up first, stop at a valid JSON object, and re-key the folder rather than deleting it, so its settings and membership survive:

"grp_llm_infra": { ... }   →   "VHlVa0Cw7yvX13LPgDVe": { ... }

Any key of 20 or fewer letters and digits works. Reload the Docker page and the folder behaves normally again.

Note for anyone scripting this file

If you register folders from a script, mint the key as [A-Za-z0-9]{1,20}. A UUID looks like the safe choice and is exactly the one that gets stuck.

@johner thankyou for reporting that. Did your bot happen to get a copy of your plugin diagnostics while this issue was present? Would be beneficial if you sent that to me.

@johner did you have your AI setup FolderView3 by chance and it modified the docker.json itself?

3 hours ago, chodeus said:

@johner did you have your AI setup FolderView3 by chance and it modified the docker.json itself?

Sorry, didn’t get the diagnostics, and yes at one point I got it to group a ton of containers it was managing.

It was a mix of auto and manual config.

11 minutes ago, johner said:

Sorry, didn’t get the diagnostics, and yes at one point I got it to group a ton of containers it was managing.

It was a mix of auto and manual config.

No problem. I appreciate people trying to break the plugin so I know how to strengthen it 😂

In future, try to not let it modify the .jsons and have it make the changes via the webui instead.

This should be resolved when I’m ready to release the next stable version.

Thankyou for reporting it!

Edited yesterday at 03:41 AM1 day by chodeus