2021年3月18日木曜日

Contact Form 7 version 5.4 以降 動かなくなった Contact Form 7 add confirm プラグイン(Contact Form 7 に確認を追加する)を動作させるには

 筆者自身は、「上記内容で間違いありません」のチェックボックスを設けるぐらいで回避したり、Googleフォームも確認がないので利用はしていませんでした。

でもこの「Contact Form 7 add confirm」プラグインについては、WordPress勉強会か WordCampのコントリビューターディか忘れましたが、そうした場所で「開発したー」というのを聞いた記憶が朧気ながらあるのです。まぁそれを証明するものがないので漠然とした記憶だけです。

まぁともあれ、Contact Form 7 のバージョン5.4 から動作しなくなったという情報が、ちらほら目につくようになりました。

これについて、サポートフォーラムで修正方法が掲載されたので備忘録をこめてメモしておきます。


対処方法


Contact Form 7アップデートでContact Form 7 add confirmが効かない(WordPress.org 日本語版サポートフォーラム)

にあるように、

plugins\contact-form-7-add-confirm\includes\js\scripts.js

223行目と 226行目の、event.detail.idevent.detail.unitTag に変更すれば動くというものです。

変更前


変更後


ということですね。

実際に手持ちの WordPress 5.7 + PHP 8.0.0 でも動作することを確認しました。

2021年3月18日 @kimipooh

2021年3月5日金曜日

MAMP 上の WordPress で PHPキャッシュ「APCu」モジュールを有効にしてみよう!

MAMP 6.3 から PHP 8.0 をサポートするようになりました。

ローカル環境として、いくつかのツールを併用しており、MAMPはその一つです。

MAMP上の WordPress は最近とても動作が遅くなってきました。そのため、パフォーマンスを改善するための PHPキャッシュをつかいたいと思うようになったので、設定したメモを備忘録として残しておきます。

準備と条件


次のことを前提としています。
  1. macOS であること(検証したOSは macOS 10.15.7)
  2. MAMP 6.3がインストールされていること
  3. MAMP上にWordPressをインストールして動く状態(管理ダッシュボードにログインえきる)
MAMP無料版では、PHPバージョンの選択は2つまでです。
したがって、
  • /Applications/MAMP/bin/php
にある PHPフォルダのうち、2つ以外は別フォルダへ移動しておいてください。そうすることで、選択したい PHPバージョンにできます。たとえば、php8.0.0と php5.6.40 だけのフォルダを残せば、下図のようにその2つのバージョンを選択できるようになります。


STEP 1. PHPキャッシュ APCu モジュールを有効化する


MAMPのデフォルトでは、 APCu モジュールは有効になっていません。
これを有効化するには、 php.ini の変更が必要です。MAMP上では、php.ini はバージョンごとに別フォルダで用意されています。MAMPの php 8.0.0 の場合、
  • /Applications/MAMP/bin/php/php8.0.0/conf/php.ini
になります。

このファイルにある
  • ;extension=apcu.so
の先頭のコメントを外してください。
  • extension=apcu.so
そして、MAMPのサービスを終了して、再度起動しなおします。
ターミナルアプリより
  • /Applications/MAMP/bin/php/php8.0.0/bin/php -m
を入力してEnterすることで、PHPで利用できるモジュール一覧が出てきます。
その中に apcu が存在すれば、APCu モジュールが有効になっているということになります。

STEP 2. WordPress で有効化


*注意:下記で紹介する WP-FFPC プラグイン 1.11.2 (2021年3月5日時点)は、そのままでは PHP 8.0.0 では動作しません。

WP-FFPC プラグイン 1.11.2 (2021年3月5日時点)を利用する場合には、
を参考に、プラグインソースの変更が必要です。変更しなければ PHP 8.0ではサイトがエラーでアクセスできなくなります。したがって事前にFTP接続などサイトのWordPressファイルを直接いじることができるようにしておくのがよいです。

MAMPのようなローカル環境ならサイトエラーが出てから、上記リンク先を参考にプラグインのソース・ファイルを後から修正することで対応は可能です。

しかし本番環境では、
  • https://wordpress.org/plugins/wp-ffpc/
より WP-FFPCプラグインをダウンロードし、FTP経由でプラグインをインストールし、問題の箇所を修正するのがよいでしょう。

また一時的な措置としては構いませんが、プラグインが更新されたときに変更した部分が上書きされて、サイトがエラーでとまってしまうリスクがあります。したがって、PHP 8.0で利用する場合には、本番用では対応するまで使わないほうがよいでしょう。

プラグインを有効化できたら、設定 > WP-FFPCより、APCu を選択して保存すれば有効になります。


ローカル環境だとそれでいいですが、本番環境だとキャッシュの期限を調整するとよいと思います。


2021年3月5日 @kimipooh

WordPress プラグイン「WP-FFPC」を PHP 8.0で動かす!

 WordPress で PHPキャッシュ(APCu等)を有効化するプラグイン「WP-FFPC」ですが、PHP 8.0 ではエラーがでてサイトが止まってしまいます。PHP 7.4 では動きます。PHP の APCu モジュールは、さくらインターネットのレンタルサーバー等、APCu モジュールが使える PHPで有効化するとサイトのパフォーマンスがかなり上がる無くてはならないものです。それが PHP 8.0になるとサイトが止まってしまうのは大問題です。

そこで WP-FFPC 1.11.2 (2021年3月5日時点)を修正して問題を解決してみました!その備忘録をまとめておきます。

PHP 8.0.0 上で、WP-FFPCをインストールすると・・・


有効化するまえに、下記のエラーでサイトが止まります。

これらを参考にソースコードをチェックした結果、下記の赤文字の部分の問題があることがわかりました。どのような問題かは後述します。

wp-ffpc-class.php
1016-1018行目

public function plugin_options_migrate( &$options ) {

if ( version_compare ( $options['version'], $this->plugin_version, '<' )  ) {


問題を解決する方法


この 1017行目に
if($options === false) $options = array('version' => '0.0');
を追加することで本問題を回避できます。
実際には、下記の青のコードを追加するということです。
	public function plugin_options_migrate( &$options ) {
		if($options === false) $options = array('version' => '0.0');
		if ( version_compare ( $options['version'], $this->plugin_version, '<' )  ) {

原因の説明


これはプログラムのバグです。
wp-ffpc-abstract.php
514行目から
public static function _get_option ( $optionID, $network = false ) {
if ( $network ) {
static::debug ( sprintf( __( '- getting network option %s', 'PluginUtils' ), $optionID ) );
$options = get_site_option( $optionID );
}
else {
static::debug( sprintf( __( ' – getting option %s', 'PluginUtils' ), $optionID ));
$options = get_option( $optionID );
}

return $options;
}
において、 戻り値の $options は、false (bool値), 配列等いくつかのパターンがあり、最初にインストールするときに、WP-FFPCの設定が WordPressで利用するデータベースに存在しないことから、$options の値が false (bool値)となります。

そうすると、下記の $options['version'] が存在しないことになり (falseとなる)、version_compare の第1引数が false になります。しかし、version_compare は引数に string を期待しているため、型の不一致が起こります。PHP 8.0からはそうした場合にはエラーになるということです。

wp-ffpc-class.php
1016-1018行目

public function plugin_options_migrate( &$options ) {

if ( version_compare ( $options['version'], $this->plugin_version, '<' )  ) {


このバージョンチェックは、WP-FFPCプラグインのバージョンが、インストール前のバージョンよりも新しければというチェックをしています。つまりプラグインが更新したときの処理でしょう。そのため、初期値を 0.0 にすることで、最初にインストールしたときには、必ずこのチェックが真になるように、下記のように比較前にコードを追加してあげればよいです。
if($options === false) $options = array('version' => '0.0');

これでエラー無く動くので、あとは一度でも WP-FFPCの設定を保存すれば、以後は $options が false になることはないはずです。

開発者の GitHUBに ISSUEとしてあげておきました。

さらに WordPress.org のプラグインサポートのほうにも投稿

修正されることを祈っておきます!

付録A) APCu キャッシュを有効にできる他のプラグイン等について


なかなか思うようなプラグインには出会えず。

  • Power Cacheプラグイン: https://ja.wordpress.org/plugins/powered-cache/
    • ドロップインに追加されるが、エラーがでてしまっている。wp-content/object-cache.php → wp-content/plugins/object-cache.php  へシンボリックリンクを張れば動く。



  • APC Object Cache Backendプラグイン:https://wordpress.org/plugins/apc/
    • PHP 8.0では重大なエラーがでて有効化できず

付録B)  Deprecated: contextual_help の使用はバージョン 3.3.0 から非推奨になっています ! への対応


作成:2021年3月8日

Deprecated: contextual_help の使用はバージョン 3.3.0 から非推奨になっています ! 代わりに get_current_screen()->add_help_tab(), get_current_screen()->remove_help_tab() を使ってください。 in /****/wp-includes/functions.php on line 5234

これは、wp-admin/ 以下の管理画面の上部にヘルプタブに追加する機能のようです。
が使い方が書かれていますが、結構修正は大変のように見えます。
これなくても機能としては問題ないため

wp-ffpc-class.php
 add_filter('contextual_help', array( &$this, 'plugin_admin_nginx_help' ), 10, 2);
//  add_filter('contextual_help', array( &$this, 'plugin_admin_nginx_help' ), 10, 2);

wp-ffpc-abstract.php
 add_filter('contextual_help', array( &$this, 'plugin_admin_help' ), 10, 2);
// add_filter('contextual_help', array( &$this, 'plugin_admin_help' ), 10, 2);

とコメントして無効化しておけば、とりあえず問題なさそうですね。


2021年3月5日 @kimipooh
2021年3月8日 付録2) を追記

2020年12月11日金曜日

Travis-CI と GitHUB連携で WordPress プラグインの PHPUnit によるテストを実行する(PHP 7.4対応)

 もうすぐ PHP 8.0対応のWordPress 5.6がリリースされる(2020年12月8日予定)ということで手持ちの公式プラグインを Travis-CIにてチェックし始めました(WP CLI 2.4.0 の wp scaffold plugin-tests プラグイン名 で吐き出すてs)。ところが、いつの間にか PHP 7.3以上については Travis-CIが PHPUnit 8.x(PHP8.0.0-devは PHPUnit 9.x)を使うため、PHPUnit 7.x までしか対応していない ため、現行のWordPressでは下図のようにエラーがでて動かなくなっていました。1年前ぐらいは問題なかったのですけどね。WordPress 5.6からは PHPUnit 8.x をサポートするそうです。この記事は WordPress 5.6がでる前(WordPress 5.6 RC2〜RC3)のときに検証した結果です。 WordPress 5.6も検証していますが、PHPUnit 8.x は未検証です。

付録(後述)で、MAMPを使った PHPUnitテストも説明しています。
また GitHubとTravis-CI 連携はできているものとします。そのやり方は検索したらいろいろと情報がでてくるでしょう。



PHP 8.0.0-devはうまくいかず

また数日調べたり、試してみましたが PHP 8.0.0-dev については、うまくいきませんでした。というわけで、こちらは素直に WordPress 5.6が出てから考えることにしました。


PHP 7.3/7.4 利用時に Travis CI に PHPUnit 7 を強制させる

PHPUnit 8.x対応の WordPress 5.6がでたら不要になるかもしれませんが、2020年12月1日現在は、WordPressが PHPUnit 7.x 以下しか対応しないため、やむを得ません。

変更するのは「.travis.xml」です。また composer.json がないと 「Composer could not find a composer.json file in XXX 」のようにエラーがでる場合があります。

したがって追加や変更点は

  • .travis.xml の変更
  • composer.json
  • phpunit.xml.dist の test-sample.php の除外設定をコメントアウトする
    (<!-<exclude>./tests/test-sample.php</exclude> -->)
の三点です。

詳細は
のコードを参考にしてみてください。

なお WP-CLIが吐き出す PHPUnit (wp scaffold plugin-tests)に含まれる .travis.xml は、2点古い書き方があります。

  1. matrix キーは、jobs キーへ変更(matrixはjobsへのエイリアス)したので、今後は jobs キーを使うこと
  2. sudo: は廃止キーだから削除推奨

また、PHP 7.3, 7.4 については、Travis CIで失敗しても許容するように、allow_failures キーを設定しておきます。ここで指定しておけば失敗しても Travis CIのジョブとしては失敗とはみなされないということになります。

まず jobに PHP 5.6〜 7.4を追加します。 PHP 7.4については WordPress 5.6(リリース候補)も含めておきます。

うまくすべてが成功していれば、下図のように allow_failures に含めた PHP 7.3と 7.4でもテストが成功していることがわかります。なお、ここでの WordPress nightlyバージョンとは、WordPress 5.6 RC2あるいは RC3を指します。

付録:MAMPを使った PHPUnitテスト方法

2020年12月9日時点(日本時間)においては、 WordPress 5.6の日本語版もリリースされました。ただ PHPUnit 8.5.13 を実行しようとすると

Error: Looks like you're using PHPUnit 8.5.13. WordPress requires at least PHPUnit 5.4 and is currently only compatible with PHPUnit up to 7.x.
Please use the latest PHPUnit version from the 7.x branch.
とでます。
をみる PHPUnit 9以降は PHP8以降のみサポート。PHPUnit8 は PHP7.1以降のサポートだとか。とりあえず、ここでは PHPUnit 7でのやり方を説明します。

検証環境

  • macOS Big Sur (11.0.1)
  • MAMP 5.7 (最新の6.2 は Apacheの80 ポート利用でコケるのでまだ使っていない)
    • PHP 7.4.2
  • zsh(シェル)
  • プラグインテストの準備
  • svn をインストールしておきます(Big Surには標準搭載されていない)
    • Xcodeには含まれなくなったため、Homebrew をインストールして、 brew install svn からインストールできます。

STEP 1.  MAMPの phpや mysql等コマンドを優先する PATHを通す

ターミナルが起動しているときのみの一時的な有効化になりますが、
ターミナルを起動して次の2つのコマンドを、順番に実行してください。
*bash/zsh 両シェル対応

export php_path="`ls -d /Applications/MAMP/bin/php/php* | tail -1`"
export PATH="${php_path}/bin:/Applications/MAMP/Library/bin:$PATH"

これによって、MAMP内の最新 PHPを php コマンドに一時的に割り当てます。
which php
でパスが /Applications/MAMP/bin/php/php7.4.2/bin/php (今回の場合)になっていることを確認しておくことが重要です。

STEP 2. wp scaffold plugin-tests が吐き出す bin/install-wp-tests.sh の変更

  • https://github.com/kimipooh/view-shortcodes/blob/master/bin/install-wp-tests.sh
のうち、下記の赤文字の部分を削除してください。
MySQL 5.6以降、コマンドラインから DBへのアクセスにパスワードを指定することは、セキュリティ上好ましくないので警告を出してできないようになっているようです。
  • mysqladmin: [Warning] Using a password on the command line interface can be insecure.
回避するためには、「パスワードを入れてmysqlコマンドを実行すると「Warning: Using a password on the command line interface can be insecure」が表示される」などの記事にあるようにファイルにパスワードを記載してそれをコマンドに読み込ませるという方法もありますが、ここでは素直にパスワードをキーボードから入力することにします。

変更前(bin/install-wp-tests.sh)
  • mysqladmin create $DB_NAME --user="$DB_USER" --password="$DB_PASS"$EXTRA

変更後(bin/install-wp-tests.sh)
  • mysqladmin create $DB_NAME --user="$DB_USER" --password $EXTRA

こうすることで MAMPの初期設定(MySQLポート 8889、ユーザー、パスワードともに root)であれば、

STEP 3. テスト用 WordPress のインストール

bash bin/install-wp-tests.sh view-shortcodes root 'root' 127.0.0.1:8889 latest

というコマンドを叩くことで、WordPress最新版(latest)が、 

/var/folders/_6/ユニークキー/T/wordpress/

あたりにインストールされるでしょう。

STEP 4. PHPUnit7 のダウンロードと実行

  • https://phar.phpunit.de/phpunit-7.phar
より PHPUnit 7の最新版をダウンロードします。
phpunit7 とリネームして
chmod 755 phpunit7 と実行権限を付与しておきましょう。
これをパスが通っている場所に移動しておきます。
MAMP限定なら、/Applications/MAMP/Library/bin にいれておけばよいです。
STEP 1 で上記へのパスは一時的に有効になっているはずです。

あとは、 テスト環境野整った プラグインフォルダで

phpunit7

と実行すれば

Installing...
...
...
OK (1 test, 1 assertion)

のようにテストされるはずです。

2020年12月11日 @kimipooh

2020年11月22日日曜日

Kansai WordPress Meetup@大坂 #6 参加して・・・ #WPmeetupOsaka


プログラム

プログラムは、 #5だが、実際には #6だった模様。このイベントは大半がビデオオンでの参加が印象的だった。

以下、発表を筆者が聞いて、筆者なりに理解した内容をネットで調べた情報などを加味した上で記載しています。そのため、必ずしも発表者の意図した内容になっていない場合もあります。

質問は、Twitter に #WPmeetupOsakaのハッシュタグを使って行うというのがベースとなっていた。

WordPress で Headless フロントエンド



発表者:岡本 秀高氏

Headlessを利用するにあたってのデータ取得は、

  • WP API(WPコアが提供するREST API)を使う
  • WP GraphQL(プラグイン)
    • WordPress のデータを GraphQLで扱える
    • 過去に破壊的変更があったので注意
とりあえず WP APIを使って始めるのがよいが、カスタム投稿やフィールドが増えてくると GraphQLも検討の対象になるようだ。
いずれにせよ GETかPOSTでデータをいくつも引っ張ってくる必要がある。

Webサイトの表示方法は、SSR / SPA / SSGある

Client Side Rendering(SPA)・SSR・SSG を整理してみた(雑草魂エンジニアブログ)

  • SPA = Single Page Application(描画:ブラウザ上)
    • Ajax でデータを取得して表示というのが多い(Webアプリなど)
    • WordPress だと Reast で REST API利用するような形態
    • データ取得したときにサニタイズしておくのが無難(されているはずだが)
  • SSR = Server Side Rendering描画:サーバー上)
    • すべて JavaScript でやるので、SEO / OGPで一手間必要
    • JavaScript の読み込みサイズが肥大化しやすい
  • SSG = Static Site Generator描画:CI / ローカルなどサーバー上)
    • React での SSGとして、Next.js(自前実装必要), Gatsby (GraphQL 利用) などがある。
    • サイトで表示するHTMLを事前に生成する(Movable TypeのGenerate のようなもの)# WordPressのHTML静的化プラグインのようなものか...
    • HTML化することにあるので、表示速度がはやく、WordPressやDBに障害がおきてもウェブサイトはダウンしない。
    • ビルド(HTML化)しないと公開できない(全ページをビルドし直す)。250ページぐらいだと2分ぐらい掛かった経験がある。
    • ページ数に比類してビルド時間がかかる
    • ビルドのデバッグが少し大変
関連情報

    SSR で Webサイトを作る


    FrontityでWebサイト(Note.js のサーバーを動かす必要がある)
    などもあるが、WordPress のテーマがやっていることを別のシステムでやっているだけなので、車輪の再発明ではないかという話はある。

    JavaScript でフロントエンドをなぜ作るのか


    開発環境・公開サーバーの用意が楽
    共有可能なコンポーネントが作ることができ、利用できる

    Reactstrap / Material Design / Foundation 等を使ってマークアップの共有化ができる

    筆者感想

    筆者はデジタルキューブのAMIMOTOマネージドサーバーを利用して WordPressをいくつか管理運用している。そのうちの一つが、裏側で WordPress を動作しつつ StaticPress用な静的HTMLへビルドして、表のサイトを表示するということをやってもらっている。これがまさに SSG のような手法であり、今後はそちらのほうがいいのかもしれない。WordPressのStaticPressのようなプラグインは開発が停止してしまうこともあり、何度か変えた覚えもあるため。

    以下、筆者が気になった質問を書き出してみた。

    質問1(筆者)

    https://twitter.com/kimipooh/status/1330390365359190017

    WordPressの静的HTML化プラグインのようなものでウェブサイトを作っているものもあるのですが(そのサイト自体はもう更新しないのでいいのですが)、今後同じような運用形態が必要な場合、SSGを使うのがよいのかどう判断したらいいでしょうか。規模でしょうか。 #WPmeetupOsaka

    回答

    これも SSGといえる。1つや2つのサイトを作るぐらいで Next.js などを利用した SSGを使うのはコストパフォーマンスが悪いと思うので、 WordPress テーマを静的HTML化するのがよいとは思う。ただし、WordPress プラグインは内部PHPで静的HTML化処理をしており、大規模サイトなどではパフォーマンスが悪い場合が出てくる。そのため、デジタルキューブが提供を始めた Shifter のように外部から静的HTML化するという手もある。

    質問2

    どこから始めたらいい?

    回答

    とりあえずやってみたいというなら、Frontity がよい。

    • Frontity -> Gatsby -> Next.js

    らしい。

    質問3

    既存の WordPress で運用方法(SSR / SPA / SSG)を変更するときの気をつけることは?

    回答

    ウィジェットがうまく行かない可能性がある。プラグインやテーマが吐き出す CSS は Headless は自動取得できず、それぞれ調べて追加しないといけないので、既存テーマままで、移行するのはナンセンス。テーマ部分は作り直したほうがいい。

    質問4

    Headless を作ったサイトの管理運用は普通の人(WordPress でのサイト担当者)はできる?

    回答

    Headless をある程度理解している人に管理運用を担ってもらったほうがいい。

    運用現場からお伝えします! Headless CMS を使ったJamstack 構成の運用


    発表者:Hiromi Ito

    Jamsrack は始めて聞いた言葉。
    をみると、JAM = JavaScript/APIs/Markup とのこと。
    • コンテンツ担当者にとっては、WordPress の画面なのでとっつきやすい
    • マルチ管理しなくてよい
      • 1つ書いたら、複数サイトに同時更新できる
    • 本番前には Staging でチェック
      • マスターと Staging の2つのサイトが動いていて、Staging のほうでチェックしてから、マスターを更新するようにしている
    • エラー時はログで判断する必要あり
      • Headless CMS ==> Static Site Generator ==> CDN / Hosting という構成になると、どこの工程でどうなっているかはログをチェックし、それらのサーバーやシステムを管理するエンジニアとコンタクトする必要あり
    関連情報
    質問1

    エンジニアに相談する頻度は?(発表者に対する質問)

    回答

    立ち上げ時はかなりの頻度だが、安定してきたらあまりない。

    質問2

    Headlessを導入する意味は?個人が利用するブログ程度だと?
    一日一度程度の更新ぐらいで。

    回答

    更新をどうするかは、サービスごとにちがうが、基本的には更新は全データを更新することになる。少し時間がかかるぐらいと思えばいいぐらい。ただプレビューをどうすればよいかとかの問題はでてくる。そのため、個人ブログや数人が少しのコンテンツを更新するぐらいだと、WordPress 単体のほうがコストパフォーマンスは圧倒的に大きい。
    ただ小規模サイトでもセキュリティを気にする担当者を納得させたり、速度を気にする場合には Headless もありうる(Headlessをどの手法で使うかにもよるが)。

    WordCamp Japan 2021 (オンライン) 実行委員募集をしているとのこと!

    今回は日本全体としてやるとのこと!


    2020年11月22日 @kimipooh

    2020年11月2日月曜日

    リバースプロキシ(nginx)環境下で、WordPressのメニューが更新できない(エラーになる)

     保存しようとすると、下記のエラーがでます。

    • 204 recv() failed (104: Connection reset by peer) while reading response header from upstream
    これは時間がかかり過ぎて接続が切れたというものです。

    様々な解決方法(後述)を試しましたが、うまくいかず最終的には次の方法で解決しました。なおリバースプロキシが原因と特定できたのは、クローンサイトを手持ちのローカル環境で再現すると、遅いながらも問題なくメニューが保存できたこと。まぁ遅いのは1つのサーバーの多数のウェブサイト(WordPress含む)を動作させていて、リソースが足りていないことが原因の1つではあったものと思う。特殊な事例なので記録に残しておく。

    リバースプロキシキャッシュのバッファー調整


    次の3つの数値を調整する。
    • proxy_buffer_size 64k;
    • proxy_buffers 4 128k;
    • proxy_busy_buffers_size 128k;

    今回は、赤文字の部分を
    • proxy_buffers 100 128k;
    とすることで問題解決できた。
    ようは、バッファーの受け皿としてバッファーサイズが足りていないのではなく、最大個数がたりていなかった(4→100とした)のだった。

    PHPの調整


    下記をいろいろしたが解決せず。結局リバースプロキシのバッファー設定の問題だった。

    2020年11月2日 @kimipooh

    2020年3月11日水曜日

    WordPress では /?author=数字 で WordPressのユーザー名(ログインID)が漏洩してしまう件の対応について

    何が問題か


    WordPress では、
    • WordPressサイトのURL/?author=数字
    にアクセスすることで、
    • WordPressサイトのURL/author/ユーザ名
    に自動転送される仕組みになっています。
    これを悪用すれば、
    • WordPress のユーザー名に割り当てられている「すべての」ユーザー名(ログインID)を知られてしまいます。
    このことは
    にあるように脆弱性診断システムなどで脆弱性ありと判断される場合があります。

    対策しているかどうかの確認方法


    コマンドラインツール curl を使えば(macOS には標準搭載)、たとえば、 http://example.com に WordPressのサイトがあるとすると
    • curl -v -D -  "http://example.com/?author=1"
    と Mac ならターミナルから入力することで、標準出力にヘッダー情報が出てきます。
    そこの location: をみると
    • location: http://example.com/author/ユーザー名/
    になってユーザー名が見えてしまっています。これが存在しない場合、ユーザー名でない場合には何らかの対策がされているということになります。

    実際にウェブサーバーログをみると、
    ?author=1
    ?author=2
    ?author=3
    ?author=4
    ...
    など大量にスキャン(ポーリング)されているサイトもありました。

    ユーザー名が漏洩したからといって即座に問題になるとは限らない


    先に説明しておきますが、ログインのユーザー名が漏洩したからといって、それだけで不正ログインされるわけではありません。一般的にはパスワードが必要だからです。しかしながら、他のサイトとパスワードを同一(パスワードの使いまわし)をされていれば、もし他のサイトからパスワードが漏洩してしまうとログインできてしまいます。ですので別途ログインについては、下記のようなセキュリティ対策を施しておくのがよいです。
    • IPアドレス制限
    • 認証にクラウドサービス(Google認証等)をつかう
    • 総当り攻撃(ブルートフォース攻撃)への対策(一度に大量アクセスを防止)
    などです。そうすれば、たとえユーザー名が漏洩したとしても問題はなくなります。

    とはいえ、WordPress にどのユーザーがログインできているのか知られることは嫌ですよね。ですので対策したほうがよいでしょう。
    ここでは

    1. ウェブシステム側で止める
    2. WordPress プラグインで止める(自作)

    に絞って備忘録として残しておきます。

    対策1. ウェブシステム側で止める


    各ウェブサイトの設定において、先頭から
    • /?author=***  = 404エラーとする
    • /author/*** = トップページへリダイレクトする
    これが可能なら、WordPress に到達する前に止めることができるのでウェブサイトへの負荷が減ります。
    /author/** のケースは、 /hogehoge/author/** を除外するかどうかが、ややこしくなります。たとえばカテゴリー名に使った場合とかです。とはいえ、author は予約語でもあるので、まぁそこは除外するでよいでしょう。

    Apache での設定方法


    WordPress側では、RewriteBase が設定されているはずなので
    • RewriteRule ^\?author=(.*)? / [NC,R=404,L]
    • RewriteRule ^author/(.*)? / [R=302,L]
    の2つを追加すればよいです。
    管理者画面側では、?hogehoge=**&author=**
    となるので、管理者画面では除外できるはずです(未検証)。
    うまくいかなければ、RewriteCond ルールなどを併用すればいいでしょう。筆者は NGINX しかほぼ触っていないので、詳細は

    NGINX での設定


    nginx は if 文など条件を入れ子構造にできないという問題があります。
    したがって細かな条件を書くのが超大変です。
    ここではドメインやサブドメイン直下(http://example.com やhttp://hogehoge.example.com/) のように http://example.com/hogehoge というサブディレクトリに保存されていないと仮定すると、汎用性がある設定としては、

    set $rp_flag  flag;   
    set $rp_flag2 flag; 

    if ($request_uri ~ "^/wp-admin/"){
            set $rp_flag false;
    }
    if ($request_uri ~ "^/author/"){
            set $rp_flag2 "${rp_flag2}_true";
    }
    if ($args ~ "author=(.*)"){
            set $rp_flag "${rp_flag}_true";
    }
    if ($rp_flag = flag_true){ 
            return 404;
    }
    if ($rp_flag2 = flag_true){
            return 302 /;
    }


    上記コードでは、

    1. /wp-admin/ (管理画面)は対象外(リダイレクトしない)
     *つまり公開している側のみリダイレクトする
    2. /author/ か GETパラメーターに author= があるかのいずれか
    上記をすべて満たす場合に、トップページへリダイレクトする

    ということになります。
    「1」が必要な理由は、管理画面の投稿や固定ページ等で各ユーザーごとに一覧を表示するのに、author パラメーターが使われているためです。それは必要だろうという判断です。

    このように、フラグを文字連結させた上で、それを文字判定させる手法になります。
    さらに、requiest_uri に ? があるとパラメータ扱いになって、$args に保存されるという仕様もあってなおややこしい。

    参考:

    対策2. WordPress プラグインで止める(自作)



    ウェブサーバーのほうで止めることができない場合(設定をいじれない)もあると思います。その場合には、テーマの functions.php に書くなどの方法もありますが、サイトが大量にあるとやってられません。
    公式プラグインだと WP-CLIコマンドなどで一括インストールが可能になるので、その設定をしていれば、
    • wp @all  plugin install  プラグイン名  --activate
    プラグインを作成してそれを公式プラグインに登録しちゃえばよいのです。
    幸い筆者は WordPress の公式プラグインをいくつかアップして、メンテナンスしているのでそのあたりのやり方は知ってます。

    ただ問題はどのような手法で止めるのかがかなり悩みました。

    など速度低下が著しい模様。wp_safe_redirect をつかうのも同様じゃないかなぁと思います。そこで結局は
    で提示された方法を採用しました。また /author/ の場合を追加して、その場合にはトップへリダイレクトすることにしました。author=数字 は明示的に攻撃しているといってもいいですが、 /author/ はもしかして誤って入力したかもしれず、表示されないよりはリダイレクトにしたほうがいいかなぁという想いです。つまりは、
    1. 管理画面以外(公開されている部分のみ)に適用
    2. QUERY_STRING に「author」項目がある = 404エラー
    3. REQUEST_URI に /author/ があること =  トップへリダイレクト
    4. redirect_canonical にも対応し、自動補正時にもチェックが走るようにする
    という感じです。

    2020年3月11日 @kimipooh