フォーラムへの返信

15件の返信を表示中 - 271 - 285件目 (全293件中)
  • フォーラム: 使い方全般
    返信が含まれるトピック: 検索結果をテンプレート別に作りたい

    日本語ページと英語ページを実装しています。

    どのように実装したのかによるので、条件次第ですが、

    検索結果ごとにテンプレートを当てるのは可能でしょうか。

    は可能です。

    Plugin API/Filter Reference/template include

    をご覧ください。

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

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

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

    フォーラム: プラグイン
    返信が含まれるトピック: Popular Posts で記事ごとのタグを表示したい

    wpp_get_mostpopular() を使う段階では、データベースからのデータ取得、表示の整形は終了していますので、何を入れても動作しません。

    wordpress-popular-posts.php 自体をいじるしかないのでしょうか。

    ということになります。wordpress-popular-posts.php の 1080 行目から 1230 行目までが取得したデータをいじる場所です。$p 変数が個別データへのリファレンスになっているので、ここなら、

    wp_get_post_tags($p->ID)

    で該当のタグを取れます。wpp_get_mostpopular() から飛んできた引数がこうなっていたら、こう返すみたいな作りですので、前後を見ながら作ればよいでしょう。

    フォーラム: 使い方全般
    返信が含まれるトピック: 画像のアップロード先変更について

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

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

    フォーラム: 使い方全般
    返信が含まれるトピック: 画像のアップロード先変更について

    すいません、見落としてました。

    あるのは「meta_id」「post_id」「meta_key」「meta_value」の4つ…

    これで正しいです。meta_key カラムに ‘_wp_attached_file’ というデータが、meta_value カラムに ‘yyyy/mm/*.jpg’ みたいなデータが入っています。

    hogetan さんがお示しになった

    UPDATE $wpdb->wp_postmeta SET meta_value = REPLACE(meta_value, '2014/01/', '/') WHERE meta_key = '_wp_attached_file';

    というクエリは、’2014/01/sample.jpg’ というようなデータを ‘/sample.jpg’ に変えるものです。WordPress のメディアライブラリでは、この前に、’http://example.com/wp-content/uploads/’ というのがついてサムネールを表示しています。とすると、置換文字列の ‘/’ は、hogetan さんの勘違いで、正しくは ” と、空文字列にしないといけないところです(たぶん、ちゃんと動作はすると思いますが)。

    ただ、これは ‘2014/01/’ しか変換してくれませんから、次には ‘2013/12/’ に書き換え、次は ‘2013/11/’ に書き換えして最後まで、というシナリオです。だから、

    100行ぐらいに収まるかと思います。

    ということなのですね。

    これはちょっとたいへんなので、はやり PHP スクリプトで正規表現置換を使うやつを書きました。meta_key ‘_wp_attached_file’ のデータとシリアライズされた meta_key ‘_wp_attachment_metadata’ のデータ、それから、posts テーブルの guid データを一気に書き換えます。

    1000 行のデータでテストしましたが、前半の ‘_wp_attached_file’ の書き換えだけで下くらいの時間がかかりました。念のため、最初でタイムリミットを300秒にしています。

    real   1m44.966s
    user   0m1.668s
    sys    0m0.272s

    コードが長いので、pastebin に置いてあります。

    http://pastebin.com/g0QpUX49

    使い方は以下の通りです。

    1. スクリプトファイルを wp-config.php のあるディレクトリに置く。
    2. 管理者としてログイン。
    3. ブラウザのアドレスバーにスクリプトのアドレスを入れ、リターン。
    4. ‘Finished’ のメッセージが出るまで待つ。

    以上です。途中でエラーがあった場合の処理は入れていませんし、テーブルロックやトランザクションは MySQL に任せっぱなしなので、メンテナンスモードにしてお使いください。テストはしましたが、無保証です。バックアップを取ってからお試しください。

    フォーラム: 使い方全般
    返信が含まれるトピック: meta_queryのvalue値に渡す引数について

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

    一つ訂正させてください。前に「無理をすれば 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 のインデックスはちゃんと使われています。

    kitaguni_htさん、

    わたしたちはサーバーにアクセス出来ない状態…

    とのことですが、

    # cp–p /backup/wp /wp

    これって、すでにサーバにアクセスできていて、しかも、root 権限をもっているということではないですか?

    アクセスできないというのは、ブラウザでってことではないかなぁ…

    Unix 系 OS の使い方、mysql、mysqldump、mysqlhotcopy といったユーティリティの使い方を覚えた方がいいような気がします。誰か近くに助けてくれる人がいませんか、kigaguni_ht さん?

    この間からいろんな情報を見過ぎてちょっと混乱していて

    まずいです。ちょっと問題を整理して、上司や先輩や同僚がいらっしゃるなら、その人たちと相談して、1つずつ取り組んだ方がいいです。余計なお世話かもしれませんが、このままでは、危ないです。

    フォーラム: 使い方全般
    返信が含まれるトピック: 検索結果が日付順に並ばない

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

    どうやら、この変更は、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');
        }
    }

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

    フォーラム: 使い方全般
    返信が含まれるトピック: meta_queryのvalue値に渡す引数について

    おおっと、シリアライズされていたのかぁ… このデータを最初に出していれば、簡単な話しでしたねぇ。

    結論は、「meta query を使うことができない」です。無理をすれば、’LIKE’ が使える、と付け加えればもっとよい答えになるかもしれません。MySQL はこれが文字列だと思って比較してますから、’=’ も ‘IN’ も使えないのです。WordPress 側で serialize してますから、WordPress が責任をもって unserialize しないといけません。

    meta query で ‘=’ や ‘IN’ が使えるデータは、例えば下のようになります。meta_key のインデックスは重複を許すものになっているので、こうできるのです。これなら、meta query が普通に使えます。

    +---------+----------+------------+
    | user_id | meta_key | meta_value |
    +---------+----------+------------+
    | 1       | area     | tokyo      |
    +---------+----------+------------+
    | 2       | area     | kanagawa   |
    +---------+----------+------------+
    | 1       | genre   | cafe       |
    +---------+----------+------------+
    | 2       | genre   | gourmet    |
    +---------+----------+------------+

    現状のままで何とかするには、予備のクエリを実行して、シリアライズされたデータをチェックボックスから飛んできたデータと比較するしかないと思います。たとえば、あくまでたとえばですが、下のような操作をしておいて、WP_User_Query インスタンスを作るということは考えられるかもしれません。

    global $wpdb;
    $meta_key = 'メタキーの値を入れてください';
    $strings_to_search = チェックボックスから得た1次元配列データ;
    
    $results = $wpdb->get_results($wpdb->prepare("SELECT user_id, meta_value FROM $wpdb->usermeta WHERE meta_key='%s'", $meta_key));
    
    foreach ($results as $result) {
        $user_meta_values = maybe_unserialize($result->meta_value);
        if (!is_array($user_meta_values)) continue;
        foreach ($user_meta_values as $value) {
            if (in_array($value, $strings_to_search)) {
                $users_to_search[] = $result->user_id;
                break;
            }
        }
    }
    
    $args = array(
        'ID' => $users_to_search
    );
    
    $user_query = new WP_User_Query($args);

    チェックボックスのデータは ‘OR’、他の条件は ‘AND’ の検索するのと同じ結果になると思いますが… 自分では試してません。

    フォーラム: 使い方全般
    返信が含まれるトピック: meta_queryのvalue値に渡す引数について

    うーん、タイムアウトするほどのクエリには見えないのですが… 考えられる原因は、やはり、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 の数だけ配列を追加していけばいいわけです。配列が空でも動作はしますが、その場合の処理もあったほうがよいかもしれません。

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

    フォーラム: 使い方全般
    返信が含まれるトピック: 画像のアップロード先変更について

    guid は、feed に使われます。投稿記事は一意のデータなので、変えてはいけないけれども、メディアのアドレスは例外だから、ちゃんと変えてね、と書いてあります。

    フォーラム: 使い方全般
    返信が含まれるトピック: meta_queryのvalue値に渡す引数について

    カスタムタクソノミーは、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 になるので、すぐには返信できないかもしれませんが、もしよろしければ、やってみてください。

    フォーラム: テーマ
    返信が含まれるトピック: wp_list_commentsで自動付与されるを削除したい

    1日考えてみました(嘘です)。WordPress コアを変更せずに実現するには、自分で Walker クラスを継承して新たなクラスを定義するか、Walker_Comment クラスを継承して関数をオーバーライドするしかないようです。

    functions.php:

    class myWalker_Comment extends Walker {
        フィールドとメソッドの定義
    }

    または、end_el メソッドのオーバーライド(お手軽)。

    class myWalker_Comment extends Walker_Comment {
        function end_el(&$output, $comment, $depth = 0, $args = array()) {
            if (!empty($args['end-callback'])) {
                ob_start();
                call_user_func($args['end-callback'], $comment, $args, $depth);
                $output .= ob_get_clean();
                return;
             }
            if ('div' == $args['style'])
                $output .= "</div><!--#comment-##-->\n";
        }
    }

    template file:

    $comments = get_comments($arguments_array);
    $args = array(
            'walker' => new myWalker_Comment(),
            ....etc
            );
    wp_list_comments($args, $comments);
    フォーラム: 使い方全般
    返信が含まれるトピック: カスタム投稿ページとタグクラウドに関する質問

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

    「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恐るべしです。*/

    フォーラム: 使い方全般
    返信が含まれるトピック: カスタム投稿ページとタグクラウドに関する質問

    Function Reference/wp tag cloudの最初に書いてありますよん。

    Beginning with Version 2.8, the taxonomy parameter was added so that any taxonomy could be used as the basis of generating the cloud.
    バージョン2.8から、taxonomyパラメータが追加されたので、あらゆるtaxonomyをもとにして、クラウドを生成することができます。

    パラメータの説明を見ると、taxonomyは、stringまたはarrayということですから、下のようにすればよいのではないでしょうか。

    $args = array( 'taxonomy' => array( 'post_tag', 'your_custom_taxonomy', 'etc...' );
    wp_tag_cloud($args);
15件の返信を表示中 - 271 - 285件目 (全293件中)