ラベル 備忘録 の投稿を表示しています。 すべての投稿を表示
ラベル 備忘録 の投稿を表示しています。 すべての投稿を表示

2026年6月11日木曜日

WP-CLI で WordPress の Core バージョンアップが出来ない場合

いくつかのケースでそうした事例がでてきたのでまとめておきます。

なおこれまでの WP-CLI関連の記事は下記の通り


STEP 1. WP-CLIのバージョンが最新かチェックする


wp cli version

を実行して、バージョンを確認しましょう。それが最新かどうかは、下記のサイトを確認してください。


最新でなければ

wp cli update

を行う。なお、レンタルサーバーなどでは勝手に更新できない場合が多い。その場合には、
$HOME/bin にフォルダを作成して、そちらに wp をインストールし、こちらを使うという手もある。


STEP 2. サーバー上で apc.enable_cli = 1 が有効になっているか確認する


CLIでも APCキャッシュを扱えるようにする必要があります。
ただし、さくらインターネット等の場合、CLIについてはサーバー共通の php.ini のみ読むことができる設定になっており、コントロールパネルで apc.enable_cli = 1 を設定しても有効になっていない可能性があります。

この場合には、サーバーへSSHログイン可能なら、ログインした上で
ログインシェルの設定（.cshrc等）に、

さくらインターネットの場合

CSH系の場合
setenv PHPRC $HOME/www

BASH系の場合
export PHPRC=$HOME/www

のようにコントロールパネルで設定可能な php.ini を読み込むようにしてください。

これで更新できなければ、下記を参考にしてみてください。

うまくいかない場合


1. キャッシュメモリ系プラグインを無効化してみる


現時点で確認できているのは、APCu Manager プラグイン。こちらが有効な場合には、Core や プラグインアップデートが読み取れないことがある。

上記プラグインは、WP-CLI に対応しているため

wp apcu settings disable object-caching --yes

で一時的にオブジェクトキャッシュを無効化した上で、

各種アップデートをしてみるのがよい。
終わったあとは

wp apcu settings enable object-caching --yes

をして有効化するのを忘れないように。

2. それでも更新出来ない場合


WP-CLIのキャッシュをクリアみることがよい。

たとえば、WordPress の新しい Core があるのに、

wp core check-update

でアップデートがないと出てしまう場合には、

wp transient delete update_core

でキャッシュをクリアした上で、

wp core check-update

で確認してみるとよい。
もちろん「STEP 2. キャッシュメモリ系プラグイン」を使っている場合には、そのキャッシュを先に一時的に無効化してやってみること。

wp transient delete update_core　については、削除できなかったとでてきても、そのまま wp core check-update をしてみるとよいだろう。

うまくいったなら、

wp transient delete update_core; wp core update 

など連続してコマンド実行するようにしておけば確実だと思う。

どうしてもうまくいかないなら、
下記のようにすべてキャッシュをクリアしてから実行してみるとよい。

wp cache flash 


2026年6月11日 @kimipooh
2026年6月15日 加筆
2026年7月21日 加筆


投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2024年7月3日水曜日

【備忘録】WordPress.org で２段階認証を有効にする方法

突然、WordPress.org へのログインができなくなって ??? と思ったのですが、WordPres.org Plugin Directory からのメールをみて納得しました（6月29日に届いていた）。

件名：[WordPress.org] Password Reset Required for Plugin Authors

内容としては、一部のプラグイン作者がパスワードの使いまわしをしていて、そのパスワードが WordPress.org とは異なるサイトで漏洩してしまい、これを悪用されたかで WordPress.org のプラグインディレクトリのいくつかのプラグインに悪意あるコードを追加されてしまった模様という感じですね。

Password Reset Required for Plugin Authors – Make WordPress Plugins

一時的に全プラグインのコミットはチームによる承認制なって対策していたということです。現在は解除されているとのこと。

で、プラグイン作成者とセキュリティ研究者によって漏洩したとおもわれるパスワードを使っていたユーザーについて、WordPress.org へのログインパスワードを無効化（強制リセット）したということです。

プラグイン作成者は、パスワードのリセットが必要になったわけですが、同時に２段階認証を有効にするように推奨しています。というわけで私のパスワードも無効化されていたのでした。

WordPress.org は、2023年5月から２段階認証を導入していた


下記のようにプラグインコミッターは、少なくてもパスワードに20文字以上で、大文字小文字記号を含め、他のサービスで使いまわししないようにとあります。私自身はランダム生成のパスワードをつかっているので、使い回しはありませんが、パスワードは12文字だったので今回20文字以上にしました。

Keeping Your Plugin Committer Accounts Secure – Make WordPress Plugins

プラグインコミッターでなくても、アカウントへの不正アクセスを防ぐためにも２段階認証は有効にしたほうがよいですね！ 私もしていたつもりがしていなかったので今回してみました。

STEP 1. Two-Factor App と Two-Factor Backup Codes を有効にしてみる




下記にアクセスします。


Two-Factor Apps


あらかじめ、 スマートフォンに Google Authenticator や Microsoft Authenticator など２段階認証用のアプリをインストールしておきます。そして、Two-Factor App をクリックして、表示されたQRコードを、そのアプリで読み込みます。すると6桁の数字が一定時間ごとに変更されたものが表示されるので、その数字を入力して設定を完了します。

Tw-Factor Backup Codes


ここをクリックすると10個の緊急時用の１度のみ使えるバックアップコードが発行できます。もし２段階認証として使っていた端末やアプリが使えなくなったときにログインできるコードになります。どこかにメモっておきます。

STEP 2. Two-Factor Security Key を有効にする


最近流行りのパスキーです。

パスキーの詳しい話は、Googleの公式ヘルプあたりをチェックするとよいかなと思います。

パスワードの代わりにパスキーでログインする - Google アカウント ヘルプ

こちらは端末ごとに設定しておくことになります。パスキーに対応している端末をお持ちの場合には設定しておくと便利ではあります。

下記の「Register new key」をクリックして、名前をつけて設定します。
macOS をお使いなら、iCloud キーチェーンのほうに保存しておくのがよいでしょう。


設定するとパスキーがメインの認証方法になります。


STEP 3. 実際にログインを試してみる



各ブラウザについてプライベートモード（Cookieとキャッシュを無効化したログインしていない状態）にして、WordPress.org にログインしてみます。

アカウントとパスワードを入力すると、下記のようにパスキーを聞いてきます。
macOSと iPhoneをセットで持っているなら、iCloud キーチェーンで同期しているため、iPhoneのカメラで下記のQRコードを読み取ってアクセス。iPhoneのほうで認証します。iPhoneで顔認証を有効にしていれば、顔認証をすることで認証できることになります。

それができない（オンラインでない）場合には、「キャンセル」ボタンをクリックして、下記のようにエラーがでてきたら「User your authenticator app」を選択して、スマートフォンに設定したはずの認証アプリに表示されている WordPress.org 用の6桁の数字を入力すればよいです。この認証アプリについてはオフラインでの利用が可能です。


２段階認証を有効にしておけば、パスワードが漏洩したとしてもログインされることはなくなります。特にパスワードの使い回しをすると、他の脆弱なサイトで漏洩する危険性があるので、そうしないように気をつけないといけませんね

なおパスワードを考えつかない！という場合には、パスワード生成してくれるサイトは検索すればいろいろでてきます。そうしたものを活用してパスワードをランダム生成して、それをブラウザのパスワードマネージャーに保存する、メモするなどをしておくとよいかと思います。

2024年7月3日 @kimipooh
投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2024年6月21日金曜日

【備忘録】APCu の object caching が原因で WP-CLI の wp plugin list でプラグインの更新状況が確認できない場合の対処

PHP を利用したページ表示を高速化する APCu キャッシュを WordPress で有効化すると、かなりサイトの表示速度を向上することができます。利用するためには、PHP で APCu が有効になっている必要があります。たとえば、さくらインターネットやエックスサーバーなどのレンタルサーバーでは、標準で有効となっています。

WordPress でも手動の場合には、下記の方法もありますが、

何らかのプラグインを使っていることも多いはず。

以前は、WP-FFPCプラグインを使っていて、長期メンテナンスされておらず PHP8.0に非対応だったので対応させたりしてましたが、手動でやるのは限界があります。したがって、最近は APCu Manager プラグインを使っています。

 

WP-CLI の wp plugin list で更新が出てこない問題


下記のように、backwpup プラグインは 4.1.1 が最新であり、WordPress の管理画面にログインするとプラグイン更新画面には出てくるのに、WP-CLIでの update_version には出て来ない場合があります。 このことはずっと原因がわからなくて、ようやく「wp plugin list stopped working [with W3 Total Cache object caching] #1047」の情報にたどり着いたのでした。2014年からこの問題はあったのですねぇ。なおこの問題が起こった場合、WordPress 管理画面から設定するプラグイン自動アップデートも機能しませんでした。あくまで更新ボタンを押して手動で更新しなければ、更新できない問題があったということです。


% wp plugin list
+------------------+----------+--------+----------+-------------------+-------------+
| name             | status   | update | version  | update_version    | auto_update |
+------------------+----------+--------+----------+-------------------+-------------+
| apcu-manager     | active   | none   | 4.0.0    |                   | off         |
...
| backwpup         | active   | none   | 4.1.0    |                   | off         |
...
| object-cache.php | dropin   | none   |          |                   | off         |
+------------------+----------+--------+----------+-------------------+-------------+

このケースにおいては、APCu のキャッシュ機能を有効にしていた場合には無効にして試してみてください。下記のように更新がでてくれば、このキャッシュ機能と WP-CLI問題だということになります。

% wp plugin list
+------------------+----------+--------+----------+-------------------+-------------+
| name             | status   | update | version  | update_version    | auto_update |
+------------------+----------+--------+----------+-------------------+-------------+
| apcu-manager     | active   | none   | 4.0.0    |                   | off         |
...
| backwpup         | active   | none   | 4.1.0    |     4.1.1              | off         |
...
| object-cache.php | dropin   | none   |          |                   | off         |
+------------------+----------+--------+----------+-------------------+-------------+

対応方法


そもそも、WP-CLIをつかうのは、プラグイン更新を自動化したい目的もあるはず（ wp plugin update --all など）。となると、下記の一連の操作をしたいと思うはず！
  1. APCu の object caching を一時的に無効にして
  2. WP-CLI によるプラグインを更新して
  3. APCu の object caching を有効化
APCu Manager プラグイン は WP-CLI による制御が可能ため、このプラグインをつかうことで、うまくいきました。
  1. wp apcu settings disable object-caching --yes
  2. wp plugin update --all
  3. wp apcu settings enable object-caching

APCu Manager プラグイン の状況は、
wp apcu status 
コマンドでわかります。

2024年6月21日 @kimipooh
投稿者 時刻: 0 件のコメント:
ラベル: , ,

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 プラグイン名 で吐き出すてｓ）。ところが、いつの間にか PHP 7.3以上については Travis-CIが PHPUnit 8.x（PHP8.0.0-devは PHPUnit 9.x）を使うため、PHPUnit 7.x までしか対応していない ため、現行のWordPressでは下図のようにエラーがでて動かなくなっていました。１年前ぐらいは問題なかったのですけどね。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 は、２点古い書き方があります。

  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

投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2019年11月1日金曜日

WordPress のプラグインバージョンアップ中にブラウザを閉じたらどうなる？

WordPress のプラグイン更新方法は、WP-CLIなどコマンドラインからも可能です。それは脇において、WebブラウザからWordPressにログインし、「更新」よりプラグインを更新している途中に、ブラウザを閉じたらどうなるでしょうか。

のようなブログをみると、メンテナンスモードのままになるよって書いてあります。そのとおりなんでしょうが、こういったものは実際にテスト環境で体験してみるのが一番いいなと思ったのでやってみました。

ブラウザを閉じた時点で強制処理が終了する


実際にローカル環境にいれたマルチサイト環境のWordPress で試してみました。
するとサイトがメンテナンスモードになったままログインできない事態に・・・


この段階でブラウザを閉じてみると


のようにメンテナンスモードが解除されずにサイトにアクセスできなくなりました（運が良ければメンテナンスモードにならない）しました。こちらは、WordPress本体にできたロックファイル「.maintenance」を削除することでメンテナンスモードは解除できます。FTPなどでサーバーにログインする必要がでてきます。

このメンテナンスモード用ファイルを削除してプラグインを見てみると、更新中だった Loco Translate までは更新できていて、あとは残っている感じですね。


基本的に WP-CLI のコマンドラインでサーバー上で自動アップデートしているので気にしていませんでしたが、ブラウザ上でやるのってネットが不安定だと問題が発生するんだなぁと思った瞬間でした。。。（ネット不安定な海外からやっちゃうと危ないってことか）。場合によってはプラグインが壊れて、壊れたプラグインを探し出して一旦削除しないと駄目なんて事態になるかもしれません。なんでも試して見るものですね。

2019年11月1日 @kimipooh

投稿者 時刻: 0 件のコメント:
ラベル: ,

2018年3月13日火曜日

【備忘録】nginx 1.13.9 で実装された http2_push_preload を WordPress で使ってみよう！

WP-CLI チームメンバーとして有名な宮内氏が作成した

についての情報をキャッチしたので、実際に試してみました。
ちょっと戸惑った点もあったので、本ブログにて備忘録として残しておきます。

準備


  • nginx 1.13.9（CHANGE LOG）
  • PHP 7 以降
  • WordPress 4.9 以降
  • https://◯◯ なサイト
です。準備については割愛します。
また、macOS のターミナルからチェックする方法として、Homebrew をインストールしているなら
  • brew install nghttp2 
として nghttp コマンドをインストールしておくと便利です。

Server PUSH の概要


情報は古いですが、
にわかりやすく解説されているかなぁと思います。
また、
も分かりやすいかも。ようするに、リクエストされたファイル内で別ファイルを読み込んでいると、１ファイルずつやりとりせずに、一括でやってしまえという考え方。

HTTP2_PUSH で動作確認


まずは WordPress 内の１ファイルを対応してみましょう。
別に WordPress 内である必要はありません。

server{
    listen 443 ssl http2;
    ...

    location / {
      ...
      ...
      proxy_buffer_size   128k;
      proxy_buffers   4 256k;
      proxy_busy_buffers_size   256k;
      http2_push_preload on;

      http2_push /wp-content/themes/△△/top_bg.jpg;
      ...
     }
}

nginx の server 直下か、location 内に、ファイルごとに http2_push で指定します。
※ この技術は https かつ HTTP/2.0 を有効にしたサイトじゃないとダメです。
※ WordPress だと管理画面だけ https の場合もあるので、サイトまるごとでなくてもいけるとは思います。

いずれも Chrome の Developer Toolsを開いて、Networkにて確認しています。
その際、キャッシュを無効にするために「Disable cache」にチェックをいれています。


設定前
Intiator = (index)

設定後
Intiator = Push / (index)


もし nghttp をインストールしてしているなら
nghttp  -nv  https://◯◯/  | grep PUSH_PROMISE
のように、サイトトップで読み込まれる https://◯◯/wp-content/themes/△△/top_bg.jpg について、Server Push に対応している表示がされます。

なおディスクキャッシュが優先されるようで、キャッシュされていたら Push は出てきませんね。 

ということで、１ファイルごとの設定は使えたので Server Push は使えてるということになります。あとは、 http2_push_preload のほうを利用できるように WordPress に組み込みます。http2_push_preload のほうは、適切な Link ヘッダーを出せばいいので、それをやってくれるプラグイン「HTTP/2 Server Push」（宮内氏作成）をインストールします。

HTTP/2 Server Push プラグインの概要


このプラグインは、ソースの lib/function.php を見てみると
  1. wp_enqueue_style と wp_enqueue_script で読み込まれた CSS と JavaScript を読み取って Link ヘッダーを出す
  2. フィルタフック「http2_server_preload_items」で指定したファイル
    ※ https://github.com/tarosky/http2-server-push-preload の Customizing 参照
を読み取って LINK ヘッダーを吐き出すようです。
なので、テーマによって style.css に @import とかで CSSを読み込ませていると、「１」には引っかからないので、「２」で個別指定する必要があります。

HTTP/2 Server Push プラグインのインストール


  1. https://github.com/tarosky/http2-server-push-preload/releases より  http2-server-push-preload.zip をダウンロードする
  2. 展開したフォルダを、WordPress のプラグインフォルダへ入れる
  3. WordPress 管理画面より、「Http2 Server Push」 プラグインを「有効化」する

とまぁこれが一般的かと思いますが、composer と WP-CLI が導入されているサーバーだと（※注意：下記の方法だと、 nightly バージョンになりました。管理画面のプラグインやテーマの更新から安定版への更新 0.5.0 が出来ました）

cd WordPressのインストールフォルダ
cd wp-content/plugins
git clone https://github.com/tarosky/http2-server-push-preload
cd http2-server-push-preload
composer install
cd ../../../
wp plugin activate http2-server-push-preload

なんかで、ソースをダウンロードしてインストールして WP-CLI でプラグインを有効化するまでをコマンドラインで出来ます。

動作確認


※ここでは、macOS 10.13.3 にいれた valet 環境を使って WordPress をインストールし、試しています（ https://demo.test ）。

brew upgrade nginx
sudo brew services restart nginx 

として、nginx 1.13.9 をインストールして nginx を再起動しておいてください。
そして、 $HOME/.valet/Nginx/demo.test の server セクションに
  
のように、 
      proxy_buffer_size   128k;
      proxy_buffers   4 256k;
      proxy_busy_buffers_size   256k;
      http2_push_preload on;  
を追加しておきます。
そして
sudo brew services restart nginx 
をして nginx を再起動しておきます。
※ valet については【備忘録】 wp valet new コマンドで Error establishing a database connection が出る あたりを参考にしてみてください。


Chromeで サイトにアクセスして、Developer Tools を開きます。
Network タグで「Disable cache」にチェックをいれて、サイトを読み込み直します（Command+r）。
すると、下図のように CSSやJavaScript ファイルの Intiator が「Push」となっていたらOK。


そして、http2-server-push-preload プラグインを無効にすると下図のように、Push ではないことが確認できるはずです。


ただし、テーマによって style.css に直書きとか、@import を使ってCSSを読み込んでいると、このプラグインの対象外になります。その場合には、管理画面で試してみて下さい。大抵のプラグインは、CSSやJavaScriptを読み込む時に、正しい手順をしていると思うので、うまくいくはずです。まぁ最悪サイトそのものには適用できなくても、管理画面は適用できて速くなる！ってことはあるかもしれませんね。

2018年3月13日 @kimipooh

投稿者 時刻: 0 件のコメント:
ラベル: , ,

2018年3月12日月曜日

【備忘録】 wp valet new コマンドで Error establishing a database connection が出る

WordCamp Kyoto 2017 に参加して #wckyoto2017 で Valet + WP-CLI によって、手軽に手持ち macOS に WordPress のテストサイトを立ち上げる環境を構築したのですが、

wp valet new demo

などと https://demo.dev を作成しようとすると、

Error: Error establishing a database connection. This either means that the username and password information in your `wp-config.php` file is incorrect or we can’t contact the database server at `localhost`. This could mean your host’s database server is down.

というエラーがでてまともにインストールできなくなってしまいました。筆者だけの環境でそんなようなことが起こる可能性もありますが、何かのトラブルシューティングに使えるかもしれませんので、どういう対策をしたのか備忘録として残します。

準備


macOS に Valet や WP-CLI を導入する方法は割愛します
WordCamp Kyoto 2017 に参加して #wckyoto2017 あたりや他のサイトをチェックしてみてください。

.dev ドメインのままなら、 .test ドメインに変更しておくこと
  • valet domain test
すると
$HOME/.valet/config.json 
"domain": "test" 
$HOME/.valet/dnsmasq.conf 
address=/.test/127.0.0.1

と変更されているはず。

wp-config.php の DB_HOST の値を 127.0.0.1 にする


define( 'DB_HOST', 'localhost' );

だとエラーがでて、

define( 'DB_HOST', '127.0.0.1' );

だとうまくいくので、これを直して WordPress をインストールするといけるということ。wp valet new では、DB_HOSTの設定はいじれないので、ちょっと工夫が必要。

https://demo.test の作成手順


便宜上、Valet のインストールフォルダは、$HOME/valet とする

cd $HOME/valet
valet park
valet secure demo
wp valet new demo
cd demo
rm -f  wp-config.php
wp core config --dbhost="127.0.0.1" --dbname="wp_demo" --dbuser="root" --dbpass=""
wp core install --url="https://demo.test" --admin_user="admin" --admin_password="admin" --admin_email="sample@example.com" --title="demo"


という一連のコマンドでもって、 https://demo.test に WordPress を導入できます。
wp valet new コマンドで、WordPress 本体のダウンロードまでは出来るけれど、WordPress のインストールでエラーになります。そこで、valet によって作成された wp-config.php を削除して、wpコマンドで改めて作成し、WordPressをインストールするとうことです。
valet は、データベースのパスワードはなし（初期）なので、同じようにしてます。
また説明上、WordPressのログイン ユーザー名とパスワードは共に admin にしてます。

2018年3月12日 @kimipooh
投稿者 時刻: 0 件のコメント:
ラベル: ,

2017年9月9日土曜日

【備忘録】WordPress の カスタムフィールドの日付で、日別アーカイブを生成するには

WordPress.org 日本語フォーラムで
という質問があり、実際に試して回答しました。
これについての情報が見当たらなかったので、ここで備忘録としてメモしておきます。どういう考えて修正してうまくいったのかも書き出しておきます。SQL文の勉強になるかもですよ！　それに筆者も、またどこかで使えるかもしれませんので、残しておくのは役立ちます。

やりたいこと


記事のアーカイブを、各記事に設置した カスタムフィールド（date_field）に沿って、日別アーカイブ表示したいというもの

2017/09/02 (1)
2017/08/19 (2)
2017/07/02 (3)

とかそういう感じに出すってことです。
そして日付をクリックしたら、カスタムフィールド（date_field）の日付が一致したものの一覧がでるということですね。


がちょうど年月のアーカイブができるので、これに日をたせればできるんじゃない？ってことで実際にやってみました。

前提


管理ダッシュボード > 設定 > パーマリンク
で投稿に対して、日付（年月日）が付与されるようにしてください。



利用方法


Step 1. テーマの functions.php に下記のソースコードを追加


ソースコード：https://ideone.com/BavQDi

Step 2. 表示するコードを追加（例  index.php）


ここでは説明のために デフォルトテーマ「Twenty Seventeen」の index.php に書き込み、トップページの記事の一番上に表示するようにします。


下記のコードを図のように if ( have_posts() ) : の下に追加してみてください。

my_get_year_archives( array(
'date_field' => 'date_field',
) );




そうすればトップページに日付一覧が降順に表示されるはずです。

【WordPress】カスタムフィールドの日付でカスタム投稿の年月別アーカイブ（pronet）では、カスタムフィールド（date_field）は、YYYY/MM/DD （2017/07/02）を元にしていました。このあたりはいろいろ変更できます。
さて備忘録なので、実際にどういう変更をしたのかも説明しておきます。

変更点


変更１）カスタムフィールドの値から 年月だけでなく 日も取り出すSQL文に書き換える


$select = "SELECT SUBSTRING($field,1,4) AS `year`, SUBSTRING($field,6,2) AS `month`, SUBSTRING($field,9,2) AS `day`, count(p.ID) AS posts";

$query = "$select FROM $wpdb->posts AS p $join $where GROUP BY SUBSTRING($field,1,4), SUBSTRING($field,6,2), SUBSTRING($field,9,2) ORDER BY $field DESC $limit";


赤い部分の追加です。
YYYY/MM/DD 、１文字 = 1バイト（1バイト英数記号）と仮定すると、
  • 1,4 = 1文字目から４文字分（YYYY）
  • 6,2 = 6文字目から2文字分（MM）
ときたらもうわかりますよね。
  • 9,2 = 9文字目から2文字分（DD）
を付与すればよいということです。

※全角（日本語）のように ２０１７／０８／１９ とした場合に、SQLクエリの方でなんとかしたいなら、CATをつかうとよいようです。


変更２）HTMLコード出力に日データを追加


$url = add_query_arg( array( 'meta_key' => $date_field ), get_day_link( $arcresult->year, $arcresult->month, $arcresult->day) );

$text = sprintf( '%d', $arcresult->year ).'/'.sprintf( '%02d', $arcresult->month ).'/'.sprintf( '%02d', $arcresult->day );

->year, ->month, ->day の year, month, day については、変更１）の AS `year`、 AS `month`、AS `day` に紐付いています。

<li><a href='https://demo.dev/2017/09/02/?meta_key=date_field'>2017/09/02</a>&nbsp;(1)</li>
<li><a href='https://demo.dev/2017/08/30/?meta_key=date_field'>2017/08/30</a>&nbsp;(1)</li>
<li><a href='https://demo.dev/2017/07/02/?meta_key=date_field'>2017/07/02</a>&nbsp;(1)</li>

のようなコードが出力されます。

変更３）WordPress の検索クエリのカスタマイズに日を追加


下記の赤文字の部分が追加分です。
WordPress での投稿日付は、年 = year、 月 = monthnum、日 = day に保存されます。
ので下記のような追加になります。

function my_pre_get_posts( $query ) {
    if ( $query->is_day ) {
        $meta_query = array(
            array( 
                'key'     => $query->get( 'meta_key' ),
                'value'   => $query->get( 'year'     ).'/'.sprintf('%02d', $query->get( 'monthnum'     )).'/'.sprintf('%02d', $query->get( 'day'     )),
                'compare' => 'LIKE'
            ),
        );
        $query->set( 'meta_query' , $meta_query );
        $query->set( 'year'             , ''          );　
        $query->set( 'monthnum'   , ''          );
        $query->set( 'day'   , ''          );
        $query->set( 'date'       , ''          );
        $query->set( 'meta_key'   , ''          );
        $query->set( 'post_type'  , 'post');
    }
}

2017.9.9 @kimipooh

投稿者 時刻: 0 件のコメント:
ラベル: ,

2017年3月7日火曜日

【備忘録】WordPress 4.7.3 で修正されたメディアアップロードの中身

【備忘録】WordPress 4.7.1 よりメディアアップロード時のMIMEチェックにファイル本体のチェック機能が付与されていた・・・ で finfo_open 関数の問題でアップロードできないファイルが出てきた問題について、
にて、WordPress 4.7.3で修正されるよ〜という情報があったわけですが、実際にはどうなったのでしょうか。
をみても、原文にも書かれてません。
ならばとコードをチェックしてみました。


wp-include/functions.php
2316行〜2334行 ( wp_check_filetype_and_ext 関数内）

の部分ですね。
そして今回変更があったのは、 2322〜2333行でした。

変更前


If ($real_mime !== $type) {
  $type = ext = false;
}

finfo_open でアップロードされたファイルのコンテンツをチェックした上でのMIMEタイプ（$real_mime）と、アップロードされたファイルの拡張子に割り当てられたMIMEタイプ（$type）とが一致しなければ、セキュリティを理由のブロックしていました。


変更後


if ( $real_mime && ( $real_mime !== $type ) && ( 0 === strpos( $real_mime, 'application' ) ) ) {
    $allowed = get_allowed_mime_types();
    if ( ! in_array( $real_mime, $allowed ) ) {
            $type = $ext = false;
    }
}

  1. finfo_open でアップロードされたファイルの中身をチェックし、MIMEタイプデータ（$real_mime）がある。
  2. 「１」のMIMEタイプ（$real_mime）とアップロードされたファイルの拡張子に割り当てられたMIMEタイプ（$type）と一致しない
  3. 「１」のMIMEタイプ（$real_mime）データが「application」から始まる場合
  4. 「１」のMIMEタイプ（$real_mime）が、WordPress のMIMEタイプ（$allowed）に登録されていない

この４つの条件を「すべて」満たす場合のみ、セキュリティを理由にブロックする。

と変更されていますね。
つまり変更後は、このMIMEチェックがかなり限定されてますね。
  • アップロードしたファイルの中身と拡張子が一致しない場合、中身チェックのMIMEが application の時のみ、WordPressに登録されたMIMEかどうかチェックする

具体例


テキストデータ（sample.txt）の拡張子だけ pdfに変更（sample.pdf）し、これをアップロードしてみました。

  • finfo_open でのMIMEタイプは「text/plain」($real_mime）
  • アップロードファイルの拡張子に割り当てられたMIMEタイプは「application/pdf」（$type）

となります。このケースでは、変更後にはアップロードできちゃいます。
なぜなら、「３」の条件に当てはまらないから（finfo_open でチェックしたMIMEタイプ が application で始まってないから）。

もちろん、今回紹介したチェックは finfo_open を使ったチャックの部分であり、それ以前に、WordPressに登録されたMIMEの拡張子以外はアップロードできないようチェックがあります。
なので、sample.jpeg2002 とか適当な拡張子にしてもアップロードはできませぬ。
まぁただ、 sample.png を sample.txt にしてもアップロードできちゃいますけどね、、、このあたりは WordPress 4.7.1以前に戻ったよ〜って感じでしょうね。

2017年3月7日 @kimipooh

投稿者 時刻: 0 件のコメント:
ラベル: ,

2017年2月14日火曜日

【備忘録】JetPackプラグインの「タイルギャラリー」の落とし穴に注意！

WordPress の JetPackプラグイン内にある「タイルギャラリー」について、ちょっと特殊な問題が起こって解決したのでメモっておきます。

制限サイトではギャラリーが表示できない


制限サイトとは、IPアドレス制限やパスワード制限されたサイトのことです。
よく準備中のサイトって一部メンバーのみチェックのために、そういった設定にしていることはありませんか。

どうやらその場合には、タイルギャラリーのギャラリーデータの画像が表示できないようです。このタイルギャラリーは、WordPress.com の CDNを通じて提供されており、画像としては ***.wp.com で生成された画像を表示することになります。制限されたサイトでは、生成された画像が GETできない（400エラー）となります。制限を解除して、キャッシュ系プラグインやシステムがあるなら、キャッシュをクリアすると問題なくでます。

以上から、WordPress.com 側がサイトの画像から直接データを取得してコンバートして CDN として提供しているのじゃないかなーと思います。なので、サイトへのアクセスが制限されていると画像が取得できなくて生成できないのかなぁと。

ただ一度サイトのアクセス制限を解除してタイルギャラリーができあがれば、再度サイトのアクセス制限をしてもギャラリーは残ります。

でも毎回やるの面倒だよ〜


その場合には、WordPress.com からのサイトへのアクセスを許可すればいけました。IPアドレスの細かい範囲は分からないので、パスワード保護されたWordPressを WordPress.com で管理するためには で以前調べた Automattic社の IPアドレス群をまるごと許可しました。
  • 192.0.64.0/18
ですね。実際に CDNは、 i0.wp.com とか i1.wp.com とかいくつかあるようで、それらはカバーしてそうです。BASIC認証をしているなら

Nginx
     satisfy any;
     auth_basic  "Hogehoge---";
     auth_basic_user_file /hogegegege/.htpasswd;
     allow 192.0.64.0/18;

Apache
   Order Deny,Allow
   Deny from all
   Allow from 192.0.64.0/18;
   AutoType Basic
   AutoUserFile  /hogegege/.htpasswd
   require valid-user
   Satisfy Any;

のように、Satisfy Any で OR条件にした上で、IPアドレス許可を追加すればいけまーす。

2017年2月14日 @kimipooh

投稿者 時刻: 0 件のコメント:
ラベル: ,

2017年2月9日木曜日

【備忘録】WordPress の古いバージョンもセキュリティメンテナンスリリースされているけど、安全なのか

ちょっと内輪で質問されたことを受けて、調べてみても情報がなかなか見つからなかったので、フォーラムで質問してみました。皆さんからいろいろ回答頂いてやりとりしていたのですが、調べていくうちに、Make WordPress Core の Handbook に回答を見つけました。忘れない内にメモっておきます。

最新版以外は非推奨


つまりは結論的にはそうだったのでした。
確かに WordPress バージョン一覧（WordPress Codex 日本語版）をみると、WordPress 4.7.2 がリリースされた 2017年1月26日付で、WordPress 3.7以降のすべてのバージョンのマイナーバージョンがリリースされています。過去バージョンも、https://wordpress.org/download/release-archive/　よりダウンロード可能です。
WordPress.org フォーラムのモデレーターも、フォーラムにて、WordPress 4.6.2は 4.7.1（同時にリリース）のセキュリティフィックスをすべて含んでいるよという発言をされてます。

しかしながら、上記ダウンロードサイトの冒頭にも書かれていますが、
のSecurity項目の冒頭を抜粋すると

== 抜粋 ==
In the case of a purely security release, all patches should be created well ahead of time. Different patches may be necessary for trunk and stable branches. Currently, we make an effort to back port patches to all versions of WordPress that support autoupdates (3.7+). However, back porting patches is not always possible and those versions of WordPress are not officially supported as a result.
========
のように、自動更新を実装した WordPress 3.7以降のすべてのバージョンについて、可能な限りセキュリティリリースをするよう務めるけれど、すべてをフィックスできるわけではないし、公式にサポートいません。

と書かれているではないですか。
となると公式にサポートされている最新版以外は非推奨。ってことなのですよね。
確かに 一つ前のバージョンぐらいは全部フィックスされる可能性は高いですが、しかし保証されているわけではないのでアップグレードして対応するのが推奨ってことですねぇ。



なるほど〜って思った今日この頃でした。

P. S.
いろいろな事情でメジャーバージョンアップできないケースも多々あると思います。WordPressでは 3.7というかなり古いバージョンも、できる範囲でしょうが頑張ってセキュリティフィックスされている開発者の皆様には脱帽です。


2017年2月9日 @kimipooh

投稿者 時刻: 0 件のコメント:
ラベル: ,

2016年10月21日金曜日

【備忘録】カスタム投稿で記事コピー出来るプラグイン Duplicate Post が動かなくなった！？

ここ最近バタバタしていて使っていなかったのですが、あれ？下書きモードで記事をコピーできる「新規下書き」がなくなってるなと気づきました。

Duplicate Post プラグイン 3.0.0 の新機能の問題か


3.0.0 より、Duplicate Post の設定内の権限項目が付与され、投稿タイプによってこのプラグインを有効無効にできるようになりました。どうやらデフォルトは、投稿と固定ページのみのため、カスタム投稿はOFFになっていたのが原因でした。

すべてのサイトでは検証していないので、特殊な要因かもしれませんが、ここ最近 Duplicate Post プラグインがカスタム投稿で動かないな−と思ったら、設定をご確認あれ〜

2016年10月21日 @kimipooh


投稿者 時刻: 0 件のコメント:
ラベル: ,

2016年9月12日月曜日

【備忘録】特定の親カテゴリー以下の子孫カテゴリー情報を収集したい

ちょっとしたきっかけで試してみたので、備忘録メモとして残しておきます。

事例）親カテゴリー（記事）のID=2に属する、子、孫以下のすべてのカテゴリーIDを収集


$parent_id = 2;
$children_ids = array();
$term_children =  get_terms( 'category', array('child_of' => $parent_id) );

 if($term_children){
  foreach($term_children as $child){
     $children_ids[] = $child->term_id;
  }
}

がもっとも短いコードかなーと思います。
ここの、 $term_children をチェックすることで、カテゴリー名やスラッグなども収集できますね。特定カテゴリーにの子孫の記事情報を表示したい、非表示にしたいなどのときも活用できそうです。

2016年9月12日 @kimipooh

投稿者 時刻: 0 件のコメント:
ラベル:

2016年7月26日火曜日

【備忘録】公開日時を投稿内容の任意の場所に表示させる方法（＋有効期限を表示する方法）

WordPress.org 日本語版フォーラムでのやり取りで解決した内容です。
今後使うこともありそうなので、備忘録としてここに残しておきます。



公開日時を投稿の好きな場所に表示させる


テンプレートを利用する方法などいろいろ方法はありますが、もっとも単純かつ分かりやすい方法は、the_content に対するフック（割り込み）を利用して、特定文字を置換することです。「いや、ショートコード作れよ！」ってツッコミが入りそうです。うむ、ならば単なる備忘録じゃなくてショートコードでやってみますか！
フックを用いる方法は、上記フォーラムで提示したコードを参照してみてください。

■ functions.php に追加

続きを読む »
投稿者 時刻: 0 件のコメント:
ラベル: ,

2016年7月1日金曜日

【備忘録】WooCommerce 2.6.2（プラグイン）で日本の郵便番号についてはハイフンが自動付与される機能が実装

WooCommerceでの日本の郵便番号でハイフンを入れたい (WordPress.org 日本語版）でのやり取りを経て、実装されたっぽいので備忘録としてメモっておきます。
私自身はこのプラグインは使っておりませぬ (^^;

今回の修正で、日本、ポルトガルの補正が追加されたようです。
日本は、XXXYYYY --> XXX-YYYY、ポルトガルは、XXXXYYY → XXXX-YYY に登録時に自動補正されるってことですね（つまりハイフンありなし関係なく、ハイフンありに補正されて登録される）。

下記は左が 2.6.1 、右が 2.6.2 の includes/wc-formatting-functions.php のソースの該当部分です。




ちょっと動作について調べてみた

続きを読む »
投稿者 時刻: 0 件のコメント:
ラベル: ,

2016年6月29日水曜日

【備忘録】WordPressサイトを常時SSL化（http:// → https://）したときのメモ（nginx / http2.0編）

常時SSL化そのものはいろいろ情報がでているので割愛。
ここでは自分でやってみて引っかかった点を備忘録メモしておきます。

自分用なので、次の前提があるとします。

  • サーバーにログインでき、ファイルへの書き込み権限があること
  • WP-CLIが使えること
  • find / grep / sed / egrep コマンドが使えること

データベースの書き換え


  • wp search-replace  http://◯◯  https://◯◯  --skip-columns=guid

WP-CLIを使うと簡単ですね！
※ --skip-columns=guid は、GUIDを変更しないというものです。公開前サイトからURL変更する場合には不要ですが、それ以外は基本的に GUIDの置換はしないことが望まれています。詳しくは、WordPress のドメイン名やURLを変える際の GUID 問題のちゃんとした話（CAPITAL P）で詳しく解説されているので参考にしてみてください（2017.01.25追記）

テーマ内ファイルの書き換え

続きを読む »
投稿者 時刻: 0 件のコメント:
ラベル: ,

2016年4月27日水曜日

【備忘録】nginx + fastcgi のアップロード容量サイズと WordPress Download Monitor の rewrite 設定について

2点結構悩んだので纏めておきます。

nginx + fastcgi のアップロード容量サイズ


デフォルトは 4MBになっています。
これを32MBに拡張しようとすると、

nginx.conf（nginx 設定）

 client_max_body_size 32M;

php.ini（PHP設定）
  post_max_size = 32M
  upload_max_filesize = 32M

php-fpm （FastCGI設定）
  php_admin_value[upload_max_filesize] = 32M
  php_admin_value[post_max_size] = 32M

の３つをチェックしてみてください。特にphp-fpm は忘れていたので盲点でした。

続きを読む »
投稿者 時刻: 0 件のコメント:
ラベル: ,

2016年2月10日水曜日

パスワード保護されたWordPressを WordPress.com で管理するためには

所有のWordPressを JetPackプラグインを介在し、WordPress.comでサイトの一元管理ができることは知っている方も多いと思います。これは2014年12月に実装されて随分経っているので今更なのですが、ようやく重い腰をあげて対応してみました。

まぁ通常だとそんなに躓かないのですが、BASIC認証などによってパスワード保護されたWordPressについてはちょろっとしたコツがいるので合わせて備忘録としてメモしておきます。

XMLRPC対策をしている場合


現在WordPressで標準搭載されているxmlrpc機能（/xmlrpc.php）は、WordPressから直接ログインせずにWordPressを管理できる機能を有しています。たとえば Microsoft WordからWordPressの記事を更新できますし、それ以外の対応ソフトからもxmlrpc.phpを介在してコンテンツを閲覧したりテーマ変更したりなどが可能です。

しかしながら、ここへの総当たり攻撃をされるとサイト全体がとても重くなったり、xmlrpc.php 自体に脆弱性があった場合には不正アクセスされる恐れもあります。

従って外部からのアクセスを遮断しているケースも多いかと思います。

そういう場合には、サーバーの設定で（.htaccess等）

<Files ~ "xmlrpc.php$">
  allow from 192.0.64.0/18
  deny from all
</Files>

をしているケースも多いと思います。
192.0.64.0/18 は、Automattic社が管理するIPアドレス全体。

xmlrpc.php は基本拒否するけれども、JetPackと連携するために WordPress.comからのアクセスのみは許可したいということです。どの範囲か分からないので、JetPackやWordPress.com提供元のAutomattic社のIPアドレスまるごと許可しているというわけです。

しかーし、サイト丸ごとパスワードロックしている場合にはダメで・・・

通常はそれでいけるのですが、このケースが厄介です。
サイトを見られたくないけど、xmlrpc.php のみ アクセスして欲しいという要望はあるわけです。そういう場合には、Satisfy設定を使いましょう。

<Files ~ "xmlrpc.php$">
  allow from 192.0.64.0/18
  deny from all
  Satisfy Any
</Files>

とまぁ一行追加するだけです。
これで、BASIC等認証をかけていた場合、OR判定になります。

つまりBASIC認証をかけていたとしても、xmlrpc.phpへのアクセスだけ、 192.0.64.0/18 からはBASIC認証を迂回して普通にアクセスできるようになります。

間違っても、サイト丸ごとのBASIC認証に対して、 192.0.64.0/18をSatisfy Anyに設定することはしないようにしましょう。それやっちゃうと、Automattic社のネットワークからローカルなサイトが丸ごと閲覧されちゃいますよ〜。

付録：あれ？JetPackプラグインいれたら画像が表示されなくなったけど？

とりあえず、JetPack設定より、Photonを無効にしてみてください。

を見ると、キャッシュが適応されるまで時間がかかるからってことですね。
しかしならばデフォルトでONにしている以上、そのことの注意喚起がないと困りますねぇ。またサイト丸ごとパスワードロックしているサイトで、有効にして2日経っても画像が表示されませんでした。もしかしたらサイトまるごとパスワードロックしている場合には、キャッシュできないのかもしれませんね。

2016年2月10日 @kimipooh
2016年2月12日 付録を追加

投稿者 時刻: 0 件のコメント:
ラベル: ,

2015年8月18日火曜日

【備忘録】 WPMLプラグインの自動更新方法（WPML 3.1.7以降） #wpml

WordPress - Installer プラグインが激重な件 #wpml で、WPML 3.1.7以降で InstallerプラグインをインストールするとWordPressが激重になるという記事を書きました。

結論

  • Installerプラグインは、WPML3.1.7リリースを持ってサポート打ち切りしたので削除してください。
という回答を得ました。ただ、それはまぁわかっていたのｄすが問題は、


にInstallerプラグインの導入が推奨されていることにあります（アーカイブではあるのですが、検索上位にひっかかる）。
ただやり取りするのが面倒（時間ない...）になってきたのと、すでにInstallerプラグインはリンク先からダウンロードできないので、もういいやーって思いました。
でも、もしWPML 3.1.6以下を使っていて、さらにInstallerプラグインで自動更新を構築している場合には、WPML3.1.7以降にアップデートすることで問題起こる可能性があるので纏めておきます。

WPML 3.1.7以降は英語版ドキュメントを見よ！


続きを読む »
投稿者 時刻: 0 件のコメント:
ラベル: , ,

2015年8月13日木曜日

WordPress - Installer プラグインが激重な件 #wpml

ここ最近、管理画面のみ激遅（何か動作させるのに30秒〜1分ぐらいかかる）ってことで、今日一日チェックしていました。

最初はApacheやMySQL、PHP周りをチェックしましたが、WordPressの特定サイト以外は特に遅いとは感じませんでした。まぁ若干チューニングアップはしましたので、他のサイトが少し速くなったのはよかったかもね。

結論からいうと、WPMLプラグインの自動更新を提供する「Installer」プラグインが犯人でした。こいつを停止すると、約7倍速くなりました... とても気づきにくいのでメモしておきます。

今回の現象

管理画面のみ応答が遅く、よく「接続が切れた」というメッセージが出て使いものにならないレベルになった。ウェブサイトの表示側は問題なし。

続きを読む »
投稿者 時刻: 0 件のコメント:
ラベル: , ,
登録: 投稿 (Atom)