maintain-wordpress

WordPress のメンテナンス

まず確認して報告し、ユーザーが承認した項目だけを更新します。サイトは一度に1つずつ対応し、次のサイトに進む前に、それぞれが引き続き読み込めることを確認します。

操作の呼び出し

• 各操作を初めて呼び出す前に、search が返す inputSchema を読みます。以下の名前が未知の操作として拒否された場合は、その手順で行う内容を search で検索します（例：「wordpress plugins update」）。
• 読み取り操作は multi-execute でまとめて実行します（1バッチあたり最大20ステップ）。バッチ内の操作は1つのサーバー内で連鎖します。Hostinger Connector では、wordpress、hosting、agency-hosting は別々のサーバーとして実行されます。
• 更新、アクティベーション、アンインストール、コアの変更はジョブとしてキューに登録されます。成功応答は「キューに登録済み」を意味します。変更が反映されるまで、該当する読み取り操作を10～20秒ごとにポーリングします。書き込み操作を再送信してはいけません。

1. インストールを見つける

• 1つのサイトの場合：domain を指定して wordpress_installations_list を実行します（部分一致するため、完全一致するエントリを使用します）。すべてのサイトの場合：フィルターを指定せずに wordpress_installations_list を実行し、ユーザーが他者のために管理しているサイトも含めるには ownership: "all" を追加します。
• id（すべての wordpress_* 呼び出しで指定する software パラメーター）、username、domain、directory、is_valid、validation_error を保持します。
• Agency Plan の WordPress サイトは、website_types: ["wordpress"] を指定した agency-hosting_websites_list-plan から取得します。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 — テーマについても同様の情報。

インストールごとに4つのステップで、1バッチあたり5つのインストールを処理できます。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つずつ更新する

1. 脆弱性を修正するプラグイン — スラッグを指定して wordpress_plugins_update を実行します。
2. 承認された残りのプラグインを更新し、その後 wordpress_themes_update でテーマを更新します。
3. コアは wordpress_installations_update-core で更新します。パッチリリースには minor: true を指定し、メジャーな version はユーザーから依頼された場合にのみ指定します。

アクセスの多いサイトでは、実行中に enabled: true を指定して wordpress_maintenance_toggle を有効にすることをユーザーが希望する場合があります。失敗した場合も含め、作業後は必ず無効に戻します。

各サイトの作業後：

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を確認し、次にenabled: trueを指定してwordpress_object-cache_toggle-memcachedを実行します。通常、手早く速度を向上できます。
• 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）で更新します。

複数のサイト

作業を始める前に、インストール数をユーザーに伝えます。バッチごとに確認し、実行中のレポートを一つだけ維持します。サイトごとに更新し、失敗した場合は残りのサイトには手を加えず、処理を停止します。