先日の「永続オブジェクトキャッシュを使用してください」から始まる放浪の続編です。
あのあと「テーマは変えた」と投稿したのですけれど、時系列的にはその前になります。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上で行ったと思うのだ。

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

このサイトではWordPressを使ってます。先日から英語版のアップデート通知が出ていて今日から（？）日本語版もアップデートできるようになってますが、「WordPress3.1にアップして少し慌てる」など一部のプラグインに非互換のものがあるらしいので、まだ適用してません。時間が取れてからアップデートする予定。

で、… portal shit!さんの「WordCamp Fukuoka 2011に行った」を引きつつWordPressについて少し書こうかと思ったんですが、なんかうまく書けそうにないので今日のところはフェイドアウトします。
眠い …。

• AmazonJS

  WordPressプラグイン。
  値段表示可能、カスタマイズ前提の設計、DBを使わない、JavaScriptでデータ取得など、かなり気になるスペック。

• ヨメレバ、カエレバ

  amazlet同様のリンク生成サービス。
  前者が書籍用、後者が一般商品用。Amazonだけでなく楽天など他の通販業者へのリンクも同時掲載できるのは画期的。

見つけただけでまだ詳細は確認してません。 😕
後日改めてチェックしてみる予定です。取り急ぎ、メモ。

ふと、「WordPressでキャッシュを効かせたら表示が速くなるんじゃないか？」と思いつく
↓
W3 Total Cacheを導入してみた
↓
有効にするにはサイトのURL表記を変更しないといけないことに気付く
↓
変更してみた
↓
キャッシュは有効になった！ 速くなったような気もする！ 😀
↓
アンテナで更新時刻が取得できなくなってた… 😕

自分でやってるアンテナで自分のサイトの更新時間が拾えてないって、マヌケすぎます。
WordPressの場合はサイトのURLをなつみかん（アンテナのソフト）で見に行っても正しい更新時刻を返してくれないのでFeedをチェックしてたんですが、それがキャッシュのものだったため本来の時刻が取得できなくなってたのです。
あれこれ調べたけどわからず、結局Feedのキャッシュをあきらめることで何とか拾えるようになりました。

で、W3 Total Cacheですが、設定がかなりたくさんありローカライズもされてないのでどこか間違ってる可能性もあります。一通り見直さないといけないかも。

ググって参考にさせていただいたのがWordPressのコメント欄にアバターを表示する方法です。このキャラ画像を「アバター」と呼ぶこともこのタイトルを見てやっと思い出しました。
詳細は参照していただくとしておおまかにいうと「Gravatarにメールアドレスと画像を登録すればよい」ということです。
早速メアドを入力したところ「すでに登録されてるよ」というような警告が出てかなり焦りましたが、これはwordpress.comにも登録していたせいでした（WordPressセットアップ時に登録するはず）。両ドメインのサービスで情報を共有しているとのことです。
ログイン後に画像をアップロードすればサイト上で適正なサイズにトリミングもできて、完成。わりとすぐに反映されました。 🙂

使った画像はこれ ↓。

特に何も考えずに、そのあたりに転がっていたぬいぐるみを撮ったしだいです。

… 次は、そろそろいい加減にテーマを変えたいぞ。

WordPressにしてからなるべく画像を使おうと心がけてはいるものの、用意するのは結構手間だったり適当な写真が手元になかったりするのです。そんなときに使えるプラグインがPhoto Dropper。Flickrなどから、キーワードに対応した使用が許可されている写真（CCライセンス）を探してきてくれます。おもしろい！使える！ 🙂
上の写真は実際にそうやって取得したキーワード「Moon」の写真です。

ついでにもう一枚。

photo credit: andypowe11

キーワードが日本語でもいけます。もちろん、Flickr側に登録されているものであれば、ということなんでしょうけど。↓こちらは「月」で検索しました。

photo credit: wolfpix

検索にやや時間がかかる場合があることや使われているタグ（＜small＞とか）が気になりましたが、おおむね好印象です（上の3枚の写真は取得できるタグをそのまま使ってます）。
問題はむしろ、「ひとさまのとった大事な写真を権利表記をしているとはいえシレッと自分のブログに掲載することへの抵抗感」です。理屈では問題ないはずだとわかっているのに、何か後ろめたいのです。慣れですかね。
あと、検索対象サイトにフォト蔵が入ってればいいのにと思いましたが、それは無理というものですね。

E-WA’S BLOG「当ブログはこんなモノでできている」および、向かい風でも軽やかに「re:当ブログはこんなモノでできている」を拝見して「おぉー」とつぶやいたりしてるわけです。読んでるだけじゃいけないと奮起して、リストアップしてみました。
あ、現行テーマは8someです。

• Akismet
  スパムフィルタ
• Contact Form 7
  メールフォーム生成
• My Link Order
  リンクの並び順変更
• Revision Control
  リビジョン機能無効・回数調整
• Smilies Themer
  スマイリーアイコン変更
• Smilies Themer Toolbar
  スマイリーアイコンツールバー
• Ultimate Google Analytics
  Google Analytics解析コード追加
• WP-DBManager
  データベース管理
• WP Multibyte Patch
  マルチバイト文字関連不具合の修正
• WPtouch iPhone Theme
  iPhone、iPod Touch用ページ変換

まだあまり使いこなせてないって感じ…。「もうちょっとなんとかしたい」というところがあちこちにあるので、手を入れていきたいです。
# 本谷さん、LiTaGのご利用感謝！ 🙂