织梦后台常用批量操作审核移动删除失效完整实操修复指南

第一步：排查批量操作触发的核心前提条件

织梦后台批量操作（尤其是文章类）90%以上的失效都是基础前提没满足，先按顺序逐一验证：

• 验证是否选中目标对象：点击顶部或底部全选框时，检查左侧所有数据前的复选框是否真的勾选（织梦5.7SP1以前版本偶尔存在前端全选逻辑失效）——如果是前端全选问题，直接跳转到第三步修复
• 验证当前账号权限：登录超级管理员账号（admin默认账号，非自己添加的仅部分栏目有权限的账号），重新尝试批量操作——非超级管理员的话，检查系统→系统用户管理→对应账号的“栏目权限”“频道模型权限”“批量操作权限”是否打勾
• 验证目标数据是否允许操作：比如已审核通过的普通稿件，普通栏目管理员账号默认不能批量“取消审核”；已生成的静态文档，批量删除前如果没勾选“同时删除已生成的静态文件”，可能因为文件被占用/路径写死提示失败，但不属于“完全没反应”类失效
• 验证浏览器兼容性：织梦5.7全系推荐用IE8-IE11、360安全浏览器（兼容模式）、搜狗浏览器（兼容模式）——谷歌/火狐最新版有时会因为JS引擎的严格模式限制失效

第二步：修复批量操作无响应的文件权限问题

如果超级管理员用兼容浏览器手动逐行勾选也无反应，大概率是PHP文件/目录的读写权限异常（Linux系统最常见）：

Linux宝塔面板用户操作

• 登录宝塔面板→点击“网站”→找到织梦站点→点击“设置”→“目录权限”
• 批量设置权限的目录与数值：
  • /data目录设置为755或777（临时），递归修改子目录与文件
  • /dede（后台入口目录，你可能改了名）目录下的batch_main.php、archives_do.php、catalog_do.php、article_add.php设置为644或755
  • /include目录递归设置为755
• 修改后刷新织梦后台重新尝试

Linux虚拟主机用户操作

• 登录虚拟主机提供的FTP工具（推荐FileZilla，官网下载地址：https://filezilla-project.org/download.php?type=client）
• 连接到站点后，右键选中上述目录/文件→选择“文件权限”
• 输入数值权限，勾选“递归应用到子目录和文件”（仅针对目录），点击确定

第三步：修复织梦5.7全选/批量提交的前端JS逻辑漏洞

织梦5.7SP1以前（包括早期SP1补丁版本）的批量操作存在2个高频前端漏洞：全选失效、表单提交按钮没有绑定事件。修复前先备份以下2个文件：

备份路径：/dede（后台入口目录）/templets/

备份文件：index2.htm（文档列表页）、catalog_do.htm（栏目批量操作页）

修复文档列表页全选+批量提交

用记事本、Notepad++（官网下载地址：https://notepad-plus-plus.org/downloads/）或宝塔面板的“文件”→“编辑”功能打开/dede/templets/index2.htm：

• 搜索以下旧全选代码（约在第210-230行，不同模板顺序有差异）：

• 保留上面的input标签，在标签之前（约第180-200行）添加或替换完整的selAll函数代码：

• 搜索批量提交按钮的旧代码（约在第350-380行）：

• 替换为绑定了onsubmit事件的表单修改+提交代码组合（确保替换时包含原来的按钮前后文，比如
  标签内）：

• 检查标签的id是否为form1（正常情况下默认是，如果不是改成form1）
• 保存文件，刷新后台重新尝试

修复栏目批量操作页全选+批量提交

操作逻辑与文档列表页一致，打开/dede/templets/catalog_do.htm：

• 同样替换前的selAll函数为上面的完整代码
• 同样把批量提交按钮的type="submit"改成type="button"，添加onClick="document.form1.submit()"

第四步：修复批量操作执行后数据未变更的后端PHP逻辑漏洞

如果前端全选+提交都正常，跳转后提示“操作成功”但数据没变，是PHP处理函数的SQL语句或session验证问题：

修复文档批量操作的PHP逻辑

备份/dede/archives_do.php后打开：

• 搜索“CheckPurview(”开头的代码段，确保所有批量操作对应的权限验证是对的（比如批量审核对应CheckPurview('a_Check,a_AccCheck')），如果不确定可以临时注释掉权限验证测试——注释方法是在代码前加//，比如//CheckPurview('a_Check,a_AccCheck');
• 搜索批量删除的SQL语句“$dsql->ExecuteNoneQuery(”，确保语句里的条件是“where arcrank > -2 and id in ($aids)”（arcrank=-2是回收站的标识，防止误删未完全删除的文档），如果有其他多余条件直接删除
• 搜索批量移动的SQL语句，确保有更新typeid、typedir、ispart（如果是顶级栏目）等字段的完整语句，如果缺失直接替换为以下批量移动的完整核心代码（替换掉原来的if($job=='move')代码块）：

  if($job=='move')
  {
  CheckPurview('a_Move');
  if(empty($aids)) ShowMsg("请选择需要移动的文档！","-1");
  $aids = preg_replace("[^0-9,]", '', $aids);
  if($newtypeid==0) ShowMsg("请选择目标栏目！","-1");
  $row = $dsql->GetOne("SELECT id,typename,ispart,typedir FROM `@__arctype` WHERE id='$newtypeid' ");
  if(!is_array($row)) ShowMsg("目标栏目不存在！","-1");
  $dsql->ExecuteNoneQuery("UPDATE `@__archives` SET typeid='$newtypeid',typeid2='0' WHERE id IN($aids) ");
  $dsql->ExecuteNoneQuery("UPDATE `@__arctiny` SET typeid='$newtypeid' WHERE id IN($aids) ");
  $dsql->ExecuteNoneQuery("UPDATE `@__taglist` SET typeid='$newtypeid' WHERE aid IN($aids) ");
  ShowMsg("批量移动成功！","catalog_do.php?gotype=arcList&cid=$newtypeid");
  exit();
  }

• 保存文件，刷新后台重新尝试

修复栏目批量操作的PHP逻辑

备份/dede/catalog_do.php后打开，操作逻辑同上，重点检查批量删除/移动栏目的权限验证和SQL语句，尤其是批量删除时要确保同时删除了@__arctype、@__arctiny、@__archives里的对应数据。

第五步：如果以上方法都无效，尝试替换核心批量操作文件

如果是织梦版本过老（比如5.7GBK/UTF8 2015以前的版本）导致的底层漏洞，直接替换对应编码的核心批量文件即可：

• 先确认你的织梦编码：登录后台→系统→系统基本参数→核心设置，查看“网站编码”（GBK或UTF-8）
• 下载对应编码的织梦5.7SP2纯净版（官网最新稳定版下载地址：https://www.dedecms.com/download/）
• 解压后，把纯净版的/dede/batch_main.php、/dede/archives_do.php、/dede/catalog_do.php、/dede/templets/index2.htm、/dede/templets/catalog_do.htm覆盖到你的站点对应目录（注意：如果你的后台入口目录改名了，先把纯净版的/dede改成你的后台名再覆盖）
• 覆盖后重新设置文件权限（按第二步操作），刷新后台重新尝试