カテゴリー: Web制作・プログラミング

WordPressのAll in One SEOは自動でパンくずの構造化データを出力してくれる。

大変ありがたいんだけど、自前でプログラムを用意する場合や、他のプラグインを使いたくてちょっと邪魔になる場合もある。

しかし管理画面から構造化データの出力をオフにすることはできないので、プログラムで書いてやる必要があるのであった。。

実装

こう！

add_filter( 'aioseo_schema_output', 'aioseo_filter_schema_output' );

function aioseo_filter_schema_output( $graphs ) {
    foreach ( $graphs as $index => $graph ) {
		if ( 'BreadcrumbList' === $graph['@type'] ) {
			unset( $graphs[ $index ] );
		}

		foreach ( $graph as $key => $value ) {
			if ( 'breadcrumb' === $key ) {
				unset( $graphs[ $index ][ $key ] );
			}
		}
	}
	return $graphs;
}

なお、All in One SEOが吐き出す構造化データを全部消したいときは、こう！

add_filter( 'aioseo_schema_disable', 'aioseo_disable_schema_products' );

function aioseo_disable_schema_products( $disabled ) {
   if ( is_singular( 'product' ) && aioseo()->helpers->isWooCommerceActive() ) {
      return true;
   }
   return $disabled;
}

以上、現場からでした。

wp_queryで、特定のtermを選択している記事を表示させるのはリファレンスに書いてあるとおり、

$args = array(
	'post_type' => 'post',
	'tax_query' => array(
		array(
			'taxonomy' => 'people',
			'field'    => 'slug',
			'terms'    => 'bob',
		),
	),
);
$query = new WP_Query( $args );

これでオッケー。

じゃあ、termを何も選択していない記事だけ表示したいときはどうすんのということですが、ググったけどわからずChatGPTに聞いたら教えてくれたので、ググってこの記事にたどり着いてしまった人に共有しておきます。

$args = array(
	'post_type' => 'post',
	'tax_query' => array(
		array(
			'taxonomy' => 'people',
			'operator'    => 'NOT EXISTS'
		),
	),
);
$query = new WP_Query( $args );

こうです！

以上、現場からでした。

ローカルでXAMPPとかを使ってWordPressの開発を行っている際、MW WP Formの確認→完了の遷移や、メール本文の中身もテストしたい。

そんなご要望にばっちりお応えする機能が、MW WP Formにはあります。

実装

wp-config.phpに、以下のように書きます。場所は define(‘WP_DEBUG’, false); の直下にでも。

define('WP_DEBUG', false); // ←元からあるやつ
define('MWFORM_DEBUG', true); // ←追加

これだけで、MW WP Formのデバッグモードが有効になります。

デバッグモード中は、送信ボタンを押してもメールは送信されませんが、メールが機能していなくても確認→完了画面の遷移が機能します。

また、wp-content > uploads > mw-wp-form_uploads フォルダ内に、メール送信時のログが出力されます！

これにより、メールを送信することなく、メールの中身を見ることが可能。公開されているサイトでも、メール送信なしで動作確認したい場合にも使えますね。

現場からは以上です。

wp_get_archives()でカスタム投稿タイプの月ごとのアーカイブのリストを表示させたのに、リンク先が404になってしまう…

そんなときの対策です。

なぜ404になるんだい

月別アーカイブページのURLって、デフォルトだと例えばnewsという投稿タイプであれば’/news/2021/08’みたいな感じだと思うんですけど、投稿タイプのパーマリンクを’/news/%post_id%’にしてしまっている場合、記事の詳細ページのURLが’/news/2021’って感じで、アーカイブのURLとかぶるんですよね。

つまり、「‘/news/2021/08’ という記事はありませんよ」と誤って認識されちゃうみたいです。

アーカイブページじゃなくて、記事ページとして認識されてしまっている。

ということは記事のパーマリンク構造を変えればいけるのでは？ってなると思うんですが、記事のパーマリンク構造を変えるのはまぁいろいろきついです。

ここは、もっと簡単なプランBでいきましょう。

実装

実は、月別アーカイブページには「/news/2021/08」ではなく「/news/date/2021/08」でもアクセスできることがあります。これはアクセスできないときもあるので、おそらく、パーマリンクを’/news/%post_id%’にしているとき限定で特別に用意されるパーマリンクなのかなと。

というわけで、wp_get_archives()のリンクの文字列を無理やり書き換えちゃいましょう。

wp_get_archives(); を書く場所を、以下のように変更。

$args = array(
  'show_post_count' => true,
  'echo' => false,
  'post_type' => 'news'
);

$monthly_list = wp_get_archives( $args );
$monthly_list = str_replace('/news/', '/news/date/', $monthly_list);
echo $monthly_list;

wp_get_archives()はそのままでは出力までしてしまうのですが、‘echo’ => falseを設定することで、文字列として変数に代入できます。
さらに文字列を置換する関数str_replaceで、リンクの’/news/’を’/news/date/’に書き換えているわけですね。

ちなみにですが、デフォルトの投稿（post）では、この処理はwp_get_archives()で自動でやってくれるみたいなので、やらなきゃいけないのはカスタム投稿タイプのときだけのようです。

現場からは以上です。

WordPressの現在のURLを取得する方法を調べていたところ、get_the_permalink();を使う方法がよく紹介されていたのですが、なんか難しかったのでもっと簡単な方法がないかと、自分なりにシンプルにできる方法を考えてみました。

実装

get_the_permalink();ではなく、get_permalink(); を使用します。
これは、引数に記事IDを入れることで、その記事のURLを取得することができる関数。

つまり、今の記事のIDを取得して、get_permalink(); に入れればいいわけです。

$current_url = get_permalink( $post->ID );

 
以上、現場からでした。

WordPressの検索、便利なんですがカスタムフィールドには対応していません。

というわけで、対応させましょう。

実装

デフォルトのフリーワード検索を使う場合。通常のフリーワード検索はタイトル、本文、カテゴリー、タグあたりを検索しますが、そこにカスタムフィールドも追加で検索できるようにするイメージです。

functions.phpに以下のように書きます

function cf_search_join( $join ) {
	global $wpdb;
	if ( is_search() ) {
		$join .= ' LEFT JOIN ' . $wpdb->postmeta . ' ON ' . $wpdb->posts . '.ID = ' . $wpdb->postmeta . '.post_id ';
	}
	return $join;
}
add_filter( 'posts_join', 'cf_search_join' );

function cf_search_where( $where ) {
	global $wpdb;
	if ( is_search() ) {
		$where = preg_replace(
			"/\(\s*" . $wpdb->posts . ".post_title\s+LIKE\s*(\'[^\']+\')\s*\)/",
			"(" . $wpdb->posts . ".post_title LIKE $1) OR (" . $wpdb->postmeta . ".meta_value LIKE $1)", $where );

		// 特定のカスタムフィールドを検索対象から外す
//		$where .= " AND (" . $wpdb->postmeta . ".meta_key NOT LIKE 'number')";
//		$where .= " AND (" . $wpdb->postmeta . ".meta_key NOT LIKE 'zip')";
//		$where .= " AND (" . $wpdb->postmeta . ".meta_key NOT LIKE 'access')";
	}
	return $where;
}
add_filter( 'posts_where', 'cf_search_where' );

function cf_search_distinct( $where ) {
	global $wpdb;
	if ( is_search() ) {
		return "DISTINCT";
	}
	return $where;
}
add_filter( 'posts_distinct', 'cf_search_distinct' );

特定のカスタムフィールドを検索対象からはずすこともできます。

こちらの記事を参考にさせていただきました。ありがとうございます。
WordPress内の検索対象にカスタムフィールドも適用する

現場からは以上です。

WordPress functions.phpを関数ごとに分割して管理しやすくする話

WordPressの記事一覧でよくある、公開して一週間の間は「NEW」を表示させるやつ。

毎回テンプレートに直接プログラムを書くのは大変なので、関数を作って、表示させる日付も簡単に変更できるようにしましょう。

実装

functions.phpに、以下のように書きます

function get_my_new( $limit = 7 ) {
  $days = $limit;
  $today = date_i18n('U');
  $entry = get_the_time('U');
  $kiji = date('U',($today - $entry)) / 86400;

  // 出力部分
  if( $days > $kiji ){
    $html = ' class="new"';
  } else {
    $html = '';
  }
  return $html;
}

$html = ‘ class=”new”‘;の部分を、表示させるNEWマークに合わせて変更してください。この場合は、newというclassをくっつける処理ですね。画像を出したり、テキストを出したり、なんでもできます。

$limit = 7の部分で、デフォルトで何日表示させるかを設定できます。

※functions.phpは、以下の記事のように関数ごとにファイルを分けると、使いやすくなります。

WordPress functions.phpを関数ごとに分割して管理しやすくする話

あとはテーマ内でNEWマークを表示させたい部分に、

<?php echo get_my_new(); ?>

と書くだけです。

ここで、

<?php echo get_my_new(10); ?>

のように引数を指定してやると、デフォルトでは７日だけど、この部分だけ10日表示させるといったことも可能です。

以上、現場からでした。

WordPressを構築していたら、本番環境とテスト環境で違う値にしなきゃいけないことがあると思います。

例えばMW WP Formをfnctions.phpでカスタマイズする場合、フックにフォームIDを使う必要があるわけですが、テストと本番ではIDが違う場合が多いです。

そんなとき、テストから本番にアップする際は値を変えてアップする…なんてことをしていると、テストでは動かなくなるし、また違う日に違うカスタマイズを誰かがやらなきゃいけなくなったときに、その値を正しく変えてくれる保証はありません。いつの間にか動かなくなってるとか怖いですよね。そしてめんどくさい。そんなことを考えなきゃいけないのが何よりめんどくさい。

というわけで、いい感じに解決しましょう。

wp-config.phpに定数を定義する

テスト環境と本番環境でほぼ間違いなく違っていて、そしてそう触ることのないファイル。
それがwp-config.phpです。

wp-config.phpには各環境のデータベース情報が書かれていますので、つまりその環境ごとに固有の設定が書かれているわけです。wp-config.phpは、テストで修正したものを本番にアップする際に、そのまま一緒にアップするということはまずないと思います。

そんなwp-config.phpに定数を定義してあげれば万事解決。

例えばテストでは

/** MW WP Form ID Settings. */
define('MW_WP_FORM_ID', 2222);

とし、本番では

/** MW WP Form ID Settings. */
define('MW_WP_FORM_ID', 3333);

こうしとく。

ちなみにですが、この定数はwp-config.phpにもともと書かれている「/* 編集が必要なのはここまでです ! WordPress でブログをお楽しみください。 */」より上に書いてください。つまり「define(‘WP_DEBUG’, false);」の真下ですね。じゃないとうまく動かないです。

そしてfunctions.phpのフック内では

add_filter( 'mwform_choices_mw-wp-form-'.MW_WP_FORM_ID, 'mwform_add_birthday_options', 10, 2 );

こうやって定数を呼び出してやれば、同じfunctions.phpをテスト/本番で使っていても、値はそれぞれ別になっていることになります。

これで安心！いろんな面倒なことから解放されます。環境が他にもあったとしても使えますしね。

以上、現場からでした。