古いデータベースをコピーしてつなぐのはあきらめました.空のWordPressサイトを立ち上げて,しばらく運用しながら古いデータの移転を考えます.
- 空のデータベースを立ち上げる(固定ページ用とBLOG用)
- WordPressの新規インストール
- Plugin,Header imageなどの設定
- 外部に公開
- sendmail, DX spiderの設定
- Samba,Netatalkの設定
- WordPressの古いデータの移転を試行
横断歩道での一時停止は善意ではなく義務 (Powered by WordPress)
古いデータベースをコピーしてつなぐのはあきらめました.空のWordPressサイトを立ち上げて,しばらく運用しながら古いデータの移転を考えます.
現在,一度macOS 26.2 TahoeにupgradeしたM4 Mac miniをmacOS 15.7.3 Sequoiaにダウングレード中です.

主な理由は,TahoeにおけるMacPortsでrsyncがbuildインストールできなかったことによります.OpenSSL 3のインストール時にエラーが出ます.
もちろんrsyncもOpenSSLも重要なソフトで何か見落としがあるか,あるいはバグだったにしても優秀なメインテナーたちがすぐに直してくれると思います.
しかし,もうひとつ耐えられない事情があります.それは “ミュージック” の出来の悪さです.筆者にとってiTunesの流れをくむ “ミュージック” はMacの存在理由のひとつと言っても過言ではありません.
大学生時代から独身時代にかけてエアチェックで録り溜めた楽曲に加えて,オーストラリア在住中に買ったCD,そしてそれ以後は時々ですが購入したCDやダウンロードした楽曲を収録してあって,リリース年順に聞いています.
手順としては朝起きてMac miniの電源を入れて1, “ミュージック” を立ち上げ,曲のならびを “最後に再生した日” 順にしてプレーを開始して2,すぐに “年” 順に並び替えて次の曲に飛びます.これで前日の続きが聞けます.
これはmacOS Sequoiaまでは有効でしたが,同じことをTahoeの “ミュージック” ですると,「次に再生」というリストに, “最後に再生した日(時)” の順で曲が並ぶのです.そのまま再生をすると昨日聞いた曲を遡っていきます.
この次に再生はYouTubeなどのUIを真似たのだと思いますが,全く出来が悪いです.
このworkaroundは, “最後に再生した日” のリストで1番上の曲を再生したら,曲のならびを “年” にしたところで,次に再生のリストをクリアします.そしてリストで今再生中の曲の次をダブルクリックします.あるいは, “年” のならびのまま, “最後に再生した日” を見て,前日に再生した曲の次の曲をダブルクリックします3.
また,収録曲の音量のレベルのバラツキがひどいように感じます.これは,客観的根拠はないです4.
UIについては根本的にはmacOS 26.xでは改善されないでしょうから26.xはパス,ということにします.
しかし,rsyncでMariaDBをコピーした場合,ユーザーのデータに不具合が残る.
先に,MariaDBを正規の手続きで移転する.
Pagesで長時間大きめのファイルを開いているとMetadataが増大してプチフリーズが発生しやすくなる旨以前書きました.
そう認識してからは,なるべくPagesは使用し終わったら終了し,開きっぱなしの時も一年分の日記のような長大な文書ファイルは開かないようにしていました.
ところが,それを守っていても,CorespotlightのMetadataが増大してしまいました.今朝ブートした直後には1.5GBだったことを確認しています.庭仕事をして戻って来たらこんなになっていました.

さいわい今のところプチフリーズは発生していません.SSDのアクセス速度も正常です.

しかし,Metadataが50GBを超えるのは正常ではありませんしSSD領域の無駄遣いなので,このエントリーを書き終えたらMetadataを削除してリブートすることにします.
現行サーバーのWordPressにインストールしてあるプラグインは24個でした.1つずつ新規にインストールしたWordPressにインストールするというじみな作業をしました.
ABC順でAnnieは既にデイスコンのようです.3番目くらいにインストールしたClient IP Detectorですが,Activateしたらcritical errrorが発生したとかで,ダッシュボードはおろか,webサイトの表示もしなくなりました.
エラーを起こすプラグインの除去法をネット検索しますが,ダッシュボードから…というものばかり見つかり話になりません.
WordPressのディレクトリーに行って探したら,wp-content/pluginsの下にclient-ip-ditectorというディレクトリーがあるので,ディレクトリーごと削除したら回復しました😓
そんなわけで残りは恐る恐る作業を続けましたが,Client IP Detectorほどひどいものはありませんでした.ディスコンになって見つけられないものは3つほどありました.
まあ,できるところまでということで,これで完了とします.