XPressME Integration Kit

フォーラム

WP Super Cacheのプラグイン導入時のXPressMEハック

永らくありがとうございました › フォーラム › バグ報告と提案 › WP Super Cacheのプラグイン導入時のXPressMEハック

  • このトピックには7件の返信、2人の参加者があり、最後に匿名により13年、 3ヶ月前に更新されました。
8件の投稿を表示中 - 1 - 8件目 (全8件中)
  • 投稿者
    投稿
  • 2009 年 12 月 2 日 10:23 AM #2623
    匿名
    ゲスト

    toemon様

    お世話になっております。

    先日WPtouchのハックをマージしていただいた、うえむことuemeraです。

    本日はwordpress プラグイン WP Super Cacheの件で投稿させていただきます。

    WP Super CacheはWordPressをキャッシングしてくれるプラグインで、以下から

    ダウンロードできます。

    http://wordpress.org/extend/plugins/wp-super-cache/

    先日、これをXpressME Integration Kit上のWordPressに導入したところ、その

    ままではうまく動かず、XpressMEの方のソースを修正して動作させることが

    出来ましたので、ご報告します。

    お忙しいところ恐縮ですが、

    ・このハックで問題ないかどうか

    ・この修正をXPressME本体にマージしていただけるかどうか

    等のご検討をいただければ幸いです。

    ■XPressME修正個所

    /include/add_xpress_process.php

    13行目付近

    <br />
$_SERVER = 'POST';<br />

    をコメントアウトしました。

    (すべてのリクエストがPOSTリクエストだとうまく動作しないので、GETリクエストにしました)

    /wp-content/plugins/xpressme/include/custom_functions.php

    /wp-content/plugins/xpressme/include/xpress_common_functions.php

    の両ファイルの、$author_cookieにCookie名をセットしている個所(合計4か所)

    <br />
$author_cookie = get_xpress_dir_name() . "_select_author" ;<br />

    を

    <br />
$author_cookie = "xpressme" . get_xpress_dir_name() . "_select_author" ;<br />

    に変更しました。

    (クッキー名の最初の文字列が可変だと動作に影響する場合があるので、最初の文字列を固定にしました)

    これでWP Super Cacheがひとまず動作するようになりました。

    詳しくは私のサイトにプラグイン導入手順からXPressMEのハックまでの手順を掲載しましたので、ご確認いただけますと幸いです。

    よろしくお願いします。

    2009 年 12 月 2 日 3:25 PM #3000
    toemon
    キーマスター

    uemeraさん、ようこそ。

    読みにくいコードを追っかけていただき、ありがとうございます。

    まず

    /include/add_xpress_process.php

    13行目付近

    $_SERVER['REQUEST_METHOD'] = 'POST';

    をコメントアウトしました。

    の部分ですが、

    このコードの上部にある拙いコメントにあるように、

    XOOPSのイベント通知（プライベートメッセージ）、それも公開予約している記事が公開になったときの処理の為に、追加しています。

    具体的には

    WordPressは予約投稿があった場合、ユーザがサイトを訪れた際に、公開日時をチェックして、必要であれば公開するという手順を踏んでいます。

    ここで、WordPressが記事を公開した時のイベントをフックして、XOOPSのイベント通知をコールする訳ですが、（これを行わないと、多くのXOOPSモジュールのように、予約投稿をしても、イベント通知は投稿をポストした時点で行われてしまいます。)

    XOOPSのほうはというと、XOOPSのデータベース接続にはDatabaseSafe、とDatabaseProxyがあって、

    $_SERVER != ‘POST’のときは、DatabaseProxyで接続されます。

    ここで、DatabaseProxyの場合は SELECT文しか通さず、INSERTやUPDATEなどのデータベース書き込み操作が禁止されます。

    つまり、プライベートメッセージをＤＢに書き込み出来ないという事態が発生します。

    で、苦肉の策が、$_SERVER = ‘POST’;の追加というわけです。

    強いて、やるとすれば

    <code>$_SERVER['REQUEST_METHOD'] = 'POST';<br />
<br />
require_once $xoops_config->xoops_mainfile_path; //It is necessary to execute it for the user attestation before wp-settings.php.</code>

    の部分を

    <code>$request_method =  (isset($_SERVER['REQUEST_METHOD'])) ? $_SERVER['REQUEST_METHOD'] : '';<br />
$_SERVER['REQUEST_METHOD'] = 'POST';<br />
require_once $xoops_config->xoops_mainfile_path; //It is necessary to execute it for the user attestation before wp-settings.php.<br />
$_SERVER['REQUEST_METHOD'] = $request_method;</code>

    とすることで、XOOPS側をだまし打ちできるかも知れません。

    イベント通知の方は当方で確認いたしますので、

    WP Super Cacheのほうはuemeraさんのほうで確認いただけないでしょうか？

    クッキーのほうは、要するにクッキー名の頭にモジュール名を使用すると、モジュールの命名によっては

    WP Super Cacheの

    preg_match( “/^wp-postpass|^wordpress|^comment_author_/”, $key )の判断に引っかかる場合があるので、一致させないための、プレフィックスを追加する必要がある、という解釈で宜しいでしょうか？

    そういう意味では、include/set_cash_cookie_path.phpにある

    USER_COOKIE

    PASS_COOKIE

    AUTH_COOKIE

    SECURE_AUTH_COOKIE

    LOGGED_IN_COOKIE

    TEST_COOKIE

    などのdefineも対象になりそうなのですが、

    set_cash_cookie_path.phpでdefineしない素のwordpress では、wp-setting.phpの432行目あたりからの設定で

    クッキーの先頭にwordpressが設定されているのにも関わらず引っかからないということは、対象外と考えてよいということでしょうか？

    2009 年 12 月 2 日 4:01 PM #3001
    toemon
    キーマスター

    uemeraさんのサイトの記事にありました

    WP Supeer Cacheは、初回リクエストの時点でCookie情報があると、うまくキャッシュしてくれません。

    XOOPSモジュールのWordPressではなく、WordPress単体で動作させた場合は、ブラウザからの初回リクエストはCookieが

    拾えないので、それでうまくキャッシュが動くのですが、XPressMEは初回リクエストでも上記Cookieを必ずセットして

    しまうようです。

    につきましては、先にXOOPSにログインしている状態で、XPressMEにアクセスした場合、最初っからログイン状態でのアクセスとなりクッキーが作成されてしまうという現象だと思います。

    まだWP Super Cacheのコードを見ていないのでなんとも言えないのですが、初回アクセスの判断のみが問題だとすれば、WP Super Cache側でアクセス済みクッキーを設定して、判断するという手もあるかも・・・

    2009 年 12 月 3 日 1:56 AM #3002
    toemon
    キーマスター

    少しだけWP Super Cacheの資料を読んでみました。

    1. Users who are not logged in.

    　　　（ログインしていないユーザ)

    2. Users who have not left a comment on your blog.

    　　　(ブログにコメントを書き込んでいないユーザ）

    3. Or users who have not viewed a password protected post.

    　　　(パスワード保護された記事を見ていないユーザ）

    に関してはあらかじめ用意されたキャッシュのほうを読み込む仕様みたいですね。

    で、上記条件に該当するかしないかを、クッキーで確認する

    単純にいえばログインしてなければクッキーが無いはずなので、ということみたいですね。

    そうすると

    そういう意味では、include/set_cash_cookie_path.phpにある

    USER_COOKIE

    PASS_COOKIE

    AUTH_COOKIE

    SECURE_AUTH_COOKIE

    LOGGED_IN_COOKIE

    TEST_COOKIE

    などのdefineも対象になりそうなのですが、

    set_cash_cookie_path.phpでdefineしない素のwordpress では、wp-setting.phpの432行目あたりからの設定で

    クッキーの先頭にwordpressが設定されているのにも関わらず引っかからないということは、対象外と考えてよいということでしょうか？

    こちらの方は逆にwordpressから始まるクッキーじゃないと、ログインしていても、WP Super Cacheのほうは該当クッキーがないからログインしてないと判断してしまうかもしれませんね。

    /wp-content/plugins/xpressme/include/custom_functions.php

    /wp-content/plugins/xpressme/include/xpress_common_functions.php

    の両ファイルの、$author_cookieにCookie名をセットしている個所(合計4か所)

    $author_cookie = get_xpress_dir_name() . “_select_author” ;

    を

    $author_cookie = “xpressme” . get_xpress_dir_name() . “_select_author” ;

    に変更しました。

    のほうはログアウトしても残っているクッキーなので、ご指摘のとおりの変更が必要になります。

    2009 年 12 月 3 日 8:16 AM #3003
    toemon
    キーマスター

    と、ここまでの確認で行った修正は、チェンジセット477になります。

    確認いただければ幸いです。

    2009 年 12 月 3 日 11:02 AM #3004
    匿名
    ゲスト

    toemon様

    uemeraです。お忙しいところ、さっそくのご返信ありがとうございます。

    XOOPSのイベント通知（プライベートメッセージ）、それも公開予約している記事が公開になったときの処理の為に、追加しています。

    REQUEST_METHODを強制的にPOSTに書き換えている件、了解しました。

    どうしても必要な処理だったんですね。

    私もXOOPSモジュールを作ったことがあるので分かるのですが、確かにGETでは

    更新処理は許されていませんので、止むなくPOSTにて処理したことがあります。

    提供いただいた、XOOPSだまし討ちのコードを代わりに埋め込んでみたところ、これでcacheの方も

    うまく動くようになりました。どうもありがとうございます！

    cookieの方は、すみません私が勘違いしてたところがありました。

    再度supercacheの仕様や挙動を確認したところ、以下のことが分かりました。

    ・cacheの生成条件は、ページ単位ではなく、「ページ」と「cookie」単位である

    つまり、例えばindex画面(記事一覧画面)表示において、以下のリクエストはそれぞれ

    違うcacheファイルを生成します。

    言いかえれば、以下のリクエストはどんな順番で来ても、それぞれの初回表示は

    cacheが使用されず高速表示されません。

    ・1つもcookieを持たないブラウザからのリクエスト

    ・1つだけcookieを持つブラウザからのリクエスト

    ・2つcookieを持つブラウザからのリクエスト

    cookieを持っているかどうかの判断は、

    if ( preg_match( “/^wp-postpass|^wordpress|^comment_author_/”, $key ) ) {

    にマッチするかどうかで決まるんだと思います。

    ここで、あらためてXpressME経由のWordPressのindex画面表示の動作を見て見ると、

    以下のようになり、3回目のリクエストで初めてcacheが効くことが分かりました。

    1. 初回リクエスト

      cookie「無し」の状態でcacheが作られる。

      次にXPressMEプラグインが動作し、$author_cookie (=(dirname)_select_author)cookieが作られる。

    2. 2回目リクエスト

      select_authorのcookieがあるので、cookieが「1つだけ有り」の状態でcacheが作られる。初回リクエストで作られたcacheは使用されない。

    3. 3回目リクエスト

      cookieが「1つだけ有り」の状態のcacheがあるのでそれが使われる。

    つまり、$author_cookieの名前を変更しなくても、3回目にはcacheされます。

    プラグインの名前の順番により、XPressMEよりもWP Super Cacheの方が先に処理されるため、

    このような挙動になるようです。

    仮に、先日私が行ったような$author_cookieのcookie名称を変更をした場合、2回目リクエストで

    super cacheは「cookieなしリクエスト」と解釈するので、

    2回目リクエストの時点でcacheされるようになります。

    ちなみに、上記の説明はすべて未ログイン状態での話です。

    ログインした場合はAUTH_COOKIEなど別のcookieも生成され、未ログイン時とはcookieの数が変わる

    ので、これはこれで別のcacheが新しく生成されます。

    1回分余計にcacheが機能しないだけの差ですので、XPressMEのcokkie名の変更まではしていただく必要

    もないかなと思っています。

    あと、WP Super Cacheは、「ON」モードと「HALF ON」モードがあり、「ON」モードの方が速いらしいのですが、

    私の環境では「ON」モードはどうも動きがおかしいので採用をあきらめました。

    これは、XPressME経由ではない素のWordPressでもうまく動かなかったので、今回とはまた別の問題と思います。

    しかも、「ON」モードにしても、パラメータ渡しが伴うGETリクエストはすべて「HALF ON」モードで処理されて

    しまう仕様であり、「ON」モードで動くシーンは限られていますので、「ON」モードにしてもそれほど恩恵を受け

    られる訳ではありません。

    初回アクセスの判断のみが問題だとすれば、WP Super Cache側でアクセス済みクッキーを設定して、判断するという手もあるかも・・・

    ダッシュボードからの設定を見てみましたが、そのような設定はできなさそうでした。

    ソース変更についても、上記でご説明したように、メカニズムはだいたい分かり、回避もできますので、

    WP Super Cache側の変更は必要なさそうです。

    まとめますと、WP Super Cacheを導入するに当たっては、

    ・XPressME側のPOSTメソッド設定処理の変更

    するだけで動作し、

    ・cacheは3回目から効く

    ことになります。

    いろいろとご教授ありがとうございました。

    よろしくお願いいたします。

    2009 年 12 月 3 日 12:16 PM #3005
    toemon
    キーマスター

    提供いただいた、XOOPSだまし討ちのコードを代わりに埋め込んでみたところ、これでcacheの方も

    うまく動くようになりました。どうもありがとうございます！

    確認、ありがとうございます。こちらはそのまま、対応策として反映させていただきます。

    クッキーのほうですが

    $author_cookieはwordpressが使うクッキーではなくXPressMEが使用するクッキーですので、WP Supeer Cacheから見たとき、よりWordPressに近い状態にするには、

    if ( preg_match( "/^wp-postpass|^wordpress|^comment_author_/", $key ) ) {

    のパターンに引っかからないようなプレフィックスを$author_cookieに追加する必要があると思います。（クッキー名は異なりますがuemeraさんの実施された変更内容と同等にさせていただきます。）

    加えて、include/set_cash_cookie_path.phpのほうは、モジュール名をxpressなどにした場合は、

    USER_COOKIE

    PASS_COOKIE

    AUTH_COOKIE

    SECURE_AUTH_COOKIE

    LOGGED_IN_COOKIE

    TEST_COOKIE

    などのwordpressの持つクッキーのプレフィックスが全てxpress_ となってしまい、WP Supeer Cacheからみた場合、永遠にクッキーが作られていないという判断になってしまうかと思われますので、プレフィックスとしてwordpress_を加え、確実に

    if ( preg_match( "/^wp-postpass|^wordpress|^comment_author_/", $key ) ) {

    のパターンに引っかかるようにしたいと思います。

    従いまして、上記の内容を反映させた

    チェンジセット477とチェンジセット478をもって、WP Supeer Cacheへの対応とさせていただきます。

    修正内容は今週末あたりにリリース予定のVer2.2.0RC3に反映させていただきます。

    2009 年 12 月 3 日 1:53 PM #3006
    匿名
    ゲスト

    uemeraです。

    すみません私の投稿の前のtoemonさんの投稿(2件)の存在に気がつかないまま投稿してしまいました。

    よって私の投稿内容がかみ合ってないところがあり申し訳ありません。

    チェンジセット477と478を確認しました。

    いつもながら、仕事の速さに感服してしまいます。

    # 私のフリーソフトは4カ月くらい放置してやっと今週バージョンアップしましたので…

    WordPressはなかなか動作が重たくて、非力なマシンでは困ったことになっているのですが、今回のWP Super Cacheを入れることでかなり速度は改善されました。

    XPressME環境でもこのプラグインを利用される方が多く出ることを願ってやみません。

    お忙しいところ本当にどうもありがとうございました。

  • 投稿者
    投稿
8件の投稿を表示中 - 1 - 8件目 (全8件中)
  • このトピックに返信するにはログインが必要です。