kjmtsh
フォーラムへの返信
-
フォーラム: プラグイン
返信が含まれるトピック: 固定ページに表示したPage Naviの表示がおかしいです。実は、h-pine-h さんの一つ前の投稿でお示しになったコードでも動作するはずなのですが、２つ別の方法で、同じ結果ということは、どこか別に原因があるかもしれません。
念のため、
echo $the_query->found_posts . '<br />'; echo $the_query->query_vars['posts_per_page'] . '<br />'; echo $the_query->max_num_pages . '<br />';を追加して、出力を教えていただけますか? あと、パーマリンクの設定も知りたいです。
フォーラム: 使い方全般
返信が含まれるトピック: 投稿を【ユーザーメタデータ】で検索したいげ、すんません。コードもドキュメントもごちゃごちゃですね。
<?php $my_posts = search_with_usermeta();?> <?php foreach ($my_posts as $post) : : ?> <p><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></p> <?php endforeach; ?>繰り返し部分についてなのですが、上記の書き方で合ってるでしょうか？
これはもう必要ありませんので、削除してください。search.php デフォルトのループだけでけっこうです。黙って仕様を変えるという反則技を使っちゃいました。
カスタムポストタイプの指定はform部分でする必要は無い？
はい、ハードコーディングされてます。必要なら、チェックボックスなどをフォームに追加して、環境変数で受け取ることができます。(‘カスタム投稿’) と書いてありますが、(‘カスタム投稿’, ‘post’, ‘draft’) みたいな書き方ができます。
フォーラム: プラグイン
返信が含まれるトピック: 固定ページに表示したPage Naviの表示がおかしいです。archive.php はアーカイブで使うのに、こんなコードがまじっていていいのでしょうか? 普通に固定ページ用のテンプレート page.php または page-なんとか.php の方がよくないですかねぇ。
query_posts() については、新旧さまざなページが検索でヒットすると思いますが、記事の日付に注意されるのがよいと思います。WP-PageNavi についても同様です。
それはさておき、wp_pagenavi() は引数にクエリオブジェクトをとれますので、下のように、WP_Query を使うと、どうなりますか?
<?php $args = array( 'posts_per_page' => 5, 'paged' => get_query_var('paged'), ); $the_query = new WP_Query($args); ?> <ul> <?php if($the_query->have_posts()): ?> <?php while($the_query->have_posts()): $the_query->the_post(); ?> <li><?php the_content(); ?></li> <?php endwhile; endif; ?> </ul> <?php if(function_exists('wp_pagenavi')) { wp_pagenavi(array('query' => $the_query)); } ?> <?php wp_reset_postdata(); ?>カスタム投稿タイプが複数あって、それを１ページに表示したいとか、固定ページ自体のコンテンツがあって、それに加えて投稿リストを表示したいとかいうのでなければ、pre_get_posts フックを使った方が簡単です。
フォーラム: 使い方全般
返信が含まれるトピック: プラウザでのソース表示が変？あーっと、
nobita さん、これがですねぇ、もとのメソッドは、プライオリティが 9998-10000 にしてあるんですよ。99 では足りませんです。
ikechan さん、
add_filter( 'the_content', 'my_entities', 20000);くらいにしといてください。
以下、雑談です。
検索ロボットが理解しやすいのか？
さあ、どうでしょうねぇ? Google の論文、たくさんあってすごく役立つけど、こういう処理についてはちゃんとしたドキュメントがないので、わかりません。都市伝説はたくさんありますけどね。
<html lang="ja">となっていて、ヘッダやタイトルは普通の日本語で、本文だけは文字参照だというのは、一般的でないことは確かでしょうね。文字数のカウントは間違いなく原文とは違うことになると思いますし…CM Tooltip Glossary のサポートフォーラムを見てたら、ペルシャ語の方、キリル語の方、latin-1の方、それぞれが、ちゃんと表示されないよって、バグリポートしてました。こういった言語に対応するために、現在の仕様になったんでしょう。面白いと思ったけど、確信をもってやっているというより、苦肉の策だったのですね。
ikechan さん、気に入ったプラグインなら、フォーラムで、「協力するから、ちゃんとローカライズ対応やる気ない?」ってポストしてみたらどうでしょう? 少し協力すると、「じゃぁ、プロバージョンのライセンス送るよ」みたいに言ってくれる人が多いですよ。
フォーラム: 使い方全般
返信が含まれるトピック: カスタムフィールドを使用した複数選択の絞り込み検索ができないsearch.php のコードは、ご自分で書かれたのでしょうか、それとも、どこかからコピーしたものですか?
if ($service)以下の部分が何をしようとしているか、理解できますか?search.php というのは、検索結果を表示することしかできませんので、実際に検索を実行するコードは別のところ、たとえば、functions.php などに書かなければ動作しません。
フォーラム: 使い方全般
返信が含まれるトピック: 投稿を【ユーザーメタデータ】で検索したいすいません、また修正です。上の投稿は、途中で文章が切れていたりして、さんざんですが、一言で言うと、手動で query_posts() を実行しているということです。また、カテゴリテンプレートの件は、誤りで、is_search => true となっているようです。以下修正版のコードです。
<form role="search" id="searchform" method="GET" action="<?php echo home_url('/'); ?>"> <label for="s">Search for:</label> <input type="text" value="" name="s" id="s" /> <label for="address">Address</label> <select name="address"> <option value="none">none</option> <option value="関東">関東</option> <option value="東北">東北</option> </select> <input type="submit" id="searchsubmit" value="Search" /> <?php wp_nonce_field('my_search', 'my_nonce'); ?> </form>if (isset($_GET['my_nonce']) && wp_verify_nonce($_GET['my_nonce'], 'my_search') { if (isset($_GET['address']) && $_GET['address'] != 'none') { function replace_search_template($template) { return locate_template(array('search.php')); } add_filter('template_include', 'replace_search_template', 99); search_with_usermeta(); } } elseif (isset($_GET['address'])) { if (!isset($_GET['my_nonce']) || !wp_verify_nonce($_GET['my_nonce'], 'my_search')) { echo 'This operation is not allowed on this server'; exit; } } function search_with_usermeta() { global $wpdb, $wp_query; $query_strings = $_GET['s']; $post_types = "('post')"; // 投稿タイプ 複数指定可 $post_status = "publish"; // 投稿ステータス See WP_Query manual $address = urldecode($_GET['address']); // 住所 meta_value の値に使う $meta_key = "key"; // wp_usermeta の meta_key フィールド名 $limit = 5; // 1ページに表示する投稿数 $where = ''; $query_strings = stripslashes($query_strings); if (empty($query_strings)) { $search_terms = array(''); } else { $query_strings = urldecode($query_strings) $query_strings = str_replace(array("\r", "\n"), '', $query_strings); if (preg_match_all('/".*?("|$)|((?<=[\t ",+])|^)[^\t ",+]+/', $query_strings, $matches)) { foreach ($matches[0] as $match) { if (preg_match('/^".+"$/', $match)) $search_terms[] = trim($match, "\"'"; else $search_terms[] = trim($match, "\"' "); } if (empty($search_terms)) { $search_terms = array($query_strings); } } else { $search_terms = array($query_strings); } } foreach ($search_terms as $term) { $term = like_escape(esc_sql($term)); $where .= " AND ((p.post_content LIKE '%{$term}%') OR (p.post_title LIKE '%{$term}%'))"; } $where .= " AND (p.post_type IN $post_types AND p.post_status = '{$post_status}')"; $where .= " AND (um.meta_key = '{$meta_key}' AND um.meta_value = '{$address}')"; $sql = "SELECT * FROM $wpdb->posts AS p LEFT JOIN $wpdb->usermeta AS um ON p.post_author=um.user_id WHERE 1=1 $where ORDER BY p.post_date DESC LIMIT $limit"; $args = array( 'query' => $sql, 'posts_per_page' => $limit, 'paged' => get_query_var('paged') ); unset($wp_query); $wp_query = new WP_Query($args); }フォーラム: 使い方全般
返信が含まれるトピック: プラウザでのソース表示が変？おっと、もう解決してましたね。
これで原因が特定できたので、
このプラグインを使わなければ、事態は解消できるのですが、もはや事態は解消しているのではないですか? 使うと何か不都合がありますか?
ちょっと興味が湧いたので、リポジトリを覗いてみましたが、the_content() に add_filter() しているメソッドを追っていくと、call_back メソッドの中で、
if( !$dom->loadHtml(mb_convert_encoding($html, 'HTML-ENTITIES', "UTF-8")) )こんなことをしていました。$html の実体は、投稿の本文です。このプラグインを使う限り、今の現象は異常事態ではなくて、むしろ、作者はそれを意図して使っています。全体を読んだわけではないので、細部はわかりませんが、本文データを検索して glossary（たぶんXML） と照合し、マッチした部分に data-tooltip やリンクを付け加えているのではないでしょうか。
ここで照合に実体参照を使うのは、考えてみれば、とても合理的な選択で、文字コードや符号化、それどころか、言語さえもこえて、us-ascii のみで扱えるという利点があります。途中で変換するのは、データベースに保存された本文は再編集や検索の都合があるので、いじれないからでしょう。また、そのまま出力しても、ブラウザを通す限り、ちゃんと人間に読める形になりますから問題ありませんよね。ikechan さんにとっても、訪問者にとっても不都合はないような気がします。
ikechan さんが、人間に読める形のソースにこだわる理由はわかりませんが、そうしたいなら、cm-tooltip-glossary-frontend.php の中で cmtt_glossary_parse() メソッド（たぶんこれだけでいいと思いますが、確認できません）を探して、最後の
return $content;を、
return mb_convert_encoding($content, 'UTF-8', 'HTML-ENTITIES');すれば、戻るとは思いますが、お勧めはしません。他のメソッドが発狂するかもしれないし、パーサが途中で止まるかもしれないからです。試す場合は、自己責任でお願いします。
日本語部分のみ、＆＃37202；のようなコードで表示されている事なのですが・・・。
PHP manualで、mb_convert_encoding()、htmlspecialchars()、htmlentities() などをご覧になると、いろいろなことが発見できますよ。こちらはお勧めです。
フォーラム: 使い方全般
返信が含まれるトピック: プラウザでのソース表示が変？ん? 待った。
私の使っているテーマでは、
テーマをデフォルトにする、というのは、デフォルトのテーマ twentyfourteen にかえることをいいます。現在使っているテーマの設定をデフォルトに戻すことではありません。
ikechan さん、申し訳ありませんが、もう一度以下を確認していただけますか?
- 全てのプラグインを停止する。一つも残しちゃだめです。WP Super Cache なんてのもあるので、ちょっと難しいのですが、とにかく全て「無効化」して試してください。
- 「私の使っているテーマ」ではなく、デフォルトのtwentyfourteenにテーマを変更してください。
なお、the_content() を別の関数に入れ替えて、フィルタを書き戻す、というのは可能ですが、これは問題の解決ではなくて、回避ですから、お勧めしません。とりあえず、今、時間がないので、上の点だけお願いします。試していただいた出力は後で見ます。
フォーラム: 使い方全般
返信が含まれるトピック: プラウザでのソース表示が変？うーん、
しかも、page.phpとsingle.phpの時のみ、
これが理解できませんねぇ。index.php、archive.php、author.php、category.php、 search.php なら正常ということですよね?
<?php the_content(); ?>の動きが犯人であると確定しました。index.php でも使われていますので、確定はしていないように見えますが。ちなみに、the_content() は内部で get_the_content() を使い、次にフィルタを適応します。
同じ場所で、
global $wp_filter; print_r($wp_filter['the_content']);とすると、何か出てきますか?
フォーラム: 使い方全般
返信が含まれるトピック: 投稿を【ユーザーメタデータ】で検索したい解説の理解は、100%正解です。もうここまでわかったら、あとはそれをコーディングするだけですね。正直なところ、ちょっと難しいかな、と思ったのですが、temina さんの理解力に、こちらがびっくりです。
実は、様々な方法を試してみて、暫定解ではページングの情報をつけるのがちょっと難しいということがわかり、WordPress の機能をもう少し利用できるのでは、ということで、別解を作りました。少しトリッキーな方法になりますが、普通の検索と同様の出力ができて、テンプレート用の関数が通常どおり使えるようにするには、これしか思いつきませんでした。前の投稿の、2番目の解に近い方法です。
検索フォームを通常のものから変えて、
<form role="search" id="searchform" method="GET" action="<?php echo home_url('/'); ?>"> <label for="s">Search for:</label> <input type="text" value="" name="s" id="s" /> <label for="address">Address</label> <select name="address"> <option value="none">none</option> <option value="関東">関東</option> <option value="東北">東北</option> </select> <input type="hidden" name="use" value="usermeta" /> <input type="submit" id="searchsubmit" value="Search" /> </form>こんな形にすることは可能ですか? 通常の検索ボックスに加えて、ユーザメタの meta_value をドロップダウンで選択するようにします。検索ボックスは通常どおりに動作させて、meta_value の値によって、AND 検索を実行する、というシナリオです。hidden フィールドはこの検索フォームからの検索のときだけ
以下のコードは、functions.php に書きます。
if (isset($_GET['use']) && $_GET['use'] == 'usermeta') { function replace_search_template($template) { return locate_template(array('search.php')); } add_filter('template_include', 'replace_search_template', 99); } function search_with_usermeta() { if (isset($_GET['address']) && $_GET['address'] != 'none') { global $wpdb, $wp_query; $query_strings = $_GET['s']; $post_types = "('post')"; // 投稿タイプ 複数指定可 $post_status = "publish"; // 投稿ステータス See WP_Query manual $address = $_GET['address']; // 住所 meta_value の値に使う $meta_key = "key"; // wp_usermeta の meta_key フィールド名 $limit = 5; // 1ページに表示する投稿数 $where = ''; $query_strings = stripslashes($query_strings); if (empty($query_strings)) { $search_terms = array(''); } else { $query_strings = urldecode($query_strings) $query_strings = str_replace(array("\r", "\n"), '', $query_strings); if (preg_match_all('/".*?("|$)|((?<=[\t ",+])|^)[^\t ",+]+/', $query_strings, $matches)) { foreach ($matches[0] as $match) { if (preg_match('/^".+"$/', $match)) $search_terms[] = trim($match, "\"'"; else $search_terms[] = trim($match, "\"' "); } if (empty($search_terms)) { $search_terms = array($query_strings); } } else { $search_terms = array($query_strings); } } foreach ($search_terms as $term) { $term = like_escape(esc_sql($term)); $where .= " AND ((p.post_content LIKE '%{$term}%') OR (p.post_title LIKE '%{$term}%'))"; } $where .= " AND (p.post_type IN $post_types AND p.post_status = '{$post_status}')"; $where .= " AND (um.meta_key = '{$meta_key}' AND um.meta_value = '{$address}')"; $sql = "SELECT * FROM $wpdb->posts AS p LEFT JOIN $wpdb->usermeta AS um ON p.post_author=um.user_id WHERE 1=1 $where ORDER BY p.post_date DESC LIMIT $limit"; $args = array( 'query' => $sql, 'posts_per_page' => $limit, 'paged' => get_query_var('paged') ); unset($wp_query); $wp_query = new WP_Query($args); } }やっていることを少し説明します。
まず、ブラウザが GET 要求で検索クエリ（?s=関東）飛ばすと、これをもとにWordPress は通常の検索用 SQL でメインクエリを作ります。このとき、?s= の後が空白文字列だと、全ての投稿がマッチします。ところが、?s=&meta_value=関東 のような形になると、WordPress は meta_value を処理できないので、カテゴリと解釈し、category.php をテンプレートとして表示するようになります。このとき、meta_value というカテゴリがなければ、全てのカテゴリが表示されます。
is_category => true、is_search => false となるのですね。この動作をメインクエリが作成された後に変更することはできません。WP_Query クラスで定義された以外のものがブラウザからの要求に含まれていると、必ずこのような動作になります。
また、前に説明したとおり、WP_Query で Meta Query を使うと、wp_postmeta を使うことができ、WP_User_Query で Meta Query を使うと、wp_usermeta を使うことができますが、wp_posts と wp_usermeta、wp_users と wp_postmeta の組み合わせは使うことができません。temina さんのやりたいのは、前者となりますが、これを使いたい場合、WP_Query も WP_User_Query も使えません。したがって、query_posts() 関数も pre_get_posts フィルタも使えません。
だから、SQL 文を自前で作ることになるのですが、wpdb クラスを使うと、生のデータが返ってくるので、テンプレート関数が全て使えなくなります。ループで setup_postdata() を使えば一部は動作しますが、ページング情報は使えません。
そこで、SQL 文は自前で作るけれども、実行は、新たに作った WP_Query クラスのインスタンスで行い、すでに作られているメインクエリを破棄して、それに付け替えるということをしています。こんなことをするように作られたクラスではないので、どこかにひずみが出るかもしれませんが、確認した限りでは、通常のメインクエリと同様の動作をし、同様のデータの持ち方になるようです。こちらの方がお勧めなので、前の投稿のコードと差し替えてください。フォームに、author や tag などを追加していくのも難しくはないと思います。なお、フォームでselect を使ったのは、LIKE 検索よりも = の方がスピードが速いというのと、ユーザの入力チェックを省略するためです。
無保証ですが、動かない、使い方がわからない場合はまたポストしてください。
フォーラム: 使い方全般
返信が含まれるトピック: プラウザでのソース表示が変？MySQL はこんなことはしませんし、実体参照は charset や collation とは別の概念なので、データ入力から保存までの間か、データを表示する部分で PHP が何かをやっています。前者なら、本文検索が一切機能しなくなるので、何らかの対策が必要となります。
タイトルやサイドバーなどの表示は、
きちんと日本語とタグの構成で表示されています。ということなので、データベースにはちゃんと普通の日本語が保存されていて、mb_convert_encoding() のような関数がかかわっている可能性が高いと思いますが、現状では断定できません。
どうにかしたいというのであれば、まったく原因の手がかりがありませんので、何をおいてもすべきなのは、
- プラグインを全て停止して、デフォルトのテーマを使い、表示を確認する。
- 変化がなければ、その状態で新たな投稿を作成してみる。
です。何の変化もない、となったら、本格的な異常なので、次の原因究明が必要になります。なお、WordPress のバージョン、PHP のバージョンといった基本的な情報は、たとえ後で関係がないと分かったとしても、必須です。
フォーラム: その他
返信が含まれるトピック: プロフィールのアイコンの変更方法フォーラム: 使い方全般
返信が含まれるトピック: カスタムフィールドの価格の合計Plugin Directory でリポジトリを覗き、ドキュメントを読みました。とてもきれいなコードで、doc string もきちんとしていているし、API ドキュメントもわかりやすいものでした。
さて、本題ですが、2 度目のループは必要ないのではないでしょうか。1 度目のループのときに同じことができませんか? それがどうなっているか、ここに出すことができますか?
フォーラム: 使い方全般
返信が含まれるトピック: Firefox27.0.1とwordpressのcookieについて「識者」ではないので、資格には欠けるかもしれませんが…
cookie は、http でアクセスしてきたクライアントに、サーバ側から送られるもので、ブラウザはそれを要求できませんから、サーバ設定が原因ではないでしょうか?
Mac なので、ターミナルから、http で接続し、GET 要求をしてみると、Nginx が何を送ってきているかわかるのではないでしょうか。User Agent 偽装するのをお忘れなく。
/* WordPress とは関係ないと思うぞ 😛 */
フォーラム: 使い方全般
返信が含まれるトピック: 特定のページをSSLにする場合のシンボリックリンク利用についてスレッドをつなげるのはここでいいでしょうかね? もう一つの投稿での情報がなくなってますが…
共用サーバがクラックされた件で、攻撃者に利用されたことから奇妙な具合に有名になってしまいましたが、シンボリックリンク自体は、危険でも安全でもありません。インターネットが危険な存在にも、便利なツールにもなるというのと同じように、危険な使い方と安全な使い方があるだけです。ブログなどでセンセーショナルに、また、幾分かはお祭り騒ぎのように共用サーバの名前が溢れかえり、「シンボリックリンク」という言葉が「危険」という言葉を連想させる不幸な事態が広がってしまいましたけれど。
シンボリックリンク自体が危険だと思うなら、金輪際そんなものは使わず、単純にハードリンクにすればよいし、リンクが嫌なら、コピーをすればいいのではないかと思います。そうではなくて、つまり、危険とは思わないなら、積極的に活用すればよいのではないでしょうか。UNIX 系の OS では普通に、さまざまな用途で使われていますし、ライブラリ関数 symlink() がなくなるという話しも聞きませんしね。
kitaguni_ht さんの場合ですが、一般的にいえば、VPS でなら、共用サーバでのような近隣からの被害はありません。隣では別の OS が動いていますので、いくらシンボリックリンクがファイルシステムを越えられるといっても、隣の OS までは手が出せません。
もちろん、Linux Programmer’s Manual が記述するとおり、シンボリックリンク自体のパーミッションには意味がないことも事実です（常に lrwxrwxrwx です）。ということは、その先にあるファイルやディレクトリのパーミッションには細心の注意を払う必要があるということです。が、これは権限を持ったサーバ管理者がするべきことです。
他の投稿からわかることですが、kitaguni_ht さんは、どうやら、このサーバにアクセスできず、WordPress の管理画面しか触れないわけですよね? httpd.conf も php.ini もさわれず、それどころか、シェルアクセス権もないわけですから、サーバについては、「お客様」に任せる以外にありません。
kitaguni_ht さんがするべきことは、WordPress 本体からの侵入を許さないように最善を尽くすことだけではないでしょうか（Apacheのログくらいは読めるようになっていた方がよいとは思いますが）。シンボリックリンクで実現できることなら、それを使えばよいし、できなければ他の方法を考えて実装すればよいと思います。完成したら、外からアクセスしてみて、セキュリティ上好ましくないことがないかどうかを調べてみればよいのではないでょうか。もちろん、うまくいったら、ここで報告をするとコミュニティの利益になります。
以上は、私の個人的見解であって、何かを代表したり、擁護したり、批判したりする意図はまったくありません。