かもメモ

自分の落ちた落とし穴に何度も落ちる人のメモ帳

WordPress PHP 7.x でデータベース接続確立エラー

PHP 7.3にして、WordPressをみてみたら「データベース接続確立エラー」の表示。お久しぶりっす!!
データベースのユーザー名・パスワードに変更がない・MySQLのバージョンを変更していないならphp.iniでの接続設定に問題がありそう。

mysqlのsocketの設定をみてみる

php.iniの場所を調べる

$ php --ini
Configuration File (php.ini) Path: /Users/<USER_NAME>/.phpbrew/php/php-7.3.1/etc
Loaded Configuration File:         /Users/<USER_NAME>/.phpbrew/php/php-7.3.1/etc/php.ini

php.iniを開いてdefault_socketで検索。
mysqli.default_socketに何も設定されてなかったのが原因のようです。

[MySQLi]
; Default socket name for local MySQL connects.  If empty, uses the built-in
; MySQL defaults.
; http://php.net/mysqli.default-socket
mysqli.default_socket = /tmp/mysql.sock

PHP7.3とPHP5.6のphp.iniにあるdefault_socketの違いのメモ

socket PHP7.3 PHP5.6
pdo_mysql.default_socket あり あり
mysql.default_socket なし あり
mysqli.default_socket あり あり

PHP7ではmysql_connect関数が削除されたためでしょう。mysql.default_socketが存在していません。
PHP5系のときはmysql.default_socketだけ設定しておけばWordPressとのデータベース接続は出来ていたのですが、PHP7からはmysqli.default_socketにsocketのパスを設定しておかなければWordPressが「データベース接続確立エラー」になってしまいます。pdo_mysqlだけではWordPressはダメみたいです。(PHP5.xでもmysqliに設定しておくほうが良さそうな気がしますが...

PHP7を入れ直したので設定し忘れでした... orz


[参考]

mysql_connect
警告 この拡張モジュールは PHP 5.5.0 で非推奨になり、PHP 7.0.0 で削除されました。 MySQLi あるいは PDO_MySQL を使うべきです。
出典: PHP: mysql_connect - Manual

詳細! PHP 7+MySQL 入門ノート

詳細! PHP 7+MySQL 入門ノート

MySQL mysql.socketがどこにあるか探したい。

php.iniとかに設定するmysql.socketのパス。
設定が必要になる頃には覺えてないし、アップデートとかでパスが変わってるかもしれないのでmysql.socketがどこにあるか探す方法のメモ

mysql_config --socket コマンドを使う

$ mysql_config --socket
/tmp/mysql.sock

MySQL起動させて無くてもパスが表示されます。

mysql.socketが存在しないときは生成させることも出来るようです

  1. /etcmy.cnfファイルを作成
  2. my.cnfに下記を記述
    [mysqld]
    socket=/var/mysql/mysql.sock
    [client]
    socket=/var/mysql/mysql.sock
    
  3. mysqld_safeを実行
    $ sudo /usr/local/mysql/bin/mysqld_safe
    

参考

以前パスが有るべき場所にtouch mysql.socketって空ファイル生成したら問題なくMySQLが起動したことがあって、イマイチこのmysql.socketが何者なのか解ってないです。
俺たちは雰囲気でコーディングしてる...


[参考]

👇プラグの差込口のこと「ソケット」って呼ぶのですね。学んだ

WordPress pre_get_posts内でSQLをカスタムするフィルターを使う時に注意すること

他人が作った古のWordPressテーマをバージョンを上げずにカスタマイズするお仕事で辛みを感じている今日此頃。如何お過ごしでしょうか? (季節の挨拶)

カスタムフィールドやORDER BYなど複雑なクエリで取得したいような時、posts_requestposts_joinposts_orderbyというフィルターを使うとSQLを直接変更してデータを取ってくることができます。

WP_Query内で使用する場合はwp_reset_postdata()で元のクエリに戻せるのでよいのですが、大元のwp_queryを変更するpre_get_posts内でこれらのフィルターを使っていると該当するページ内でWP_Queryget_postsなど使用していると、これらのサブクエリにもpre_get_posts内で設定したフィルターがかかりSQLが変更されてしまい意図しないデータなってしまうの場合があるので注意が必要です。

e.g.

カスタム投稿 アイカツカードaikatsu_cardアーカイブページではカスタムフィールドcard_nocard_typeとで並び替えたいような場合。($wp_query->set()で実現できそうな気もするけど敢えてfilterで)

  1. 投稿に紐づくカスタムフィールドcard_no, card_type を取得する
  2. card_no の値、card_typeの値で並び替え
<?php // functions.php
add_action('pre_get_posts', 'my_custom_wp_query');
function my_custom_wp_query( $wp_query ) {
  // WP_Query に影響を与えないようにメインクエリに限定
  if( $wp_query->is_main_query() ) {
    // カスタム投稿 `aikatsu_card`
    if( is_post_type_archive('aikatsu_card') ) {
      add_filter('posts_join', custom_card_archive_join, 10, 2);
      add_filter('posts_orderby', 'custom_card_archive_orderby', 10, 2);
    }
  }
}
// joinのSQLを変更するフィルター
function custom_card_archive_join($join, $query) {
  global $wpdb;
  $prefix = $wpdb->prefix;
  $join .= ""
    ." INNER JOIN {$prefix}postmeta AS card_no"
    ." ON card_no.post_id = {$prefix}posts.ID"
    ." AND card_no.meta_key = 'card_no'"
    ." INNER JOIN {$prefix}postmeta AS card_type"
    ." ON card_type.post_id = {$prefix}posts.ID"
    ." AND card_type.meta_key = 'card_type'";
  return $join;
}
// orderbyのSQLを変更するフィルター
function custom_card_archive_orderby($orderby, $query) {
  $orderby = ""
    ."card_no.meta_value ASC"
    ."card_type.meta_value ASC";
  return $orderby;
}

これでカスタム投稿aikatsu_cardアーカイブページは、カスタムフィールドcard_nocard_typeの値順に並び替えられたもので表示されます。(雑にINNER JOINSQL作ったのでカスタムフィールドの値がないものは取得されない)

で、aikatsu_cardアーカイブページのテンプレートファイルなどメインクエリ内でnew WP_QUERY()でサブクエリを実行すると、上記のフィルターがSQLにセットされてしまい意図したデータが取得できなくなるっぽい。(is_main_query内にしているのに影響があるのはちょっと不思議。触っているWordPressv4.1なので、新しいバージョンでは発生しない可能性は否めません...)

wp_queryがセットされた後にフィルターを解除すればOK

This action hook runs immediately after the global WP class object is set up. The $wp object is passed to the hooked function as a reference (no return is necessary).
出典: Plugin API/Action Reference/wp « WordPress Codex

wpというglobalのWP class objectが設定された後に実行されるアクションフックがあったので、ここでSQLを変更するフィルターを削除すれば、それ以降のクエリ作成時にフィルターがかかることはなくなります。

<?php // function.php
add_action('pre_get_posts', 'my_custom_wp_query');
function my_custom_wp_query( $wp_query ) {
  if( $wp_query->is_main_query() ) {
    if( is_post_type_archive('aikatsu_card') ) {
      add_filter('posts_join', custom_card_archive_join, 10, 2);
      add_filter('posts_orderby', 'custom_card_archive_orderby', 10, 2);
    }
  }
}
// global WP Object 設定後に実行される
add_action( 'wp', 'my_remove_custom_query_filter');
function my_remove_custom_query_filter() {
  global $wp_query;
  if($wp_query->is_main_query() ) {
    if( is_post_type_archive('aikatsu_card') ) {
      // my_custom_wp_query 内で設定した filter を削除する
      remove_filter( 'posts_join', 'custom_card_archive_join');
      remove_filter( 'posts_orderby', 'custom_card_archive_orderby');
    }
  }
}

これで、aikatsu_cardアーカイブページ内でnew WP_Query()get_posts()を実行してもフィルターの影響なくデータを取得することが出来るようになりました。

WP_Queryはサブクエリになるという認識だったので、is_main_query内で実施したフィルターの影響は受けないと思っていたのでハマってしまいました。なんとなくバグっぽい気がしなくもないので、これが今回触っていたのが古いWordPress v4.1だから発生した現象なのかどうか、つまり最新のバージョンでも発生するかどうかという部分は未検証です。
 

フィルターじゃなくて$wp_query->set()WP_Query()のパラメーターで設定できるのが良いとは思うのですが、そうはいかない場合もありますよね…
そして、WordPressのコアはアップデーする前提で運用して欲しい…と切実に思うのでした。 (古い環境で関数が使えるのかどうかとか探すのが大変なので...)


[参考]

本件とは関係ないけどWordPressさん特定のarchive-{post_type}-taxonomy-{taxonomy}.phpみたいな投稿タイプ+タクソノミーなアーカイブのテンプレート名が欲しい…

イケアではないシャーク🦈