「WordPress」の記事 - Crieit

(WordPress) 非公開記事も含めた記事数カウントを管理画面に表示するプラグイン

2022-03-06T00:02:57+09:00

経緯

WordPress でブログを運用していると、カテゴリーやタグ、カスタムタクソノミーを整理したくなることがあります。

特にタグのように非階層型の入力形式のタクソノミーの場合は自由入力なので、スペースの有無や誤字等で似たようなタームを誤って生成しがちです。

Windows 11 と Windows11 (スペースの有無)
Google Chrome と Gooogle Chrome (誤字。 o が1つ多い)

しかも、異なるタグとして集計されるのでタグクラウドの中から絞り込むと思わぬところで必要な記事が漏れていて「あの記事絶対タグが付いているはずなのに……」と見付からずに右往左往したり。

基本的には管理画面の「投稿」→「タグ」に進んでタグの一覧からどちらか一方にタグを付け直して、もう片方のタグで「カウント」つまり記事数が0になったタグを削除すれば良いとは思います。

しかし、ここで一つ課題が。

技術記事等で自分用メモとして残すための非公開記事がいくつかあったりするのですが、先程のタグ編集画面の「カウント」は非公開記事は除外された数のようです。

そのため、例えタグ編集画面で「カウント」が0になっていても、実際は非公開記事で使用されていた……ということが考えられます。これでは迂闊にタグを削除することができません。

コード

そこで、タグ編集画面で非公開記事も含めたカウントを表示するプラグインを作りました。

class FrostColumns
{
    protected $taxName;
    protected $postTypeName;
    protected $countIncludePrivateID;
    protected $countIncludePrivateLabel;

    /**
     * mb_strlen() での空文字列判定のラッパー関数
     *
     * @param string $str        : 入力文字列
     *
     * @return boolean            : 出力文字列
     */
    public function boolStrLen( $str )
    {
        return mb_strlen(
            $str,
            'UTF-8'
        ) > 0;
    }
    /**
     * コンストラクタ
     *
     */
    public function __construct()
    {
        if(
            mb_strpos(
                parse_url(
                    $_SERVER['REQUEST_URI'],
                    PHP_URL_PATH
                ),
                'edit-tags.php',
                0,
                'UTF-8'
            ) !== false
        ) {
            // edit-tags.php のみで動作
            $tax = esc_html(
                filter_input(
                    INPUT_GET,
                    'taxonomy',
                    FILTER_SANITIZE_SPECIAL_CHARS
                )
            );
            // タクソノミーの名前を取得
            $this->taxName = $this->boolStrLen( $tax )
                ? $tax
                : '';
            $posttype = esc_html(
                filter_input(
                    INPUT_GET,
                    'post_type',
                    FILTER_SANITIZE_SPECIAL_CHARS
                )
            );
            // 投稿タイプの名前を取得
            $this->postTypeName = $this->boolStrLen( $posttype )
                ? $posttype
                : '';
            // ラベル
            $this->countIncludePrivateID = 'count_include_private';
            $this->countIncludePrivateLabel = 'カウント(非公開・予約含)';
        }
    }
    /**
     * SQLを直接発行して公開済み・非公開・予約投稿の記事の投稿IDのみの一覧を取得、その数をリンクと共に出力する
     *
     * @param int $termID : タームID
     *
     */
    public function countArticlesBySQL( $termID )
    {
        // $wpdb 読み込み (global で宣言した変数のスコープの兼ね合いでここで読み込み宣言する)
        require_once( ABSPATH . '/wp-load.php');
        global $wpdb;

        // 各タームのオブジェクトを取得
        $termObj = get_term( $termID, $this->taxName );
        // 投稿のカテゴリー、タグはキー名がタクソノミー編集ページと投稿一覧ページで異なるので変換する
        $taxNameParam = $this->taxName;
        switch ( $this->taxName ) {
            case 'category':
                $taxNameParam = 'category_name';
                break;
            case 'post_tag':
                $taxNameParam = 'tag';
                break;
            default:
                $taxNameParam = $this->taxName;
                break;
        }
        // カスタム投稿タイプならばリンクのGETパラメータに投稿タイプの名前を付与
        $postTypeParam = $this->boolStrLen( $this->postTypeName )
            ? '&post_type=' . $this->postTypeName
            : '';
        // SQLのクエリで指定する投稿タイプの名前の文字列をセット
        $postTypeDBParam = $this->boolStrLen( $this->postTypeName )
            ? $this->postTypeName
            : 'post';
        // WP_Query では結果の投稿オブジェクトが大き過ぎてメモリを食い潰すので直接SQLを発行してIDのみ結果として取得して省力化する
        $the_query = "SELECT " . $wpdb->prefix . "posts.ID FROM " . $wpdb->prefix . "posts LEFT JOIN " . $wpdb->prefix . "term_relationships ON (" . $wpdb->prefix . "posts.ID = " . $wpdb->prefix . "term_relationships.object_id) WHERE 1=1 AND ( " . $wpdb->prefix . "term_relationships.term_taxonomy_id IN ( %d ) ) AND " . $wpdb->prefix . "posts.post_type = %s AND ((" . $wpdb->prefix . "posts.post_status = 'publish' OR " . $wpdb->prefix . "posts.post_status = 'future' OR " . $wpdb->prefix . "posts.post_status = 'private')) GROUP BY " . $wpdb->prefix . "posts.ID ORDER BY " . $wpdb->prefix . "posts.post_date DESC";
        $results = $wpdb->get_results(
            $wpdb->prepare(
                $the_query,
                $termID,
                $postTypeDBParam
            )
        );
        $cnt = count($results);

        echo <<{$cnt}

CNT;

    }
    /**
     * 欄としての列の出力
     *
     * @param array $columns : 列
     *
     * @return array $columns : 列
     *
     */
    function addCountIncludePrivateColumns( $columns )
    {
        echo <<
    .taxonomy-{$this->taxName} .manage-column.num \{width: 90px;\}
    .taxonomy-{$this->taxName} .manage-column.column-id \{width: 60px;\}


STL;

        $columns[$this->countIncludePrivateID] = $this->countIncludePrivateLabel;
        return $columns;
    }
    /**
     * 追加した列に実際の値を表示させる
     *
     * @param string $content     : 出力するコンテンツ
     * @param string $column_name : 列名
     * @param int    $term_id     : タームID
     *
     */
    function customCountIncludePrivateColumns( $content, $column_name, $term_id )
    {
        if ( $column_name == $this->countIncludePrivateID ) {
            $this->countArticlesBySQL( $term_id );
        }
    }
    /**
     * 初期処理。アクションフック・フィルターフックを発動させる
     *
     */
    public function initialize()
    {
        // 列の追加
        add_filter(
            'manage_edit-' . $this->taxName . '_columns',
            [
                $this,
                'addCountIncludePrivateColumns'
            ]
        );
        // 追加した列に実際の値を表示させる
        add_action(
            'manage_' . $this->taxName . '_custom_column',
            [
                $this,
                'customCountIncludePrivateColumns'
            ],
            10,
            3
        );
    }
}

// 処理
$wp_ab_frostcolumns = new FrostColumns();

if( is_admin() ) {
    // 管理者画面を表示している場合のみ実行
    $wp_ab_frostcolumns->initialize();
}

コンストラクタ:
- URLをパースして edit-tags.php のみで動作するように判定
- GETパラメータからタクソノミーの名前と(必要ならば)投稿タイプの名前を取得
countArticlesBySQLメソッド:
- 本プラグインの肝
- 後で使用するため wp-load.php から $wpdb で WordPress のDBオブジェクトを読み込み
- edit-tags.php ではカテゴリーは category、タグは post_tag だが投稿一覧ページではそれぞれ category_name, tag とキーとなる文字列が変わるため遷移時の GETパラメータに付与するときのために変換をかけておく
- カスタム投稿タイプの場合、 SQLクエリや GETパラメータへの付与が必要になるため処理
- タクソノミーと投稿タイプ、投稿ステータス( publish, private, future のいずれか)で絞り込むSQLクエリを発行して投稿IDのみのオブジェクトを取得する
  - WP_Query で投稿データ全体のオブジェクトを取得すると重過ぎて PHP のメモリバッファを食い潰してしまうため、最小限になるように調整
- 記事数を count で取得して、 aタグとして出力
addCountIncludePrivateColumnsメソッド:
- テーブル出力にオリジナルの列を出力する。フィルターフック
customCountIncludePrivateColumnsメソッド:
- 追加した列に実際の値を表示させるアクションフック
- テーブル出力のキーが予めセットされていた文字列 (今回のオリジナル列) と同じ場合、 countArticlesBySQLメソッドを呼ぶ

やっていることとしてはこのような感じ。

検証

それでは、デモで検証してみます。

このように9つの記事を適当に作ってみました。今回はプラグインの効果をタグで試すことにします。

例えば、「ヘイルストーム」で記事を検索すると公開記事2件、非公開記事2件と2件ずつ、合計4件がヒットします。

ところが、通常のタグの編集画面では先の「ヘイルストーム」の記事数は2と表示されています。実際は非公開記事も含めて4件あるはずで、今回は「4」と表示されてほしいわけです。

それじゃスペルカード発動。先の「ヘイルストーム」の記事数は追加された列で4と表示されるようになりました。意図通りです。

別のサンプル。誤字した例として伸ばし棒のない「コールドディヴィニティ」は上述のタグ編集画面だと通常0件、追加列では1件と表示されています。ページ遷移すると、非公開記事1件のみが一覧に表示されています。

こういうケースでは伸ばし棒のある「コールドディヴィニティー」に直して、プラグインで追加された列も含めて「0」表示となったことを確認した後に伸ばし棒のない「コールドディヴィニティ」タグを削除する、というフローで活用できる、という寸法です。

参考

(未使用だが参考にはなった) 表示処理

WordPress\/edit-tags.php at master ・ WordPress\/WordPress ・ GitHub

$wp_list_table->display(); でテーブルを出力している。

WordPress\/class-wp-list-table.php at master ・ WordPress\/WordPress ・ GitHub

基底クラスのこの部分が該当処理。ただし汎用的な内容。

(未使用だが参考にはなった) WP_Terms_List_Table

WP_Terms_List_Table | Class | WordPress Developer Resources

使用しているクラス

column_posts()メソッドがそれっぽい。が、引数の $tag に既に情報が入っているようなのでこの中ではない。

WP_List_Table | Class | WordPress Developer Resources

display_rows()メソッドでもない。

found_postsプロパティ

(未使用) wp_count_posts()

WordPressで記事の数を取得する → wp_count_posts() か found_posts - シンプルシンプルデザイン WordPress

複雑な条件の件数となると WP_Query 一択。

タクソノミー→ターム

(未使用だが参考にはなった) WP_Term_Query

countプロパティはDBの値を読むだけ。逆に言えばDBに値が保存されていることが判明。

(未使用だが参考にはなった) タクソノミー操作系の目星

get_tax_sql()
- WordPress\/taxonomy.php at master · WordPress\/WordPress · GitHub
実際にテーブルを作っているクラス
- WordPress\/class-wp-terms-list-table.php at master · WordPress\/WordPress · GitHub
  - 基底クラス: WordPress\/class-wp-list-table.php at master · WordPress\/WordPress · GitHub

(未使用だが参考にはなった) タクソノミーやタームに関係ありそうなクラス

WordPress\/class-wp-tax-query.php at master · WordPress\/WordPress · GitHub
WordPress\/class-wp-taxonomy.php at master · WordPress\/WordPress · GitHub
WP_Term | Class | WordPress Developer Resources
- WordPress\/class-wp-term.php at master · WordPress\/WordPress · GitHub
  - Termのオブジェクト(ハコ)という感じ

get_term()

関数リファレンス\/get term - WordPress Codex 日本語版

PHP

GETパラメータ

PHP: filter_input - Manual

filter_input(INPUT_GET, 'taxonomy', FILTER_SANITIZE_SPECIAL_CHARS) で取得できる。

Docker 上の Almalinux のタイムゾーン設定について

2022-02-25T22:46:15+09:00

経緯

AlmaLinux ベースの自作LAMP環境構築用 Docker で WordPress を動かしたところ、投稿が「予約投稿の失敗」となってしまい正常に投稿できない現象に遭遇したため対処。

変更

これらの設定を次のようにしました。

Dockerfile (共通)

RUN rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux \
    && dnf -y update && dnf -y install \
    # 略
    # timezone
    glibc-locale-source \
    # locale, timezone
    && localedef -f UTF-8 -i ja_JP ja_JP.UTF-8 \
    && ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
# local & timezone
ENV LANG="ja_JP UTF-8" \
    LANGUAGE="ja_JP:ja" \
    LC_ALL="ja_JP.UTF-8" \
    TZ="Asia/Tokyo"

やり方を大幅に変更。強制コピーで localtime ファイルを上書きするのではなく、段取りを踏んで設定するようにしました。

検証

新しい方法で設定した Docker 環境上に先程と同様 WordPress をインストールして記事を投稿すると、無事投稿が公開されました。

このとき、 wp_posts のテーブルを直接見ると、 post_date, post_modified は同じ日時、 post_date_gmt, post_modified_gmt は -９時間の日時になっていました。

やはりここがおかしかったようです。

続・検証

さて、それではこの時刻の狂いはどこに起因しているのでしょうか。

Webサーバの Dockerコンテナのみ今回の新しい方法で localtime を設定した場合。OKですね。

DBサーバの Dockerコンテナのみ今回の新しい方法で localtime を設定した場合。NGです。

ということで、原因は Webサーバ側にありそうです。

Webサーバでの date

ただ、 Webサーバのコンテナで date コマンドを打っても日時は正しい日時が返ってくるのですよね。

設定方法が未変更の状態の Webサーバコンテナ

# php -r 'echo date_default_timezone_get() . PHP_EOL; echo date("y-m-d H:i:s") . PHP_EOL;'
Asia/Tokyo
22-02-13 19:06:21
# date
Thu Feb 13 19:06:28 JST 2022

設定方法を変更した状態の Webサーバコンテナ

# php -r 'echo date_default_timezone_get() . PHP_EOL; echo date("y-m-d H:i:s") . PHP_EOL;'
Asia/Tokyo       
22-02-13 19:16:50
# date
2022年  2月 13日 日曜日 19:16:56 JST

ご覧の通り時刻は正常……ってあれ、確かに日時は正常ですが、出力フォーマットが異なっています。

どうやら今までの設定変更ではやはり不完全な部分があるようです。どこが、というところまでは追い切れていないですが、ここまでの検証で確かに今までの設定方法では宜しくないであろう、ということが断片的に表われているので、ここは大人しく新しい設定方法に変更していった方が良さそうです。

使ってないWordPressからWebサイトをグチャグチャにされかけた件

2021-12-17T10:48:49+09:00

概要

昔試しにデプロイしてそのまま忘れていたWordPressに不正アクセスされ、自分の運営するWebサイトをグチャグチャにされかけた。

発端

ある日突然、自サイトのトップページが真っ白になり何も表示されなくなった。
自サイトはPukiwikiメインで動いており、この時は「またPHPか」と思っていた。

レンタルサーバーの現在のPHP環境を見たら、PHP5ではなくPHP7を推奨していた。ここで自分は、今のサーバーはPHP5の扱いが終了したのだと思った。
ダメ元でPukiwikiの最新版を取りに行ったら、PHP7対応版が公開されており、その一式をダウンロードして、とりあえずまるごと差し替える事で無事Pukiwikiが表示された。
細かい設定や独自に入れたPluginは全部上書き初期化されてしまったが、もうサイトの維持に疲れていたので、制作物とかはGithubに移動し、可能な限り縮小していくことを決めた。なのでテキストとかが取り出せればいいやと思っていた。
また、この機会にShift-JISとEUC-JPとUTF8が混在していたのを全部UTF8に統一し、SSL/TLS対応もした。

疑問

デフォルトのPukiwikiのページ下部には使用しているPHPのバージョンが出るのだが、「PHP 5.6.24」と表示されていた。「PHP7になったから動かなくなったのでは？」と疑問に思ったが、まあ今動いているからいいかと思った。
また、今回の更新作業のためにWebサイトのデータ一式をダウンロードしたが、いくつかのphpファイルがウイルス判定されていた。なんでphpファイルがウイルス判定？と思い、エディタで開こうとしてもWindowsが開く事を拒否する。誤検知だと思ってそのままにしていた。

確実におかしい事に気付く

20年間付き合ってきた自サイトなので、中身はかなりゴチャゴチャしていて、整理はかなり難しい状況だったが、それでも明らかに使ってないファイルは消していこうとしていた。
その中で、そんな名前のファイル自分は作らないぞ！？といったファイルや、100k超えのphpファイルが目についた。
レンタルサーバーの提供する機能でブラウザ上でサーバー内のファイルを直接扱えるサービスがあるので、それでphpファイルを開いたら、デコードされた読めない内容が展開されたので、やっと何かがおかしいと気づいた。

調査

様子がおかしいphpファイルはいくつかあったが、「wp-」で始まるファイルが多かったので調べたところ、WordPressのファイルだった。WordPressなんか入れた覚えないぞ・・と思ったが、サイト更新を楽にしようといろいろ試していた時は確かにあり、もしかしたらWordPressも入れてみた事があるのかもしれない・・・
そして、WordPressはかなり攻撃を受けやすく、常に最新版に更新する必要があるとの事。WordPressに不正にログインされると何が起こるのかも、調べた結果と自分の状況が一致していた。
自分が入れたWordPressはどこからもリンクされていないが、おそらくURL決め打ち＋脆弱性を突かれてアクセスされ、各所にファイルを作られたり、書き換えられたりしていた。

被害

index.phpを書き換えられていた
これでTOPページが真っ白になっていた。数十回に1回は詐欺サイトに飛ばされるタイプもあるとの事で、何回かリロードしてたら飛ばされたのかもしれない。
.htaccessを書き換えられていた
ガバガバにされてた。
知らないphpファイルを各所に作られていた
デコードされていてすぐに読めないものが大半。中身が空のものもあった。

サーバー運営からは何も怒られていないので、大量にメールを誰かに送るとかはしていないと思う。

対処

勘違い対処で最新のPukiwikiと差し替えた事で、Pukiwiki関係のphpは修正された状態。
WordPress関係のファイルを全部削除した。そもそもWordPressは入れただけで全く使ってなかったので、まるごと消すだけでよかったのは楽。
.htaccessを修正。古いWebサイト一式のバックアップがあったので、それを使用した。
phpファイルを検索し、怪しいファイルを全部削除した。
その他、使ってないCGIも全部削除。

最後に

今回の件や、php更新されてスクリプトが動かなくなる等の突然の悲しい作業が降って湧くのがきつく、最近は個人でのWebサイト運営に限界を感じる事が多くなってきています。
Webサイト運営は手段であってこれ自体が趣味とかではないので、自分で決めてない作業に時間をとられたくないです。まあこの機会に制作物をgithubにまとめられたのはよかったと思います。
いまはPukiwiki入れてますが、これすらもやめて、最終的に静的なHTMLを置くだけにしたくなっています。

(WordPress) 記事投稿時にスラッグを機械的に投稿IDと投稿日付で整形するプラグイン

2021-12-05T12:17:15+09:00

経緯

記事投稿時にスラッグを機械的に投稿IDと投稿日付で整形するプラグインが欲しくなったので作りました。

条件としては以下の通り。

基本的に1日1記事しか作成しない運用の WordPress サイト
通常の投稿のみ適用する
フォーマットは --yyyy-mm-dd とする
- month, date は0詰めあり
- 通常の投稿のみなのでは不要ではありますが、念のためつけておきます

コード



これで意図した挙動になることを確認。

参考


WordPressの投稿の日本語スラッグを自動的に英字スラッグに書き換える方法 - Offise Kondo
PHPでの日付取得方法！ 詳細まとめました


(余談) 「スラッグ」の語源は？


ソフトウェアの世界での slug / スラグ / スラッグの意味 - valid,invalid


原文: url - What is the etymology of 'slug'? - Stack Overflow
slug line: Screenplay - Wikipedia

パーマリンクとスラッグ | What's wp ?
スラグ - Wikipedia



home_url、get_template_directory_uri、get_stylesheet_directory_uriの違い【WordPress勉強備忘録】
2021-11-29T16:12:33+09:00
home_url

サイトのURL

例）https://example.com/

get_template_directory_uri

親テーマディレクトリまでのURL

例）https://example.com/wp-content/themes/xxx/

get_stylesheet_directory_uri

子テーマディレクトリまでのURL

例）https://example.com/wp-content/themes/xxx-child/


WordPress で処理の結果をログに出力したい
2021-11-18T00:03:13+09:00
WordPress のアクションフックで処理している内容を覗き見たいと考えました。

ただし、記事を公開した際の publish_post で処理される内容を見たい……というようなケースでは、画面出力するとブロックエディタの画面に出力されることになり、表示が大幅に崩れたりして悪影響が出ることが想定されます。

そこで、ログファイルにこっそり吐き出す方法を採ることにしました。

コード



サンプルですが、上述のようなイメージ。 var_dump() を文字列として出力するためのバッファリングを使用しつつ、その文字列に日付等を付与してログの出力のような体裁を整えることにしました。

そしてその内容をPHP標準の error_log()関数 でファイルに出力します。

なお、このコードを使用するに当たり WordPress の wp-config.php で次のようにデバッグモードとデバッグのログ出力を有効にしておきます。

//define('WP_DEBUG', false);
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);


これでファイルに変数の中身が出力されるので確認できます。

参考


WordPress のログ出力方法と仕組み | ultra code
WordPressの本番運用中にログ出力をする方法 | ソフプラント
PHP :: error_log() 関数を利用したロギング [Tipsというかメモ]



(WordPress) 自作プラグインの設定ページの $hook_suffix を調べる
2021-11-17T00:01:52+09:00
WordPress で自作プラグインの設定画面にアクションフックを引っかけたかったのですが、引っかからなかったので $hook_suffix について調べました。

経緯

自作プラグインの設定画面で処理を走らせるため、アクションフックを引っかけようとしました。

イメージとしては以下の流れを想定しています。


自作プラグインの設定画面(サブメニュー)でボタンをクリック
POSTパラメータを投げた先のページで処理を実行 (アクションフック)


ただしDBにオプションの値としてデータを保存したいわけではない
そのため、 options.php 経由はしないと想定

2.より、1.と同じ自作プラグインの設定画面(サブメニュー)に2.POSTパラメータがセットされたリクエストがあった場合は処理をする、としたい


そこで


admin_head-{$hook_suffix} | Hook | WordPress Developer Resources


このアクションフックを使おうとしました。


ワードプレスの管理画面に適応するスタイルシートを読み込む方法 | ワードプレスドクター


$hook_suffix は該当ページの名前、とのこと。

今回は wp-admin/admin.php?myplugin_settings_submenu_page というようなURLだったので安直に以下のように書いてみました。

function hoge()
{
    echo "HOGEEEEEEEE";
}
add_action( 'admin_head-admin.php?myplugin_settings_submenu_page', 'hoge' );


が、実行されず。そもそもGETパラメータ付きの名前は許容されているのか、というところも含めて調べることにしました。

調査

調査した結果、やはり $hook_suffix は異なる値でした。

今回のように自作プラグインで設定画面を設けている場合は、次のようなルールになります。

独自追加プラグイントップメニュー

toplevel_page_<メニュースラッグ>


独自追加プラグインサブメニュー

<トップレベルのメニュー名を sanitize_title() した値>_page_<メニュースラッグ名>


今回は後者のパターンですね。そして地味に厄介なのは「トップレベルのメニュー名を sanitize_title() した値」という部分。メニュー名はサイドバーのメニューの表示文字列なので、日本語でメニューを作ったプラグインの場合はサニタイズの結果パーセントエンコードされたものになります。

かといってここを小文字の半角英数字とハイフンのみにすると名前がよく分からないことになってしまうので微妙なところ。

例えば、メニュー名を「マイプラグイン 設定」として、サブメニューのスラッグを myplugin_settings_submenu_page としていた場合、 $hook_suffix は %E3%83%9E%E3%82%A4%E3%83%97%E3%83%A9%E3%82%B0%E3%82%A4%E3%83%B3-%E8%A8%AD%E5%AE%9A_myplugin_settings_submenu_page となります。

そして、冒頭のアクションフックは次のようになります。

function hoge()
{
    echo "HOGEEEEEEEE";
}
add_action( 'admin_head-%E3%83%9E%E3%82%A4%E3%83%97%E3%83%A9%E3%82%B0%E3%82%A4%E3%83%B3-%E8%A8%AD%E5%AE%9A_myplugin_settings_submenu_page', 'hoge' );


気持ち的には小文字の半角英数字とハイフンのみにしたいところですが、止む無し。

検証用コード

$hook_suffix を通知バーに表示させるコード。分かりやすいのでこの表示のさせ方は良いですね。

function current_pagehook()
{
    global $hook_suffix;
    if( !current_user_can( 'manage_options') ) return;
    echo 'hook_suffix : ' . $hook_suffix . '';
}
add_action( 'admin_notices', 'current_pagehook' );


※特定のWordPress管理画面でのみ独自のCSSやJavaScriptを読み込む方法 | WordPress テーマ DigiPressより

参考


admin_head-{$hook_suffix} | Hook | WordPress Developer Resources
ワードプレスの管理画面に適応するスタイルシートを読み込む方法 | ワードプレスドクター
$hook_suffix | WordPressのプラグインを作ろう
WordPressの管理画面に独自のスクリプトやスタイルを読み込ませる方法まとめ | 明日のための記録
特定のWordPress管理画面でのみ独自のCSSやJavaScriptを読み込む方法 | WordPress テーマ DigiPress
add_submenu_page - WordPress私的マニュアル
add_menu_page - WordPress私的マニュアル



WordPress で画像の直リンクを禁止する
2021-11-15T00:07:31+09:00
表題の通り、 WordPress で画像の直リンクを禁止する方法についてメモ。

ページ内とかであれば WordPress の処理である程度どうにかできますが、直接参照されると WordPress としての処理は走らないので効かないのですよね……。

対処


RewriteEngine on
RewriteCond %{HTTP_REFERER} !^http(s)?://example\.com [NC]
RewriteRule \.(jpg|png|gif|wepb)$ - [F]



対処としては .htaccess を記述することで抑制できます。

RewriteEngine on でリダイレクトを有効にして、 RewriteCond %{HTTP_REFERER} !^http(s)?://example\.com [NC] (実際は example.com ではなく実際のサイトのドメイン) で自サイトは許可、それ以外は禁止とします。

最後に RewriteRule \.(jpg|png|gif|wepb)$ - [F] で画像に該当するファイルの拡張子の場合は参照できなくしてしまう、と。

これである程度は抑制できるのではないでしょうか。

参考


WordPress でアップロードした画像への直リンクを禁止する方法
Wordpressの画像等の直リンクを禁止する ? GettingOUT
画像などの直リンクを禁止してブログのパクリを防ぐ方法 | Fukuro Press
画像への直リンク防止策 - kotonoha



WordPress の REST API に wp-json/ でアクセスしたら 404 not Found. エラー
2021-11-06T00:02:35+09:00
非常に簡単な内容ですが、表題の通り WordPress の REST API に wp-json/wp/v2/ でアクセスしたら 404 Not found. になり戸惑ったのでメモ。

現象

https://example.com/wp-json/wp/v2/ で REST API にアクセスしたら、 404 Not found. エラーになってしまいました。

プラグインやテーマの functions.php で REST API をオフにするようなものがないか探しましたが該当するものなし。

しかも、ソースコードを表示すると https://example.com/index.php?rest_route=/ という記述があり、その通り https://example.com/index.php?rest_route=/wp/v2/ にアクセスすると REST API の結果が表示されました。

index.php?rest_route=/ とは……。

原因

パーマリンク設定が「基本」の場合、 wp-json/wp/v2/ は 404 Not Found. になるとのこと。

そして、 index.php?rest_route=/ もれっきとした REST API にアクセスするURIでした。パーマリンク設定が「基本」の場合はこちらでしかアクセスできないようです。

普段「基本」以外にしてしまうので、なかなかお目にかかる機会がありませんでした。

参考


Wordpress | WP REST API | /wp-json が見えない（無効化されている） - Qiita
wordpressでWP REST API使用時に404 Not Foundが出たときの対応 | takeshit.info



WordPress のシングルページで特定のタクソノミーの場合のみ表示を変えたい
2021-11-04T23:46:16+09:00
表題の通り、WordPress のシングルページで特定のタクソノミーの場合のみ表示を変えたいケースのスニペットをメモ。

さっくり終わらせたかったのでとりあえずできたものを貼っておきます。

スニペット

ID,
                    'AN_TERMS_KEY'
                ),
                'slug'
            )
        )
    ) {
?>
    



今回はこれでfix。

サンプルケース

例えば「cms」というカスタムタクソノミーに「wordpress」,「basercms」,「concretecms」といったタクソノミー、およびそのスラッグが存在した場合に「wordpress」のみ if内 の内容を表示させたい場合は次のようなイメージ。

ID,
                    'cms'
                ),
                'slug'
            )
        )
    ) {
?>
    



参考

カスタムタクソノミーの表示


カスタム投稿タイプのターム名を［single-XX.php］に表示する方法【WordPress】 | 妙高Web屋
関数リファレンス/get the terms - WordPress Codex 日本語版


PHP, 連想配列の中の特定のキーの値で判定


PHP | in_array()で配列・多次元配列のデータから値が存在するか判別する方法 | ONE NOTES



WP CLI で Error: YIKES! It looks like you're running this as root. エラー
2021-10-23T14:21:14+09:00
WP CLI で Error: YIKES! It looks like you're running this as root. ... というエラーが発生したのでメモ。

# wp help
Error: YIKES! It looks like you're running this as root. You probably meant to run this as the user that your WordPress installation exists under.

If you REALLY mean to run this as root, we won't stop you, but just bear in mind that any code on this site will then have full control of your server, making it quite DANGEROUS.

If you'd like to continue as root, please run this again, adding this flag:  --allow-root

If you'd like to run it as the user that this site is under, you can run the following to become the respective user:

    sudo -u USER -i -- wp 


原因としては root で実行しようとしているけど大丈夫？他のユーザで sudo で実行してね？ということのようです。

今回は Docker 環境の中で特に気にするものもないので安直に --allow-root で落ち着きました。

参考


[WordPress] WP-CLI でエラーが出た時の対処方法
WP-CLI自身をアップデートするコマンド wp cli update | サイト構築日記(WordPress編）



静的ページで WordPress の埋め込みに対応できるかテスト
2021-08-28T00:05:38+09:00
ふと気になったので静的ページで WordPress の埋め込みに対応できるかテストしてみることにしました。

調査

調べてみたところ、 WordPress の埋め込みは oEmbed の仕様をベースに独自カスタマイズが入った仕組みとなっている模様。

必要なのは以下の3つ


oEmbed の仕様に則ったデータ ( XML または JSON 、あるいは両方)
ページ自体に上述のデータへの link タグ
埋め込み時に表示する HTML


サンプルコード

今回はひとまず以下のような構成に。

dist/
   ├ css/             // 略
   ├ embed/           // 埋め込み用のリソース
   │    ├ index.html  // 埋め込み時に表示するHTML
   │    └ index.json  // 埋め込みに必要なデータ
   │
   ├ js/              // 略
   └ index.html       // 本来の閲覧者が実際に見るページ


embed/index.json

まずはデータ。今回は JSON 形式を用意しました。

{
    "version": "1.0",
    "provider_name": "Embed Test Page",
    "provider_url": "https://embedtest.example.jp/",
    "author_name": "アルム＝バンド",
    "title": "TopPage",
    "type": "rich",
    "width": 600,
    "height": 338,
    "html": "TopPage
\n"
}


各種パラメータはもとより、 html の部分がボリューミーです。ベースは WordPress が出力している JSON の中身をベースにして、サイト名やページ名、URL等のパラメータ部分だけ必要に応じて書き換えたものとなります。

WordPress の場合、 
～
～～～ という形式になっていなければならないようです。また、 blockquote, a, iframe 以外は使用できない等の制約もあるようです。

index.html

実際にビジターが閲覧するページでは上述のデータへのリンクを貼ります。




今回は JSON だけなので1行ですが、 XML の場合は XML 用の、両方用意した場合は2行になります。

embed/index.html




    
    
    
    
    
    


    
        
            TopPage
        
        
            静的サイトで WordPress の埋め込みに対応できるかどうかのテストです。仕様はある程度 oEmbed に則っている模様です。
        
        
            
                
                    Embed Test Page
                
            
        
    
    




埋め込み時に表示される HTML 。こちらも基本的に WordPress のコードを持ってきて、共有オプションのところで dashicon を使っていたり WordPress 特有のリソースを使用している部分は削除してシンプルにしました。

検証

これらをサーバにアップロードして、 WordPress で動作確認してみます。



記事作成画面で埋め込みブロックを選択します。



URLを貼り付けると、埋め込みに成功しました。大丈夫そう……と思ったのですが。



別の WordPress 環境だと失敗してしまいました。こちらは使用しているテーマや PHP のバージョン等条件が諸々異なるので何とも言えませんが、環境によってできたりできなかったりすることがあるようです。

……うーん、微妙。



検証した結果としては「最低限動くかどうか」というラインになってしまいました。

また、埋め込みに対応するためにはパラメータを記述したデータ (XML or/and JSON) や専用の HTML が必要ということが検証して分かりました。

これを静的サイトの各ページごとに生成するのは大変なので、仮に対応するならば何かしらの仕組みが必要となりそうです。

参考


オブジェクトの埋め込み | WordPress.org 日本語
WordPressの「埋め込み」に非WordPressサイトで対応するための方法

-静的なHTMLページをoEmbedで他サイトに埋め込み可能にする - にせねこメモ
oEmbed



WordPress 管理画面の一覧ページ当たりに表示される件数を増やす
2021-05-06T23:40:30+09:00
WordPress の管理画面の中で、記事一覧ページとメディア一覧ページで1ページ当たりの表示される件数を増やす方法についてメモ。

コード

早速ですがコードは以下。テーマの functions.php に記述するかプラグインとしてインストールするかどちらでも。



フィルターフックを2つほど追加することで実現できました。なお、上述の例では共に1ページ当たり100件とました。

備考

上述のフィルターフックについていくつか気付いた点を書き留めておきます。


要微調整


スペックやによって、データの量などに応じては表示件数が50件でも一覧表示でエラーを起こすことがある
300件では一括削除の際のGETリクエストのURIが長すぎて怒られることがある

edit_{$post_type}_per_page


ドキュメント(edit_{$post_type}_per_page | Hook | WordPress Developer Resources)では edit_post_per_page の仲間として edit_attachment_per_page, edit_post_per_page, edit_page_per_page が例として挙げられています
しかし、 edit_posts_per_page だけで投稿一覧ページだけでなく、固定ページ一覧ページやカスタム投稿一覧ページまで効力を発揮しました
「固定ページだけ」のときは edit_pages_per_page 、といったように「のみ」という場合は使い分け、全体で構わない場合は edit_posts_per_page だけで良い、という感じの使い分けになりそうです

s


上述で edit_attachment_per_page, edit_post_per_page, edit_page_per_page を挙げましたし、ドキュメントやコアファイル(WordPress/post.php at af4b043a693fc7178ef8a1fcd0402f14fba0a040 · WordPress/WordPress · GitHub)でもそう書かれています
しかし、実際は edit_attachments_per_page, edit_posts_per_page でした。おそらく edit_page_per_page も edit_pages_per_page ではないかと思われます( edit_pages_per_page については未検証)

メディア一覧ページ


上述で edit_attachments_per_page があったためこれが該当するのかと思いきや、効果なし
メディア一覧ページのフィルターフックは upload_per_page でした



特に s は気を付けないと見逃すので注意 (いずれも WordPress 5.7.1 で検証)。


#14135 (edit_posts_per_page) – WordPress Trac


2010年の edit_posts_per_page と edit_post_per_page についての Trac がありましたが、議論されているコードは wp-admin/includes/template.php 内のもので今回の wp-admin/includes/post.php,  wp_edit_posts_query とは別の場所のコードなので直接の関係はなさそうです。

参考


【WordPress】管理画面の「投稿一覧」と「固定ページ一覧」の最大表示数を変更する方法。 - 株式会社オンズ
edit_posts_per_page | Hook | WordPress Developer Resources
edit_{$post_type}_per_page | Hook | WordPress Developer Resources
upload_per_page | Hook | WordPress Developer Resources
WordPress/post.php at af4b043a693fc7178ef8a1fcd0402f14fba0a040 · WordPress/WordPress · GitHub



WordPress で一部の .xlsファイル だけがアップロードできない (解決)
2021-04-18T17:11:54+09:00
前回の続きです。プラグインを作成しましたが、挙動が変わらなかったためさらに調査を続行しました。

結果

結果から記すと、プラグインを以下のように改修することで解決できました。

 'application/vnd.ms-office'
            ],
            [
                'xla|xls|xlt|xlw' => 'application/vnd.ms-excel'
            ],
        ];
    }
    /**
     * Bibishii                  : フィルター追加
     *
     * @param {Object} $check    : MIMEタイプ の一覧のオブジェクト
     * @param {File} $file       : チェック対象ファイル
     * @param {Object} $filename : チェック対象ファイルの名前
     *
     * @return {Object}          : 誤判定している MIME タイプを追記する
     *
     */
    public function Bibishii ( $check, $file, $filename )
    {
        if ( empty( $check['ext'] ) && empty( $check['type'] ) ) {
            foreach ( self::Vivid() as $mime ) {
                remove_filter(
                    'wp_check_filetype_and_ext',
                    [
                        $this,
                        'Bibishii'
                    ],
                    99
                );
                $mime_filter = function($mimes) use ($mime) {
                    return array_merge($mimes, $mime);
                };

                add_filter(
                    'upload_mimes',
                    $mime_filter,
                    99
                );
                $check = wp_check_filetype_and_ext( $file, $filename, $mime );
                remove_filter(
                    'upload_mimes',
                    $mime_filter,
                    99
                );
                add_filter(
                    'wp_check_filetype_and_ext',
                    [
                        $this,
                        'Bibishii'
                    ],
                    99,
                    3
                );
                if ( ! empty( $check['ext'] ) || ! empty( $check['type'] ) ) {
                    return $check;
                }
            }
        }

        return $check;
    }
}

// instantiate
$ab_wp_plugin_mimeuruwashii = new MIMEuruwashii();



元の原型ないですね。引っかけるアクションフックも upload_mimes から wp_check_filetype_and_ext に変わっています。

調査

調査の過程を以下に記します。

挙動が変わらなかった理由を wp-includes/functions.php を追いかけて調べて行きます。


メソッドwp_get_mime_types() では拡張子と MIMEタイプ をそれぞれキー・値として持つ連想配列を返却しています
wp_get_mime_types() が呼ばれている場所を辿っていきます


get_allowed_mime_types() はいくつかの処理( .swf や .exe の除外、ユーザ権限がない場合は .html, .htm, .js を除外)をした後に upload_mimes でチェックする拡張子と MIMEタイプ を登録
do_enclose() は動画関連のチェックのように見えます。しかし、ここで気になるコードを発見


拡張子の方は if ( preg_match( '!^(' . $exts . ')$!i', $extension ) ) で正規表現による判定を行っている (例えば !^(xla|xls|xlt|xlw)$!i のような形式)
一方、 MIMEタイプ は $type = $mime; で代入しているだけ


しかも break; している





上述のコードを見て、「ひょっとして複数の MIMEタイプ を想定していないのでは？」と思い至り、検索。


WordPressでファイルアップロードができない(m4b、m4a、vtt、key） - Qiita


uploads - How to assign multiple file-mime-types to extension? - WordPress Development Stack Exchange



やはり1つの拡張子に対して複数の MIMEタイプ を持つ場合に対応していない (今回のケースで言うと「 .xlsファイル は application/vnd.ms-excel または application/vnd.ms-office を受け付ける」としたい) ようです。

前回のように MIMEタイプ を付け足す方法は、 .ai や .psd のような、デフォルトの連想配列に拡張子がキーとして存在しない MIMEタイプ ならば良いと思います。しかし、今回の .xls のように既存の拡張子の場合は最後に付け足したキーまで評価されていなさそうです。

そこで、上述記事のように前回の upload_mimes 時に判定する MIMEタイプ を付け足すのではなく、そもそものチェック処理の wp_check_filetype_and_ext を変更する、という方針に転換しました。

その結果が冒頭のプラグインのコードとなります。

雑感

複数の MIMEタイプ が想定されていない作りということを初めて知って驚きました。

上述の Stackoverflow でも取り上げられていますが、 .svg や .zip 等他にも類似のケースが考えられるので意外でした。

参考


WordPressでファイルアップロードができない(m4b、m4a、vtt、key） - Qiita
uploads - How to assign multiple file-mime-types to extension? - WordPress Development Stack Exchange



WordPress で一部の .xlsファイル だけがアップロードできない (失敗)
2021-04-17T13:25:24+09:00
WordPressサイト で一部の .xlsファイル だけがアップロードできない現象に遭遇したため、対処しました。

現象

とある WordPressサイト で .xlsファイル をアップロードしようとすると以下のエラーが表示されました。


  “XXXXXXXXXXX.xls” のアップロードに失敗しました。
  
  このファイルタイプはセキュリティ上の理由から、許可されていません。




しかも困ったことに、「Aの .xlsファイル はOKだが、Bの .xlsファイル はNG」というように、ファイルによって現象が分かれました。

両方とも正常に開ける .xlsファイル ですし、見た目上は同じなのですが……。

対処1

最初の対処として、 wp-config.php にファイルアップロードの際のフィルタリングをオフにする方法を試しました。



これでファイルアップロードを試したところ、2つの .xlsファイル 共にアップロードできるようになりました。

ただし、この方法ですとファイルアップロードの際のフィルタ処理を全てオフにしてしまうため、セキュリティ的に好ましくありません。

そこで、もう少し調査を続けることにしました。

検証

上述の対処1より、ファイルアップロードの際のフィルタリング処理で引っかかっていることは分かりました。


【WordPress】アップロード可能なファイル拡張子を増やす | deep-space.blue


このフィルタリングは、拡張子と MIMEタイプ の判定をしているということが分かりました。

ファイルとしては、 wp-includes/functions.php です。


WordPress/functions.php at master · WordPress/WordPress · GitHub


中身を見て、関数 wp_get_mime_types() で拡張子と MIMEタイプ の一覧を持っていることが分かります。

この処理にアクションフックを引っかけることができれば良さそうです。

MIMEタイプ の確認

次に、問題のファイルの MIMEタイプ を確認します。

試しに、以下のような構成を作ります。

   /
  ├ files/
  │    ├ sample1.xls  // ファイルアップロード OK の .xlsファイル
  │    └ sample2.xls  // ファイルアップロード NG の .xlsファイル
  │
  └ index.php


また、 index.php を


ファイルの種類（MIMEタイプ）を確認する | GRAYCODE PHPプログラミング


この記事を参考にして、以下のようにします。

 $value) {
    echo $value . ": ";
    echo $finfo->file( $value, FILEINFO_MIME_TYPE );
    echo "

\n\n";
}



これを問題が発生している WordPressサイト と同じサーバにアップロードします。



すると、ファイルアップロード OK の .xlsファイルは MIMEタイプが application/vnd.ms-excel だったのに対し、 NG だった .xlsファイル は application/vnd.ms-office でした。



ちなみに、他の環境に同じファイル群をアップロードしたところ両方とも application/vnd.ms-excel で、この環境では今回の現象は発生しませんでした。


よくある MIME タイプ - HTTP | MDN


MIMEタイプ は .xls の場合 application/vnd.ms-excel のはずですが……。


  先に結論から言ってしまえば、利用しているサーバーのPHPのバージョンが低く、PHPの中で呼び出される「Fileinfo」というファイル操作のモジュールのバージョンが低かった為、アップロードしたエクセルファイルの正しいMIMEタイプが認識がされていないという状態になっていました。
  
  WordPressのメディアにアップロードが出来ない時 | スタッフブログ | 株式会社クーネルワーク


PHP のバージョンによって Fileinfoモジュール の判定結果が異なるとのこと。 WordPress の MIMEタイプ 判定もこのモジュールを得利用しているとのことで、ここで影響を受けてしまうようです。

以上より、今回の環境では本来 application/vnd.ms-excel となるべき MIMEタイプ が、何故か application/vnd.ms-office と判定され、結果、 WordPress のファイルアップロードの際のフィルタリング処理の中の MIMEタイプ 判定で引っかかっていた、というのが今回の現象の原因でした。

対処2

以上の検証を踏まえて対処をします。具体的には、アクションフックでファイルアップロードの際のフィルタリング処理の際に application/vnd.ms-office も許可するようなプラグインを作成します。



このプラグインを .zip でアップロード、インストールして有効化します。

もちろん、 wp-config.php の ALLOW_UNFILTERED_UPLOADS の行は削除して試験しました。

……が、挙動は変わらず、解決できませんでした。

参考

ALLOW_UNFILTERED_UPLOADS


WordPressの「セキュリティ上の理由によりこのファイル形式は許可されません」エラーの処理方法
WordPressのメディアにアップロードが出来ない時 | スタッフブログ | 株式会社クーネルワーク


WordPress 内のファイルアップロードのフィルタ処理について


【WordPress】アップロード可能なファイル拡張子を増やす | deep-space.blue
WordPress/functions.php at master · WordPress/WordPress · GitHub


Fileinfoモジュール による MIMEタイプ 判定


ファイルの種類（MIMEタイプ）を確認する | GRAYCODE PHPプログラミング


MIMEタイプ の一覧


よくある MIME タイプ - HTTP | MDN



WordPress の REST API で投稿の記事一覧か個別記事かを判定する
2021-04-17T13:14:11+09:00
経緯

WordPress の REST API で出力されるデータをカスタマイズする際に、記事の一覧なのか個別の記事なのかを判定したくなったので。

例えば、「記事一覧のデータでは本文はいらず、個別記事のデータの場合のみ本文をデータに出力する」みたいなことをしたくなったときに、 is_single() のようなテンプレートタグがないかな、と。

……検索してみましたが見当たらなかったので、自前で判定することにしました。

実装

get_route() ) ) {
            // route が .../posts/{記事ID} の形式ならば単独記事のデータ取得と見なす
            $is_single = true;
        }
        if (!$is_single) {
            // 記事一覧のデータ取得ならばコンテンツ本文を削除
            unset( $response->data['content'] );
        }

        return $response;
    }
}

// instantiate
if( !is_admin() ) {
    // 管理者画面以外
    $filterrest = new FilterREST();
}



以前のコードに判定と処理を足してみました。

is_single() っぽいものが見付からなかったので、力業で GETリクエストの URL(ルーティング) が /wp/v2/posts/{記事ID} の形式ならば個別記事、そうではない /wp/v2/posts(最後にスラッシュ+記事IDの数字が付かない) の形式ならば記事一覧、というイメージです。ルーティングの情報は $requestオブジェクト から get_route()メソッド で引っ張ってきています。

一応これでできましたが……もう少しスマートにできる方法はないのでしょうか？

参考


WP_REST_Request | Class | WordPress Developer Resources
WP_REST_Request::get_route() | Method | WordPress Developer Resources



WordPress の REST API の出力内容をフィルタリング (プラグイン編)
2021-04-14T00:00:27+09:00
経緯

WordPress の REST API で出力されるデータを GETリクエストのパラメータでフィルタリングすると、クライアント側で指定する URL がごちゃごちゃするので WordPress 側で制御できないかと考えました。

「REST API にアクセスされた際に、レスポンスデータを出力する直前」のタイミングという、そこそこカスタマイズのニーズがありそうなポイントではアクションフックが用意されていそうなので、「アクションフックで余計な出力が出ないように制限する」ということはできそうな気がします。

調査


WordPressのREST APIから「guid」など不要な項目を削除する | オレDEV.com
WordPressのREST APIから「_links」を削除する | オレDEV.com


調べてみたらあったのでこの方法で考えます。ついでにアクションフックは rest_prepare_post が良さそうです。

実装

data['type'] );
        unset( $response->data['link'] );
        unset( $response->data['excerpt'] );
        unset( $response->data['author'] );
        unset( $response->data['featured_media']); // アイキャッチだが即座に画僧のパスを取得できるものではないので削除
        unset( $response->data['date_gmt'] );
        unset( $response->data['modified_gmt'] );
        unset( $response->data['guid'] );
        unset( $response->data['excerpt'] );
        unset( $response->data['comment_status'] );
        unset( $response->data['ping_status'] );
        unset( $response->data['sticky'] );
        unset( $response->data['template'] );
        unset( $response->data['format'] );
        // _links の全要素を取得
        $links = $response->get_links();
        // 要素を foreach で全て削除
        foreach ( $links as $key => $value ) {
            $response->remove_link( $key );
        }
        return $response;
    }
}

// instantiate
if( !is_admin() ) {
    // 管理者画面以外
    $filterrest = new FilterREST();
}



ブロックエディタは REST API を使用していますし、他のプラグインでも使用しているケースがあるので、ログインしていない場合のみ絞る方向で調整してみようかと。

それから、一応クラスにしてなるべくグローバルスコープを汚染しないようにしておきます。ついでにプラグインとして実装してみました。

応用

ついでに「本文内にある href 属性内の URL がサイト内部へのリンクだった場合は置換をする」ということもやってみます。

// 略

class FilterREST
{
    /**
     * __construct : プラグイン有効時にメソッドを呼ぶ
     *
     */
    public function __construct() {
        // 有効化の際に発動
        add_action(
            'rest_prepare_post',
            [
                $this,
                'remove_data',
            ],
            10,
            3
        );
        add_action(
            'rest_prepare_post',
            [
                $this,
                'url_replace',
            ],
            11,
            3
        ); // 追加
    }

    // 略

    /**
     * url_replace                : content のリンクを書き換える
     * 
     * @param {Object} $response  : レスポンスとして返却するデータ
     * @param {Object} $post      :
     * @param {Array} $request    : リクレストデータ
     *
     * @return {Object} $response : レスポンスとして返却するデータ
     * 
     */
    public function url_replace ( $response, $post, $request )
    {
        $search_pattern = '/href=\\"([^"]*?)\\"/i';
        $response->data['content']['rendered'] = preg_replace_callback(
            $search_pattern,
            [
                $this,
                'replace_process',
            ],
            $response->data['content']['rendered']
        );
        return $response;
    }
    /**
     * replace_process          : 外部サイトへのリンクはそのままで、それ以外は置換
     * 
     * @param {string} $matches : url_replace で $search_pattern にマッチした文字列
     * 
     * @return {string}         : 置換された文字列
     * 
     */
    public function replace_process ( $matches )
    {
        $siteurl    = site_url();
        $static_url = 'https://example.com/releasenote/'; // 何かしらの静的サイトの更新履歴の個別記事ページを想定
        if( strpos( $matches[1], $siteurl ) === false ) {
            // サイト外へのリンクならばリンク文字列をそのまま返す
            return $matches[0];
        }
        else {
            // サイト内リンクならば置換する
            if( strpos( $matches[1], '?p=' ) !== false ) {
                // 「基本」
                $id = explode( '?p=', $matches[1] )[1];
                return 'href="' . $static_url . $id . '"';
            }
            else if( strpos( $matches[1], 'archives/' ) !== false ) {
                // 「数字ベース」
                $id = explode( 'archives/', $matches[1] )[1];
                return 'href="' . $static_url . $id . '"';
            }
            else {
                // ルールに該当しない場合はブランク
                return 'href="#"';
            }
        }
    }
}

// 略



こんなことをすると、同じ WordPress の投稿記事のどれかの記事へのリンクは https://example.com/releasenote/{記事ID} という形で置換されます。投稿を静的サイト側の JS でごにょごにょしたい……という場合には使えるかもしれません。

参考

WordPress の REST API


WP REST API　を使って独自エンドポイントを設定する。 - Qiita
WordPressのREST API周りのfilter hook / action hook のまとめと、一部のREST APIを開放する方法 - Qiita
WordPress REST APIについてまとめてみた | WebCraftLog
WordPress 4.7以降でREST APIのレスポンスを加工する（ACFの値も追加可能） - Qiita


ブロックエディタは REST API を使用していますし、他のプラグインでも使用しているケースがあるので、ログインしていない場合のみ絞る方向で調整してみようかと。

なお、アクションフックとしては rest_api_init, rest_endpoints, rest_prepare_post 等がある模様。

不要な出力を削除


WordPressのREST APIから「guid」など不要な項目を削除する | オレDEV.com
WordPressのREST APIから「_links」を削除する | オレDEV.com
WordPress 4.7以降でREST APIのレスポンスを加工する（ACFの値も追加可能） - Qiita


今回は使わなかったが今後使いそうなもの

カテゴリの詳細情報も取得


WordPressのREST APIから記事取得時に、まとめてカテゴリ詳細も取得する | オレDEV.com


アイキャッチ画像の情報を取得


WordPressのREST APIでアイキャッチ画像を取得する2つの方法 | オレDEV.com


PHP

正規表現


PHPで正規表現を使ってHTMLを強引にほじるコツ - Qiita
正規表現でhtml内のリンク名称とリンク先を取得 - Qiita
[PHP] preg_replace　後方参照でちょっと悩んだ - 脱力系備忘録BloG
PHP: preg_replace_callback - Manual
カンマ区切りの文字列を正規表現で表す | クソざこCoding


正規表現や後方参照について。念のため。

一部に文字列を含むか


【PHP】特定の文字列を含むかのチェック - Qiita


WordPress テンプレートタグ


テンプレートタグ/site url - WordPress Codex 日本語版


たまにだと site_url() か home_url() か迷うので。


WordPress の REST API で出力内容をフィルタリング (リクエスト編)
2021-04-13T23:43:18+09:00
WordPress の REST API で出力されるデータをフィルタリングできることを知ったのでメモ。

例えば、 https://example.jp/ という WordPressサイト があったとします。

以下の URL の REST API に GETリクエスト を飛ばすと、投稿の一覧が取得できます。

https://example.jp/wp-json/wp/v2/posts

個別記事はIDで指定します。

https://example.jp/wp-json/wp/v2/posts/42

ここまでは知っていましたが、色々な情報が出力されるため、場合によっては不要なデータの方が多い、というケースも考えられます。

例えば、 AJAX で投稿のID、タイトル、投稿日時、URLだけ欲しい場合は以下のように _fields パラメータで指定すると、そのデータのみ抽出できるとのこと。

https://example.jp/wp-json/wp/v2/posts?_fields=id,title,date,link

同様に、個別記事でもフィルタリングが可能。IDが 42 の記事のタイトル、更新日時、本文が欲しい場合は以下。

https://example.jp/wp-json/wp/v2/posts/42?_fields=title,modified,content

こうすると余分なデータを省けるのでコードも書きやすいですし、レスポンスが軽くなることが期待できそうです。

ちなみに、個別にキーを指定するのではなく、「埋め込み前提である程度絞る」のであれば context=embed も利用できるかと。これは一覧表示の時に役に立ちそうです。

https://example.jp/wp-json/wp/v2/posts?context=embed

参考


WordPressのREST APIの使い方 - Qiita
WP REST APIでの記事の取得と表示[PHP版 / JS版] | ocws BLOG
WordPressのREST APIで記事一覧取得に「embed」を指定すると9割以上サイズを減らせた | オレDEV.com


余談

現在 REST API 周りのドキュメントを読もうと思うと、公式の英語のドキュメントになりますかね？


REST API Handbook | WordPress Developer Resources


4.7までのプラグイン時代の癖で「WP REST API」で検索すると以下がヒットしますが、内容が変わっている部分もあると推測されるのでやはり上述のドキュメントですかね……。


WP REST API v2 Documentation



WordPress の検索結果を関連度から日時降順にする
2021-03-20T15:23:30+09:00
WordPress のデフォルトの検索結果は 3.7 以降関連度順になっているのですが、これだと少々不便……ということがあったので、サクッと変更しました。

サンプルコード (プラグインのケース)




関数を posts_search_orderby のアクションフックに引っかける
関数の戻り値にSQL文 の ORDER BY の後ろに付く文字列を指定する


という感じで良いようです。

参考


[WordPress] 検索結果の並び順 - Qiita
posts_search_orderby | Hook | WordPress Developer Resources
Version 3.7 - WordPress Codex 日本語版



WordPress の非公開記事を購読者でも閲覧できるようにする
2021-03-17T20:58:16+09:00
WordPress の非公開記事を「購読者 (subscriber)」でも閲覧できるようにしたくなったので、やり方をメモしておきます。

ちなみに、 WordPress はデフォルトの状態では「管理者 (administrator)」と「編集者 (editor)」のみ非公開記事の閲覧ができます。

ただし、ケースによっては「記事の編集権限は与えたくないので、購読者で記事の閲覧権限だけ付与したい」という場合もあるかと思います。

そこで対処。

シンプルなコード

単純に付与することだけを考えるならば、フォーラムにある「非公開」の権限について | WordPress.org 日本語のスレッドのコードで良いかもしれません。

$subscriber = get_role( 'subscriber' );
$subscriber->add_cap( 'read_private_posts' );


これをテーマの functions.php に追加すれば、要件は満たせるようです。ただし、add_cap() の Codexには


  注意: この設定はデータベース(テーブル wp_options のフィールド wp_user_roles)へ保存されます。そのため、テーマやプラグインを有効化した時に実行したほうがいいかもしれません。
  
  関数リファレンス/add cap - WordPress Codex 日本語版


という注意書きがありました。設定がDBに保存されるのであれば、元に戻せるようにしておきたいです。また、DBに設定が保存されるのであれば、何度もこのコードが実行されるのではなく、初回の一度だけ実行される方が良さそうな気がします。

そこで、「コードをプラグイン化し、プラグインの有効化の際に上記コードが実行、プラグイン無効化の際は逆に設定を戻すコードが実行」されるような設計にしたいと思います。

コード (プラグイン)

上述の設計を落とし込むと以下のようになりました。なお、一応生関数をブローバルスコープに置くのではなく、クラスとして使用してみました。

role );
        $subscriber->add_cap( $this->privilege );
    }
    /**
     * removeReadPrivilege : 購読者から非公開記事を閲覧する権限を剥奪
     *
     */
    public function removeReadPrivilege ()
    {
        $subscriber = get_role( $this->role );
        $subscriber->remove_cap( $this->privilege );
    }
}

// instantiate
$ReadableSubscriber = new ReadableSubscriber();



プラグイン名や関数名は適当に。

これで簡単にチェックしたところ、望んだ通りの挙動になりました。

参考


「非公開」の権限について | WordPress.org 日本語


ユーザーの種類と権限 - WordPress Codex 日本語版

関数リファレンス/add cap - WordPress Codex 日本語版
プラグイン API - WordPress Codex 日本語版


関数リファレンス/register activation hook - WordPress Codex 日本語版
関数リファレンス/register deactivation hook - WordPress Codex 日本語版

「WordPress」の記事 - Crieit

(WordPress) 非公開記事も含めた記事数カウントを管理画面に表示するプラグイン

Docker 上の Almalinux のタイムゾーン設定について

使ってないWordPressからWebサイトをグチャグチャにされかけた件

(WordPress) 記事投稿時にスラッグを機械的に投稿IDと投稿日付で整形するプラグイン

home_url、get_template_directory_uri、get_stylesheet_directory_uriの違い【WordPress勉強備忘録】

WordPress で処理の結果をログに出力したい

(WordPress) 自作プラグインの設定ページの $hook_suffix を調べる

WordPress で画像の直リンクを禁止する

WordPress の REST API に wp-json/ でアクセスしたら 404 not Found. エラー

WordPress のシングルページで特定のタクソノミーの場合のみ表示を変えたい

WP CLI で Error: YIKES! It looks like you're running this as root. エラー

静的ページで WordPress の埋め込みに対応できるかテスト

WordPress 管理画面の一覧ページ当たりに表示される件数を増やす

WordPress で一部の .xlsファイル だけがアップロードできない (解決)

WordPress で一部の .xlsファイル だけがアップロードできない (失敗)

WordPress の REST API で投稿の記事一覧か個別記事かを判定する

WordPress の REST API の出力内容をフィルタリング (プラグイン編)

WordPress の REST API で出力内容をフィルタリング (リクエスト編)

WordPress の検索結果を関連度から日時降順にする

WordPress の非公開記事を購読者でも閲覧できるようにする

WordPress で一部の .xlsファイルだけがアップロードできない (解決)

WordPress で一部の .xlsファイルだけがアップロードできない (失敗)