禁止用戶時選擇清空頭像，頭像還在

IsaacZ

還是不行，頭像仍在。有沒有其他人幫忙測試一下？

IsaacZ

湖中沉 發表于 2025-12-4 09:50
是的，邏輯是一樣的。我這邊測試也多次封禁，沒有問題

真的沒有效果

湖中沉

IsaacZ 發表于 2025-12-7 12:11
真的沒有效果

這邊本地、線上兩個站點，測試均已可以

IsaacZ

湖中沉 發表于 2025-12-7 12:22
這邊本地、線上兩個站點，測試均已可以

禁止后，在 phpmyadmin 中看到相關用戶的 avatarstatus 仍然為1

湖中沉

IsaacZ 發表于 2025-12-8 00:21
禁止后，在 phpmyadmin 中看到相關用戶的 avatarstatus 仍然為1

你這不走代碼斷點排查沒法進一步核實了

IsaacZ

湖中沉 發表于 2025-12-8 09:45
你這不走代碼斷點排查沒法進一步核實了

千問給解決了：

湖中沉

IsaacZ 發表于 2025-12-19 23:22
千問給解決了：;

你要不要仔細看看代碼，千問說的這段在else里的代碼在1805行，我改的那部分在2025行，根本不是一回事，我改的那段，判斷條件是管理員操作，且clear不為空，根本沒在它說的else里。

不過千問處理的里面，增加了UC禁用的情況倒是真的。那就要確保你是否禁用了UC（比如使用了獨立模式或者UC通信失敗）

IsaacZ

湖中沉 發表于 2025-12-20 07:57
你要不要仔細看看代碼，千問說的這段在else里的代碼在1805行，我改的那部分在2025行，根本不是一回事，我 ...

AI說的那段1805行代碼和你添加的2025行的不一樣。它指的是另外這一段：

我的論壇沒有禁用UC，UC通信也是正常的。

我追問了2025行的增添代碼為何無效，回答如下，僅供參考：

湖中沉

IsaacZ 發表于 2025-12-20 10:59
AI說的那段1805行代碼和你添加的2025行的不一樣。它指的是另外這一段：;我的論壇沒有禁用UC，UC通信也是 ...

你看他的總結：
1、說執行的太晚，但那是對所有清理項操作的順序里的
2、說放在adminid=1里，這是正常的權限檢測
3、缺少本地文件刪除邏輯，這個邏輯只有當UC無效時才有用，正常邏輯調用UC的刪除頭像邏輯即可，并無問題

所以AI改了個寂寞，按照正常順序邏輯，逐項清理clear選中的項，完全沒問題

IsaacZ

湖中沉 發表于 2025-12-20 11:54
你看他的總結：
1、說執行的太晚，但那是對所有清理項操作的順序里的
2、說放在adminid=1里，這是正常的 ...

后來那個AI回復我說了僅供參考，不過一開始給的代碼還是不錯的，解決了我的問題。