許可したタグをエスケープしない 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:// の部分は含める必要があります
  • 最後のスラッシュ “/” は含めないでください
  • データベースの値を上書きしません
  • 管理画面の設定>一般 で値を変更することはできなくなります

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 );

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

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

「サイトで技術的な問題が発生しています」のメールはつまり、「リカバリーモード」の一環として、エラーが起きたことを知らせて、リカバリー(復旧)用の特別なログイン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」を付けると確認できるはずです。

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

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

wp-block-library-theme-inline-css を削除

WordPress 5.8.2 現在、フロントに下記のようなインラインCSSが読み込まれていることに気が付きました。

<style id='wp-block-library-theme-inline-css'>
    #start-resizable-editor-section {
        display:none
    }

    .wp-block-audio figcaption {
        color: #555;
        font-size: 13px;
        text-align:center
    }

    .is-dark-theme .wp-block-audio figcaption {
        color:hsla(0, 0%, 100%, .65)
    }

    .wp-block-code {
        font-family: Menlo, Consolas, monaco, monospace;
        color: #1e1e1e;
        padding: .8em 1em;
        border: 1px solid #ddd;
        border-radius:4px
    }

    .wp-block-embed figcaption {
        color: #555;
        font-size: 13px;
        text-align:center
    }

    .is-dark-theme .wp-block-embed figcaption {
        color:hsla(0, 0%, 100%, .65)
    }

    .blocks-gallery-caption {
        color: #555;
        font-size: 13px;
        text-align:center
    }

    .is-dark-theme .blocks-gallery-caption {
        color:hsla(0, 0%, 100%, .65)
    }

    .wp-block-image figcaption {
        color: #555;
        font-size: 13px;
        text-align:center
    }

    .is-dark-theme .wp-block-image figcaption {
        color:hsla(0, 0%, 100%, .65)
    }

    .wp-block-pullquote {
        border-top: 4px solid;
        border-bottom: 4px solid;
        margin-bottom: 1.75em;
        color:currentColor
    }

    .wp-block-pullquote__citation, .wp-block-pullquote cite, .wp-block-pullquote footer {
        color: currentColor;
        text-transform: uppercase;
        font-size: .8125em;
        font-style:normal
    }

    .wp-block-quote {
        border-left: .25em solid;
        margin: 0 0 1.75em;
        padding-left:1em
    }

    .wp-block-quote cite, .wp-block-quote footer {
        color: currentColor;
        font-size: .8125em;
        position: relative;
        font-style:normal
    }

    .wp-block-quote.has-text-align-right {
        border-left: none;
        border-right: .25em solid;
        padding-left: 0;
        padding-right:1em
    }

    .wp-block-quote.has-text-align-center {
        border: none;
        padding-left:0
    }

    .wp-block-quote.is-large, .wp-block-quote.is-style-large {
        border:none
    }

    .wp-block-search .wp-block-search__label {
        font-weight:700
    }

    .wp-block-group.has-background {
        padding: 1.25em 2.375em;
        margin-top: 0;
        margin-bottom:0
    }

    .wp-block-separator {
        border: none;
        border-bottom: 2px solid;
        margin-left: auto;
        margin-right: auto;
        opacity:.4
    }

    .wp-block-separator:not(.is-style-wide):not(.is-style-dots) {
        width:100px
    }

    .wp-block-separator.has-background:not(.is-style-dots) {
        border-bottom: none;
        height:1px
    }

    .wp-block-separator.has-background:not(.is-style-wide):not(.is-style-dots) {
        height:2px
    }

    .wp-block-table thead {
        border-bottom:3px solid
    }

    .wp-block-table tfoot {
        border-top:3px solid
    }

    .wp-block-table td, .wp-block-table th {
        padding: .5em;
        border: 1px solid;
        word-break:normal
    }

    .wp-block-table figcaption {
        color: #555;
        font-size: 13px;
        text-align:center
    }

    .is-dark-theme .wp-block-table figcaption {
        color:hsla(0, 0%, 100%, .65)
    }

    .wp-block-video figcaption {
        color: #555;
        font-size: 13px;
        text-align:center
    }

    .is-dark-theme .wp-block-video figcaption {
        color:hsla(0, 0%, 100%, .65)
    }

    .wp-block-template-part.has-background {
        padding: 1.25em 2.375em;
        margin-top: 0;
        margin-bottom:0
    }

    #end-resizable-editor-section {
        display: none
    }
    </style>

調べてみたところ、
wp_common_block_scripts_and_styles()
という関数の中に

if ( current_theme_supports( 'wp-block-styles' ) ) {
	wp_enqueue_style( 'wp-block-library-theme' );
}

と書いてあり、おそらくこの 'wp-block-library-theme' というキーで読み込まれているスタイルのようだぞ、と。
前後の if 文を見ると、テーマで 'wp-block-styles' をサポートしている場合と読めるので、ブロックスタイルをサポートしていたら、上記のインラインスタイルを読み込むというような仕組みらしい。5.0 から、設置されているようですね。

調べたら、当該のテーマでは、ばっちり、add_theme_support( 'wp-block-styles' ) してました。

とは言え、邪魔なので、フロントからは削除

テーマの functions.php に下記のように書きます。

function ccc_theme_scripts() {
	
	//そのほか
	
	/**
	 * wp_common_block_scripts_and_styles() 経由で
	 * ブロックスタイルサポート時に読み込まれているインラインCSSをフロントからは削除
	 * 
	 * @url https://developer.wordpress.org/reference/functions/wp_common_block_scripts_and_styles/
	 */
	wp_dequeue_style( 'wp-block-library-theme' );
	
	//そのほか
}
add_action( 'wp_enqueue_scripts', 'ccc_theme_scripts' );

'wp-block-library-theme' というキーで読み込まれているスタイルなので、同じキー名で否定する、、、という感じです、
wp_dequeue_style( 'wp-block-library-theme' )
が、その部分です。
テーマでフロントに読み込むスクリプトやスタイルをまとめて読み込んでいる部分に一緒に書いています。たぶん、そうじゃないと動かないはず(試してないですが)。

あくまで、フロントだけ削除してます。管理画面でも読み込まれているんですけど、そっちは、まあ、いいかな、、、と思って、、、。フロントエンドの <head> の中をスッキリさせたい、スタイルの衝突を防ぎたいのが目的です。(仕方ないのかもしれないけど、まじ、インラインCSSはやめてくれ!て思う・・・)

下記の記事を参考にしました。

リビジョンの制御

リビジョン、便利な機能なのですが、開発中にリビジョンが「かさむ」のが少し、嫌で。
需要はあるかわかりませんが、リビジョンを停止、もしくは上限を設ける方法のご案内です。

下記のコードを、wp-config.php に書きます。

/**
 * リビジョンを制御
 * リビジョンを保存しない
 * @url https://ja.wordpress.org/support/article/revisions/#%E3%83%AA%E3%83%93%E3%82%B8%E3%83%A7%E3%83%B3%E8%A8%AD%E5%AE%9A
 */
define( 'WP_POST_REVISIONS', false );

/**
 * リビジョンを制御
 * リビジョンを3件保存(プラス自動保存1つ)
 */
define( 'WP_POST_REVISIONS', 3 );

/**
 * リビジョンを制御
 * リビジョンを全て保存(デフォルト)
 */
define( 'WP_POST_REVISIONS', true );

参考にしたのは下記のページ。

リビジョンの削除

ざっと調べたところ、プラグインを使うというのが優勢でした。DBから直接削除も可能です。いずれも、実施の際はバックアップを取ってから!というのが重要かと。

いずれ、WP-CLI とかで、できるようになったらいいなあ・・・・。