XPressME Integration Kit

Trac

Opened 10 years ago

Closed 10 years ago

#62 closed 作業 (修正済み)

ブロックの取得方法実験

Reported by: toemon Owned by: toemon
Priority: 普通 Milestone: Ver.2.0.0
Component: ブロック Version: 2.0.0
Severity: 普通 Keywords:
Cc:

Description

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

Change History (1)

comment:1 Changed 10 years ago by toemon

  • Resolution set to 修正済み
  • Status changed from new to closed

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

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

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

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

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

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

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

Note: See TracTickets for help on using tickets.