目次
前提条件
サーバー:さくらレンタルサーバー
WordPressバージョン:6.5.3
サイトヘルスの警告(?)再び
1年以上前に「[WordPress]サイトヘルスの警告について(完結編)」でサイトヘルスの問題は完了したと思っていたが、気付けば新たな2項目の指摘があるというメッセージが出てきています。
まぁ、WordPressもどんどん新しい機能に対応したり、セキュリティの対応しているから仕方のない部分ではあると思いますが…。
なお、この記事では、この指摘事項について調べた事を記載しているだけで、指摘事項を消す方法は記載しておりません。指摘事項を消す方法をお探しの方は、読むだけ時間の無駄になってしまいますので、ご了承願います。m(_ _)m
※個人的には調べた結果「放置するしかない」という結論に至ったためです。
指摘内容の確認
兎にも角にも指摘内容を確認してみます。
サイトヘルスの画面を確認すると…
指摘事項は「おすすめの改善」(パフォーマンス)で、致命的な問題ではないので、最悪放置でも問題はなさそうです。
ただ、精神的には対応して、これらのメッセージに対応して、表示しないようにしたいので、個々の指摘事項について確認してみます。
指摘①「古いデータベースサーバー」
こちらは、WordPressが利用しているMySQL(データベース)のバージョンを8.0以上の物に変更してくださいという指摘です。
しかし、さくらレンタルサーバーで提供されているMySQLのバージョンは5.7です(2024/05時点)。
コントロールパネルへログインしてデータベース新規作成しようとしても、バージョンは5.7しか選択できない様になっています。
よって、現時点でMySQLのバージョンアップについては何ともしようがないので、そのままにしておきます。(さくらレンタルサーバーがMySQLのバージョンアップに対応してから対応という事になるでしょう)
指摘②「REST APIで予期しない結果が発生しました」
こちらは「REST API」に疎いので、何からみれば良いかはさっぱりでした。
ネットで対応方法を検索、しかし…
ネットを検索して、このサイトヘルスの指摘事項の対応方法として、
- WPプラグインを全て無効化してみる
- 更新通知機能のPINGを変更してみる
- さくらレンタルサーバーのWAFを無効化してみる
- サーバーの設定、デーモンの設定を変更(…はさすがにできない)
の様なものを試してみましたが、まったく効果なく、メッセージは出続けました…。
時間のある時にネットで検索しては、試して、治らずがっかりという事が長期間続きました…。
ログを確認するも
サーバーのエラーログ、WordPressのデバッグログを有効にしてログを確認するも、このREST APIに関してそうなログは残っていませんでした。
そもそも何でエラーになっているのか…
メッセージ中の「REST API エンドポイント」はURLアドレスの様なので、ここにブラウザで直接アクセスしてみます。
JSONぽい応答が返却されましたので、REST API自体はきちんと動作している様です。
メッセージがUNICODEぽくて読めませんが、上部の「プリティプリント」にチェックを入れると…
と読みやすく表示しなおしてくれました。
Codeが「rest_forbudden_context」([REST]禁止されたコンテクスト)なので、REST API レスポンスが「(403) Forbidden」になっているのかな?
Messageは「この投稿タイプの投稿を編集する権限がありません」とあり、dataは「Status:401」で401はHTTPではUnauthorized(認証資格不足)なので、どうやらREST APIなるものを実行するのに権限がない(足りない)ような挙動になっています。
ここでふと「自分は投稿の編集も、投稿もできているのに…」と疑問がわきました。
権限とは?
WordPressではユーザーにそれぞれ役割(管理者、編集者など)が与えられ、それぞれの役割で出来る事が変わってきます。
管理者であれば、基本自身のWordPressについてのすべての作業を行う権限が与えられますが、編集者はテーマやプラグインの新規追加や変更の権限がないので、そういった操作は出来ません。
さて、このサイトは基本私一人で管理しているので、管理者権限を持つユーザー1つです。
もし、そのユーザー権限でアクセスしているのなら、「投稿を編集する権限がありません」などという事にはならないはずです。
サイトヘルスは一体何の権限を使っているのでしょう…?
コードを追ってみた
ブラックボックスの中身を見ずに、外から推測するだけでは分からないので、WordPressのPHPコードを確認してもました。
該当のREST APIのコードは、wp-includes/rest-api/endpoints/class-wp-rest-post-types-controller.phpのget_items_permissions_check()関数あたりになりそうです。
public function get_item( $request ) { ...略... if ( 'edit' === $request['context'] && ! current_user_can( $obj->cap->edit_posts ) ) { return new WP_Error( 'rest_forbidden_context', __( 'Sorry, you are not allowed to edit posts in this post type.' ), array( 'status' => rest_authorization_required_code() ) ); }
この中でcurrent_user_can()で失敗しているようです。
この関数は現在のユーザーが引数の操作(ここではedit_posts)が出来るかどうかを返す関数です。
これは、wp-includes/capabilities.phpに定義されています。
function current_user_can( $capability, ...$args ) { return user_can( wp_get_current_user(), $capability, ...$args ); }
wp_get_current_user()で現在のユーザーを取得して、そのユーザーが$capabilityの権限を持っていればtrue、持っていなければfalseを返します。
ブラウザに直接REST APIエンドポイントを指定して、ここでエラーになる場合のユーザー情報は下記の様に空でした。
object(WP_User)#1237 (8) {
["data"]=> object(stdClass)#1238 (0) { }
["ID"]=> int(0)
["caps"]=> array(0) { }
["cap_key"]=> NULL
["roles"]=> array(0) { }
["allcaps"]=> array(0) { }
["filter"]=> NULL
["site_id":"WP_User":private]=> int(0)
}
これでは、権限がないと指摘されるのも分かります。
サイトヘルスでのエラー
ただ、サイトヘルスのチェックでcurrent_user_can()でfalseが返されるのは「edit_posts」ではなく、「unfiltered_html」「manage_options」の権限チェックの時の様です。
edit_postsのチェックの前段階で必要な権限なのか、そもそもedit_postsとは無関係なチェックで使われる権限はどうか分かりませんが、いずれもその際にユーザーは空なので(何も権限がないので)、当然falseが返されていました。
サイトヘルスの権限って…?
管理者権限を持つユーザーがWPのダッシュボードのサイトヘルスを見てるという事は、サイトヘルスはユーザー権限(管理者権限)で実行されていると思いましたが、なぜ、管理者ユーザでなく、何者でもないユーザーとして実行されてしまうのでしょう…?
もしかして原因は?
ネットを調べていくと、これかなという原因っぽいのを見つけましたが、本当にこれが原因かは分かりません…
WordPress wp_get_current_user() returns empty payload while a user is logged-in
https://stackoverflow.com/questions/76359071/wordpress-wp-get-current-user-returns-empty-payload-while-a-user-is-logged-in
「ユーザーがログインしているのに、wp_get_current_user() が空を返します」という質問で、それに対して「リクエストを送る時には『Nonce』が必要」との回答が…
もしかして、サイトヘルスのコードの問題…?(いやいやそんな…)
結局のところ放置するしか
サイトヘルス実行時のユーザー権限が足りてなくてエラーになっているというのは、言い換えれば、権限がしっかりチェックされて、正しく動作しているという事。
実際、WordPressの投稿の編集はじめ、その他の動作は問題なく動作しているし。
現状、放置するしかないですね…。
まとめ
現時点で出でいる2件の改善指摘点(MySQLバージョン、REST APIのエラー)については、個人的には出来る事なしの結論としました…。
※サイトヘルスに関しては、単なる「おすすめ」なら、「次回から表示しない」のようなチェックボックスを付けてほしいなとも思う。