PEAK XOOPS - BlocksAdminとSPAWで「Invalid Session」 
BlocksAdminとSPAWで「Invalid Session」
- You cannot open a new topic into this forum
- Guests cannot post into this forum
Previous post
-
Next post
|
Parent
-
Children.1
|
Posted on 2005/12/19 3:42
yono
Posts: 9
Posts: 9
よのと申します。
以前旧ＸＯＯＰＳ日本公式サイトで「TinyDで各コンテンツにタイトル」という内容でお世話になりました。
その後数多くのモジュールを使わせていただいております。有難うございます。
今回は表記の通りなのですが、XoopsCube(2.0.13a JP)に「blocksadmin」と「SPAW(TinyD 2.19付属)」をそれぞれインストールし、カスタムブロックについて「SPAW」での編集を行おうとしたところ、「Invalid Session」エラーが出る…というご相談です。
上記構成はレンタルサーバ（ＷＡＤＡＸ(http://wadax.ne.jp/)）で発生したものです。念の為別のレンタルサーバ（ハッスルサーバ（http://www.hustle.ne.jp/)）にも同様の環境を構築してみましたが、まったく同様のエラーが出るところまでは確認できました。
どうやら必ず発生するわけではなく、ごく稀にですが編集を完了できることがあり、一層悩みを深くしています。
念の為こちらとXoopsCube公式サイトで検索をかけてみたのですが、こちらのフォーラムで、未解決と思しき（英語が苦手なもので…(^^ゞ）エントリを発見すること以外できませんでした。
別の方のモジュールでチケットシステム周りとの不整合があった…という事例も合ったようなので、そのあたりからも探ってみましたが、解決策を発見できませんでした。
ぜひ対処方法などをご教示いただければと思います。
よろしくお願いします。
p.s.不足している情報があったらレス下さい。
追って記載します。
以前旧ＸＯＯＰＳ日本公式サイトで「TinyDで各コンテンツにタイトル」という内容でお世話になりました。
その後数多くのモジュールを使わせていただいております。有難うございます。
今回は表記の通りなのですが、XoopsCube(2.0.13a JP)に「blocksadmin」と「SPAW(TinyD 2.19付属)」をそれぞれインストールし、カスタムブロックについて「SPAW」での編集を行おうとしたところ、「Invalid Session」エラーが出る…というご相談です。
上記構成はレンタルサーバ（ＷＡＤＡＸ(http://wadax.ne.jp/)）で発生したものです。念の為別のレンタルサーバ（ハッスルサーバ（http://www.hustle.ne.jp/)）にも同様の環境を構築してみましたが、まったく同様のエラーが出るところまでは確認できました。
どうやら必ず発生するわけではなく、ごく稀にですが編集を完了できることがあり、一層悩みを深くしています。
念の為こちらとXoopsCube公式サイトで検索をかけてみたのですが、こちらのフォーラムで、未解決と思しき（英語が苦手なもので…(^^ゞ）エントリを発見すること以外できませんでした。
別の方のモジュールでチケットシステム周りとの不整合があった…という事例も合ったようなので、そのあたりからも探ってみましたが、解決策を発見できませんでした。
ぜひ対処方法などをご教示いただければと思います。
よろしくお願いします。
p.s.不足している情報があったらレス下さい。
追って記載します。
Votes:16
Average:5.63
GIJOE
Posts: 4110
Posts: 4110
PHPのバージョンはいくつでしょうか？
PHP5.0.5との相性問題は確かにあったので、0.31ではそのあたりは修正していますが、それでもなさそうです。
その次に怪しいのは、ブラウザだったりしますが。
とりあえず別のブラウザ（それもなるべくデフォルト設定）で操作したらどうなりますか？
PHP5.0.5との相性問題は確かにあったので、0.31ではそのあたりは修正していますが、それでもなさそうです。
その次に怪しいのは、ブラウザだったりしますが。
とりあえず別のブラウザ（それもなるべくデフォルト設定）で操作したらどうなりますか？
Votes:8
Average:1.25
yono
Posts: 9
Posts: 9
ご多忙中のご返答、有難うございました。
必要な情報などすっかり書きそびれていました。申し訳ありません。
まずはPHPのバージョンについて。
テスト環境で３箇所用意しました。それぞれPHPのバージョンは4.4.1(WADAX及びハッスルサーバー）、4.3.11（ロリポップ）となっています。
ブラウザについてはMozilla1.5とIE6（いずれもWinXP環境）です。
IEについてはブラウザ設定もセキュリティレベルもリセットしてみましたが、同様にエラーが発生しました。
Norton Internet Securityを入れており、そちらについても（XOOPSに限らずリファラやCookieの制御が問題になったりするので）無効にしてトライしてみたりもしましたが、それでもやはり同様です。
前回もお話しましたが、ごく稀にセッションエラーが出ずに、操作を完了できることがあります。
いまだに法則性はつかめていないのですが、単純な文字詰めの変更だけ…などの場合はエラーが出ずにクリアできることが多いようです。
ただし、これは参考にはならないかもしれません。
念のためPHPデバグをオンにしてみたのですが、その状態でSPAWにアクセスすると、SPAWの画面が表示される途中で動作がストップしてしまいます。
（つまり、SPAWのウィンドウはグレーのまま、デバグ内容も表示されず…という状態です。さりとてフリーズしているわけではなく、ブラウザの「戻る」ボタンで前の画面に戻ることが出来ます）
なので、どのようなメッセージが出ているのかは確認できていません。
昨日、上記環境のうちひとつ（ハッスルサーバー）でnobunobuさんのWordpressモジュールのバージョンを0.5.0RC Finalに変更しました。
その折SPAWを同バージョン添付のものに入れ替えています。この状態ではまだBlocks Adminのテストは行っていないので、今夜にでもテストしてみたいと思います。
また、手元にほぼまっさらのWin2kマシンが用意できましたので、そちらでも改めて試してみたいと思います。
（ブラウザ周りの問題だったのだとすると、投稿でお騒がせしたのは非常に申し訳ないことになってしまいますから(^^ゞ）
いずれも結果がわかり次第この投稿にレスします。
今しばらくお待ち下さい。
-------------------------------------
追記です。
テストしたマシンについて、書きそびれがありました。
IE6(WinXP)については、WADAXに設置したSPAWについて都合３台のマシンでエラーを確認しています。うち２台はクライアントのマシンで、１台はNorton Internet Security2005、１台にはウィルスバスター2006体験版（エラー発生当時）がインストールされていました。
Nortonのプライバシー制御周りについては、かなり早い時期に無効にしてありましたが、いずれのマシンでもエラーは同じようなタイミングで発生しています。
ちなみに、TinyDからSPAWを利用した場合、すべてのマシンで「Invalid Sesion」エラーは発生せず、ほぼ思い通りの編集作業が出来ています。
必要な情報などすっかり書きそびれていました。申し訳ありません。
まずはPHPのバージョンについて。
テスト環境で３箇所用意しました。それぞれPHPのバージョンは4.4.1(WADAX及びハッスルサーバー）、4.3.11（ロリポップ）となっています。
ブラウザについてはMozilla1.5とIE6（いずれもWinXP環境）です。
IEについてはブラウザ設定もセキュリティレベルもリセットしてみましたが、同様にエラーが発生しました。
Norton Internet Securityを入れており、そちらについても（XOOPSに限らずリファラやCookieの制御が問題になったりするので）無効にしてトライしてみたりもしましたが、それでもやはり同様です。
前回もお話しましたが、ごく稀にセッションエラーが出ずに、操作を完了できることがあります。
いまだに法則性はつかめていないのですが、単純な文字詰めの変更だけ…などの場合はエラーが出ずにクリアできることが多いようです。
ただし、これは参考にはならないかもしれません。
念のためPHPデバグをオンにしてみたのですが、その状態でSPAWにアクセスすると、SPAWの画面が表示される途中で動作がストップしてしまいます。
（つまり、SPAWのウィンドウはグレーのまま、デバグ内容も表示されず…という状態です。さりとてフリーズしているわけではなく、ブラウザの「戻る」ボタンで前の画面に戻ることが出来ます）
なので、どのようなメッセージが出ているのかは確認できていません。
昨日、上記環境のうちひとつ（ハッスルサーバー）でnobunobuさんのWordpressモジュールのバージョンを0.5.0RC Finalに変更しました。
その折SPAWを同バージョン添付のものに入れ替えています。この状態ではまだBlocks Adminのテストは行っていないので、今夜にでもテストしてみたいと思います。
また、手元にほぼまっさらのWin2kマシンが用意できましたので、そちらでも改めて試してみたいと思います。
（ブラウザ周りの問題だったのだとすると、投稿でお騒がせしたのは非常に申し訳ないことになってしまいますから(^^ゞ）
いずれも結果がわかり次第この投稿にレスします。
今しばらくお待ち下さい。
-------------------------------------
追記です。
テストしたマシンについて、書きそびれがありました。
IE6(WinXP)については、WADAXに設置したSPAWについて都合３台のマシンでエラーを確認しています。うち２台はクライアントのマシンで、１台はNorton Internet Security2005、１台にはウィルスバスター2006体験版（エラー発生当時）がインストールされていました。
Nortonのプライバシー制御周りについては、かなり早い時期に無効にしてありましたが、いずれのマシンでもエラーは同じようなタイミングで発生しています。
ちなみに、TinyDからSPAWを利用した場合、すべてのマシンで「Invalid Sesion」エラーは発生せず、ほぼ思い通りの編集作業が出来ています。
Votes:16
Average:5.00
GIJOE
Posts: 4110
Posts: 4110
う〜ん。
一通りチェックしてみましたが、それらしきエラーは出ませんね。
そもそも、PHPデバッグで止まってしまう時点で、かなりおかしいです。（4.4.1なら不思議はありませんが）
4.3.11のサーバの方でもPHPデバッグで止まりますか？
いずれにせよ、アップロードとかmainfile.phpの編集とか、そういう基本的な部分でひっかかっているように見えます。
一通りチェックしてみましたが、それらしきエラーは出ませんね。
そもそも、PHPデバッグで止まってしまう時点で、かなりおかしいです。（4.4.1なら不思議はありませんが）
4.3.11のサーバの方でもPHPデバッグで止まりますか？
いずれにせよ、アップロードとかmainfile.phpの編集とか、そういう基本的な部分でひっかかっているように見えます。
Votes:8
Average:8.75
yono
Posts: 9
Posts: 9
レス遅くなりました。
別の問題に緊急に対処せねばならず、そちらに時間を取られてしまいました。
早速なのですが…
Quote:
ご指摘の通り、4.3.11（ロリポップ）ではPHPデバグは正常に表示されました。
今のところ「Invalid Session」エラーも表示されません。
で、問題の4.4.1サーバー（WADAX）なのですが…
Quote:
自分の中で気になる部分もあり（WindowsXPの「マイ ネットワーク」が持っているＦＴＰを使ってファイルをアップしていたので）、まるっきりそれとは関係のない、まっさらなXOOPSを、今度はFFFTPを使ってUPし、構築してみました。
まっさらなXOOPSにblocksadminとTinyD、それにProtectorモジュールをインストール、この時点でカスタムブロックを作成し編集したところ普通に編集が可能。
しかし、インストールするモジュールを増やしていったところ、また同様に「Invalid Session」エラーが発生するようになりました。
（ちなみにモジュール類はXOOPSのアップ時にすべて「modules」フォルダに準備した上で一括で転送。念の為各作者のサイトからモジュールをすべてダウンロードしなおしています）
PHPデバグに関しては、こちらは相変わらず「blocksadmin+SPAW」の環境下では表示されないので、エラーの内容等も残念ながらわかっていません。
ともあれ、もうしばらく今回構築したサイトを使用して挙動などを詳しく見てみようと思います。
更に別サイトにも同様の環境を作って試してみたいと思います。
別の問題に緊急に対処せねばならず、そちらに時間を取られてしまいました。
早速なのですが…
Quote:
4.3.11のサーバの方でもPHPデバッグで止まりますか？
ご指摘の通り、4.3.11（ロリポップ）ではPHPデバグは正常に表示されました。
今のところ「Invalid Session」エラーも表示されません。
で、問題の4.4.1サーバー（WADAX）なのですが…
Quote:
いずれにせよ、アップロードとかmainfile.phpの編集とか、そういう基本的な部分でひっかかっているように見えます。
自分の中で気になる部分もあり（WindowsXPの「マイ ネットワーク」が持っているＦＴＰを使ってファイルをアップしていたので）、まるっきりそれとは関係のない、まっさらなXOOPSを、今度はFFFTPを使ってUPし、構築してみました。
まっさらなXOOPSにblocksadminとTinyD、それにProtectorモジュールをインストール、この時点でカスタムブロックを作成し編集したところ普通に編集が可能。
しかし、インストールするモジュールを増やしていったところ、また同様に「Invalid Session」エラーが発生するようになりました。
（ちなみにモジュール類はXOOPSのアップ時にすべて「modules」フォルダに準備した上で一括で転送。念の為各作者のサイトからモジュールをすべてダウンロードしなおしています）
PHPデバグに関しては、こちらは相変わらず「blocksadmin+SPAW」の環境下では表示されないので、エラーの内容等も残念ながらわかっていません。
ともあれ、もうしばらく今回構築したサイトを使用して挙動などを詳しく見てみようと思います。
更に別サイトにも同様の環境を作って試してみたいと思います。
Votes:17
Average:4.71
Grizzly
Posts: 11
Posts: 11
GIJOEさんyonoさんこんばんわ。横レス失礼致します。
複数のレンタルサーバ（とｐｈｐのバージョン）で、同様の症状を体験中です（汗
・Limeplan（ｐｈｐ4.1.2）
・クララオンラインVPS Demi（php4.3.2）
特にクララVPSが不思議ちゃんで、自分の放置サイトのほか4件借りており、
最近立て続けに借りた2件のうちの片方に症状が出ております。
http.confとphp.iniと.htaccessはどちらも同一にしてみましたが、
症状は変化ナシです。
LimeplanとクララVPSの3件のphpinfo()を見比べてみて気づいたのは、
PHP Variablesの_SERVER["HTTP_COOKIE"]の中身が違っているという点です。
（比較の際の前提条件として、XOOPS2.0.13aでセッションの設定をカスタマイズする=はい、セッションクッキー名を変更）
快調な方は、_SERVER["HTTP_COOKIE"]の値：変更後のセッションクッキー名＝*****・・・
不調な方は、値がPHPSESSID=hoge; locale=ja-JP; セッションクッキー名=fuga と、
やたら長いとか、PHPSESSIDのみとかでした。
コレって、何か関係ありますか？(´(･)｀)
複数のレンタルサーバ（とｐｈｐのバージョン）で、同様の症状を体験中です（汗
・Limeplan（ｐｈｐ4.1.2）
・クララオンラインVPS Demi（php4.3.2）
特にクララVPSが不思議ちゃんで、自分の放置サイトのほか4件借りており、
最近立て続けに借りた2件のうちの片方に症状が出ております。
http.confとphp.iniと.htaccessはどちらも同一にしてみましたが、
症状は変化ナシです。
LimeplanとクララVPSの3件のphpinfo()を見比べてみて気づいたのは、
PHP Variablesの_SERVER["HTTP_COOKIE"]の中身が違っているという点です。
（比較の際の前提条件として、XOOPS2.0.13aでセッションの設定をカスタマイズする=はい、セッションクッキー名を変更）
快調な方は、_SERVER["HTTP_COOKIE"]の値：変更後のセッションクッキー名＝*****・・・
不調な方は、値がPHPSESSID=hoge; locale=ja-JP; セッションクッキー名=fuga と、
やたら長いとか、PHPSESSIDのみとかでした。
コレって、何か関係ありますか？(´(･)｀)
Votes:16
Average:3.75
yono
Posts: 9
Posts: 9
yonoです。すっかりご連絡が遅れて申し訳ありません。
前のレスで書いた「別の問題（CBB1.16で、アップロードした添付ファイルをダウンロードすると破損してしまう）」が後を引いており、（タナボタですが）クライアントの了承を得て、先日すべてのファイルの再アップロードを行いました。
（データベースは残したまま、ローカルにすべて新しくダウンロードしなおしたファイルで同じ構成を作り直し、一旦サーバ上のすべてのファイルを削除した上で再アップロード…という手順です）
結果なのですが…
百発百中で「Invalid Session」が出るようになってしまいました…(^^ゞ
（
今まではエラーの出ていなかった（と、思われる）TinyDでも、SPAWをコンポーネントとして利用できるBlueMoonさんの「news+Embed」(Ver1.4)でも、ほぼ１００％の確率で「Invalid Session」エラーが出てしまいます。
で、改めて調べて見ました。
すると、 nobunobuさんののところ(wordpressモジュールのユーザーさん）でも同様の現象が一部で起こっているらしく、問い合わせのスレッドにnobunobuさんからこのような返信がされていました。
Quote:
試しにBlocks Adminモジュールで「SPAW」を利用したカスタムブロックの編集を行う際、上記の手順で編集を行ってみました。
短時間のテストではあり、ハッキリと確証は持てないのですが、この方法だとエラーは発生せず、とりあえず編集作業は完了します。
（暫定的に、一度試してみてはいかがでしょう？ ＞ Grizzlyさん）
ともあれ、実際にSPAWを（ニュース記事の投稿やブロックの編集など、限られた権限で）使うクライアント側に、余りパソコン慣れしていない人が多いため、できることならグラフィカルな環境を提供したいとこ（しかも、そういう方々は「余計なひと手間」を、とても嫌がりそうなので(^^ゞ）なので、もうしばらく調べてみたいと思います。
結果がわかり次第、またレスします。
前のレスで書いた「別の問題（CBB1.16で、アップロードした添付ファイルをダウンロードすると破損してしまう）」が後を引いており、（タナボタですが）クライアントの了承を得て、先日すべてのファイルの再アップロードを行いました。
（データベースは残したまま、ローカルにすべて新しくダウンロードしなおしたファイルで同じ構成を作り直し、一旦サーバ上のすべてのファイルを削除した上で再アップロード…という手順です）
結果なのですが…
百発百中で「Invalid Session」が出るようになってしまいました…(^^ゞ
（
今まではエラーの出ていなかった（と、思われる）TinyDでも、SPAWをコンポーネントとして利用できるBlueMoonさんの「news+Embed」(Ver1.4)でも、ほぼ１００％の確率で「Invalid Session」エラーが出てしまいます。
で、改めて調べて見ました。
すると、 nobunobuさんののところ(wordpressモジュールのユーザーさん）でも同様の現象が一部で起こっているらしく、問い合わせのスレッドにnobunobuさんからこのような返信がされていました。
Quote:
ブラウザによって、フォームがキャッシュに残ってしまって0.5.0以降で
取り込んだTicketシステムがうまく動かない場合があるみたいです。
出来れば、投稿フォームを開いた後に一度リロードボタンを押してから、
記事を書いて書き出しボタンを押すようにしてみて下さいませんでしょうか？
試しにBlocks Adminモジュールで「SPAW」を利用したカスタムブロックの編集を行う際、上記の手順で編集を行ってみました。
短時間のテストではあり、ハッキリと確証は持てないのですが、この方法だとエラーは発生せず、とりあえず編集作業は完了します。
（暫定的に、一度試してみてはいかがでしょう？ ＞ Grizzlyさん）
ともあれ、実際にSPAWを（ニュース記事の投稿やブロックの編集など、限られた権限で）使うクライアント側に、余りパソコン慣れしていない人が多いため、できることならグラフィカルな環境を提供したいとこ（しかも、そういう方々は「余計なひと手間」を、とても嫌がりそうなので(^^ゞ）なので、もうしばらく調べてみたいと思います。
結果がわかり次第、またレスします。
Votes:9
Average:1.11
yono
Posts: 9
Posts: 9
ふと思い立って、ブラウザのキャッシュ設定を弄ってみました。
IE6:「インターネットオプション」−＞「インターネット一時ファイル」の「設定」ー＞「保存しているページの新しいバージョンの確認」
値を「自動的に確認する」から「ページを表示するごとに確認する」に変更。
firefox1.5:pref.jsの「browser.cache.disk.enable」を「false」に変更。
（いずれもWinの場合）
元々、キャッシュ値を「1MB(IE)」「0(firefox)」に設定していたため、キャッシュ容量の問題ではなく、機能そのものを殺すか、バイパスさせてやる必要があったようです。
上記設定で、とりあえず問題が出ないようになりました。
なので、クライアントには環境を上記で統一してもらう様マニュアルを作成して対応しようと思います。
しかしながら、なぜ「設置したサーバによって挙動が異なり、（ブラウザ側の設定が同一で）エラーが発生するサーバとしないサーバがあるのか？」についての疑問は残っています。
PHP、サーバ構築ともお恥ずかしいことに「ド」がつく素人なのですが、非常に興味が湧いてきました。
どちらも勉強はこれからなので、解決策をご提供できるかどうかは不明（他のヒントも含め、すべて出揃ってしまえば皆さんの方が早いかも
）ですが、出来る限り調べてみたいと思います。
逆に、何か調べる必要があれば、いつでも調べます。
必要があれば、レス下さい。
（なにせブラウザの設定を元に戻せばエラーが起こる環境は丸のまま残っているので(笑)）
ともあれ、とりあえずのご報告まで。
p.s.
Grizzlyさんのマシンでも、ぜひ上記の設定を試してみていただけないでしょうか？
それでどのような結果があるか、という事については、非常に興味があります。
不躾なお願いで申し訳ありません。
IE6:「インターネットオプション」−＞「インターネット一時ファイル」の「設定」ー＞「保存しているページの新しいバージョンの確認」
値を「自動的に確認する」から「ページを表示するごとに確認する」に変更。
firefox1.5:pref.jsの「browser.cache.disk.enable」を「false」に変更。
（いずれもWinの場合）
元々、キャッシュ値を「1MB(IE)」「0(firefox)」に設定していたため、キャッシュ容量の問題ではなく、機能そのものを殺すか、バイパスさせてやる必要があったようです。
上記設定で、とりあえず問題が出ないようになりました。
なので、クライアントには環境を上記で統一してもらう様マニュアルを作成して対応しようと思います。
しかしながら、なぜ「設置したサーバによって挙動が異なり、（ブラウザ側の設定が同一で）エラーが発生するサーバとしないサーバがあるのか？」についての疑問は残っています。
PHP、サーバ構築ともお恥ずかしいことに「ド」がつく素人なのですが、非常に興味が湧いてきました。
どちらも勉強はこれからなので、解決策をご提供できるかどうかは不明（他のヒントも含め、すべて出揃ってしまえば皆さんの方が早いかも
）ですが、出来る限り調べてみたいと思います。逆に、何か調べる必要があれば、いつでも調べます。
必要があれば、レス下さい。
（なにせブラウザの設定を元に戻せばエラーが起こる環境は丸のまま残っているので(笑)）
ともあれ、とりあえずのご報告まで。
p.s.
Grizzlyさんのマシンでも、ぜひ上記の設定を試してみていただけないでしょうか？
それでどのような結果があるか、という事については、非常に興味があります。
不躾なお願いで申し訳ありません。
Votes:2
Average:0.00
GIJOE
Posts: 4110
Posts: 4110
yonoさん、こんにちは。
私自身、再現ができなくてなんともアドバイスができず心苦しいのですが、キャッシュというのはありそうです。
ホスティングサービス会社によって結果が異なるのだとすれば、HTTPレスポンスヘッダをまずは確認してみてはいかがでしょう。
Firefoxをご利用であれば、WebDeveloper拡張（0.9.4日本語版がおすすめ）を入れて、情報->HTTPレスポンスヘッダーで表示してみてください。
私自身、再現ができなくてなんともアドバイスができず心苦しいのですが、キャッシュというのはありそうです。
ホスティングサービス会社によって結果が異なるのだとすれば、HTTPレスポンスヘッダをまずは確認してみてはいかがでしょう。
Firefoxをご利用であれば、WebDeveloper拡張（0.9.4日本語版がおすすめ）を入れて、情報->HTTPレスポンスヘッダーで表示してみてください。
Votes:1
Average:0.00
Grizzly
Posts: 11
Posts: 11
Quote:
yonoさん、 偉 い ！！
カスタムブロックの編集とtinyDコンテンツ編集で試したところ、
症状は見事に改善しました！
＃これでお客さんに「Griちゃん、エ ロ い ！」って褒めてもらえそう（笑
では、引き続きFirefoxでの挙動と、HTTPレスポンスヘッダについて
調査してみます〃∠(´(・)｀；)
元々、キャッシュ値を「1MB(IE)」「0(firefox)」に設定していたため、キャッシュ容量の問題ではなく、機能そのものを殺すか、バイパスさせてやる必要があったようです。
上記設定で、とりあえず問題が出ないようになりました。
yonoさん、 偉 い ！！
カスタムブロックの編集とtinyDコンテンツ編集で試したところ、
症状は見事に改善しました！
＃これでお客さんに「Griちゃん、エ ロ い ！」って褒めてもらえそう（笑
では、引き続きFirefoxでの挙動と、HTTPレスポンスヘッダについて
調査してみます〃∠(´(・)｀；)
Votes:13
Average:4.62
Grizzly
Posts: 11
Posts: 11
HTTPレスポンスヘッダー、点検してみました！
２軒ともほぼ同じ時期にクララオンラインVPSに申し込み、
似たようなモジュール構成のWebサイトを比較してみました。
どちらもカスタムブロックの編集でSPAWを選択後のページにて
HTTPレスポンスヘッダーを表示させ、比較してみました。
・・・コレといって違いが見当たりませんでした。。
yonoさんのほうでは、いかがでしたか？
２軒ともほぼ同じ時期にクララオンラインVPSに申し込み、
似たようなモジュール構成のWebサイトを比較してみました。
どちらもカスタムブロックの編集でSPAWを選択後のページにて
HTTPレスポンスヘッダーを表示させ、比較してみました。
・・・コレといって違いが見当たりませんでした。。
yonoさんのほうでは、いかがでしたか？
Votes:14
Average:4.29
yono
Posts: 9
Posts: 9
GIJOEさん、Grizzlyさん、レス有難うございます。
>yonoさん、 偉 い ！！
いや、nobunobuさんのところにヒントが転がっていたのに、そこを調べていなかったのは…お恥ずかしい限りです
別サイトでwordpressモジュールを使っていて、しかもnobunobuさんの手も入っているSPAWの話なのに…(^^ゞ
感謝は、nobunobuさんに…
ただこの設定、「ケータイでのデータ通信しか環境のない出先でメンテナンスをしなければいけない管理者」（具体的にトラブルの起きてるサイトを管理するクライアントの担当者がかなりそれに該当するのですが(笑)）にとっては、パケ代が嵩んで痛い設定ではあります。
なによりごく稀に同様のケースが発生しており、もしこれがきっかけで解決の糸口がみつかるのであれば、一ユーザーとしてもとても嬉しかったりします。
で、早速ＨＴＴＰレスポンスヘッダ、見てみました。
複数のサイト（XOOPSのモジュール構成などはまちまちなまま）について確認をしています。
WADAX(Apache1.3.34、PHP4.4.1、mod_ssl/2.8.25 OpenSSL/0.9.7i)＜＝エラーの確立高め
ハッスルサーバー（Apache1.3.34 PHP4.4.1）＜＝エラー発生率５０％くらい？）
ロリポップ（Apacheバージョン不明、PHP4.3.11）＜＝エラー発生せず
…多分チェックしなければいけないのは「Cache-Control」の部分と「Pragma」の部分（これはまだHTTPヘッダの中で指定できたのですよね？確か）なのだろうと思いますが、すべてのサーバーで同じ値でした(x_x)
ただ、気になるところがひとつ。
このサイト(www.peak.ne.jp/xoops)のＨＴＴＰレスポンスヘッダと上記三サイトのそれは、異なっていました。
（もちろん、このサイトのSPAWを確認したわけではありませんでした）
恐らくphp.iniの「session.cache_limiter」値だと思いますが、初期設定では「nocache」ですよね？
大半のサーバでは初期設定のままですが、ここを「Private」に変更したりすると、効果があったりするのでしょうか？
ごめんなさい。今日はもう無理そう(Zzz...)なので、明日の晩にでも試してみます。
が、もし推測が間違っているようであればご指摘下さい。
（あ、あと記述に公表したらマズい部分などあったら、書き込みを気にせず削除してください。不慣れでごめんなさい。）
>yonoさん、 偉 い ！！
いや、nobunobuさんのところにヒントが転がっていたのに、そこを調べていなかったのは…お恥ずかしい限りです
別サイトでwordpressモジュールを使っていて、しかもnobunobuさんの手も入っているSPAWの話なのに…(^^ゞ
感謝は、nobunobuさんに…
ただこの設定、「ケータイでのデータ通信しか環境のない出先でメンテナンスをしなければいけない管理者」（具体的にトラブルの起きてるサイトを管理するクライアントの担当者がかなりそれに該当するのですが(笑)）にとっては、パケ代が嵩んで痛い設定ではあります。
なによりごく稀に同様のケースが発生しており、もしこれがきっかけで解決の糸口がみつかるのであれば、一ユーザーとしてもとても嬉しかったりします。
で、早速ＨＴＴＰレスポンスヘッダ、見てみました。
複数のサイト（XOOPSのモジュール構成などはまちまちなまま）について確認をしています。
WADAX(Apache1.3.34、PHP4.4.1、mod_ssl/2.8.25 OpenSSL/0.9.7i)＜＝エラーの確立高め
ハッスルサーバー（Apache1.3.34 PHP4.4.1）＜＝エラー発生率５０％くらい？）
ロリポップ（Apacheバージョン不明、PHP4.3.11）＜＝エラー発生せず
…多分チェックしなければいけないのは「Cache-Control」の部分と「Pragma」の部分（これはまだHTTPヘッダの中で指定できたのですよね？確か）なのだろうと思いますが、すべてのサーバーで同じ値でした(x_x)
ただ、気になるところがひとつ。
このサイト(www.peak.ne.jp/xoops)のＨＴＴＰレスポンスヘッダと上記三サイトのそれは、異なっていました。
（もちろん、このサイトのSPAWを確認したわけではありませんでした）
恐らくphp.iniの「session.cache_limiter」値だと思いますが、初期設定では「nocache」ですよね？
大半のサーバでは初期設定のままですが、ここを「Private」に変更したりすると、効果があったりするのでしょうか？
ごめんなさい。今日はもう無理そう(Zzz...)なので、明日の晩にでも試してみます。
が、もし推測が間違っているようであればご指摘下さい。
（あ、あと記述に公表したらマズい部分などあったら、書き込みを気にせず削除してください。不慣れでごめんなさい。）
Votes:19
Average:2.63
yono
Posts: 9
Posts: 9
自己レスです。
早速上記の変更をＷＡＤＡＸで行ってみました。
一応WADAXで上記設定変更を行い、IEの設定を元に戻した上で改めてSPAWの操作をしてみたところ、IE6(WinXP)では問題なく更新が行えるようになりました。
ただし、如何せん短時間での作業のため、確証は持てません。
一応、上記の方法をたどり着くために、調べた上で導き出した仮説なのですが…
こちらのなんか適当なサイトさんに、
Quote:
という記述を見つけたことにヒントを得ています。
ただ「なぜそうなのか？」について色々ググってみたのですが、短時間でもあり、キーワードが思わしくないのか、イマイチ的を得た答にたどり着けません。
また、同じ「nocache」の設定になっている複数のサーバーで、現象が異なっている理由も、上記引用文だけでは導き出すことが出来ません。
個人的には「（ネットワーク上の）中継点にあるプロキシサーバ（あるいはキャッシュサーバ）に問題があるのではないか？などと考えてみたりしました。
PHPマニュアルの記述を見ている限り、「nocache」の設定にしておけばローカル、プロキシのいずれにもキャッシュを残さないことになっているはずですが、何らかの拍子に「SPAW」部分のみ「（プロキシサーバなどに）残されたキャッシュ」を参照してしまい（あるいはその逆に「SPAW」部分のみをリロードしてしまい）、セッションが途切れてしまっているのではないか？と。
「Invalid Session」エラーのケースもさまざまなようで、必ずしも特定のサーバに依存するものではなさそうですし、特定のＰＣ環境に依存するものでもなさそうです。
私の場合「特定のサーバでのみ、複数のＰＣ環境で」でしたし、探ってみた中には「（自宅サーバ環境で）自宅以外のＰＣからの編集の場合のみ」という方もいらっしゃいました。（これは微妙にケースが異なるのかもしれませんが）
セッションの連続性、サーバの挙動など、（前述の通り）あまり詳しくないので、極端に的外れな指摘をしているのかもしれません。
session.cache_limiter = nocache の場合でもキャッシュしてしまうプロキシが（問題発生点に経路的に近い場所に）存在する…などという事があるのかどうか？なんてのが焦点だったりする気もします。
ちなみに、上記PHPマニュアルの解説ページに、
Quote:
ので、session.cache_limiter の値は「private」ではなく「private_no_expire」の方が恐らく良いのでしょう。
いずれにしてもウチのfirefox1.5では、キャッシュの設定を「有効」に戻してしまうとSPAWの部分のみ表示されない…ということが（サーバに関係なく）頻発するので、これを機にキャッシュ設定を「無効」のままにしてあります(^^ゞ
ので、session.cache_limiter = private_no_expire」が有効な設定なのかどうかは、正直わかりませんm(___)m
ローカルにキャッシュが残ってしまう…というのも、(XOOPS本体の)動作上の問題、リスクの両面から気になるところではありますが…
ともあれ、
session.cache_limiter = private
の設定のまま、複数の環境で試してみたいと思います。
（金曜日に件のクライアントを訪問する予定があるので、そちらでもチェックしてみたいと思っています）
追記：
今日、勢い余って自分のメインマシンに、公開されたばかりのIE7 Public Betaをインストールしてしまいました。
（そういうことには滅法目のないもので…(^^ゞ）
従って、上記テストはメインマシンのIE7betaと、サブマシン(WinXP)のIE6の両方で行っています。
とりあえずどちらの環境でも編集は正常に出来ています。
ちょくちょくフリーズしたり、描画が恐ろしく遅かったり、不安定な環境でのテストではありますが…(^^ゞ(^^ゞ
追記も含め、長文大変失礼しましたm(___)m
早速上記の変更をＷＡＤＡＸで行ってみました。
一応WADAXで上記設定変更を行い、IEの設定を元に戻した上で改めてSPAWの操作をしてみたところ、IE6(WinXP)では問題なく更新が行えるようになりました。
ただし、如何せん短時間での作業のため、確証は持てません。
一応、上記の方法をたどり着くために、調べた上で導き出した仮説なのですが…
こちらのなんか適当なサイトさんに、
Quote:
session.cache_limiter = nocache の場合(デフォルト値)、IE5.01 とかだと SESSION+POST の場合にキャッシュまわりが奇妙な動作になるんで、session.cache_limiter = private にしとく必要がある(public の場合、プロキシでのキャッシュ対象になってしまう)。
という記述を見つけたことにヒントを得ています。
ただ「なぜそうなのか？」について色々ググってみたのですが、短時間でもあり、キーワードが思わしくないのか、イマイチ的を得た答にたどり着けません。
また、同じ「nocache」の設定になっている複数のサーバーで、現象が異なっている理由も、上記引用文だけでは導き出すことが出来ません。
個人的には「（ネットワーク上の）中継点にあるプロキシサーバ（あるいはキャッシュサーバ）に問題があるのではないか？などと考えてみたりしました。
PHPマニュアルの記述を見ている限り、「nocache」の設定にしておけばローカル、プロキシのいずれにもキャッシュを残さないことになっているはずですが、何らかの拍子に「SPAW」部分のみ「（プロキシサーバなどに）残されたキャッシュ」を参照してしまい（あるいはその逆に「SPAW」部分のみをリロードしてしまい）、セッションが途切れてしまっているのではないか？と。
「Invalid Session」エラーのケースもさまざまなようで、必ずしも特定のサーバに依存するものではなさそうですし、特定のＰＣ環境に依存するものでもなさそうです。
私の場合「特定のサーバでのみ、複数のＰＣ環境で」でしたし、探ってみた中には「（自宅サーバ環境で）自宅以外のＰＣからの編集の場合のみ」という方もいらっしゃいました。（これは微妙にケースが異なるのかもしれませんが）
セッションの連続性、サーバの挙動など、（前述の通り）あまり詳しくないので、極端に的外れな指摘をしているのかもしれません。
session.cache_limiter = nocache の場合でもキャッシュしてしまうプロキシが（問題発生点に経路的に近い場所に）存在する…などという事があるのかどうか？なんてのが焦点だったりする気もします。
ちなみに、上記PHPマニュアルの解説ページに、
Quote:
privateモードにおいて、Expireヘッダがクライア ントに送信されます。これは、Mozillaのようないくつかのブラウザを混 乱させます。これを避けるには、 private_no_expireモードを使用してください。 このモードでは、Expireヘッダはクライアントに送信されません。
ので、session.cache_limiter の値は「private」ではなく「private_no_expire」の方が恐らく良いのでしょう。
いずれにしてもウチのfirefox1.5では、キャッシュの設定を「有効」に戻してしまうとSPAWの部分のみ表示されない…ということが（サーバに関係なく）頻発するので、これを機にキャッシュ設定を「無効」のままにしてあります(^^ゞ
ので、session.cache_limiter = private_no_expire」が有効な設定なのかどうかは、正直わかりませんm(___)m
ローカルにキャッシュが残ってしまう…というのも、(XOOPS本体の)動作上の問題、リスクの両面から気になるところではありますが…
ともあれ、
session.cache_limiter = private
の設定のまま、複数の環境で試してみたいと思います。
（金曜日に件のクライアントを訪問する予定があるので、そちらでもチェックしてみたいと思っています）
追記：
今日、勢い余って自分のメインマシンに、公開されたばかりのIE7 Public Betaをインストールしてしまいました。
（そういうことには滅法目のないもので…(^^ゞ）
従って、上記テストはメインマシンのIE7betaと、サブマシン(WinXP)のIE6の両方で行っています。
とりあえずどちらの環境でも編集は正常に出来ています。
ちょくちょくフリーズしたり、描画が恐ろしく遅かったり、不安定な環境でのテストではありますが…(^^ゞ(^^ゞ
追記も含め、長文大変失礼しましたm(___)m
Votes:10
Average:8.00
GIJOE
Posts: 4110
Posts: 4110
う〜ん、難しいですね。
その「同じレスポンスヘッダ」は実際にどうなっていますか？
Pragma
Expires
Cache-Control
ETag
Last-Modified
あたりの関係ありそうなヘッダを実際に書いていただく方が早いと思います。
IEの「自動的に確認する」っていうのは、過去に取得したキャッシュのETagとかLast-Modifiedあたりで判断しているんでしょうか。
「表示する毎に確認する」というのは、おそらく先にHEADメソッドで、ETagとかLast-Modifiedを取得して、キャッシュ内容と比較する、という方法でしょうから、おそらく遠くはないと思います。
とすれば、やはり通常のページにおけるレスポンスヘッダをじっくり比較するのが一番、ってことになりそうです。
その「同じレスポンスヘッダ」は実際にどうなっていますか？
Pragma
Expires
Cache-Control
ETag
Last-Modified
あたりの関係ありそうなヘッダを実際に書いていただく方が早いと思います。
IEの「自動的に確認する」っていうのは、過去に取得したキャッシュのETagとかLast-Modifiedあたりで判断しているんでしょうか。
「表示する毎に確認する」というのは、おそらく先にHEADメソッドで、ETagとかLast-Modifiedを取得して、キャッシュ内容と比較する、という方法でしょうから、おそらく遠くはないと思います。
とすれば、やはり通常のページにおけるレスポンスヘッダをじっくり比較するのが一番、ってことになりそうです。
Votes:14
Average:4.29
Grizzly
Posts: 11
Posts: 11
GIJOEさん、こんちクマ(´(・)｀)ノ
HTTPレスポンスヘッダーを貼り付けちゃいます。
どちらもクララオンラインさんのVPSです。
＃php.iniとhttpd.confの設定は今回の症状が出てないほうに揃えたつもりです。。
Quote:
Quote:
HTTPレスポンスヘッダーを貼り付けちゃいます。
どちらもクララオンラインさんのVPSです。
＃php.iniとhttpd.confの設定は今回の症状が出てないほうに揃えたつもりです。。
Quote:
HTTPレスポンスヘッダー情報 - http://www.******.com/modules/blocksadmin/admin/admin.php?fct=blocksadmin&op=edit&bid=78&...
Date: Sat, 04 Feb 2006 06:58:10 GMT
Server: Apache/2.0.46 (Red Hat)
Accept-Ranges: bytes
X-Powered-By: PHP/4.3.2
Set-Cookie: PHPSESSID=**********; path=/
***_session=**********; expires=Sat, 04-Feb-2006 09:58:10 GMT; path=/
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Last-Modified: Sat, 04 Feb 2006 06:58:10 GMT
Content-Encoding: gzip
Vary: Accept-Encoding
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=EUC-JP
200 OK
Quote:
HTTPレスポンスヘッダー情報 - http://www.***********.jp/modules/blocksadmin/admin/admin.php?fct=blocksadmin&op=edit&bid...
Date: Sat, 04 Feb 2006 06:58:48 GMT
Server: Apache/2.0.46 (Red Hat)
Accept-Ranges: bytes
X-Powered-By: PHP/4.3.2
Set-Cookie: PHPSESSID=**********; path=/
*****_session=**********; expires=Sat, 04-Feb-2006 09:58:48 GMT; path=/
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Last-Modified: Sat, 04 Feb 2006 06:58:48 GMT
Content-Encoding: gzip
Vary: Accept-Encoding
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=EUC-JP
200 OK
Votes:20
Average:0.00
GIJOE
Posts: 4110
Posts: 4110
Grizzlyさん、こんにちは。
えっと、この２つって、どちらもおかしい方ですよね？
おかしくならない方のレスポンスヘッダはありませんか？
クライアントの設定もからむので、同一クライアントで、おかしいものとおかしくないものの比較が出来れば最善です。
えっと、この２つって、どちらもおかしい方ですよね？
おかしくならない方のレスポンスヘッダはありませんか？
クライアントの設定もからむので、同一クライアントで、おかしいものとおかしくないものの比較が出来れば最善です。
Votes:8
Average:1.25
Grizzly
Posts: 11
Posts: 11
GIJOEさん、こんちクマ(´(・)｀)ノ
えっと〜 下のほうが症状有りのほうです。。
Firefox/1.5.0.1 ＋ Web Developer日本語版1.0にてHTTPレスポンスヘッダーを確認しました。
あとで、他の順調なサイトのHTTPレスポンスヘッダーを確認してみます。。
えっと〜 下のほうが症状有りのほうです。。
Firefox/1.5.0.1 ＋ Web Developer日本語版1.0にてHTTPレスポンスヘッダーを確認しました。
あとで、他の順調なサイトのHTTPレスポンスヘッダーを確認してみます。。
Votes:7
Average:8.57
yono
Posts: 9
Posts: 9
遅くなりました。
こちらについてもレスポンスヘッダを掲載しておきます。
ハッスル（症状あり）
Date: Mon, 06 Feb 2006 08:45:01 GMT
Server: Apache/1.3.34 (Unix) mod_throttle/3.1.2
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Pragma: no-cache
X-Powered-By: PHP/4.4.1
Last-Modified: Mon, 06 Feb 2006 08:45:01 GMT
Connection: close
Content-Type: text/html; charset=EUC-JP
ＷＡＤＡＸ（症状あり）
Date: Mon, 06 Feb 2006 08:49:19 GMT
Server: Apache/1.3.34 (Unix) PHP/4.4.1 mod_ssl/2.8.25 OpenSSL/0.9.7i
X-Powered-By: PHP/4.4.1
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Last-Modified: Mon, 06 Feb 2006 08:49:19 GMT
Pragma: no-cache
Connection: close
Content-Type: text/html; charset=EUC-JP
200 OK
ロリポ（症状なし）
Date: Mon, 06 Feb 2006 08:54:09 GMT
Server: Apache
X-Powered-By: PHP/4.3.11
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Last-Modified: Mon, 06 Feb 2006 08:54:09 GMT
Connection: close
Content-Type: text/html; charset=EUC-JP
200 OK
ごめんなさい、違いがわかりませんでした(;_;)
推測そのものが間違っていたのか…(^^ゞ
（圭佐入れている情報には気を使っていますが、もしマズかったら削除してくださいm(__)m）
こちらについてもレスポンスヘッダを掲載しておきます。
ハッスル（症状あり）
Date: Mon, 06 Feb 2006 08:45:01 GMT
Server: Apache/1.3.34 (Unix) mod_throttle/3.1.2
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Pragma: no-cache
X-Powered-By: PHP/4.4.1
Last-Modified: Mon, 06 Feb 2006 08:45:01 GMT
Connection: close
Content-Type: text/html; charset=EUC-JP
ＷＡＤＡＸ（症状あり）
Date: Mon, 06 Feb 2006 08:49:19 GMT
Server: Apache/1.3.34 (Unix) PHP/4.4.1 mod_ssl/2.8.25 OpenSSL/0.9.7i
X-Powered-By: PHP/4.4.1
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Last-Modified: Mon, 06 Feb 2006 08:49:19 GMT
Pragma: no-cache
Connection: close
Content-Type: text/html; charset=EUC-JP
200 OK
ロリポ（症状なし）
Date: Mon, 06 Feb 2006 08:54:09 GMT
Server: Apache
X-Powered-By: PHP/4.3.11
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Last-Modified: Mon, 06 Feb 2006 08:54:09 GMT
Connection: close
Content-Type: text/html; charset=EUC-JP
200 OK
ごめんなさい、違いがわかりませんでした(;_;)
推測そのものが間違っていたのか…(^^ゞ
（圭佐入れている情報には気を使っていますが、もしマズかったら削除してくださいm(__)m）
Votes:11
Average:0.00
GIJOE
Posts: 4110
Posts: 4110
う〜ん。
目を皿のようにして違いを確認しましたが、どうにも違いが分からないですね。
となれば、HEADメソッドの時の反応が違うのかな？
それとも、HTTPヘッダではなく、意外にもmetaタグの中身とか。
両方のサイトのURLを公開して良ければ教えてください。
自分でHEADリクエスト送ってみます。
目を皿のようにして違いを確認しましたが、どうにも違いが分からないですね。
となれば、HEADメソッドの時の反応が違うのかな？
それとも、HTTPヘッダではなく、意外にもmetaタグの中身とか。
両方のサイトのURLを公開して良ければ教えてください。
自分でHEADリクエスト送ってみます。
Votes:7
Average:8.57
yono
Posts: 9
Posts: 9
クライアントのページなので、ちょっと公開ははばかられます(^_^;
PMでURLを送っておきます。申し訳ありません。
よろしくお願いします。
PMでURLを送っておきます。申し訳ありません。
よろしくお願いします。
Votes:7
Average:8.57
GIJOE
Posts: 4110
Posts: 4110
う〜ん。
しらべてみましたけど、表側で見ても判らないですね。
ふと思いましたが、サーバが利用しているキャッシュシステムって可能性はないですかね。
特にありがちなのは、php accelerator あたり。
それなら phpinfo(); で確認できるはずです。
あとは、もう少しApacheに近い層でのキャッシュシステムとか。
（具体名は挙がりませんが）
しらべてみましたけど、表側で見ても判らないですね。
ふと思いましたが、サーバが利用しているキャッシュシステムって可能性はないですかね。
特にありがちなのは、php accelerator あたり。
それなら phpinfo(); で確認できるはずです。
あとは、もう少しApacheに近い層でのキャッシュシステムとか。
（具体名は挙がりませんが）
Votes:1
Average:0.00
GIJOE
Posts: 4110
Posts: 4110
blocksadminのSPAW編集でまれにInvalid Sessionになってしまう件ですが…
原因不明のまま、いつまでもズルズルというのは、私自身が気持ち悪いので、一念発起して、GTicketクラスに、再投稿システムを実装してみました。
最新版のblocksadminにバージョンを上げてください。
同じ環境で動作させている人なら、同じくらいの確率でInvalid Sessionが出てしまうでしょうが、その場合でも再投稿フォームが出るので、再投稿ボタンを押せばOKです。
もし、それでも投稿できないケースでも、送信したデータは表示されているので、そこをコピペすることで、編集結果をロストすることだけは最悪防げます。
一度お試しください。
原因不明のまま、いつまでもズルズルというのは、私自身が気持ち悪いので、一念発起して、GTicketクラスに、再投稿システムを実装してみました。
最新版のblocksadminにバージョンを上げてください。
同じ環境で動作させている人なら、同じくらいの確率でInvalid Sessionが出てしまうでしょうが、その場合でも再投稿フォームが出るので、再投稿ボタンを押せばOKです。
もし、それでも投稿できないケースでも、送信したデータは表示されているので、そこをコピペすることで、編集結果をロストすることだけは最悪防げます。
一度お試しください。
Votes:9
Average:7.78
Grizzly
Posts: 11
Posts: 11
すっかりご報告が遅くなってしまい、失礼致しました。
Gticket2、サイコーに調子いいです！
ところでこのGticket2は、他の初代Gticket採用のモジュールでも
置換が可能なんでしょうか？
Gticket2、サイコーに調子いいです！
ところでこのGticket2は、他の初代Gticket採用のモジュールでも
置換が可能なんでしょうか？
Votes:13
Average:0.00
Previous post
-
Next post
|
Parent
-
No child
|
Posted on 2006/6/11 4:54
GIJOE
Posts: 4110
Posts: 4110
報告ありがとうございます。
Quote:ということは、実際に再投稿画面が出ているんですね？
何が原因かは結局判りませんでしたが、とりあえず対処できていたことにほっとしました。
Quote:一応、完全互換なので、単に上書きしていただければ、再投稿機能がつきます。
具体的にはTinyDとかでしょうか。
Quote:
Gticket2、サイコーに調子いいです！
何が原因かは結局判りませんでしたが、とりあえず対処できていたことにほっとしました。
Quote:
ところでこのGticket2は、他の初代Gticket採用のモジュールでも
置換が可能なんでしょうか？
具体的にはTinyDとかでしょうか。
Votes:7
Average:8.57
Login