maintain-wordpress

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Maintain WordPress

维护 WordPress

Check first, report, then update only what the user approves — one site at a time, proving each still loads before moving to the next.

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

Calling the operations

调用操作

Read the
```
inputSchema
```
that
```
search
```
returns before the first call of each operation. If a name below is rejected as unknown,
```
search
```
for what the step does (e.g. "wordpress plugins update").
Batch reads with
```
multi-execute
```
(up to 20 steps a batch). Batches chain operations from one server only — the Hostinger Connector runs
```
wordpress
```
,
```
hosting
```
and
```
agency-hosting
```
as separate servers.
Updates, activations, uninstalls and core changes are queued jobs: a success response means "queued". Poll the matching read operation every 10–20 s until the change shows; never re-send the write.

首次调用每项操作前，读取
```
search
```
返回的
```
inputSchema
```
。如果下面某个名称被判定为未知，请通过
```
search
```
查找该步骤执行的操作（例如 "wordpress plugins update"）。
使用
```
multi-execute
```
批量执行读取操作（每批最多 20 个步骤）。一个批次只能串联来自同一服务器的操作——Hostinger Connector 将
```
wordpress
```
、
```
hosting
```
和
```
agency-hosting
```
作为独立服务器运行。
更新、启用、卸载和 core 变更都是队列任务：成功响应表示“已排队”。每 10–20 秒轮询对应的读取操作，直到变更显示出来；切勿重复发送写操作。

1. Find the installs

1. 查找安装

One site:
```
wordpress_installations_list
```
with
```
domain
```
(substring match — take the exact entry). Every site:
```
wordpress_installations_list
```
without filters, adding
```
ownership: "all"
```
to include sites the user manages for others.

Keep

id

(the

software

parameter of every

wordpress_*

call),

username

domain

directory

is_valid

and

validation_error

Agency Plan WordPress sites come from

agency-hosting_websites_list-plan

with

website_types: ["wordpress"]

. When

wordpress_installations_list

does not include them, only

agency-hosting_wordpress_settings

and core version changes (

agency-hosting_wordpress_list-versions

agency-hosting_wordpress_change-version

) are available; plugins and themes are updated from wp-admin.

单个站点：使用
```
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

和 core 版本变更（

agency-hosting_wordpress_list-versions

、

agency-hosting_wordpress_change-version

）；plugins 和 themes 需要从 wp-admin 更新。

2. Check (read-only)

2. 检查（只读）

Per install:

```
wordpress_installations_show-core-version
```
— core version and the known vulnerabilities that affect it.

wordpress_installations_list-core-updates

— available core versions.

wordpress_plugins_list-installed

—

status

update

(the newer version, when there is one) and

vulnerabilities[]

with

fixed_in

```
wordpress_themes_list-installed
```
— the same for themes.

Four steps per install fit five installs in one batch. For an install with

is_valid: false

, run

wordpress_installations_check-if-are-valid

with

force: true

for a fresh reason and leave it out of updates — a broken install is the

troubleshoot-website

skill's job.

每个安装：

```
wordpress_installations_show-core-version
```
——core 版本及影响该版本的已知漏洞。

wordpress_installations_list-core-updates

——可用的 core 版本。

wordpress_plugins_list-installed

——

status

、

update

（存在新版本时的版本号）以及包含

fixed_in

的

vulnerabilities[]

。

```
wordpress_themes_list-installed
```
——themes 的相同信息。

每个安装有四个步骤，因此一个批次最多可检查五个安装。如果某个安装的

is_valid: false

，使用

force: true

调用

wordpress_installations_check-if-are-valid

以获取最新原因，并将其排除在更新之外——损坏安装由

troubleshoot-website

skill 负责处理。

3. Report before changing anything

3. 变更前先报告

undefined

undefined

example.com (WordPress 6.8.1)

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


Vulnerable items come first. A vulnerable plugin without a fix, or an inactive one, is better removed with `wordpress_plugins_uninstall` than left installed — inactive code on disk can still be reached. Ask which updates to apply.

存在漏洞：contact-form-x 5.2 → 已在 5.3 修复（有可用更新）存在漏洞、未启用：old-slider 1.0 — 无可用修复；建议卸载更新：core 6.8.1 → 6.8.3（次要版本）、4 个 plugins、1 个 theme


先列出存在漏洞的项目。对于没有修复版本的漏洞 plugin，或未启用的 plugin，最好使用 `wordpress_plugins_uninstall` 将其卸载，而不是继续保留在安装中——磁盘上未启用的代码仍可能被访问。询问用户要应用哪些更新。

4. Back up first

4. 先备份

The API has no backup operation. Before updating, ask the user to create a backup in hPanel or confirm the latest automatic one is recent enough. Say it plainly; the user may choose to go ahead without one.

API 没有提供备份操作。更新前，请用户在 hPanel 中创建备份，或确认最近的自动备份足够新。明确告知用户这一情况；用户可以选择不备份并继续。

5. Update, one site at a time

5. 每次更新一个站点

Plugins that fix a vulnerability —
```
wordpress_plugins_update
```
with their slugs.
The remaining approved plugins, then themes with
```
wordpress_themes_update
```
.
Core with
```
wordpress_installations_update-core
```
:
```
minor: true
```
for patch releases; a major
```
version
```
only when the user asks for it.

For a busy site the user may want

wordpress_maintenance_toggle

with

enabled: true

during the run — and it is always turned off again afterwards, even when something failed.

After each site:

wordpress_litespeed-cache_purge-lite-speed

curl -s -o /dev/null -w "%{http_code}\n" https://DOMAIN/

and the same for

https://DOMAIN/wp-login.php

— both should be

with no PHP error in the body.

wordpress_installations_check-if-are-valid

with

force: true

When a site breaks: stop the run, deactivate the plugin updated last with

wordpress_plugins_deactivate

, check again, and report which update caused it before touching any other site.

更新可修复漏洞的 plugins——使用
```
wordpress_plugins_update
```
并传入相应的 slugs。
更新其余获批的 plugins，然后使用
```
wordpress_themes_update
```
更新 themes。
使用
```
wordpress_installations_update-core
```
更新 core：补丁版本使用
```
minor: true
```
；仅当用户明确要求时才通过
```
version
```
更新主要版本。

对于流量繁忙的站点，用户可能希望在执行期间调用

wordpress_maintenance_toggle

并设置

enabled: true

——之后必须始终将其关闭，即使某一步失败也一样。

每个站点处理完成后：

调用

wordpress_litespeed-cache_purge-lite-speed

。

执行
```
curl -s -o /dev/null -w "%{http_code}\n" https://DOMAIN/
```
，并对
```
https://DOMAIN/wp-login.php
```
执行相同操作——两者都应返回
```
200
```
，且正文中没有 PHP 错误。

调用

wordpress_installations_check-if-are-valid

并设置

force: true

。

如果站点发生故障：停止运行，使用

wordpress_plugins_deactivate

停用最后更新的 plugin，再次检查，并在处理其他站点之前报告是哪个更新导致了故障。

6. Performance and access

6. 性能和访问

Page cache:
```
wordpress_litespeed-cache_show-lite-speed-status
```
; purge after design or content changes.

Object cache:

wordpress_object-cache_show-memcached-status

, then

wordpress_object-cache_toggle-memcached

with

enabled: true

— the usual quick speed-up.

PHP version:
```
hosting_php_get
```
is large (around 25 KB), so read it only when the user asks about PHP. PHP 8.x is markedly faster than 7.x; confirm plugin compatibility before
```
hosting_php_update-version
```
.
wp-admin:
```
wordpress_login_create-links
```
returns temporary one-click login links. Give them to the user only; never store or reuse them.
Hostinger's own plugins update with
```
wordpress_plugins_update-hostinger
```
(
```
slug
```
).

页面缓存：
```
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
```
前确认 plugin 兼容性。
wp-admin：
```
wordpress_login_create-links
```
返回临时的一键式登录链接。仅将其提供给用户；绝不存储或重复使用。
Hostinger 自有 plugins 使用
```
wordpress_plugins_update-hostinger
```
（
```
slug
```
）更新。

Many sites

多个站点

Tell the user how many installs there are before starting. Check in batches, keep one running report, and update site by site so a failure stops the run with the rest untouched.

开始前告知用户共有多少个安装。分批检查，持续维护一份运行报告，并逐个站点更新，这样一旦失败就会停止运行，而其他站点不受影响。