在WordPress多站点网络中，标准的删除操作确实会清除站点数据及其上传目录。如果你想在执行删除时保留站点目录结构，需要采取一些额外的步骤。
由于搜索结果中关于“保留目录”的具体操作指引不多，以下方法结合了WordPress多站点的常规管理逻辑和一些可行的调整思路。
💡 理解删除机制与调整思路
在WordPress多站点中，当你通过网络管理员后台删除一个子站点时，系统会执行一系列清理动作，这通常包括从数据库移除站点记录、删除该站点的专属数据表以及清空其上传的文件目录。
要实现“保留目录”，核心思路有二：
- 干预上传目录的删除：通过技术手段让系统跳过删除上传目录的步骤。
- 先备份，后补目录：在执行标准删除后，手动重新创建所需的目录结构。
🛠️ 具体操作步骤
思路一：通过代码干预删除过程（推荐给开发人员）
这个方法涉及在删除站点动作发生时，挂载一个自定义函数来阻止删除上传目录。
- 编辑主题的
functions.php文件或创建一个自定义插件：将下面的代码片段添加到你的主站点（网络激活）的主题functions.php文件末尾，或者将其封装成一个简单的插件。
/**
* 在删除多站点子站点时，阻止系统删除其上载目录
* 请根据你的实际路径修改 $base_upload_path
*/
add_action( 'wp_delete_site', 'preserve_site_upload_dir_on_delete', 10, 1 );
function preserve_site_upload_dir_on_delete( $old_site ) {
// 这里是核心：我们移除WordPress自带的删除站点目录的动作
remove_all_actions( 'wp_delete_site' );
// 可选：记录日志，便于调试
error_log( "Attempted to delete site with ID: " . $old_site->id . ", but upload directory preservation is active." );
}重要说明：
- 这段代码是一个概念示例。直接使用
remove_all_actions('wp_delete_site')虽然可能阻止删除上传目录，但也可能导致其他必要的清理工作无法完成，从而在数据库中留下残余数据。 - 更精确的做法是深入研究WordPress核心的
wp-includes/ms-functions.php文件中的wpmu_delete_blog函数，找到专门负责删除目录的那个钩子（hook）并单独移除它。这对于普通用户有一定难度。 - 强烈建议在生产环境使用此方法前，在本地或测试环境充分验证。
思路二：手动操作与目录恢复（更稳妥通用）
如果你觉得写代码比较麻烦，或者希望操作更直观可控，可以这样做：
- 执行标准站点删除：
进入你的WordPress多站点网络后台，找到要删除的子站点，使用“删除”功能将其删除。这个过程会清除该站点的数据库记录和文件。 - 手动重建上传目录：
删除操作完成后，通过FTP、SFTP或主机商的文件管理器，在你站点的wp-content/uploads/sites/目录下，重新创建以该子站点ID命名的文件夹。
例如，如果你删除了ID为5的站点，就新建一个名为5的文件夹。 - （可选）设置目录权限：
为了确保WordPress之后能正常使用这个新文件夹，可以将其权限设置为755（对于目录）和644（对于文件）。你可以在服务器上使用chmod命令，或者通过FTP工具、文件管理器来修改。
💎 重要提醒
- 备份是关键：在进行任何删除站点的操作之前，请务必备份你的网站数据库和文件。这样万一操作出现意外，你还能有机会恢复。
- 关于数据库：以上方法主要解决了“保留目录”的问题。标准的站点删除操作会清理该站点在数据库中的专属表（例如
wp_2_posts,wp_2_options等）。这是无法撤销的。 - 插件考量：一些插件在站点被删除时，其创建的数据表可能不会被自动清除。如果你希望数据库也保持绝对“干净”，在删除站点前，可能需要检查并处理这些插件创建的表。
希望这些方法能帮助你实现目标。如果你能告诉我你更倾向于哪种方案，或者对服务器命令行操作的熟悉程度，我也许能提供更进一步的建议。