PEAK XOOPS - Feedback for pico 1.16 
Feedback for pico 1.16
- You cannot open a new topic into this forum
- Guests cannot post into this forum
Previous post
-
Next post
|
Parent
-
Children.1
|
Posted on 2007/3/21 0:43
starck
Posts: 42
Posts: 42
GIJOEさん、こんにちは。
1.16をテストしました。
環境：
SERVER : Apache
PHP : 4.3.11
register_globals =
MySQL : 4.0.24-standard-log
XOOPS : XOOPS 2.0.16a JP
Theme : default
Quote:これなんですが、確か1.15のときは履歴の「参照する」機能は、ブラウザ上に内容を直接表示していた思うのですが、1.16では、txtファイルのダウンロードになってしまうようです。
※IE（6）のみ。Firefoxでは、問題なし。
ご確認お願いします。
＃履歴比較機能、いいですね〜〜これ。
ソースが横に長いとき見にくくなるので、body部分に関しては</del>の後、改行されると良いような。ご検討お願いします。
1.16をテストしました。
環境：
SERVER : Apache
PHP : 4.3.11
register_globals =
MySQL : 4.0.24-standard-log
XOOPS : XOOPS 2.0.16a JP
Theme : default
Quote:
ヒストリ参照機能の改善(IE対策)
※IE（6）のみ。Firefoxでは、問題なし。
ご確認お願いします。
＃履歴比較機能、いいですね〜〜これ。
ソースが横に長いとき見にくくなるので、body部分に関しては</del>の後、改行されると良いような。ご検討お願いします。
Votes:4
Average:10.00
GIJOE
Posts: 4110
Posts: 4110
Quote:いやあ、これ、まさにIE対策なんですよ。
IEって本当にお馬鹿なブラウザで、Content-Typeでtext/plainを送っていても、中身がHTMLっぽかったら、text/html だと解釈して表示しちゃいます。
それだと、JavaScriptか何かを記述しているコンテンツで酷いことになりかねません。
htmlspecialchars() をかけて、text/html で送る、というのも手ですが、それだと今度は、単純な生テキストとしての保存がとても面倒になります。テキストエディタやgrep・diffなどのツールを使うなら、生テキストがベストですから。
というわけで、IEについては、Content-Disposition: attachment をつけて、ダウンロードさせるようにしてます。それ以外のまともなブラウザについては、素直にtext/plainで生テキストで送出してます。
Quote:</del>の直後に<br />を入れる、というだけなら簡単ですが、出来れば、テキストソースそのものはいじりたくないですね。
スタイルだけでは無理でしょうか。
Quote:これなんですが、確か1.15のときは履歴の「参照する」機能は、ブラウザ上に内容を直接表示していた思うのですが、1.16では、txtファイルのダウンロードになってしまうようです。ヒストリ参照機能の改善(IE対策)
※IE（6）のみ。Firefoxでは、問題なし。
IEって本当にお馬鹿なブラウザで、Content-Typeでtext/plainを送っていても、中身がHTMLっぽかったら、text/html だと解釈して表示しちゃいます。
それだと、JavaScriptか何かを記述しているコンテンツで酷いことになりかねません。
htmlspecialchars() をかけて、text/html で送る、というのも手ですが、それだと今度は、単純な生テキストとしての保存がとても面倒になります。テキストエディタやgrep・diffなどのツールを使うなら、生テキストがベストですから。
というわけで、IEについては、Content-Disposition: attachment をつけて、ダウンロードさせるようにしてます。それ以外のまともなブラウザについては、素直にtext/plainで生テキストで送出してます。
Quote:
＃履歴比較機能、いいですね〜〜これ。
ソースが横に長いとき見にくくなるので、body部分に関しては</del>の後、改行されると良いような。ご検討お願いします。
スタイルだけでは無理でしょうか。
Votes:0
Average:0.00
starck
Posts: 42
Posts: 42
Quote:なるほどー。まさかと思ったのですが、おもいっきり外してしまいました。
ごめんなさい。
Quote:
そうでした。履歴比較機能はHTML出力ですね・・・。
display:blockとかで解決できますね。続け様、失礼しました。
というわけで、IEについては、Content-Disposition: attachment をつけて、ダウンロードさせるようにしてます。それ以外のまともなブラウザについては、素直にtext/plainで生テキストで送出してます。
ごめんなさい。
Quote:
</del>の直後に<br />を入れる、というだけなら簡単ですが、出来れば、テキストソースそのものはいじりたくないですね。
スタイルだけでは無理でしょうか。
そうでした。履歴比較機能はHTML出力ですね・・・。
display:blockとかで解決できますね。続け様、失礼しました。
Votes:0
Average:0.00
GIJOE
Posts: 4110
Posts: 4110
Quote:いえ、starckさんでさえ、アレっと思うってことは、やっぱりあまり自然な動作じゃないってことですよね。
確かに、HTTP_USER_AGENTでの振り分けって、いろんな意味でスマートじゃありません。
というわけで、「参照する」と「ダウンロード」を分けてみました。
前者はtext/htmlでinline、後者はtext/plainでattachmentです。
リンクが無駄に多くなるのはナニですが、これが表示されるのも編集画面か管理画面だけなので、クローラーも来ないし、それならいいかな、と。
なるほどー。まさかと思ったのですが、おもいっきり外してしまいました。
ごめんなさい。
確かに、HTTP_USER_AGENTでの振り分けって、いろんな意味でスマートじゃありません。
というわけで、「参照する」と「ダウンロード」を分けてみました。
前者はtext/htmlでinline、後者はtext/plainでattachmentです。
リンクが無駄に多くなるのはナニですが、これが表示されるのも編集画面か管理画面だけなので、クローラーも来ないし、それならいいかな、と。
Votes:0
Average:0.00
starck
Posts: 42
Posts: 42
Quote:GIJOEさん、ありがとうございます。
やっぱり、どのブラウザでも操作が同じなのが嬉しいです。最近、IEとFFを使う割合が同じくらいになってきましたし。
別なフィードバックになりますが、最近手近なサイトをpicoでおきかえる作業を始めたのですが、どうしてもレイアウトが崩れるページがあり、しばらく格闘？していました。
原因がやっとわかって、少し面食らったのですが、
・ページのバイト数が元々40kbyteを超えていた
・部分的にテーブルが3重にもなっているお行儀の悪いHTMLだったので
、fckeditorのソース整形機能も相まってtotalで65535byteを超えていた
という状況でした。
htmlを少し書き直したら、30kbyteくらいになったのでとりあえず回避は出来たのですが、ページの保存時に（容量を超えてしまう場合は）byte数についての警告が出たら良いなと思いました。
（フィールドタイプをmediumtextに換えるというのもちょっとやってみましたが、怖いので元に戻しちゃいました）
というわけで、「参照する」と「ダウンロード」を分けてみました。
前者はtext/htmlでinline、後者はtext/plainでattachmentです。
やっぱり、どのブラウザでも操作が同じなのが嬉しいです。最近、IEとFFを使う割合が同じくらいになってきましたし。
別なフィードバックになりますが、最近手近なサイトをpicoでおきかえる作業を始めたのですが、どうしてもレイアウトが崩れるページがあり、しばらく格闘？していました。
原因がやっとわかって、少し面食らったのですが、
・ページのバイト数が元々40kbyteを超えていた
・部分的にテーブルが3重にもなっているお行儀の悪いHTMLだったので
、fckeditorのソース整形機能も相まってtotalで65535byteを超えていたという状況でした。
htmlを少し書き直したら、30kbyteくらいになったのでとりあえず回避は出来たのですが、ページの保存時に（容量を超えてしまう場合は）byte数についての警告が出たら良いなと思いました。
（フィールドタイプをmediumtextに換えるというのもちょっとやってみましたが、怖いので元に戻しちゃいました）
Votes:0
Average:0.00
GIJOE
Posts: 4110
Posts: 4110
starck さん、こんにちは。
Quote:読んだ瞬間、「しまった〜」と心の中で叫んでしまいました。
本文に64Kbyteで制限がかかるなんて方がおかしいので、当然、mediumtextにするべき局面でした。
実際のところ「基本設計」こそがpicoの自慢だっただけに…
さっそくモジュールアーカイブは修正しましたが、1.0->1.1/1.2へのアップグレード処理で、mediumtextにALTER TABLEしますので、1.1x を使っている猛者の方は、phpMyAdmin等で、contentsテーブルのbody/body_waiting/body_cacheや、content_historiesテーブルのbodyフィールドをtextからmediumtextに変更してください orz
Quote:
・部分的にテーブルが3重にもなっているお行儀の悪いHTMLだったので
本文に64Kbyteで制限がかかるなんて方がおかしいので、当然、mediumtextにするべき局面でした。
実際のところ「基本設計」こそがpicoの自慢だっただけに…
さっそくモジュールアーカイブは修正しましたが、1.0->1.1/1.2へのアップグレード処理で、mediumtextにALTER TABLEしますので、1.1x を使っている猛者の方は、phpMyAdmin等で、contentsテーブルのbody/body_waiting/body_cacheや、content_historiesテーブルのbodyフィールドをtextからmediumtextに変更してください orz
Votes:1
Average:10.00
Previous post
-
Next post
|
Parent
-
No child
|
Posted on 2007/3/26 2:04
starck
Posts: 42
Posts: 42
GJJOEさん、早速ありがとうございます。
実は私も、散々テストしていたのに「長い本文」というのは、発想に無かったので、発見したときに「テストになってないぞ。このボケッ！
」と自分に突っ込んでました。
せめて0.xの時に見つけられていれば・・・ orz
でも、フィールドタイプの変更だけで済むのなら全然OKですよっ。
（ってフォローになってないか。。）
実は私も、散々テストしていたのに「長い本文」というのは、発想に無かったので、発見したときに「テストになってないぞ。このボケッ！
」と自分に突っ込んでました。せめて0.xの時に見つけられていれば・・・ orz
でも、フィールドタイプの変更だけで済むのなら全然OKですよっ。
（ってフォローになってないか。。）
Votes:4
Average:10.00
Login