KUSANAGIがPHP7に対応!!mysql_connectが邪魔な件も解決

追記————

※この記事を書いて間もなくプライム・ストラテジーの方からコメントを頂きました。

記事のタイトルも『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行目の問題個所です。

[php]$dbh = mysql_connect(
$dbset[‘host’],
$dbset[‘user’],
$dbset[‘pass’],
true
);[/php]

php7からはmysql_connectはmysqli_connectになっていて、従来とは違ってデータベースも同時に指定するのが基本型になっています。

すこし上の行を見ると’name’ => DB_NAMEが指定されていたので、そのまま使わせていただきます。

[php]$dbh = mysqli_connect(
$dbset[‘host’],
$dbset[‘user’],
$dbset[‘pass’],
$dbset[‘name’],
true
);[/php]

ここはこれで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側で対応してくれると良いですね。

 -

コメント一覧

  1. Hitoshi Omagari より:

    KUSANAGI のご利用ありがとうございます。
    本日、KUSANAGI 7.7-3 をリリースしております。
    この中には、Non-static method の改修も含まれておりますので、是非アップデートしてみてください。

    なお、bcache の機能は、WordPressのKUSANAGI 専用プラグインにより提供されており、このプラグインは、yumでのアップデートのみでは最新版に更新されません。これは、運用されている環境への影響が出ないように配慮したためです。最新版への更新は、
    kusanagi update plugin
    コマンドにて、意図的に更新していただく必要があります。また、エラーの発生した、advanced-cache.php および replace-class.php は、動的に生成されるため、管理画面の [KUSANAGI] > [ページキャッシュ]ページの「advanced-cache.phpの再生成」にて、ファイルの再生成を行っていただく必要があります。

    それと、コンソール上での php コマンドは、5.6になります。
    PHP7 の場合は、コマンド名自体が php7 となりますので、補足いただけますと幸いです。
    ※ ドキュメントしっかり作っておかないとだめですね。。

    使っていただいて、分からないことやご要望などありましたら遠慮無くご連絡ください。

    • japan3d より:

      コメントありがとうございます!
      yum update と kusanagi update plugin を行うことでデバッグモード上でも全く問題なく動いています。

      コンソール上でのphpコマンドが5.6ということについては、kusanagi php7コマンドを実行すれば良いということでしょうか?
      とりあえず私の環境では何ら問題がないので、そう解釈しました。

      この先もお世話になり続ける予定ですので、なにかがあれば御連絡させていただきます。
      こんな記事にまで迅速な対応をいただきまして、本当にありがとうございました。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

同じ分類

管理画面のサイドバー崩れが実はバグだった件

WordPressの4.3にアップデートしたところ、管理画面のサイドバーに表示崩れが発生してしまいました。 表示崩れ〚…続き〛

nginxのマルチサイトでコメントやjetpackの404エラー【草薙-kusanagi】

nginxを扱っていると40xや50x系のアクセスに関するエラーを出してしまうことがあると思います。 特に注意が必要〚…続き〛

カスタム投稿を大活用:新着に含める、月別アーカイブをリスト表示、タクソノミーのタグクラウド等々・・・

ここではカスタム投稿(カスタムポストタイプ)を使って、それらしいサイトを構築します。 例えば新着記事の中にカスタム投〚…続き〛

wordpressのマルチサイトで【参加サイトに表示されない】理由は簡単なミス

それは、Multisite Language Switcherを使う為にマルチサイトを構築するときのことでした。 &〚…続き〛

wordpressの子テーマはfunctions.phpで呼び出した方がイイ(*‘∀‘)

stinger3を使っていたときはサイトの速度評価に対して拘り過ぎていたため、style.css内の多くをhead内〚…続き〛

G+