かもメモ

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

WordPress pre_get_posts・WP_Query 別々の条件で記事を取得したい

WordPressWP_Querypre_get_postsアクション内で投稿を取ってくる時に、一緒にできない複数の条件(複数のSELECT文が必要な条件)で投稿を取得したいような時のメモ。

メインループ外の場合は2回WP_Queryを実行(SQLを発行)してそれぞれ取得したデータの配列をゴニョゴニョとマージしてしまうか、2回while( $the_query->have_posts() )で回してしまう方法もあります。(処理が多いかもですが、現実的にはこれが単純で簡単だと思います。)

サンプル

実現したいこと

story というカスタム投稿(post_type)を全て取得
数字の入るカスタムフィールド_sotry_noの値の順に並べて、
その後ろに、_sotry_no が存在しない投稿を続ける

UNION (MySQL)

WordPressで使われているMySQL的にはUNIONを使用すると1回のSQLで複数のSELECT文からデータが取得できるようです。

UNIONは複数のSELECT文によってデータをそれぞれ取得し、その結果を結合した上で1つのデータとして取得する場合に使います。書式は次の通りです。
SELECT col_name1, ... FROM tbl_name1
 UNION [ALL | DISTINCT] SELECT col_name2, ... FROM tbl_name2
 UNION [ALL | DISTINCT] SELECT col_name3, ... FROM tbl_name3;
出典: 取得データの結合(UNION句) - データの取得 - MySQLの使い方

また、UNIONを使って結合する、それぞれのSELECT文で並び替えを行いたい場合は、SELECT文にLIMITが含まれる必要がありました。

ex1. pre_get_posts() のメインクエリ書き換え内で別の

管理画面の一覧をカスタムフィールド_story_noで並び替えるようにしようとした場合、
_story_noフィールドが登録されていない状態で投稿(story)が作成されてしまうと、管理画面の一覧に表示されなくなってしまい編集すら行うことができなくなってしまう問題がありました。

WP_Queryを使える箇所であれば2回WP_Query()を使えば問題がないのですが、管理画面の一覧などpre_get_postsでメインクエリを書き換える必要がある箇所はpre_get_postsのアクション内でSQLを書き換えざるを得ません。 posts_requestフィルターを使えば実行されるSQLを直接書き換えることが可能なようなので、これを利用します。
[参考] Plugin API/Filter Reference/posts request « WordPress Codex

<?php // functions.php
add_action( 'pre_get_posts', 'my_posts_per_page' );
function my_posts_per_page( $wp_query ) {
  // 管理画面
  if( is_admin() ) {
    // 投稿タイプ story
    if( $wp_query->is_post_type_archive('story') ) {
      // カスタムフィールド _story_no で検索して表示させる
      $wp_query->set('meta_key', '_story_no');
      $wp_query->set('orderby', array(
        'meta_value_num' => 'DESC',
        'date' => 'DESC'
      ));

      /**
       * WP_QueryのSQLを置き換えるフィルター
       * @param: $request (Strings) ... 元のSQLのテキスト
       */
      add_filter( 'posts_request', function( $request ) {
        global $wpdb;
        // config.phpで設定されているDBのprefixを取得
        $prefix = $wpdb->base_prefix;
        // UNIONで追加するSQL文を作成
        $sql = "SELECT p.* FROM {$prefix}posts AS p
          WHERE p.post_type = 'story'
            AND p.post_status = 'publish'
            AND NOT EXISTS(
              SELECT meta.meta_id FROM {$prefix}postmeta AS meta
              WHERE meta.post_id = p.ID
                AND meta.meta_key = '_story_no'
          )
          GROUP BY p.ID
          ORDER BY p.post_date DESC
          LIMIT 0,18446744073709551615";

        // 実際に実行したいSQL文を返す
        // ※ 管理画面の一覧の$requestはデフォルトでLIMITが設定されれいるので別途LIMIT節を追加する必要なし
        return "({$request}) UNION ({$sql})";
      });
    }
  }
}

これで管理画面一覧でも特定のカスタムフィールドが無い投稿も表示され編集できるようになりました。

ex2. WP_Query() でUNIONを使う方法

残念ながらWP_Query()の引数の渡し方で複数のSELECTをマージできるような機能、UNIONを使ったSQLを作れる機能は無いようです。
[参考] Class Reference/WP Query « WordPress Codex

WP_Queryを2回実行しないのであれば、やはりposts_requestフィルターでSQLを変更するしかなさそうです。

<?php // functions.php
function get_my_story() {
  $arg = [
    'post_type' => 'story',
    // 該当する story を全件取得
    'posts_per_page' => -1,
    'meta_key'       => '_story_no',
     // _story_no が0以下のものは表示しない
    'meta_query'     => [
      [
        'key'     => '_story_no',
        'value'   => 0,
        'compare' => '>',
      ],
    ],
    // _story_no が小さい順に並べる
    'orderby'        => [
      'meta_value_num' => 'ASC',
      'date' => 'ASC',
    ],
  ];
  // SQLを書き換えるためのフィルター
  add_filter( 'posts_request', 'my_posts_request_filter');
  // WP_Query()が実行される際に↑の関数が実行される
  $the_query = new WP_Query($arg);
  // 同じページに他の WP_Query() があるとフィルターが動作してしまうので、フィルターを削除する
  remove_filter( 'posts_request', 'my_posts_request_callback');
  if( $the_query->have_posts() ) {
    while( $the_query->have_posts() ) {
      // 処理
    }
  }
  // 略
};

/**
 * WP_QueryのSQLを置き換えるフィルター
 * @param: $request (Strings) ... 元のSQLのテキスト
 */
function my_posts_request_filter( $request ) {
  global $wpdb;
  $prefix = $wpdb->base_prefix;
  $sql = "SELECT p.* FROM {$prefix}posts AS p
          WHERE p.post_type = 'story'
            AND p.post_status = 'publish'
            AND NOT EXISTS(
              SELECT meta.meta_id FROM {$prefix}postmeta AS meta
              WHERE meta.post_id = p.ID
                AND meta.meta_key = '_story_no'
          )
          GROUP BY p.ID
          ORDER BY p.post_date DESC
          LIMIT 0,18446744073709551615";

  // 実際に実行したいSQL文を返す
  // ※ 全件取得する元のSQLのORDER BYが効くようにするには LIMITが必要なので大きな値でLIMIT節を追加する
  return "({$request} LIMIT 0,18446744073709551615) UNION ALL ({$sql})";
}

表側のページの場合他の箇所でもWP_Queryが使われていたりする場合があるので、必要な箇所でのフィルター処理が完了したらremove_filterでフィルターを削除しておかないと、他のWP_Queryが使われている場所でもフィルターが実行されてしまうので注意が必要です。

 
WordPressの管理画面を見やすくなるようにと特定のカスタムフィールドで並び替えをしていたら、カスタムフィールドが空文字やNULLなら良いのですが、DBに登録されなかった場合、一覧に表示されず編集できなくなってしまう状況になり盛大にハマってしまいました。
いつもカスタムフィールドはCMB2というプラグインを使いコードベースで作成しているのですが、表示に際して必須なカスタムフィールドがある場合は必ず初期値を指定しておくべきだなと痛感しました。(初期値があれば今回のようにSQLを直接書き換える必要もなかったのです...)

MySQLとかWordPressで覚えた程度だったのでUNIONの存在を知らず、UNIONで結合したSELECT文をそれぞれ別にソートする方法にすごくハマりました... おかげで良い勉強になりなったので良かったです。
結局UNIONの問題と、存在しないカスタムフィールドを取得する複合的な問題だったので、それぞれ別の記事を作成するしました。


参考

SQLアンチパターン

SQLアンチパターン

WordPress サブテーマ テーマの絶対パスを取得したい。

WordPressでテーマのディレクトリの絶対パス取得をする方法のメモ
テーマ構成

/themes
   |- /main-theme
   |   |- functions.php
   |- /sub-theme
   |   |- functions.php

テーマディレクトリまでのパスの取得

get_template_directory

テーマのパスを取得するのに get_template_directory() を使っているのをよく見ますが、サブテーマでこの関数を使うと親テーマのディレクトリまでのパスが返されてしまいます。

親テーマ内で使用

<?php // /main-theme/functions.php
echo get_template_directory();
// 出力 => /home/www/wordpress/wp-content/themes/main-theme

子テーマ内で使用

<?php // /sub-theme/functions.php
echo get_template_directory();
// 出力 => /home/www/wordpress/wp-content/themes/main-theme

get_template_directory()は常に親テーマのディレクトリまでのパスが取得される。

get template directory
末尾にスラッシュを付けずに、現在のテーマのディレクトリへの絶対パスを取得します。
子テーマが使用されている場合には、親テーマのディレクトリへの絶対パスが返されます。 子テーマのディレクトリへの絶対パスを取得するには get_stylesheet_directory() をお使いください。
[出典] 関数リファレンス/get template directory - WordPress Codex 日本語版

get_stylesheet_directory

get stylesheet directory
現在のテーマまたは子テーマのスタイルシートディレクトリのパスを取得します。
注: 末尾にスラッシュを含みません。
[出典] 関数リファレンス/get stylesheet directory - WordPress Codex 日本語版

親テーマ内で使用

<?php // /main-theme/functions.php
echo get_stylesheet_directory();
// 出力 => /home/www/wordpress/wp-content/themes/main-theme

子テーマ内で使用

<?php // /sub-theme/functions.php
echo get_stylesheet_directory();
// 出力 => /home/www/wordpress/wp-content/themes/sub-theme

get_stylesheet_directory()を使えばそれぞれのテーマまでのパスが取得することができました!
 

get_stylesheet_directory 親テーマ内のfunctions.phpで実行されても今見ているサイトのテーマまでのパスが取得できるっぽい

WordPressの子テーマは親テーマのfunctions.phpも実行されます。
親テーマのfunctions.phpget_stylesheet_directory()がある時、子テーマから実行されると「現在のテーマ」である子テーマのパスが返されるようです。
これを利用すれば、親テーマに書いておくだけで、子テーマが複数あっても各テーマの設定ファイルを読み込んだりさせることができます。

テーマ構成

/themes
   |- /main-theme
   |   |- functions.php
   |   |- /inc
   |       |- config.php
   |- /sub-theme
   |   |- functions.php
   |   |- /inc
   |       |- config.php

親テーマ(/main-theme/functions.php)

<?php
define('__THEME_DIR__', get_stylesheet_directory());
require_once(__THEME_DIR__ . '/inc/config.php');
  1. 親テーマのサイトを見ている時
    /main-theme/inc/config.php が読み込まれる
  2. 子テーマのサイトを見ている時
    /sub-theme/inc/config.php が読み込まれる

 
WordPressで親テーマ・子テーマを作成する時は、常に親テーマまでの絶対パスを取得したい時はget_template_directory()、動的に現在のテーマまでの絶対パスを取得したい時はget_stylesheet_directory()を使えば良いとお覚えておけば良さそうです。


[参考]

WordPress マルチサイト ネットワーク管理画面のURLが変?

下記のような構成でWordPressでマルチサイトを設置しました。
サイト構成

/site-root <- サイトのルートのディレクトリ
  |- .htaccess
  |- index.php
  |- /wordpress  <- WordPress本体
        |- wp-config.php

メインサイトの管理画面のURLは example.com/wordpress/wp-admin/ です。
管理画面からマルチサイトをコントロールする「サイトネットワークの管理」にアクセスすると...
URLが example.com/wp-admin/network/ になりました。
WordPress本体が /wordpress にあるので、example.com/wordpress/wp-admin/network/ でないのがとても気持ち悪いです...

試しに example.com/wordpress/wp-admin/network/ でアクセスした所問題なくネットワークの管理画面が表示されており、 新規サイト作成のフォームのPOST先もこちらで問題なく動作しているようでした。 (見落としがあるかもしれません)

検索してみると同じような質問(Multisite network admin – URL / redirect error - WordPress Development Stack Exchange)が出ていましたが、解決方法は載っておらず...
WordPressのネットワーク管理画面のコアファイル(/wp-admin/network)でネットワーク管理画面関連のURLを出力している部分を調べてみた所、network_site_urlという関数を使ってネットワーク管理画面のURLを作成しているようでした。
このnetwork_site_url関数が定義されているコードを調べた所 network_site_url フィルターが使用できることが解りました。

network_site_url フィルターを使ってネットワーク管理画面のURLを置き換える

テーマにかかわらず常に実行してほしいのとWordPressのアップデート時に巻き戻ってしまっては困るので wp-config.php にフィルターを設置して、ネットワーク管理画面のURLを変更するようにします。

/wordpress/wp-config.php の最下部WordPressの設定を読み込んでいるrequire_once(ABSPATH . 'wp-settings.php');の下にフィルターを追記します。

<?php //wp-config.php
/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

// ▼ ネットワーク管理画面のURLを変更するフィルター ▼
// Wordpressのディレクトリ
define('__WORDPRESS_CORE_DIR__', '/wordpress');
// ネットワーク管理画面のURLを上書き
add_filter('network_admin_url', 'rewrite_my_network_admin_url', 10, 2);
function rewrite_my_network_admin_url($url, $path) {
  $networkPath = str_replace( '/wp-admin/', __WORDPRESS_CORE_DIR__ . '/wp-admin/', $url );
  return $networkPath;
}

これでネットワークの管理画面はexample.com/wordpress/wp-admin/network/になり、管理画面内からのリンクやフォームのPOST先のURLもwordpressディレクトリがある状態にすることができました!

WordPressの関数やフィルターを利用するコードを require_once(ABSPATH . 'wp-settings.php'); より上に書いてしまうとエラーになってしまうので、必ずwp-settings.phpの読み込みより下に記述しなければならないようです。

本当は.htaccessのRewriteRuleで書き換えたほうがスマートなのだと思うのですが、マルチサイトにした状態で上手くネットワーク管理画面関連だけのURLを書き換える技術力が今野私に無かったので、フィルターで出力自体を変更してしますというパワープレイに出ているので、とてもバッドノウハウな気がしてます。
現状確認できる範囲では問題なく動作しているようですが、何か不具合がある可能性は否めません。

そして、サブサイトを作成すると管理画面のURLは example.com/<sub-site>/wp-admin/ になってしまうので、WordPressのマルチサイトはそもそもサイト直下に直接WordPressのコアファイルを展開して使用する想定になってるっぽいなと思いました。

良い解決方法があればお待ちしています。

[参考]

<?php // /wp-includes/link-template.php#L3256
function network_site_url( $path = '', $scheme = null ) {
  if ( ! is_multisite() )
    return site_url($path, $scheme);

  $current_network = get_network();

  if ( 'relative' == $scheme )
    $url = $current_network->path;
  else
    $url = set_url_scheme( 'http://' . $current_network->domain . $current_network->path, $scheme );

  if ( $path && is_string( $path ) )
    $url .= ltrim( $path, '/' );

  /**
   * Filters the network site URL.
   *
   * @since 3.0.0
   *
   * @param string      $url    The complete network site URL including scheme and path.
   * @param string      $path   Path relative to the network site URL. Blank string if
   *                            no path is specified.
   * @param string|null $scheme Scheme to give the URL context. Accepts 'http', 'https',
   *                            'relative' or null.
   */
  return apply_filters( 'network_site_url', $url, $path, $scheme );
}

出典: https://core.trac.wordpress.org/browser/tags/4.8/src/wp-includes/link-template.php#L3256


人生にゆとりを生み出す 知の整理術

人生にゆとりを生み出す 知の整理術