maintain-wordpress

维护 WordPress

先检查并报告，然后仅更新用户批准的内容——每次处理一个站点，并确认每个站点仍可正常加载后，再继续下一个。

调用操作

• 首次调用每项操作前，先读取 search 返回的 inputSchema。如果下方某个名称被拒绝并提示未知，请搜索该步骤要执行的操作（例如“wordpress plugins update”）。
• 使用 multi-execute 批量读取（每批最多 20 个步骤）。每批只能串联同一服务器的操作——Hostinger Connector 将 wordpress、hosting 和 agency-hosting 作为不同服务器运行。
• 更新、启用、卸载和核心更改会作为任务排队：成功响应表示“已排队”。每隔 10–20 s 轮询相应的读取操作，直到显示更改结果；切勿重新发送写入操作。

1. 查找安装

• 单个站点：使用带有 domain 的 wordpress_installations_list（子字符串匹配——选择完全匹配的条目）。所有站点：不加筛选条件调用 wordpress_installations_list，并添加 ownership: "all"，以包含用户代他人管理的站点。
• 保留 id（每次 wordpress_* 调用中的 software 参数）、username、domain、directory、is_valid 和 validation_error。
• Agency Plan 的 WordPress 站点通过 agency-hosting_websites_list-plan 配合 website_types: ["wordpress"] 获取。如果 wordpress_installations_list 未包含这些站点，则只能使用 agency-hosting_wordpress_settings 和核心版本更改操作（agency-hosting_wordpress_list-versions、agency-hosting_wordpress_change-version）；插件和主题需从 wp-admin 更新。

2. 检查（只读）

针对每个安装：

• wordpress_installations_show-core-version — 核心版本及影响该版本的已知漏洞。
• wordpress_installations_list-core-updates — 可用的核心版本。
• wordpress_plugins_list-installed — status、update（有更新时显示较新版本）以及包含 fixed_in 的 vulnerabilities[]。
• wordpress_themes_list-installed — 主题的相同信息。

每个安装需要四个步骤，每批可处理五个安装。对于 is_valid: false 的安装，使用 force: true 运行 wordpress_installations_check-if-are-valid，获取最新原因，并将其排除在更新之外——损坏的安装应交由 troubleshoot-website 技能处理。

3. 更改任何内容前先报告

## example.com (WordPress 6.8.1)
Vulnerable: contact-form-x 5.2 → fixed in 5.3 (update available)
Vulnerable, inactive: old-slider 1.0 — no fix; uninstall recommended
Updates: core 6.8.1 → 6.8.3 (minor), 4 plugins, 1 theme

先列出有漏洞的项目。没有修复版本的易受攻击插件，或处于未启用状态的易受攻击插件，最好使用 wordpress_plugins_uninstall 将其移除，而不是继续保留——磁盘上的未启用代码仍可能被访问。询问用户要应用哪些更新。

4. 先备份

API 不提供备份操作。更新前，请用户在 hPanel 中创建备份，或确认最近一次自动备份足够新。明确说明这一点；用户也可以选择不备份并继续。

5. 逐个站点更新

1. 修复漏洞的插件——使用其 slug 调用 wordpress_plugins_update。
2. 其余获批插件，然后使用 wordpress_themes_update 更新主题。
3. 使用 wordpress_installations_update-core 更新核心：补丁版本使用 minor: true；仅当用户提出要求时，才指定主要版本的 version。

对于访问繁忙的站点，用户可能希望在更新期间调用 wordpress_maintenance_toggle 并设置 enabled: true——无论是否发生故障，之后都必须再次将其关闭。

每个站点更新后：

1. wordpress_litespeed-cache_purge-lite-speed。
2. 运行 curl -s -o /dev/null -w "%{http_code}\n" https://DOMAIN/，并对 https://DOMAIN/wp-login.php 执行相同操作——两者都应返回 200，且响应正文中没有 PHP 错误。
3. 使用 force: true 调用 wordpress_installations_check-if-are-valid。

如果站点出现故障：停止更新，使用 wordpress_plugins_deactivate 停用最后更新的插件，再次检查，并在处理其他站点前报告导致问题的更新。

6. 性能与访问

• 页面缓存：wordpress_litespeed-cache_show-lite-speed-status；设计或内容变更后清除缓存。
• 对象缓存：先运行 wordpress_object-cache_show-memcached-status，然后运行 wordpress_object-cache_toggle-memcached 并设置 enabled: true——这是常见的快速提速方法。
• PHP 版本：hosting_php_get 的输出较长（约 25 KB），因此仅在用户询问 PHP 时读取。PHP 8.x 明显快于 7.x；运行 hosting_php_update-version 前，先确认插件兼容性。
• wp-admin：wordpress_login_create-links 会返回临时的一键登录链接。仅将这些链接提供给用户；切勿存储或重复使用。
• Hostinger 自有插件通过 wordpress_plugins_update-hostinger（slug）更新。

多个站点

开始前告知用户安装数量。分批检查，持续更新一份运行报告，并逐个站点更新，以便发生故障时停止运行，不影响其余站点。