今後開発とか試してみたいと思っていること(随時更新

ごくシンプルなSEO用のプログラム

ガチのやつは、正直プラグインを使った方が早いと思うので、簡易版。とりあえず仕様を考えるところから・・・・
ACFを使うことが多いけど、とりあえず「カスタムフィールド」を利用して、そっちに任意の入力があればそれを使い、無ければ記事の抜粋、とかかなあ、、、
meta description だけでいいわ、っていうぐらいの軽いもので。
OGPとか含むようだったら、プラグインのが楽だって気がするし。

Youtube API を使ってみるテスト

再生数:13023、いいね数:83、コメント数:11

Youtube API を利用して、特定の動画の再生回数やいいね数を表示してみるテストです。
すみません、本当にテストで作ってみただけなので、詳しい解説は追って追記します(…しないかもしれません)

https://developers.google.com/youtube/v3/getting-started?hl=ja

APIキーの制限を「なし」にしないと403エラーになるのは、いまいち納得いかない。PHPに書いているからだとしても、IPアドレスか、HTTPリファラーでいいんじゃないの、、、と思ったり。不明。

URLを知る人しか見られない、という動画であっても、再生回数とかが取得できるのかどうかは謎。

許可したタグをエスケープしない wp_kses()

たまに使おうと思うたびに忘れるので、ここにメモ

wp_kses()

だいたいこんな書き方

wp_kses(
	$string,
	array(
		'span' => array(
			'class' => array(),
		),
	)
)

KSES is a recursive acronym which stands for “KSES Strips Evil Scripts”.

https://developer.wordpress.org/reference/functions/wp_kses/#more-information

…とあるのだけど、Kはどこから来たんだろう…

WPサイト URL の変更

wp-config.php ファイルを使った手動設定

//WordPress のコアファイルが存在する URL 
define( 'WP_SITEURL', 'https://example.com/wordpress' );

//フロントのURL
define( 'WP_HOME', 'https://example.com/wordpress' );

いつも忘れるのでメモ……

  • https:// の部分は含める必要があります
  • 最後のスラッシュ “/” は含めないでください
  • データベースの値を上書きしません
  • 管理画面の設定>一般 で値を変更することはできなくなります
https://ja.wordpress.org/support/article/editing-wp-config-php/#wp_siteurl

WordPress の「サイトで技術的な問題が発生しています」のメールを停止

WPサイトを編集している最中にうっかりエラーを出してしまうと、「サイトで技術的な問題が発生しています」という表題のメールが、WordPress管理者のメアドに飛ぶ場合があります。「場合があります」というのは、はっきりしないんですが、エラーを踏んだら、その度に必ずメールが送られているわけではなさそうだからです。(今のところ、管理画面でエラーを踏んだ場合かな、、、と思っていますが、はっきりしません)

WordPress 管理者のメアドがクライアントのものになっている場合に、「なんかメールきましたけど!!?」と要らぬ心配をかけてしまったことがあります(反省)。
もちろん、公開中のサイトではなかったんですが、開発中でも、驚かせてしまうことには変わりがないので、時々止めておきたいこの機能・・・、探したら方法が見つかりました。

wp-config.php に一文追加

//エラーのメッセージを送信しない
//define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );

この一文をwp-config.php の
/* 編集が必要なのはここまでです ! WordPress でのパブリッシングをお楽しみください。 */
の前に書き込んでおけばOKです。

参考:https://ja.wordpress.org/support/article/editing-wp-config-php/#wp_disable_fatal_error_handler

私は、下記のように、デバッグモードの近くに書いておくようにしました。
テーマなどを触る時だけ使って、通常時はコメントにしておくといいかもしれません。

/**
 * 開発者へ: WordPress デバッグモード
 *
 * この値を true にすると、開発中に注意 (notice) を表示します。
 * テーマおよびプラグインの開発者には、その開発環境においてこの WP_DEBUG を使用することを強く推奨します。
 *
 * その他のデバッグに利用できる定数についてはドキュメンテーションをご覧ください。
 *
 * @link https://ja.wordpress.org/support/article/debugging-in-wordpress/
 */
// WP_DEBUG モードを有効化
define( 'WP_DEBUG', true );

// /wp-content/debug.log ファイルへのデバッグログの出力を有効化
define( 'WP_DEBUG_LOG', true );

// エラーと警告の画面への表示を無効化
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

//エラーのメッセージを送信しない
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );

そもそもこのメール何??

ほぼ常にデバッグモードと共に開発をしているせいか、「なんでわざわざメール送ったりするわけ???」と不思議でならなかったのですが、調べたところ、致命的なエラーがある時にサイトにログインできなくなる場合もあり、それを回避するために導入されたようです。

https://make.wordpress.org/core/2019/04/16/fatal-error-recovery-mode-in-5-2/

「サイトで技術的な問題が発生しています」のメールはつまり、「リカバリーモード」の一環として、エラーが起きたことを知らせて、リカバリー(復旧)用の特別なログインURLを送るメールなのかなと。「リカバリーのメール」って表題にしてくれたらいいのに…。サイトの所有者がサイトの開発者に知らせて直してもらうための基本的な情報が書いてあります。

具体的な内容

リカバリーのメールの具体的な内容は以下の通りです。

こんにちは。
WordPress 5.2から、サイトでプラグインやテーマが致命的なエラーを発生させた場合にそれを検知してこの自動メールでお知らせする機能が追加されました。
今回の場合、WordPress がテーマ テーマ名 でエラーを捉えました。
まずはじめに、ご自分のサイト(URL)を開き、目に見える問題がないか確認してください。次に、エラーが発生したページ(URL)を開き、同様に問題がないか確認してください。
この問題をさらに調査するにはサーバーホストに連絡してみてください。

もしサイトが壊れていてダッシュボードに正常に接続できない場合、WordPress には特別な「リカバリーモード」があります。これによりダッシュボードに安全にログインし、さらに調査をすることができます。
〈リカバリー用URL〉
サイトを安全に保つため、このリンクは 1日 で有効期限が切れます。ですが、心配なく。有効期限後にこのエラーが再度発生すれば新しいリンクをお送りします。

この問題を解決しようとする際、以下の情報を聞かれるかもしれません。
WordPress バーション5.8.2
現在のテーマ: テーマ名 (バージョン 1.0)
現在のプラグイン: (バージョン )
PHP バージョン8.0.12
===========
エラー詳細
エラータイプ E_PARSE が template-tags.php ファイルの 213 行目で発生しました。 エラーメッセージ: syntax error, unexpected token “;”, expecting “)”

メールの文章をざっくり3つに分けました。
1番目の塊は、どのサイトのどのページでエラーを検知したかの内容。
2番目の塊は、リカバリー用URLの案内、
3番目の塊は、基本的な環境の情報と、エラーの原因についての記載(デバッグモードでみる内容と同じ)
という感じでしょうか。

サイト公開後の運用中の段階で何か起こった時には、とても便利な機能かな、と思っています。

XML サイトマップからユーザ別一覧を除外する

テーマの functions.php に以下を追加

/**
 * サイトマップからユーザを外す
 * https://make.wordpress.org/core/2020/07/22/new-xml-sitemaps-functionality-in-wordpress-5-5/
 */
function remove_user_archive_from_sitemap ( $provider, $name ) {
	if ( 'users' === $name ) {
		return false;
	}
		return $provider;
	}
add_filter( 'wp_sitemaps_add_provider', 'remove_user_archive_from_sitemap', 10, 2 );

これでOKです!

プラグイン不要でXMLサイトマップを自動生成

WordPress はそのサイトの(ほぼ)全てのページを網羅する XML サイトマップを自動で生成します。この機能はWordPress パージョン 5.5 で追加されました。
すでにWPサイトをお持ちの方は(そして5.5以上なら)、公開のアドレス(トップページ)の最後に「/wp-sitemap.xml」を付けると確認できるはずです。

詳しい解説は下記にあります。

https://make.wordpress.org/core/2020/07/22/new-xml-sitemaps-functionality-in-wordpress-5-5/

XMLサイトマップにリストされる内容は?

ちなみにこのサイトのXMLサイトマップはこちらです。(ユーザ別アーカイブは外してあります)

https://learning.ccc-labo.net/wp-sitemap.xml

上記のXMLサイトマップは、階層構造になっていて、「/wp-sitemap.xml」にさらにXMLサイトマップのURLがリストされている、という構造になっています。XMLサイトマップにリストされるのは以下のようなページです。

  • 投稿の全てのページ
  • 固定ページの全てのページ
  • カスタム投稿があればその全てのページ(※)
  • カテゴリやタグなどのアーカイブページ
  • カスタムタクソノミーのアーカイブページ(※)
  • Author のアーカイブページ

※公開クエリがfalseになっている場合はそのカスタム投稿のページは掲載されません

カスタム投稿のアーカイブは、XMLサイトマップに入らないので、追加したい場合は、XMLサイトマップをカスタマイズする必要があると思います。

さて、XMLサイトマップに列挙される中に、「Author のアーカイブページ」があります。これは、そのサイトで「記事を書くユーザ別のアーカイブ」のことです。この「ユーザ」を知られたくない場合があります。「ユーザ別のアーカイブ」では、うっかり、アカウント名がURLに利用されますので、セキュリティ上、ユーザのアカウントを見られたくない、知られたくないと言う場合は、多いと思います。

「ユーザ別のアーカイブはサイトマップから外したい!!」

そんな時は、冒頭に紹介したコードをテーマの functions.php に書けばOKです。

ちなみに、自動のXMLサイトマップは、設定>表示設定の「検索エンジンがサイトをインデックスしないようにする」にチェックが入っていると表示されません(404エラー扱いになる)ので、お気をつけください(こないだうっかりひっかかった…)。

WordPressサイトの<head>内の整理

以下、詳細な説明は追って追加していきますが、テーマのフロントエンドの <head> に出力されるもので、これは不要かな、と思うものをザクザクと削除するスクリプト一式です。
functions.php に書きます。

//絵文字使わない
remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('wp_print_styles', 'print_emoji_styles');
add_filter( 'emoji_svg_url', '__return_false' );

//generatorは削除
remove_action('wp_head', 'wp_generator'); 

//wlwmanifestをトル
remove_action('wp_head', 'wlwmanifest_link');

//フィードを消す
remove_action('wp_head', 'feed_links', 2);
remove_action('wp_head', 'feed_links_extra', 3);

//xmlrpcは要らない
remove_action('wp_head', 'rsd_link');

//ショートリンクの表示を削除
remove_action('wp_head', 'wp_shortlink_wp_head');

//<link>の前ページ、次ページをトル
remove_action('wp_head','adjacent_posts_rel_link_wp_head',10);

//srcsetは削除
add_filter( 'wp_calculate_image_srcset', '__return_false' );

//canonical は削除
remove_action( 'wp_head', 'rel_canonical' );

//Embed系のタグを削除
remove_action('wp_head','rest_output_link_wp_head');
remove_action('wp_head','wp_oembed_add_discovery_links');
remove_action('wp_head','wp_oembed_add_host_js');
remove_action('template_redirect', 'rest_output_link_header', 11 );

//DNS プリフェッチのタグを削除
function remove_dns_prefetch( $hints, $relation_type ) {
	if ( 'dns-prefetch' === $relation_type ) {
		return array_diff( wp_dependencies_unique_hosts(), $hints );
	}
	return $hints;
}

昔から繰り返し使っているもので、エラーは特に出てないと思いますが、未検証のものも多いので、追々、確認していこうと思っています。

2021-11-23 に大幅加筆修正

WordPress 5.0以降で追加された、ブロックエディタ関連のインラインスクリプトを消す方法は、以下に案内しています。

https://learning.ccc-labo.net/2021/11/delete-wp-block-library-theme-inline-css-of-frontend/