ブロックの取得方法実験

[toemon]

WordPress2.7からsnoopyの代わりに導入されたwp-includes/http.php　こいつ、使えるかも。
ブロック用のXMLキャッシュは従来どおり、追加、変更、削除のイベントで書き直して、キャッシュが無いときやブロックオプションを変更したときに（XMLキャッシュにコンテンツデータの他にブロックオプションのデータを置き、キャッシュを呼び出したときに比較する）wp_remote_post()で、XMLキャッシュ作成用のスクリプトページblock_refresh.php(新規作成)をコールする。

[toemon]

wp_remote_post()を呼ぶために、wordpressシステムを有効にする必要があるので、これは実現できそうにない。

結論として,モジュール外に配置されたブロックはキャッシュ読みを行うことに決定、
投稿の追加・削除・変更時にイベントをフックしてキャッシュをリフレッシュする。
モジュールページアクセス時、モジュール内に配置されているブロックは、キャッシュを読まず直接WordPressにアクセスする。
このとき、キャッシュがない場合、およびブロックオプションが変更されている場合はキャッシュをリフレッシュする。
（常にキャッシュを更新しないのは、アーカイブページなどで、キャッシュ更新されるとまずいからである）

この結果、インストール直後にトップページに配置したブロックにはキャッシュが存在しないので、「キャッシュが無いので、XXモジュールにアクセスして」みたいなメッセージを置くことにする。
キャッシュ側に[err_message]を置くのでブロックの<{$block.err_message}>は削除してはならない

キャッシュは、基本的にxmlデータですが、カレンダーをどうするかは、決めていない（多分htmlコードをそのままの可能性有り）

ブロックオプションの変更のチェックはキャッシュ側に[options]データをおき、比較に使用する。

キャッシュ名は
[モジュールディレクトリー名] _ [ブロック名][ブロックID] .xml

ここまでの処理は r96 にて実証完了