kjmtsh

管理画面で、サービスのアイコンをドロップする場所が違うんじゃないですか?

ここにドラッグしたサービスは「共有」ボタン内に表示されます。

の外側に落とせば、お望みのようになると思いますよ。

申し訳ありません、付け加え忘れました。

「使い終わったら、ファイルを必ず削除してください」

私も勉強になりました。ありがとうございます。

一つ訂正させてください。前に「無理をすれば LIKE が使える」と書きましたが、私の環境では、シリアライズされたデータを文字列として、LIKE 検索しても、0.00 ミリ秒～ 0.03 ミリ秒程度で処理が終わるので、環境によっては、実用に使えるとしてください（MySQL 5.5 on Debian wheezy）。EXPLAIN で調べると、やはり MySQL は、meta_key のインデックスは使いませんが、wp_users.ID と wp_usermeta.umeta_id、wp_usermeta.user_id のインデックスはちゃんと使われています。

仕様のようですよ。ドキュメントが追いついていないです。

どうやら、この変更は、3.7.0 かららしいのですが、3.7.0 で「検索にかかったタイトル順 + 日付順」となっていませんでしたか?

一番詳しいドキュメントは、現状、wp-includes/query.php のコメントなので、それを参照していただくほかないのですが、現在はこれがデフォルトです。フィルタフック、posts_search_orderby や wp_search_stopwords が追加されています。これもドキュメントがありません。

以下、日付順にしたい場合の対策です。

posts_search_orderby フックを使えばとりあえず、日付順にすることができますが、ちょっと使いにくいです。ユーザが使うために用意されたフィルタじゃないかもしれません。

add_filter('posts_search_orderby', 'your_order_func');
function your_order_func($orderby) {
    global $wpdb;
    $orderby = "$wpdb->posts.post_date";
}

みたいに使うのですが、まず、生の SQL ステートメントを書くというのが気持ち悪いです。また、昇順、降順が書き換えられません。デフォルトの降順で処理されます。

function your_order_func() {
    global $wpdb;
    return "$wpdb->posts.post_date ASC";
}

とすると、昇順にできますが、下のように、検索以外のデフォルト「日付降順」の指定が後についたクエリになるので、気持ち悪いです。というか、やめた方がいいです。

ORDER BY wp_posts.post_date ASC, wp_posts.post_date DESC LIMIT 0, 10

これ以外には、たとえば、pre_get_posts アクションフックを使って変えるという方法もあります。こちらはインターフェイスがちゃんとしているし、ドキュメントや web 情報が多いので、おすすめです。

add_action('pre_get_posts', 'your_order_func');
function your_order_func($query) {
    if (!$query->is_main_query() || is_admin()) return;
    if ($query->is_search()) {
        $query->set('orderby', 'date');
        $query->set('order', 'DESC');
    }
}

こうすると、ここで指定した順序だけが使われるようになります。条件は適宜設定してください。

うーん、タイムアウトするほどのクエリには見えないのですが… 考えられる原因は、やはり、INNER JOIN と LIKE なのですが、それにしても遅すぎますよねぇ…? 試しにコマンドラインで同様のクエリを実行してみたら、0.01ミリ秒で終わりました。ひょっとして、ユーザデータは10000件を越えてますか?

SQL をぱっと見た感じでは、同じ文が複数あって、無駄に見えるかもしれませんが、不特定の要求に対して、絶対安全確実な SQL 文を作るという点では、WordPress の SQL 文生成はよくできていて、私の知る限り、冗長になることはあっても、間違った文を作ったことは1度もありません。

それでも、JOIN と LIKE が遅いことは確かです。JOIN はユーザが変更できませんから、LIKE を何とかしましょう、ということになります。LIKE は、前に述べたことから、どうしても使わなければならないとき以外は、極力使わないようにした方がよいと思います。

key LIKE '%data%'

の % は、ワイルドカードなので、data を含む文字列は全て検索にヒットします。これは、保存されているデータがユーザの入力によるもので、データにブレがある、たとえば、「東京」と「東京都」が混在している場合、’東京%’ と指定すると、「東京」で始まるデータを全て抽出できるのですね。

この場合、LIKE 検索を使うよりも、入力の段階でリストから選ぶようにするなどの対策をしておいて、’=’ 検索を実行した方が遙かに高速動作します。

kaiji さんの場合、問題の一つは、上のように LIKE を使わなければならないかどうか、という点にあります。これがどうしても必要ということになると、残念ながら他に手段はありません。自前で SQL 文を作る（たとえば、INNER JOIN を使わない）ということも考えられますが、LIKE を最大 25 回反復するのはどうにもなりません。

そうではなくて、’=’ 検索、あるいは、’IN’ でもよい、つまり、データに曖昧さがない、ということになれば、meta query を作る前の段階に処理を追加することで、スピードアップできるかもしれません。

まず、条件ですが、25個のチェックボックスから飛んでくるデータが、同じ meta_key に属するものか、複数の meta_key が存在するのかが問題になります。毎回の投稿で、meta_key の値が違うので、これまでの投稿からは推測できないのですが、前者なら、

array( 'men', 'women', 'cafe', 'restaurant', ...)

みたいな1次元配列にまとめます。この場合、チェックボックスから飛んでくるデータがすでに配列になっているはずなので、あまり手間はかからないと思います。

後者の場合、meta_key を配列として指定することはできません。データの方を、meta_key に合わせる形で整理します。具体的には、

meta_key1 のデータ => array( ‘men’, ‘women’, etc…)
meta_key2 のデータ => array( ‘cafe’, ‘restaurant’, etc…)

というように、複数の配列に分割するわけです。

さて、実際の引数処理ですが、前者の場合は、こうなります。なお、’IN’ は一つずつ ‘=’ と ‘OR’ で検索するのと同じ意味を持ちますから、どれか一つでもヒットすれば、そのユーザのデータが返ります。

$args = array(
    'meta_query' => array(
        'relation' => 'OR',
        array(
            'key'     => 'meta_key',
            'value'   => array('men', 'women', etc...),// チェックボックスのデータ
            'compare' => 'IN'
        ),
        その他...
    )
);

後者の場合。

$args = array(
    'meta_query' => array(
        'relation' => 'OR',
        array(
            'key'     => 'meta_key1',
            'value'   => array('men', 'women'),// チェックボックスのデータ1
            'compare' => 'IN'
        ),
        array(
            'key'     => 'meta_key2',
            'value'   => array('cafe', 'restaurant'),// チェックボックスのデータ2
            'compare' => 'IN'
        ),
        その他...
    )
);

meta_key の数だけ配列を追加していけばいいわけです。配列が空でも動作はしますが、その場合の処理もあったほうがよいかもしれません。

こんな説明でわかりますか? あんまりうまく説明できていないような気がして、自信がありませんが…

カスタムタクソノミーは、post データの分類に使うので、wp_users と wp_usermeta テーブルを相手にするWP_User_Query() では検索できなくなってしまうのではないでしょうか? それから、meta_key には一応、ユニークではないインデックスがはられています。ただし、LIKE 検索で、データの先頭にワイルドカードがあると、インデックスが使われなくなってしまうのです（WordPress は前後にワイルドカードを付け加えますが、ユーザがコントロールできないようになっています）。

kaijiさん、よくわからないところがあるので、ひとつ実験してみてもらえませんか? 時間がかかって、タイムアウトするmeta query を下のようにして、実際の SQL ステートメント変換してチェックすることができます。

$args = array(
    kaijiさんが使った引数
    );
$meta_query = new WP_Meta_Query();
$meta_query->parse_query_vars($args);
$query_string = $meta_query->get_sql('user', $wpdb->users, 'ID', null);
print_r($query_string);

インスタンスメソッドを使って、SQL 文を作るだけなので、WP_Meta_Query() には引数を入れません。もちろん、実行もされません。配列データが返るので、print_r() か var_dump() を使って表示させて、結果をポストしてみてください。それで解決する保証はありませんが…

これから20時間ほど unplugged になるので、すぐには返信できないかもしれませんが、もしよろしければ、やってみてください。

おっと、そちらでしたか。

「function.php」の中身ももっといじらないとだめでしょうか？

さあ、どうでしょうか? あまりいじりすぎると、よくない気がします。コピー&ペーストの盲目的な努力よりは、シンプルな構造を理解した方が近道です。何をどこに書いたら、どこに影響が出て、何が起こるかを知った方が後々楽ではないでしょうか。

さて、それではどうするか、ですが、とりあえず、

1. Function Reference/register post typeを読む。熟読がいいけど、basic sampleだけでもかまいません。
2. Function Reference/register taxonomyを読む。熟読がいいけど、basic sampleだけでもかまいません。
3. basic sampleだけの投稿タイプ、タクソノミーを定義して試す。
4. うまくいったら、さらに引数を増やす。
5. うまくいかなかったら、1に戻ってやり直す。
6. 完成したら、自分のブログでその情報を公開する。あるいは、困っている人に教える。

こんな感じでしょうか。英語版ドキュメントばかり紹介して申し訳ないのですが、新しい情報がかなり追加されているのと、どちらにもbasic sampleがあって、シンプルだけど、関数の働きがわかって、初学者が学習するにはとてもよい教材なのです。まずそれで作ってみてください。両者の基本サンプルどおり記述して、

$args = array( 'taxonomy' => array( 'genre' );
wp_tag_cloud($args);

とすると、何と、ちゃんとタグクラウドに表示されるんですね。よくできてます。短いので、全文引用しちゃいましょう。

Function Reference/register post typeより:

function codex_custom_init() {
    $args = array(
        'public' => true,
        'label'   => 'Books'
     );
    register_post_type( 'book', $args );
}
add_action( 'init', 'codex_custom_init' );

Function Reference/register taxonomyより:

add_action( 'init', 'create_book_tax' );
function create_book_tax() {
    register_taxonomy(
        'genre',
        'book',
        array(
            'label' => __( 'Genre' ),
            'rewrite' => array( 'slug' => 'genre' ),
            'hierarchical' => true,
        )
    );
}

どうでしょう? 何がどこで使われているか、お分かりになりますか? また、bigaoeさんがご自分でfunctions.phpに書いたコードと比較ができますか?
/* 結局引用ばかりで、私が書いたコードは1行もありませんでした。Codex恐るべしです。*/