フォーラムへの返信

15件の返信を表示中 - 1 - 15件目 (全59件中)
  • トピック投稿者 developer

    (@6flat)

    自分でもほぼ同じ内容で試してみましたが、gettext よりは get_comment_author の方がほんの少しメモリのコストが低い様だったので後者を利用してみようと思います。
    (実行時間の差がどれくらいあるのかは分かりません)

    検証までして下さりありがとうございました。

    ちなみに私のコードは次のようになりました。

    function rename_anonymous( $author = '', $comment_ID = 0, $comment ) {
      if( empty( $comment->comment_author ) && empty( $comment->user_id ) ) {
        $author = '無記名';
      }
    
      return $author;
    }
    add_filter( 'get_comment_author', 'rename_anonymous', 20, 3 );

    トピック投稿者 developer

    (@6flat)

    gblsmさん、ご回答ありがとうございます。

    コメントウィジェットの表示と通常のコメント表示ではコメントを取得する方法が異なるのですね。
    アドバイスして下さった get_comment_author の第3パラメータの指定をする方法と gettext フィルターによる置き換えを試してみようと思いますが、結局表示を置き換えるだけなのであればコスト的にも最初のリンク先にある方法で良いのかもしれないと思えてきました…。

    フォーラム: 使い方全般
    返信が含まれるトピック: カスタム投稿タイプのパーマリンク階層構造

    まずパーマリンク構造を整理してみましょう。

    Custom Post Type Permalinksで設定したパーマリンク構造
    (分かりやすくするために%test_cat%を%custom_taxonomy%としています)

    /%custom_taxonomy%/%postname%/

    パーマリンク
    /custom_post_type/term/post/
    クエリ

    post_type=custom_post_type&custom_post_type=post&name=post&custom_taxonomy=term

    個別の投稿として有効なパーマリンク構造

    パーマリンク
    /custom_taxonomy/term/
    クエリ

    custom_taxonomy=term

    タクソノミーアーカイブとして有効なパーマリンク構造

    パーマリンク
    /custom_post_type/custom_taxonomy/term/
    クエリ

    post_type=custom_post_type&custom_taxonomy=term

    カスタム投稿内のタクソノミーアーカイブとして有効なパーマリンク構造

    パーマリンク
    /custom_post_type/term/
    クエリ

    name=term&category_name=custom_post_type

    個別の投稿ではない
    タクソノミーアーカイブではない
    投稿を表示するリライトルール(/category/post/)が適用されるため正しく機能しない
    適切なリライトルールがない無効なパーマリンク

    個人的にはURLが少し短くなる程度のメリットしかないように感じるので、どのカスタムタクソノミーのタームなのかが分かるように/custom_post_type/custom_taxonomy/termで良いのではないかと思いますが、一応対応する方法も書いておきますね。

    この無効なパーマリンクを有効にしたい時はadd_rewrite_ruleでリライトルールを追加します。
    実際には次のようにして追加します。

    function custom_rewrite_basic() {
      /**
       * パーマリンク
       * domain.com/custom_post_type/term
       *
       * custom_post_typeは実際に登録しているカスタム投稿タイプに置き換えてください
       * custom_taxonomyは実際に登録しているカスタムタクソノミーに置き換えてください
       * リライトルールを2つ追加していますが、これはページが分割されて表示される場合にも対応しなければいけないからです。
       */
      add_rewrite_rule( 'custom_post_type/(.+?)/page/?([0-9]{1,})/?$', 'index.php?post_type=custom_post_type&custom_taxonomy=$matches[1]&paged=$matches[2]', 'top' );
      add_rewrite_rule( 'custom_post_type/(.+?)/?$', 'index.php?post_type=custom_post_type&custom_taxonomy=$matches[1]', 'top' );
    }
    add_action( 'init', 'custom_rewrite_basic' );

    フォーラム: 使い方全般
    返信が含まれるトピック: カスタム投稿タイプのパーマリンク階層構造

    酔いが回った状態で回答していました。
    失礼しました。

    そして今じっくり見直していて思ったんですけど、他にも間違ってるところありますね。

    //'query_var' => false,
    // falseではなくカスタム投稿タイプを指定
    'query_var' => 'test'
    
    //'query_var' => true,
    // trueではなくタクソノミーを指定
    'query_var' => 'test_cat',

    一度そのコードはfunctions.phpから外してプラグインで設定した方が良いかもしれません。
    渡すべきパラメータが足りないとか間違っているとか、そういう事が原因である可能性も十分あるので、まずはそこから潰していくと原因も特定しやすいと思います。

    ちなみにプラグインはCustom Post Type Generatorが個人的におすすめです。
    このプラグインで作成したカスタム投稿タイプやカスタムタクソノミーの設定をExportするとこういうコードが取得できます。
    (プラグインで設定した内容によってパラメータは変化します)

    function cptg_custom_post_types()
    {
    	$labels = array(
    		'name' => 'テスト投稿タイプ',
    		'singular_name' => 'テスト投稿タイプ',
    		'menu_name' => 'テスト投稿タイプ',
    		'name_admin_bar' => 'テスト投稿タイプ',
    		'all_items' => '投稿一覧',
    		'add_new' => '新規追加',
    		'add_new_item' => '新規投稿を追加',
    		'edit_item' => '投稿の編集',
    		'new_item' => '新規投稿',
    		'view_item' => '投稿を表示',
    		'search_items' => '投稿を検索',
    		'not_found' =>  '投稿が見つかりませんでした。',
    		'not_found_in_trash' => 'ゴミ箱内に投稿が見つかりませんでした。',
    		'parent_item_colon' => '親投稿',
    	);
    	$args = array(
    		'labels' => $labels,
    		'public' => true,
    		'exclude_from_search' => false,
    		'publicly_queryable' => true,
    		'show_ui' => true,
    		'show_in_nav_menus' => true,
    		'show_in_menu' => true,
    		'show_in_admin_bar' => true,
    		'has_archive' => true,
    		'menu_position' => null,
    		'menu_icon' => null,
    		'hierarchical' => false,
    		'rewrite' => array( 'slug' => 'test','with_front' => true,'feeds' => true,'pages' => true ),
    		'query_var' => 'test',
    		'can_export' => true,
    		'supports' => array( 'title','editor' ),
    	);
    	register_post_type( 'test', $args );
    
    	$labels = array(
    		'name' => 'テストタクソノミー',
    		'singular_name' => 'テストタクソノミー',
    		'menu_name' => 'テストタクソノミー',
    		'all_items' => 'すべてのタグ',
    		'edit_item' => 'タグの編集',
    		'view_item' => 'タグを表示',
    		'update_item' => 'タグを更新',
    		'add_new_item' => '新規タグを追加',
    		'new_item_name' => '新規タグ名',
    		'parent_item' => '親カテゴリー',
    		'parent_item_colon' =>  '親カテゴリー',
    		'search_items' => 'タグを検索',
    		'popular_items' => '人気のタグ',
    		'separate_items_with_commas' => 'タグが複数ある場合はコンマで区切ってください',
    		'add_or_remove_items' => 'タグの追加もしくは削除',
    		'choose_from_most_used' => 'よく使われているタグから選択',
    		'not_found' => 'タグが見つかりませんでした。',
    	);
    	$args = array(
    		'labels' => $labels,
    		'public' => true,
    		'show_ui' => true,
    		'show_in_nav_menus' => true,
    		'show_tagcloud' => true,
    		'meta_box_cb' => null,
    		'show_admin_column' => true,
    		'hierarchical' => true,
    		'query_var' => 'test_cat',
    		'rewrite' => array( 'slug' => 'test_cat','with_front' => true,'hierarchical' => true, ),
    		'sort' => false,
    	);
    	register_taxonomy( 'test_cat', array( 'test' ) , $args );
    }
    add_action( 'init', 'cptg_custom_post_types' );

    Exportで取得したコードをfunctions.phpに貼り付けてしまえば、その後はプラグインを無効にしても大丈夫です。

    ただ、このプラグインは作者さんは日本の方なのですが、あえてパラメータを日本語に訳していないんですよね。
    そんなわけなので、Codexのregister_post_typeregister_taxonomyでそれぞれのパラメータを確認しながら設定を行った方が良いです。

    フォーラム: 使い方全般
    返信が含まれるトピック: カスタム投稿タイプのパーマリンク階層構造

    私、最初に書かれていたパーマリンク構造をしっかり見ることが出来てませんでしたね。
    申し訳ないですー。
    多分これで解決すると思うので、お付き合いくださいー。
    with_frontなんですけど、よーく見るとregister_post_typeの中にもありますよねー?
    もうお分かりだと思いますけど、そこがfalseになっているので、trueにしてあげてくださいー。

    フォーラム: 使い方全般
    返信が含まれるトピック: カスタム投稿タイプのパーマリンク階層構造

    そういう時はこうしちゃいましょうー。

    'rewrite' => array(
        'slug' => 'test_cat',
        'with_front' => false,
        'hierarchical' => true
    )

    あと、こういうのはCodexの関数リファレンスに大体書いてあるので、目を通してみると良いですよー。

    フォーラム: 使い方全般
    返信が含まれるトピック: カスタム投稿タイプのパーマリンク階層構造

    よく見るとslug間違ってますねー。
    これでどうでしょう?

    'rewrite' => array(
        'slug' => 'test_cat',
        'hierarchical' => true
    )

    フォーラム: 使い方全般
    返信が含まれるトピック: カスタム投稿タイプのパーマリンク階層構造

    カスタムタクソノミーのrewriteのパラメータをこうすると、お望みのパーマリンク構造になると思いますー。

    'rewrite' => array(
        'slug' => 'test',
        'hierarchical' => true
    )

    トピック投稿者 developer

    (@6flat)

    処理の流れを踏まえた上で、結果的に第二引数が無ければデータベースに書き込む前(function check_comment)のコメント本文に、第二引数があればデータベースへ保存済み(function comment_text)のコメント本文にフックすることが可能というわけですね。

    function comment_text()に確実フックしたいときは、新しく書いて頂いたコードのように第二引数をチェックした方が良さそうですね。

    分かりやすく説明して下さり助かりました。
    ありがとうございます。

    トピック投稿者 developer

    (@6flat)

    確かに、同じ名前のフィルターというのは不可思議ですし、紛らわしいですね。

    書いて下さったコードを試みたところ、コアファイルを修正することなく無事コメントを投稿できるようになりました。
    ありがとうございます。
    新規の投稿であるかどうかをそのようにして条件に加えたら良かったのですね。

    ちなみに、最初にget_commentでコメント情報が取得できないのなら$sの中身(コメント)も存在しないのではと安直に考えてしまったのですが、これは関数の実行されるタイミングの問題と見て良いですか?(うまく言葉を整理出来ませんが…)

    同名のフィルターがあるのは、フックする関数の方で対処が可能だそうです。

    第二引数がnullならcheck_comment(DBに挿入されたとき?)、nullじゃなければcomment_text(表示するとき)というように対処するという事でしょうか…?

    トピック投稿者 developer

    (@6flat)

    gblsmさん、ご回答ありがとうございます。

    初めて知りましたが、同名のフィルターが2つあるんですね。
    私の認識ではfunction comment_textにフックさせているつもりです。
    また、現在コメントを承認制にしておらず、またその予定もないのでcheck_commentの方にフックさせるつもりはありません。

    もしかするとフック先がおかしかったのでしょうか?

    フォーラム: 使い方全般
    返信が含まれるトピック: インストール直後からデータベースクエリが遅い
    トピック投稿者 developer

    (@6flat)

    解決しました。
    結論から言うと、原因はQuery Monitorでした。

    あれこれ調べているうちにDebug Barというプラグインを見つけ、また次のページに辿り着きました。

    Debug BarとDebug-Bar-ExtenderでWordPressのパフォーマンスチェック | Simple Colors

    まさかと思い、Query Monitorを停止してDebug Barのみでクエリを確認したところ、原因のクエリがクエリの一覧から消えました。
    この時は思わず乾いた笑いがこみ上げてきました。
    こんなところでjim912さんのお世話になるとは思いませんでしたが、本当に助かりました。
    回答して下さったお二方とjim912さんには心からお礼申し上げます。
    本当にありがとうございました。

    フォーラム: 使い方全般
    返信が含まれるトピック: インストール直後からデータベースクエリが遅い
    トピック投稿者 developer

    (@6flat)

    お試しで同じスタンダードプランの別のサーバを借りてWordPressをインストールしてみましたが、同じくwp_load_alloptions()で負荷の高いクエリが実行されました。
    gblsmさんと私の違いは一体何なのでしょうか…。

    option.phpにあるwp_load_alloptions()と全く同じ関数を作った上で内容を書き換えて実行結果を見てみましたが、キャッシュ自体は取得出来ている様でした。

    function test_load_alloptions() {
    	global $wpdb;
    
    	if ( !defined( 'WP_INSTALLING' ) || !is_multisite() ) {
    		$alloptions = wp_cache_get( 'alloptions', 'options' );
    		echo 'cache get';
    		var_dump( $alloptions );
    	} else {
    		$alloptions = false;
    	}
    // 省略
    }

    別の処理でキャッシュが破棄されているのでしょうか…。
    get_option()の内部でもwp_load_alloptions()が呼び出されている様なので、こちらも確認してみようと思います。

    フォーラム: 使い方全般
    返信が含まれるトピック: インストール直後からデータベースクエリが遅い
    トピック投稿者 developer

    (@6flat)

    mura0403さん、ご回答ありがとうございます。
    サポートに問い合わせたのですが、データベースサーバで支障が出る様な過負荷はないという返答でした。
    過負荷の無い状態でも他のユーザーから何らかの影響を受けるものなのでしょうか…?
    出来る事ならサーバを変えたくはないのですが…選択肢として一応考えておきます。

    フォーラム: 使い方全般
    返信が含まれるトピック: インストール直後からデータベースクエリが遅い
    トピック投稿者 developer

    (@6flat)

    何故か投稿が反映されないのでもう一度まとめます。

    私に今起こっている問題は、wp_load_alloptions()が呼び出される時に通常はオブジェクトキャッシュを利用するはずが、何らかの問題でオブジェクトキャッシュを取得できないために都度DBにクエリを送ってwp_optionsテーブルから100以上のデータを取得しているという事が原因の様です。

    これはマルチサイト機能を使うと起こる事らしいですが、私はマルチサイトは利用していませんし、新規インストールしたWordPress以外には何も無い状態なので、何が原因なのか私の知識では皆目見当がつかず、困り果てています。

    何か原因に見当のつく方が居られたらお力添えを頂けると助かります。

15件の返信を表示中 - 1 - 15件目 (全59件中)