kjmtsh
フォーラムへの返信
-
フォーラム: テーマ
返信が含まれるトピック: wp_nav_menu()が出力するliタグ内に独自css名を入れたいclassを追加するだけなら、nav_menu_css_classフィルタを使えばよいのですが、過去30日のようなタイムスパンを指定してカテゴリを得るクエリを発行できるAPIがないかもしれません。
そこを自作すると、下のような感じでしょうか。
add_filter('nav_menu_css_class', 'special_nav_class', 10, 2); function special_nav_class($classes, $item) { global $wpdb; $result = $wpdb->get_col(" SELECT DISTINCT t.name FROM $wpdb->terms AS t, $wpdb->term_taxonomy AS tt, $wpdb->term_relationships AS tr WHERE t.term_id=tt.term_id AND tt.taxonomy='category' AND tr.term_taxonomy_id=tt.term_taxonomy_id AND tr.object_id IN ( SELECT ID FROM $wpdb->posts AS p WHERE p.post_status='publish' AND DATE_SUB(NOW(), INTERVAL 30 DAY) <= p.post_modified ) "); if (empty($result)) return $classes; foreach ($result as $cat_name) { if ($item->title == $cat_name) { $classes[] = "new-post"; } } return $classes; }全てのページでこれが動作するのは、ちょっといまいちですね。wp_get_recent_posts()を適当な数だけ取ってきて、日付を比較するというのも考えられますが、データベースにアクセスしちゃうのは同じなので、変わらないと思います。どちらも、お勧めはいたしません。
なお、$item->titleの判定は書き換えないと動作しないかもしれません。
フォーラム: 使い方全般
返信が含まれるトピック: 詳細ページのないpostを作ってサイトを作りたい$where .= " AND $wpdb->posts.ID NOT IN ( SELECT tr.post_id FROM $wpdb->postmeta AS tr WHERE tr.meta_key='news_flag' AND tr.meta_value='1')"の、$wpdb->posts.ID を p.ID に変更すれば動作するのではないでしょうか。
フォーラム: プラグイン
返信が含まれるトピック: Popular Postsでカテゴリースラッグを取得する方法フォーラム: プラグイン
返信が含まれるトピック: Popular Postsでカテゴリースラッグを取得する方法残念ながら、WordPress Popular Posts には、カテゴリを個別に取得する関数や API が用意されていません。テンプレート関数の、wpp_get_mostpopular() と、ショートコード [wpp] でカスタマイズできる部分以外はハードコーディングされています。
お望みのことをそっくり実現するには、本体に手を入れるか、出力まではプラグインにやってもらって、それを整形し直すしかないと思います。たとえば、次のようなことが考えられます。
$wpp_data = do_shortcode('[wpp limit=10 range="all" stats_comments=0 stats_category=1 post_html="<li>{category}<a href='\{url}\'>{text_title}</a>"]'); echo $wpp_data;のような感じで出力を変数に代入します。wpp_get_mostpopular() はその場で echo するので、使えません。
<ul class="wpp-list"> <li><a>categrory_name</a><a>post_title</a></li> ... </ul>というような出力が得られますから、これを echo せずに、プログラムで書き換えれば、お示しになった形に整形できると思います(ちょっと間抜けな感じですが…)。
関数やショートコードのオプションは、管理画面で説明を読むことができます。
フォーラム: 使い方全般
返信が含まれるトピック: usermetaテーブル内のカスタムフィールドの値の一覧を出力したいあけましておめでとうございます。
お望みのリストは、下のクエリで取得できます。意味は、「$wpdb->usermeta テーブルから、meta_key カラムに wpcf-address_pref を持つ行の meta_value カラムの値を重複なしに抽出しろ」というものです。
$data = $wpdb->get_col("SELECT DISTINCT meta_value FROM $wpdb->usermeta WHERE meta_key='wpcf-address_pref'"); foreach ($data as $value) { echo $value . "<br />"; }47都道府県しかないのであれば、ページが表示されるたびにデータベースにアクセスするより、最初から45要素の配列を用意した方が圧倒的に速いのではないでしょうか?
フォーラム: プラグイン
返信が含まれるトピック: この違いはなんでしょうか・・・「良いお答え」かどうかはわかりませんが… プラグインを書いていらっしゃるのでしょうか。もしそうなら、Codex と呼ばれるドキュメントが役立ちます。チュートリアルや HOWTO であると同時に、API リファレンス、関数リファレンスでもあって、WordPress で何かしようというときには必ず役立つ文書です。
お示しになったコードですが、同じ内容なので、違いはなくて、同じテーブルができるのは正常な動作だと思います(テーブル作成関数はプラグインの有効化にフックした方がいいと思いますが)。
dbDelta() 関数は、CREATE クエリを渡すと、データベースを調べて、次のようにふるまいます。
- 同名のテーブルが存在しないなら、定義に従って新たに作る
- 同名のテーブルが存在し、フィールドの定義が同じなら、何もしない
- 同名のテーブルが存在し、フィールドの定義が異なれば、ALTER TABLE クエリを発行してスキーマを変更する
バージョンが変わるたびに自ら ALTER TABLE クエリを発行して、フィールド定義を変更するプラグインも多く存在しますが、WordPress 的には、dbDelta() を使うのが由緒正しい使い方、ということになるようです。Codex では、’sticky’ (「融通がきかない」) と形容されているとおり、ちゃんと書法を守らないと動作してくれない関数ではありますが、正しい使い方をすればちゃんと動いてくれます。
蛇足ですが、dbDelta() 関数の仕様からすると、
if ($wpdb->get_var("show tables like '" . table_name_with_prefix($table_name) . "'") != table_name_with_prefix($table_name))のチェックは、dbDelta() がやってくれるので、必要ありません。むしろ、このままだと、同じ名前のテーブルが存在すると、dbDelta($sql) が実行されず、フィールドの定義を変更したいと思っても、意図したとおりの結果にならないのではないでしょうか。この if 文と同じような例が日本語版 Codex Creating Tables with Plugins に掲載されていますが、翻訳元の英語版には存在しません。翻訳途中なのかもしれませんね。
フォーラム: 使い方全般
返信が含まれるトピック: DBのwp_usermetaをクエリで操作（削除）$wpdb->postsのpost_authorに他のユーザIDが入っていないのであれば、こんなのはどうでしょうか？
MySQLはDELETEに複数テーブルを指定できるので、
$wpdb->query("DELETE wp_users, wp_usermeta FROM wp_users, wp_usermeta WHERE wp_users.ID=wp_usermeta.user_id AND wp_users.user_login NOT IN ('admin'));ということができます。ループなしで、一気に削除です。
フォーラム: プラグイン
返信が含まれるトピック: [プラグイン開発]プラグイン管理画面中の画面遷移について。Codexはもうお読みになっていると思いますので、要点だけで失礼します。
a.データ一覧ページには、
options-general.php?page=slugというようなリンクが作ってあり、b.データ詳細編集ページは、
function show_b() { if ($_GET['page'] == 'slug') { database_access_codes...; show_contents_codes...; } }といった構成になっているとします。
この場合、bをリンクだけで表示させるのは、どうやら無理のようです。「どうやら」というのは、コードを全て読み切れてはいないので、そういう処理をしていると読めるが、断言はできない、と解釈してください。
ページ要求のときに、WordPressは、
- registerされたmenu情報からタイトルやcapabilityを得る
- capabilityが十分かどうかチェックして関数を実行する
という処理をしているようです。capabilityのチェックは当然で、これがないと、任意のコードが実行できてしまうというのはすぐわかると思います。
問題はこれをリンクからWordPressの関数に渡せるかどうか、ということになります。もし、これが可能ならば、capabilityのチェックは意味がなくなって、何でもありということになってしまいますから、「できない」と解釈するのがよいと思います。
さて、対策ですが、素直にmenuを登録するのがよいと思います。つまり、
add_menu_page(a.データ一覧ページを登録); add_submenu_page(b.データ詳細編集ページを登録);として、トップメニュー(推奨されていませんが)とサブメニューを登録し、a.データ一覧ページに、
admin.php?page=slugと、リンクを張ると、リンクをクリックすれば該当のページに飛ぶことができます。メニューを出してしまえば、リンクの意味がないではないか、と言われそうですが、パラメータを渡せば、被リンク側関数で表示をコントロールすることもできるので、少しはマシということでご勘弁を。