気になること

その前回に書いた通りありがたくスクリプトを使わせていただいてます。環境はmacOS Sequoia 15.3.1です。
ただ、ちょっと気になる点が出てきてしまいました。

【問題】バックアップが新しい名前になり、元ファイルは同名のまま改変保存されること

これはTerminalとかコマンドラインの世界の流儀としては問題ないのかもしれないです。しかし、俺としては外枠を描いた画像は新しい名前で保存されて欲しいし、バックアップは元の名前のままがいいのですよ。現在あるファイルはそのままに、編集後は「名前をつけて保存」しておきたいということなのです。古くから染み付いた習性、Cmd + Shift + Sですわ。最近では「名前をつけて保存」じゃなくて「複製」になってきててそれはそれで微妙な違和感はあるんだけれど考え方としては同じです。

【問題】バックアップのファイルの拡張子が機能しなくなること

追加された「.bak」によって拡張子が変更されることとなりアイコンが変わってしまったりWクリックで開けなくなったりします。これもなんとかなるといいな…。

ということで調べてみました。
結論から言うと下記のコードでいけました。

解決策

--- Setting ---
property addStr : "_b"
------------------


use AppleScript version "2.4"
use scripting additions
use framework "Foundation"

on open droppedFiles
	repeat with aFile in droppedFiles
		set filePath to POSIX path of aFile
		set pathString to (current application's NSString's stringWithString:filePath)
		set ext to (pathString's pathExtension()) as string --dotなし
		set baseFileName to (pathString's stringByDeletingPathExtension()) as string
		set newPath to baseFileName & addStr & "." & ext
		
		do shell script "cp " & quoted form of filePath & " " & quoted form of newPath
		-- Add a 1px gray border using ImageMagick
		do shell script "/opt/homebrew/bin/convert " & quoted form of filePath & " -bordercolor '#696969' -border 1x1 " & quoted form of newPath
	end repeat
end open

ただし、遅いです…！

余談

以下、調べた過程や寄り道の話です。

まず元ファイルの拡張子を取得したいので「Applescript 拡張子 取得」あたりでググってみて「指定ファイルの拡張子を取得する – AppleScriptの穴」を発見。2018年の記事ですがもちろん現在でも通用します。

指定ファイルの拡張子を取得する – AppleScriptの穴

piyocast.com

AppleScriptで扱うファイルパスはなんだかややこしくて分かりづらいのですけど、スクリプト内でファイルのフルパスを文字列として取得しているので、その最後のドットから末尾までを拡張子として取得するのがいいのかなと自分では思ってました。しかしもっとスマートな方法が書かれてました。

FinderやSystem Eventsの機能を用いて拡張子を取得するのが一番手軽ではあるのですが、macOS 10.14以降の環境ではこの程度でもアプリケーションの機能を呼び出すと認証ダイアログが（初回のみですが）表示されます。Cocoaの機能呼び出しが手軽にできるので、些細な処理でもよく呼び出して使っています（個人的に）。

ふむふむ…って、「Cocoaの機能呼び出し」って何？ AppleScriptにそんな機能あったっけ？？

AppleScript名：指定ファイルの拡張子を取得する

use AppleScript version “2.4”
use scripting additions
use framework “Foundation”

set a to choose file
set aPath to POSIX path of a
set pathString to current application’s NSString’s stringWithString:aPath
set newPath to (pathString’s pathExtension()) as string
–>　　”jpg”

「NSString」「stringWithString」「pathExtension」とか自分的には懐かしい…。

で、こういうの出来たんだっけ？と確認すると、スクリプトエディタではmacOS 10.10（Yosemite 青白タンクじゃないよOSだよ)からできたとのこと。WikipediaによるとYosemiteのリリースは2014年10月17日。うむ〜、10年以上前か…。

この機能はAppleScriptObjC(ASOC)というらしいです。XCodeにAppleScriptで書けたのはなんとなく覚えているけどあれが原型だったらしいですね。Wikipediaの「AppleScript」内のAppleScriptObjC構文が概要について結構詳しかったです。正直に言うと忘れてたのか知らなかったのかもわからなくなってますが、この機能はいいです。
ただし、体感できるぐらいもたつきますね。スクリプトの短さを優先した結果だと前向きに行きます。あと、画像以外をドロップすると改変後の名前のファイルは作成されるのに中身はただのコピーですし、エラーも出ます。原則的に自分で使うものですから、これはいいでしょう。

対策するなら拡張子のリストを持っておいてドロップされたファイルが含まれるのかをチェックする、とかなんでしょうか。

あと、ASOCの正規表現を使う方法もあるようです。

Cocoaの機能を使って正規表現で文字列を置き換えるAppleScriptハンドラ - Qiita

do shell scriptを使わないとできなかった正規表現の文字列置き換え AppleScript上でCocoaの機能を使えるようになった regexReplace.scpt use framework "Foundation" my ...

qiita.com

また、ImageMagickでなくてsipsを使ったらどうかという話もありますが、元記事の画像に枠線を付けるプログラムをマックで作るでも書かれている通り、作者さんの環境では

日本語ファイル名を扱えない

ことで断念されたようです。
自分の環境（macOS Sequoia 15.3.1）ではこの問題は確認されませんでしたが、sips 画像編集のコマンド – DigitalBooを拝見するに過去にはかなり微妙なバージョンもあったようで、そのあたりも考慮するとImageMagickを使用するメリットのほうが上回るかもしれないなと感じてます。

sipsについての参考情報もリストアップしておきます。

• Macのターミナルで簡単に画像処理できるsipsの使い方 #MacOSX – Qiita
• Mac専用sipsコマンドで、画像に枠線をサクッとつける – ハイパーマッスルエンジニア
• sips 画像編集のコマンド – DigitalBoo
• 【効率化】 一括で写真にフレームを付けてくれるアプリを作ってみた（Macのみ対応）｜KISUKE

以上です。

この2枚の画像で比較すると、上よりも下の方が見やすいというかウィンドウの一部を切り抜いたんだとわかりやすくないですか？

ということで「むかし外枠を付けるのに使っていたアプリ」を思い出そうとしていたのだけれど、たぶん、GraphicConverterだ。ドイツ製。シェアウェアで何ドルか出して購入して使っていた。手元に当時のレジストの記録があった（よくあったな）ので見たら、日付が

Date: Wed, 17 Dec 1997 08:19:23 EST

となっていた。泣ける。バージョンは「4.5-5.x」だった。今は「12」のようだからホントに昔だ。当然もうこのコードなんて使えないので他をあたることにする。
なにかコマンドラインツールだったかスクリプトだったかを使っていた気もするけれど、こっちは思い出せない。
仕方なく標準のプレビュー.appを使ってみたけれどもフリーハンドでの作業を余儀なくされるのでキツイ。オンラインツールは全面的に信用しているわけではないので今回はパスするとして、検索してもめぼしい情報はなかなか見つからない。以前対応していたらしいソフトはもう有料版へと羽ばたいていて無償版は公開停止していました。いや、それは当然です。いいものはどんどんそれに見合った代価で取引されるべきです。しかし今回の場合は「以前はできていたのに」という気持ちが出費を邪魔するのです。

それはともかく、ようやく見つけたのがこちら↓のページ。ImageMagickをDropletから使う方法です。

画像に枠線を付けるプログラムをマックで作る｜PowerCMS X 佐藤聖

note の不満は画像に枠線を付けられないことです。CSS なら border: 1px solid っていう感じです。 マックなら、Homebrew、Xcode、ImageMagick、AppleScript でドロップレットが作成できま...

note.com

出来上がったDroplet、ありがたく使わせていただきます。上の画像の枠線は、こちらを使って描いたものです。
感謝です！

追記: 続きを書きました ＞ 画像に外枠を付けるスクリプトの件の続き

画像に外枠を付けるスクリプトの件の続き

前回の画像に外枠・縁取りを付ける、外周に枠線を引くの続きです。気になることその前回に書いた通りありがたくスクリプトを使わせていただいてます。環境はmacOS Sequoia 15.3.1です。ただ、ちょっと気になる点が出てきてしまいました。...

www.aynimac.com

2025.02.16

先日の「永続オブジェクトキャッシュを使用してください」から始まる放浪の続編です。
あのあと「テーマは変えた」と投稿したのですけれど、時系列的にはその前になります。2024年の12月中旬のことです。

さて、前回は「WordPressのサイトヘルスで『永続オブジェクトキャッシュを使用してください』と出ていて対応した」という話でした。object-cache.phpによるAPCu導入、WPCodeプラグインインストール、サーバ側の高速化設定も調整などを行いました。
結果、サイトヘルスから「永続オブジェクトキャッシュを使用してください」との警告メッセージは消えたものの、新たなエラー「Page cache is not detected but the server response time is OK」が表示されるようになってしまいました。前回から残っているエラーもあります。

まずは「Page cache is not detected but the server response time is OK」というメッセージです。サイトヘルスの詳細を見てみます。

Page cache enhances the speed and performance of your site by saving and serving static pages instead of calling for a page every time a user visits.
Page cache is detected by looking for an active page cache plugin as well as making three requests to the homepage and looking for one or more of the following HTTP client caching response headers:
cache-control, expires, age, last-modified, etag, x-cache-enabled, x-cache-disabled, x-srcache-store-status, x-srcache-fetch-status.
✔ Median server response time was 201 milliseconds. This is less than the recommended 600 milliseconds threshold.
❗ No client caching response headers were detected.
❗ A page cache plugin was not detected.

ビックリマークの項目に「ページキャッシュプラグインがない」と書かれています。前回のオブジェクトキャッシュ対応時に互換性への懸念からのオブジェクトキャッシュ対応時に互換性への懸念からWP Super Cacheを停止してたんだった。今回はちょっと別のものを試したい気持ちがあってWP Fastest Cacheにしてみた。ダメならWP Super Cacheに戻すつもりで試したら、「Page cache is not detected but the server response time is OK」のメッセージは消えてくれました。ここまで順調。

次のエラーメッセージは「予約したイベントの実行に失敗しました」。

予約したイベント wp_privacy_delete_old_export_files の実行に失敗しました。サイトは動作しますが、予約した投稿や自動更新は正しく動作しないかもしれません。

このメッセージは先日のオブジェクトキャッシュのときから出ていたものですが、対処を後回しにしていたのでした。
さてどうしたものか。内容からは、ページへのアクセス時に行われる疑似Cron的動作の一部が行われなかったということらしい。
調べてみました。

まず、「予約したイベントの実行に失敗しました」の解消方法。

WordPressをインストールしたそのままだと、wp.config.phpの属性値は400になっていると思います。
こちらを604に変更します。

パーミッションの変更ですね。オレの環境では、604にしても変化はありませんでした。

次に、【原因判明】サイトヘルスに「予約したイベントが遅れています」action_scheduler_run_queue の実行が遅延していますのアナウンス。
表示されているメッセージは若干違いますが、根っこは同じ問題なのではないかと推測。

パーミッションのグループに「読み込み権限」を与えないとダメっぽいです。※もしかしたら出たり出なかったりするかも・・？
つまり、640です。

今度は640でこっちも試してみる…が、やはり変化はありませんでした。

続いて、非表示予約プラグイン「PublishPress Future」がうまく動かない時に確認すること。こちらはタイトル通りのプラグインの挙動についての対策内容なのですが、確認事項の中にサイトヘルスのエラーがあって、同様のメッセージについて扱われています。

次の定義を wp-config.php に追加してみてください。
define('DISABLE_WP_CRON', true);

解説があります。

WP-CRONは、WordPressサイトへのアクセス時にスケジュールされたタスクをチェックして実行します。
しかし、トラフィック（サイト訪問数）が少ないサイトでは、タスク（自動的に実行される、タスク管理の内部システム）が適時に実行されないことがあります。
逆に、トラフィックが多いサイトでは、WP-Cronの実行がサーバーリソースに負担をかけることがあります。
このような理由から、define('DISABLE_WP_CRON', true); を使用することで、WordPressの内部スケジューラーであるWP-CRONを無効にし、サーバーのCronジョブでタスクを管理することができます。

ふむふむ。理にかなっているように思いますので、WordPressのファイルを直接いじるのは気が進まないながらもやってみました。
つづいて、WP Crontrolプラグインのインストール。間違えて別のWPControl（スペースがない）をインストールしてしまったりしたものの、最終的には有効化できました。で、問題の「wp_privacy_delete_old_export_files」を「今すぐ実行」してみました。その後で「このフックを一時停止」し、「このフックを再開」。いずれも問題なく行えたと思います。
… しかし残念ながら、こちらでも変化はなく「予約したイベントの実行に失敗しました」は表示され続けていました。

そのほか、DNS関係設定の再チェックでも特に問題は見つからず、PHPのアップデート（7.4.33から8.2.22）ではFatal errorが発生したので断念。PHPのバージョンは気になりますし上げたほうがいいのですけど、今回のサイトヘルスのエラーメッセージ問題では他に原因があると判断しました。PHPのバージョンが原因ならもっと普通にエラーが出てるはずですから。
ここまでかなり長時間にわたって色々と試しても解決できず、時間切れでこの日は断念。書き換えた設定だとかもすべて戻して一旦終了。

後日、改めてチャレンジしました。
頭を冷やして考えてみて、「WordPress内のWP-Cronを無効化してレンタルサーバのCronを使うように変更」がちゃんと最後までできていなかったので、これをやっていきます。
参考サイトは、以下。

• 【WordPress】パフォーマンスアップ！wp-cron.phpを停止しよう【パフォーマンス】 | Hornet|静岡拠点のWeb、ホームページ制作
• WP-Cronを無効化してWordPressサイトのパフォーマンスを改善する方法を解説｜SEEDS knowledge
• WordPress WP-Cron を止めて OS層の Cron で実行する方法 | Fand.jp Blog

まず wp-config.php の編集。これは前回も行っていて問題はありません。以下のコードを挿入するだけ。

define('DISABLE_WP_CRON', 'true');

続いて、レンタルサーバでのCron設定。これが前回にはできていなかったことです。
参考にさせていただいた【WordPress】パフォーマンスアップ！wp-cron.phpを停止しようではシェルスクリプトを噛ますことも書かれていてやや記述が混乱しているけれども、途中に書かれているようにCronコマンドでPHPファイルを直接指定してもいけます（PHPのパス・バージョン番号注意）。

/usr/bin/php7.3 /home/サーバーID/独自ドメイン名/public_html/wp-cron.php > /dev/null 2>&1

で、設定するにあたっての問題は、頻度ですよ。どのくらいの間隔で実行するのがいいのか。
【WordPress】パフォーマンスアップ！wp-cron.phpを停止しようの設定例では1日1回としています。
WP-Cronを無効化してWordPressサイトのパフォーマンスを改善する方法を解説の設定例は1時間に2回と1回。
WordPress WP-Cron を止めて OS層の Cron で実行する方法の設定例では5分間隔（5分経ったらに1回実行）。かなり幅があります。最後のWordPress WP-Cron を止めて OS層の Cron で実行する方法では

実行時間は5分だと細かいようにも見えますが、もともと（アクセスさえあれば）1分間に何回でも実行されていたわけなので、実行間隔が長すぎるとも言えます。この値は提供サイトの状況によって適宜見直しをしてください。

と至極真っ当な事が書かれています。そのとおりなんだよなー。
後で見直すことも前提にしてとりあえずは1時間に2回実行するよう設定してみました。すると、インストールしていたWP Controlプラグインの「Cronイベント」タブの表示内容が更新されて、イベントの実行予定時刻や頻度が表示されるようになりました。一番短い間隔のものでも1時間に1回となっていて、オレの環境ではそれ以上実行しても意味がないということなんだなと考えて一度は頻度を落としたものの、よく考えたら必ずしもそうではないですね。タイミングによってはタスクの実行までに最長1時間かかることもあるわけで、やはりここは1時間に2回は最低ラインだと思われます。ということで、1時間に2回で様子を見てみます。

ということで、レンタルサーバのCronを使ってWP-Cronを動かすようにしてからサイトヘルスを見てみると、「予約したイベントの実行に失敗しました」は消えていました！
（設定しただけで消えたのかCron実行後に消えたのかはわからなくなってしまいましたが。）
もともと何故「予約したイベントの実行に失敗しました」が出ていたのかもよくわかりませんでしたが、レンタルサーバのCronで確実に実行することでこのメッセージは撲滅できました。たぶん。
めでたしめでたし。

WP Controlプラグインはしばらくはそのままインストールしておきます。

また長々と書いてしまった…。

まとめ

WordPressサイトヘルスのエラー対応方法

• 「Page cache is not detected but the server response time is OK」＞WP Super CacheやWP Fastest Cacheなどのページキャッシュプラグインを導入する
• 「予約したイベントの実行に失敗しました」＞ WP-Cronを無効化してサーバのCronを使ってみる

さてWordPressだけれどもそろそろテーマの変更をしようかと考えて、無料テーマで高機能で名高いCocoonをインストールしたものの、有効化できない。「何かがうまくいかなかったようです」などと言われてしまう。その前にもライブプレビュー中にメニューをカスタマイズしてもその変更内容がプレビューに反映されなかったり、どうにもおかしい。
Cocoonを再インストールしたりDBテーブルを削除したり全リセットを行ったりしたけれども、変化はありませんでした。
あちこち検索した結果Cocoon フォーラムでの「メニューに「ホーム」を追加できません」にて

一時的にWAFをOFFに設定して、同様の操作を行うと、どうなりますでしょうか？

との対策を発見。WAFかー。
サーバのコンパネからオフにしてしばらく待って有効化を確認後、同じ操作をすると…できました！ よかったよー。
細かいカスタマイズはまた行うとして、取り急ぎの変更は完了です。

WAFはまたオンにしておきました。

ブログをリスタートするにあたって、ここ10年近くほぼ放置状態だったWordPressを触り始めた。管理画面のあちこちを行きつ戻りつしているうちに「サイトヘルス」のコーナーに「永続オブジェクトキャッシュを使用してください」とか出てるのに気づいた。
調べてみて、参考にさせていただけそうな情報をいくつかリストアップ。

• 【WordPress】Xserver でプラグインなしで APCu を使う方法 | 株式会社レクタス
• 【WordPress】APCuを使えるようにする #PHP – Qiita
• WordPressでAPCuを使う – ＊ListFreak
• ［WordPress］ APCu オブジェクトキャッシュで高速化 – DigitalBoo

なんか簡単に対処できるかなと思って手を付け始めてしまったが、そんなことはなかった…。

手順としては、まず【WordPress】Xserver でプラグインなしで APCu を使う方法 | 株式会社レクタスとWordPressでAPCuを使う – ＊ListFreakを見つつ、GitHub – l3rady/WordPress-APC-Object-Cacheからobject-cache.phpをDL。このファイルは9年前のものなんだな…。

続いて、そのファイルの冒頭に【WordPress】Xserver でプラグインなしで APCu を使う方法 | 株式会社レクタスに書かれた変更を加える。

!defined( 'ABSPATH' ) and exit;
if (!function_exists('apcu_fetch')) {
  return false;
}
$arrABS = explode('/', str_replace('\\', '/', ABSPATH));
if (is_admin() && !($_SERVER["SCRIPT_NAME"] == "/" . $arrABS[count($arrABS) - 2] . "/wp-admin/site-health.php")) {return false;}

ここまでは、問題ない。
しかしその後で、考え込むことになる。【WordPress】Xserver でプラグインなしで APCu を使う方法 | 株式会社レクタスには、

ここまでだとキャッシュのクリアの方法に困る．

と書かれている。つまり、記事を編集（投稿も？）したときに更新されないということだ。対策として書かれているのはWordPressのfunctions.phpにコードを追記すること。これはちょっと嫌だなぁ。アップデートで上書きされたりしないかとか、加えた変更内容がわからなくなってサイト移転でハマったりとか、かつてそれで苦労したような記憶もあってこの方法は取りたくない。
また、よく考えれば9年も前のファイルを自分で編集してアップロードすることもアブナいと言えなくもない。もし専用のプラグインがあればそれを使えばいいんじゃないのか。

そこで改めて検索したところ、APCu Manager – WordPress プラグイン | WordPress.org 日本語を発見。これでいいんじゃないのか？ と、いちおうその他の情報も見てみたらAPCu Manager 3.8.x にご用心 … 3.9.0 にもね – DigitalBooを見つけた。過去のバージョンでのエラーの話で、

初めて APCu Manager を知ってインストールしたとき、ずっこけるほどサイトが遅くなって「駄目だこりゃ」とすぐに捨てました。その後、改良されて安心して利用できるレベルに達していましたが、先日の不具合のあと、あのときと同じ症状が舞い戻ったのです。

とも書かれていた。何度か繰り返し問題を起こしているようですね。うーん…。で、この方はどうされたかというと、それが次のエントリ。

• ［WordPress］ APCu オブジェクトキャッシュで高速化 – DigitalBoo

前掲のいくつかのリンクも踏まえて俯瞰的網羅的に書かれていて信頼できそうなので、踏襲させていただこうと思う。

で、上記の記事の中に以下の文章があった。コードが書かれたあとで

これを functions.php に書くなり、スニペットとして保存するなりします。

スニペット？ そんな機能がWordPressにある？
調べたら【ビギナーガイド】WordPressにカスタムコード（スニペット）を追加する方法 – エスティバルというページを見つけた。そうか、そういうプラグインがあるのか…。以前はWordPressのファイルに直接追記していて加えた変更内容がわからなくなってサイト移転でハマったりして、対策として自前でプラグイン書いたりもしてたわけだけど、ちょっとしたコードを追記するためのプラグインがあるんだなー。Code Snippets – WordPress プラグインの安定バージョン公開は2012年6月。知らなかったわ。

で、スニペットプラグインはこれがベストなのか、その他にはないのかも調べたら、WPCode – ヘッダーとフッターの挿入 + カスタムコードスニペット – WordPress コードマネージャー – WordPress プラグインがあった。インストール数も多いので、こっちを使ってみる。

話は戻って、永続オブジェクトキャッシュ対策の件。
スニペットとして使用するキャッシュクリアコードは以下のもの。

function my_save_post($post) {
  if (function_exists('apcu_clear_cache')) {
    apcu_clear_cache();
  } else if (function_exists('apc_clear_cache')) {
    apc_clear_cache();
  }
}
add_action('save_post', 'my_save_post');

ということで最終的な作業手順は以下の通り。

1. 今まで使っていたキャッシュプラグイン「WP Super Cache」を停止（互換性がわからないので）
2. WpCodeインストール
3. WpCodeにキャッシュクリアのためのコード（上記）をペースト
4. 編集済みのobject-cache.phpをWordPress内に配置
5. 挙動確認
6. サイトヘルスステータスも問題なければ今使っているキャッシュプラグインを削除

WPCodeの操作説明として、一応参考情報:

• 特定ページのヘッダーやフッターにコードを挿入できるWPCode Liteプラグインを使う
• functions.phpがごちゃごちゃする人必見! WP Codeですっきりと | KumaTechLab

ここまでできたので、追加したエントリはすぐに表示されるようになっているはず（同時に他のキャッシュもクリアされる）。

あとは記事保存とは別に「全キャッシュクリア」のための方法を追加しておきたい。
［WordPress］ APCu オブジェクトキャッシュで高速化 – DigitalBooや超簡単操作のAPCu キャッシュクリア【WordPress】 – DigitalBooによると、いくつか方法はある。

1. プラグイン APC Clear Cacheを使用する
2. apcu_clear_cache()を仕込んだphpファイルを作って、ブラウザで開く
3. apcu_clear_cache()を仕込んだテンプレートファイルを固定ページに仕込み、開く
4. 前項のページを呼び出すメニューをウィジェットに置く

1.は5年以上更新されてないしここでプラグインに頼るのは趣旨が違うように思うのでパス。2.もスマートさに欠けるので見送り。3.も明後日の方向を見ているようで気が進まない。この著者さんは最終的に4.に落ち着いているようだが、オレの使い方では、ウィジェットメニューにするほど通常画面からキャッシュクリアするとは思えない。
と、いうようなことで、独自の方法として「管理画面にオールキャッシュクリアするボタンを配置する」を試みたい。ただし、「オールキャッシュクリアするボタン」を押下したあとで画面遷移があるわけだからそれが上記リストの「3.」の固定ページになるのかな。
資料を探してみた。

• WordPressの管理画面を使いやすくする簡単カスタマイズ18選 | knowledge / baigie

上記を参考に、まずは管理画面で余分なウィジェットを削除、必要なウィジェットを配置、するコードをWPCodeに作成。PHPスニペットで、名前は適当に、挿入方法は「自動」、場所は「管理エリアのみ」。優先順位は「10」のままにした。

function remove_dashboard_widget() {
  remove_meta_box( 'dashboard_primary', 'dashboard', 'side' ); // WordPress イベントとニュース
}
add_action( 'wp_dashboard_setup', 'remove_dashboard_widget' );

function add_dashboard_widgets() {
  wp_add_dashboard_widget(
    'all_cache_clear_dashboard_widget', // ウィジェットのスラッグ名
    '全キャッシュクリア', // ウィジェットに表示するタイトル
    'dashboard_widget_function' // 実行する関数
  );
}
add_action( 'wp_dashboard_setup', 'add_dashboard_widgets' );

function dashboard_widget_function() {
  ?>
  <ul class="quick-action">
    <?php if ( current_user_can( 'administrator' ) ) : ?>
      <li>
        <a href="【固定ページへのリンク】">
          <span class="dashicons-before dashicons-admin-customizer"></span>
          APCu全キャッシュクリア
        </a>
      </li>
    <?php endif; ?>
  </ul>
  <?php

}

次に、固定ページに埋め込むためのショートコード。ユニバーサルスニペットで作成し、挿入方法は「ショートコード」、ショートコード属性は使用せず。

<?php apcu_clear_cache(); ?>
<p>APCu cache cleared.</p>
<p><input type="button" onclick="window.history.back();" value="もどる"></p>

続いて固定ページを作成。
タイトルは何でもいいけど「APCu 全キャッシュクリア」とした。中身は先程作ったショートコードを貼り付け、リンクをわかりやすいものに変更。ステータスを「非公開」にして保存。
この固定ページへのリンクを最初のスニペットの「【固定ページへのリンク】」に保存。最後にWPCodeのコードスニペットで有効化するのを忘れずに（有効化できないときはコードの何処かが間違っている）。
管理画面のダッシュボードに「全キャッシュクリア」が追加され、リンクを辿って固定ページが表示されて、「もどる」で元のダッシュボードへ戻れることを確認。

あと、【WordPress】Xserver でプラグインなしで APCu を使う方法 | 株式会社レクタスにかかれている「エックスサーバーの高速化の設定を変更」も実施する必要がありそう。

Xアクセラレータ設定
　　Xアクセラレータ Ver.1
サーバーキャッシュ
　　ON
ブラウザキャッシュ
　　ON［全ての静的ファイル］

自分の設定を見てみたら
Xアクセラレータ設定＝Ver.2
サーバーキャッシュ＝OFF
ブラウザキャッシュ＝ON［全ての静的ファイル］
となっていた。前ふたつを変更して、キャッシュ関係の一連の設定は終了（のはず）。
キャッシュの効果は体感できないとどこかで読んだ気もするが、ちょっと期待している。

ところで。
コードスニペットを書いているときにおかしなことがあって、貼り付けたコードがどうしても有効化できない。T_STRINGがどうたらとエラーが出る。理由は、空白部分に特殊文字が入っていてそれがエラーになっていた。
WPCodeでは外見上は全くわからないが、エラーの出るコードをCotEditorに貼り付けてみると、強調表示できる。下記のスクリーンショットでは、選択部分の中に見慣れない記号がある。

この文字を文字ビューアアプリで検索してみると名前は「NO-BREAK SPACE」、Unicode: U+00A0, UTF-8: C2 A0 となっている。
どこで混入したんだろう。
コード部分のコピー元のサイト（WordPressの管理画面を使いやすくする簡単カスタマイズ18選 | knowledge / baigie）では問題なかった。ちなみにブラウザ（Brave）上では検索しても通常のスペースと同一視されるようで検索できない。
自分で編集したところに混入しているのが気になる。編集はたぶんWPCode上で行ったと思うのだ。

長々と書いてしまった。
今度はテーマを変えてみる予定。
追記: テーマ、変えました。

かつてあちこちのWebページを見ていたときに流れ着いたところで、「備忘録おばさん」という言葉を見つけた。なんかグッと来て、「ならオレは備忘録おじさんを目指そうかな」などと思ったのでした。で、そのページがサイト移転かメンテ中かで見られなくなっているのでInternetArchiveから掲載させていただきます。

西洋占星術師が見つけた「謎の備忘録おばさん」という幸せ | ほしぱそ。（InternetArchive）

どういう流れで「備忘録おばさん」が書かれたページを知ったのかというと、おそらくObsidianについて色々調べていたときに流れ着いたのではないかと思う。

いいですよ、Obsidian。Markdownドキュメントエディタ兼管理ソフト（でいいのか？）。めちゃオススメ。
備忘録として残しておきます。

備忘録おじさん。
ゆっくりと、目指していきます。

構想数年、ようやっとこのサイトもTSL化完了です。

全面的にWordPressをhttpからhttpsにSSL化した全手順まとめ（エックスサーバー環境）を参考にさせていただきました。少し前の記事ですので、置換プラグインは「Search Regex」ではなくて「Better Search Replace」を使ったりとかはあったものの、ベースはそのままで作業できました。感謝。ただ今までこのサイトでは画像をフォト蔵に置いていて、こちらも単にURL置換で行けるかと思ってたのですが、なんとフォト蔵が対応していなかったという…。このご時世でこれはないなと感じてレンタルサーバに置くことにしました。この作業がえらく大変で時間がかかってしまいました。

で、作業はうまく行ったはずですけど、問題は「アンテナ（なつみかん）で更新時刻が得られない」ということ。「まぁ…そのあたりはなんとかなるっしょ」という諦めというか考えないことにして突き進んでしまったのですね。

今後、ぼちぼち考えます。

そういうわけで、 https://www.aynimac.com/ よろしくお願いします。

—

数日前に読んだ「「距離感が掴めないタイプのコミュ障」の人が発生するのはこんな理由？「こういう人多い」「許してくれ…」 – Togetter」。苦い思い出が少なくなくて、ほんと、許して。
明日も頑張ろう…。