追記————
※この記事を書いて間もなくプライム・ストラテジーの方からコメントを頂きました。
記事のタイトルも『KUSANAGIがPHP7に対応したけどmysql_connectが邪魔なので修正して使いながらアップデート待ち』から変更しています。
15年12月16日以降のKUSANAGI7.7-3にアップデート後、頂いたコメントの通り作業をすることで、何ら問題もなく動いています。
【解決するための要点】
1. 15年12月16日より前のKUSANAGI7.7ならyum update を行う(一見すると同じkusanagi7.7でも7.7-3になるらしい)
2. その後にkusanagi update pluginコマンドを実行する必要がある
3. kusanagi php7コマンドを打ってphp7モードに切り替える
4. wp-config.phpにdefine(‘WP_CACHE’, true);を追加
5. kusanagi bcache onコマンドを実行
6. wordpressのKUSANAGIプラグインで『advanced-cache.phpの再生成』を実行
以上の通り作業を行えば、以下の本文に書かれているような修正作業をする必要はなく、デバッグモード上でもnoticeやエラーを吐きませんでした。
fcacheについては未検証です。
下の方に頂いたコメントもあるので興味のある方は参考にしてください。
追記ここまで———–
どうもFreeGAをベータ版としてスタートしてみました。そんな中、KUSANAGIがPHP7に対応したので早速hhvmからPHP7に変更したときの話です。
![]()
なぜPHP7を使うかだって??そりゃ好きだからだよ。PHPがね。
KUSANAGIのPHP7への移行は簡単すぎる
サクリとyum updateで最新版のkusanagiへアップデートしたら、kusanagi php7コマンドを打つことでPHP7へ移行できます!!
php -v とかphpinfo.phpとかで確認してphp7に切り替わっていたら成功です。
なんか泣けるほど簡単だなぁ。3か月ぐらい前にphp7を入れたときは色々と苦労した気がするんだけど気のせいなのか。
1点注意があるとするなら・・・
FreeGAはもともとPHP7上で開発していたのでスムーズに移行できましたが、通常はNoticeが出ると思いますので軽く覚悟しましょう。
Noticeも蓄積すると開発の邪魔なので、私の場合はwp-config.phpを define(‘WP_DEBUG’, true); にして作業をしています。
あれ??bcacheもfcacheも動かない
制作中のサイトのためキャッシュを切って作業していたのですが、そろそろキャッシュも試験したい頃合いになりました。
とりあえずSSHコンソール上でkusanagi fcache onしてkusanagi statusで確認・・・・・・・・・・・・fcache offのままでした(完)
いや、エラーもでてないしfcacheとbcacheの違いをそもそも理解できてませんから、bcacheだけでいいや!!
そしてkusanagi bcache on・・・・・・・・・・・・・・・
無事にbcache onに切り替わりましたとさ(つづく・・・)
php7ではmysqlはmysqliへ移行
一見問題がなかったキャッシュ機能ですが、なんと管理者以外はサイトを見れない状態になっていました。運用中のサイトで作業している場合は気を付けましょう。
エラーをみるとこんな感じです。
Fatal error: Uncaught Error: Call to undefined function mysql_connect()
あっ。このエラーはよく見たなぁ。
にわかに信じがたいのですが、KUSANAGIのキャッシュ機能が吐くadvanced-cache.phpはPHP7に対応していないようですね。キャッシュが使えなければ自前のnginx1.9×php7からKUSANAGIへ移行した意味が皆無です。何回か修正したことのあるエラー内容だったのでadvanced-cache.php内を見てみました。
以下は120行目の問題個所です。
$dbh = mysql_connect(
$dbset['host'],
$dbset['user'],
$dbset['pass'],
true
);
php7からはmysql_connectはmysqli_connectになっていて、従来とは違ってデータベースも同時に指定するのが基本型になっています。
すこし上の行を見ると’name’ => DB_NAMEが指定されていたので、そのまま使わせていただきます。
$dbh = mysqli_connect(
$dbset['host'],
$dbset['user'],
$dbset['pass'],
$dbset['name'],
true
);
ここはこれでOK・・・他の行もサラッと読んだらmysql関数が数か所あったのですが、一見するとmysqlをmysqliにするだけで対応できそうだったので、すべてのmysqlをmysqliに書き換えてみました。
※あんま頭使って直さなくても、KUSANAGIのアップデートがあると踏んでいるが故にテキトー
今度はWarning: mysqli_query()
そりゃそうだよねって思いながら該当箇所をみるとmysqli_query( $sql, $dbh );が不味いとのこと・・・・。
あるぅえ??いけそうだが?
まぁ、小生の書き方と違うのが気持ち悪いので自分なりに書き換えるなら mysqli_query( $dbh ,$sql); です。
結果:エラーが解消
ほー。
どっちでもいけそうだけど厳密なんですね。
もう一か所 $ret = mysqli_query($sql );という箇所でエラーが出ていたので、とりあえず $ret = mysqli_query( $dbh,$sql ); に変更。
でも、なんでこんなことになっているのかなぁ・・・って思いながら付近のコードを見わたすと mysqli_select_db( $dbset[‘name’], $dbh );を発見。
そっか。以前は mysql_select_db( $dbset[‘name’], $dbh );と$ret = mysql_query($sql );を使いながら次へ繋げていたっぽい。
ってことはmysqli_select_db( $dbset[‘name’], $dbh );もいらなくなるので削除。
結果
しばらくすると以下のエラーが発生
Non-static method KUSANAGI_Replace::replace() should not be called statically in
(PHP 7 では静的にコールすることが非推奨になりました)の話は解るが、そういう話??
KUSANAGI_Replaceクラスが何かをしてるように見えるんだけどKUSANAGIという名前が出てきた時点でブラックボックスな予感がしたので define(‘WP_DEBUG’, false); にしちゃいました。
出来ればデバッグモードを使いたいので何とかしたいなぁ。
それにadvanced-cache.phpはKUSANAGIが自動で生成してくれる動的なファイルなんで、いつ書き換えられて元に戻されるか解ったもんじゃないですね。
とりあえず、好奇心もあるのでキャッシュを効かせながら運用を続けてみます。
はやくKUSANAGI側で対応してくれると良いですね。