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

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 は未検証です。

PHPUnitと PHPの対応表（PHPUnit）

付録（後述）で、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> -->）

の三点です。

詳細は

https://github.com/kimipooh/view-shortcodes

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

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

matrix キーは、jobs キーへ変更（matrixはjobsへのエイリアス）したので、今後は jobs キーを使うこと
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.

とでます。

WordPress and PHP 8.0

をみる 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（シェル）
プラグインテストの準備

WordPressでテスト駆動開発(PHPUnit)〜インストール編を参考に、wp scaffold plugin-tests でPHPUnitテスト環境を構築しておきます。

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月2日月曜日

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

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

204 recv() failed (104: Connection reset by peer) while reading response header from upstream

これは時間がかかり過ぎて接続が切れたというものです。

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

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

次の３つの数値を調整する。

proxy_buffer_size 64k;
proxy_buffers 4 128k;
proxy_busy_buffers_size 128k;

調整については「nginx-WordPress リバースプロキシにおけるバッファの最適化」を参考にした。

今回は、赤文字の部分を

proxy_buffers 100 128k;

とすることで問題解決できた。

ようは、バッファーの受け皿としてバッファーサイズが足りていないのではなく、最大個数がたりていなかった（4→100とした）のだった。

PHPの調整

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

max_input_vars を 1000→2000

参考：「カスタムメニューを追加すると別のメニューが消えていく現象への対策」
php_admin_value[max_input_vars] = 2000

client_body_buffer_size, client_max_body_size を容量大きくしてみる

nginxのリクエストボディのバッファリングに関する問題とその改善策 (Qiita)

opcache.memory_consumption, opcache.max_accelerated_files を大きくしてみる

参考：「recv（）が失敗しました（104：ピアによって接続がリセットされました）が、アップストリームから応答ヘッダーを読み取り中です」
PHPの opcacheモジュールの設定変更

php-fpm 設定でタイムアウト関連変更

参考：Nginx+PHP-FPM環境でtimeout対応
request_terminate_timeout
php_admin_value[max_input_time]
php_admin_value[max_execution_time]

php-fpm 設定で、メモリを増やす

php_admin_value[memory_limit]

2020年11月2日 @kimipooh

2017年9月1日金曜日

WordPress 公式プラグインに PHP 対応バージョンを表記できるように（でもまだ必須じゃない）

まだ単なる表記だけのようですが、そのうち必須になる流れなのかなと思います。
現状 PHP7 以降しか使えない三項演算子「??」が使いたくてウズウズしていたので、必須になったら気兼ねなく使えそうですね！

書き方

WordPress公式プラグインリポジトリが対応PHPバージョンの表記に対応（@高橋文樹氏）

などに詳しく説明されていますが、筆者自身への備忘録のためここでも説明しておきます。

readme.txt に「Required PHP: バージョン」を追加せよ！
ってことですね。実際には下記のような感じです。
このプラグインは PHP 5.3 以降（三項演算子 ?: 使っているので）が必須ですが、PHPのサポート状況を考えることとテスト環境が PHP 5.6.x と 7.0.x と 7.1.x なので、表記するなら PHP5.6 からかなぁと。

これが Required at least （WordPress のバージョン）のようにインストール時の必須項目になったら、三項演算子「??」をつかいまくってやる！！

と密かに思っているのでした。

ちょうど、 PHP カンファレンス関西 2017 で三項演算子についてまともに話を聞いて、それから三項演算子ファンになってしまったのでした。ただ PHP 5.3や 5.6では ?? が使えないのですよね。

もし $hoge["foo"] が確実に存在するなら、

$hoge_foo = $hoge["foo"] ? $hoge["foo"] : "none";

を

$hoge_foo = $hoge["foo"] ?: "none";

とかけるのだけど、存在しない場合があるなら未定義エラーになります。

ので、下記のように書かざるをえないわけですが、

$hoge_foo = isset($hoge["foo"]) ? $hoge["foo"] : "none";

PHP7から実装された ?? を使えば、

$hoge_foo = $hoge["foo"]) ?? "none";

とスマートになるわけですよね。

そんなわけで、「Required PHP: バージョン」が必須になる日が待ち遠しいのでした。

2017年9月1日 @kimipooh

2017年6月14日水曜日

【備忘録】PHP 7.1.x で、PHP Fatal error: Uncaught Error: [] operator not supported for strings エラーがでたら・・・

手持ちの MAMP 環境を久々に更新し、PHP 5.6.30 / 7.1.1 へ切り替える設定にしました。現在のメイン PHP 利用環境は、7.0.x 系なのですが、そろそろ 7.1系でもテストしないとなぁと思い立ちました。 WordPress 4.8 でましたしね！

で、自前開発のWordPress プラグインも最近出した Google Calendar List View 以外、 7.1系でチェックするのサボってました @@!

ということで環境変更です・・・完了。

そしてテスト開始。最初に遭遇したのが、

Uncaught Error: [] operator not supported for strings エラー

でした。
これは、 $sample[] = $sample_data; など、配列にデータを追加するに当たって、配列の初期化の型がおかしい場合におきるようですね。PHP 7.0.x まではエラーにはなりませんでした。

PHP 7.0.x まで許容

$sample = "";
$sample[] = $sample_data;

PHP 7.1.x より

$sample = array();
$sample[] = $sample_data;

ということだったのです。これは早速自前プラグインを修正し、かつコードチェックしてくれる TRAVIS-CI の方も 7.1 を追加しないとですね〜。

ってことで手持ちのプラグインについて、 WordPress 4.8 と PHP 7.1 で動作チェック完了し、アップデート完了。

2017年6月14日 @kimipooh

2016年5月4日水曜日

【お知らせ】自前 WordPress 公式プラグイン「WP DS FAQ PLUS」が動作しなくなっていた・・

いつのまにやら動作しなくなっていたようでした。
具体的には Ajax エラーで追加や変更ができず、項目の展開などもできなくなっていました。普段は項目は展開済みだったので気付かず...

FAQ recently broken （1週間前）

に WordPress.org に投稿があって気づきました。

まぁあの頃は、新サーバーの調整に没頭していたので全然他の作業を追えてなかったってこともあるんですけどね。

でなにをしても Ajax エラーになっていたのですがなんとか修正して 1.2.7をアップデートしたのでした。

原因：PHP7上で「mysql_real_escape_string」が動かない

もうご承知のようにその関数が PHP7 から廃止されたからですね。
それ以外はエラーが出ていなかったので、おそらくはPHP7環境で動作させたのだろうなぁと思います。のでエラー吐いて動かなかったと...今回は esc_sql 関数へ置き換えました。

参考：PHP7 で破棄された関数によるWordPressの問題編（１）mysql_real_escape_string / set_magic_quotes_runtime #wordpress

ボツボツと WordPress を PHP7 を使う環境が増えてきたってことなんでしょうねぇ。

ふ〜休みだからガッツリとチェックできました...

2016年5月4日 @kimipooh

2016年4月27日水曜日

PHP7 で破棄された関数によるWordPressの問題編（１）mysql_real_escape_string / set_magic_quotes_runtime #wordpress

１つの WordPress を nginx + PHP7 な環境に移行しました。
ここでは PHP7 周りでおっとっと、、という事例について備忘録ついでに紹介していきます。今回は、「mysql_real_escape_string」です。

mysql_real_escape_string は PHP7から廃止された！

のでこの関数をつかっている場合にはエラーが出ます。

この関数は、MySQLデータベースにSQLクエリを渡すときに特殊文字をエスケープする関数です。esc_html などと同じような感じですね！

ログには

2016/04/27 11:33:38 [error] 23763#0: *1 FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught Error: Call to undefined function mysql_real_escape_string() in 使っているPHP（パス含む）

という感じで出ます。

mysqli_real_escape_string に変更せよ！

登録: 投稿 (Atom)

Knowledge for WordPress

ページ