next »

[yama]

ドキュメントの「コンテンツタイプ」でせっかく「text/css」を選択できるように
なっているので、CSSファイルもドキュメントとして管理してみることにしました。
そして、実際に試してみたのですが…MODxというよりはIEの問題のように
思えますが、ときどきCSSの読み込みに失敗して素の状態でページが
表示されます。規則性はないので、サーバのちょっとしたレスポンスの差などが
影響しているのではないかと思っています。Firefoxでは大丈夫でしたが…

仕方なく、「リソース」→「ファイル管理」→「/assets」とアクセスし、とりあえず
templatesあたりにCSSファイルを置いて編集することにしましたが、
僕の場合CSSファイルは更新の頻度が高いので、クリック数が多く不便です。
（CSSファイル編集画面を別ウィンドウで開いておいてもいいですけど）

MODxではCSSなどの外部ファイルはこのように管理すると便利、といった
アイデアありますでしょうか。

[takumi]

こんばんは。
自分はテンプレ作成でCSSファイルだけはFTPでアップしてます。
DreamWで頻繁に編集するのでMODxの管理だとコピペ自体が面倒臭いです。
本来HTMLファイルもSQLに収めないでファイルとして読み込めれば嬉しいのですが。
（テンプレ編集をちょっとしただけでオーバーヘッドがスゴイし）
で、CSSやテンプレで使う画像の置き場ですが、templates/テンプレ名/として管理してます。
自分の場合ですけどね。

[yama]

そういえばそうですね。編集作業自体はDWなどのツールを使うのがずっと便利。
ctrl＋sで手軽にputできるし…

MODxでなんとかできるなら、ファイル実体へのショートカットをドキュメント一覧ツリーに
追加できると便利そう。

「MODxマネージャー」みたいなリッチクライアントがあると便利だろうなあと思います。
ajaxを駆使したMODxの管理画面はよくできてるけど、無理してる感もなきにしもあらず。
プログラミングのことはよく知りませんが、FlexやCurlなどを使ってこの種の管理
ツールを作る動きが将来出てくると楽しそうです。

http://japan.cnet.com/interview/story/0,2000050154,20064748,00.htm

[yama]

http://www.muddydogpaws.com/
こちらのサイトは、もしかすると外部CSSファイルをMODxドキュメントとして
管理しているのかも。IEでアクセスすると、CSSファイルが読み込まれず
ベタ状態でページが表示されることが時々あります。

http://www.muddydogpaws.com/main.css
CSSファイルのロケーションを決め打ちで開いてみると、Firefoxなら
読めますがIEだと正常に読み込めません。

[takumi]

http://www.muddydogpaws.com/main.css
CSSファイルのロケーションを決め打ちで開いてみると、Firefoxなら
読めますがIEだと正常に読み込めません。

うぅ～ん・・・どうなんでしょうね？
ちなみに、私はIE6を表示確認用に使ってますがWeb Accessibility Toolbarを入れてるので見れちゃいます。
もしMODxのドキュメントを利用しているのなら、FireFoxで良いので拡張子無しでmain.cssにアクセスしてみると良いかも知れません。
mod_rewriteを使ってるので、拡張子無しでアクセス出来るならドキュメントとして使われていると思います。

[yama]

あれれ、拡張子なしだとアクセスできませんね。じゃあこれはMODxの
ドキュメント管理下じゃなさそう。

> 拡張子無しでmain.cssにアクセスしてみると良いかも

あっ、そうなんですか。…今回の件とは関係ないのですが、フレンドリーURL構成で
*****.com/sub/
みたいなアクセスの仕方もできるんですね。実際に試して確認してみました。

同じことを某掲示板サイトで書いてる人がいましたが、
*****.com/sub.html
というURLしか認めないのかと思ってました。

[yama]

http://modxcms.com/forums/index.php/topic,4201.0.html

こちらに解決方法が書いてあるようですが、レンタルサーバでは難しそう。
（httpd.confを編集するらしい）

[eastbind]

httpd.confに書けることは、たいてい.htaccessに書けます。
ちょっと調べてみますが、試してみては？
日本のホスティングでは、どこもAllowOverride Allしているような気がします。

[eastbind]

http://modxcms.com/forums/index.php/topic,2573.msg31052.html#msg31052で展開した話と原因は一緒だと思いますので、こちらに統合して話をしようと思います。

この話は、IE6（と、IE6SP1、IE6SP2）のバグに起因するもので、解凍しても一定サイズ（確か、IEを動かしているWindowsの仮想記憶ページサイズ、4096バイト？）より小さいgzip圧縮ファイルをダウンロードすると、解凍に失敗してそのファイルを廃棄してしますというものです。ダウンロードするものは、htmlだろうが、jsだろうが、CSSだろうが全部このバグにつかまります。
ヘッダのレスポンスを見て「Content-Encoding: gzip」となっているとそのレスポンスはgzip圧縮されています。
MODxのドキュメント出力は、同梱の.htaccessの設定「php_flag zlib.output_compression On」により、すべてgzip圧縮されてブラウザに送られるのです。
また、apache 1.xのmod_gzip、apache2.xのmod_deflateによりapacheが圧縮する場合もあるので一概にzlib設定のせいとも言いがたいのですが。

もしapacheによる圧縮が無いのなら（上記のモジュールのロードが無い）、.htaccessのzlib設定をコメントしてしまえば回避できると思います。なんとかIE6に送る場合だけ、それも小さいファイルだけ圧縮しないという設定ができないか、この前から考えています。もし、いいアイデア募集します。

[yama]

この現象を意図的に再現できないかと思い、テスト用のhtmlを書いてみました。
ファイルサイズは850バイト足らず。そして zlib.output_compressionを有効にして
アクセスしてみましたが…あれ？表示されました。
有効にしたつもりで有効になってないのではと思い、問題のMODxのトップページに
アクセスしてみると、やっぱり白紙。

そのテストページのレスポンスヘッダは以下のとおりです。
どういう条件で意図的に再現できるか、探ってみたいと思います。

Code:

GET /1index.php HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: ja
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;***省略***)
Host: ******.com
Connection: Keep-Alive
Cookie: MODxLoggingCookie=2797781005; QuickEditHideLinks=null; 68b***省略***

HTTP/1.1 200 OK
Date: Mon, 01 May 2006 13:46:01 GMT
Server: Apache
Content-Encoding: gzip
Vary: Accept-Encoding
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html

[eastbind]

あれからいろいろ調べました。

この話は、IE6（と、IE6SP1、IE6SP2）のバグに起因するもので、解凍しても一定サイズ（確か、IEを動かしているWindowsの仮想記憶ページサイズ、4096バイト？）より小さいgzip圧縮ファイルをダウンロードすると、解凍に失敗してそのファイルを廃棄してしますというものです。

このバグはすでにセキュリティロールアップによって解決していました。私の調査不足でした。ごめんなさい。

では何が問題かというと、VaryレスポンスヘッダがあるとIE6のキャッシュコントロールが未だおかしいようです。そこでIEの場合にはVaryレスポンスヘッダを送信しないように設定する必要があるとのこと。どうもそのために、MODxの.htaccessのラスト4行があるようです。

BrowserMatch "MSIE" brokenvary=1
BrowserMatch "Mozilla/4.[0-9]{2}" brokenvary=1
BrowserMatch "Opera" !brokenvary
SetEnvIf brokenvary 1 force-no-vary
この4行のコメントをはずしてお試しいただけませんか？
もしかすると、apacheのmod_setenvifがロードされていない可能性はありますが。その場合はｈｔｔｐ error 500で止まると思います。そのときはサーバ業者に要望するしかありません。
http://modxcms.com/forums/index.php/topic,2573.msg31060.html#msg31060こちらのほうも同時に解決するんじゃないかなと。（多分サーバ側でキャッシュをしているような気がします。）

[yama]

試してみましたが、状況変わらず。白紙表示でした。むーー？？？
もちろんgzipオプションを有効にし結局無意味だったphp.ini指定も解除したうえで。
しかしVaryレスポンスヘッダですか、それはそれで気になりますね。

実際のところ圧縮って効果あるのかなとも思っていますが、それを言っちゃうと
つまんないでしょうね

[Solis]

xrea.comですが、以下のようにしてとりあえず白紙状態を回避しました。

サイト直下の.htaccess
私が使っているサーバーは、compressionがオンになっていて、これを外すとheaderが２度送信されるというエラーが出ますので、levelを0にして同じこと？を実現しました。

Code:

php_flag zlib.output_compression On
php_value zlib.output_compression_level 0

BrowserMatch "MSIE" brokenvary=1
BrowserMatch "Mozilla/4.[0-9]{2}" brokenvary=1
BrowserMatch "Opera" !brokenvary
SetEnvIf brokenvary 1 force-no-vary

さらに、manager/ の下にも.htaccessがありますが、FireFoxがなぜか表示されないので、こちらは暗号をかけました。

Code:

php_flag zlib.output_compression On
php_value zlib.output_compression_level 1

RewriteEngine Off

なんか余計なことをしたかもしれませんが、いまのところうまくいっています。

[yama]

この件ですが、もしかするとxreaは基本的に圧縮が有効になっているかもしれません。
「私が使っているサーバーは、compressionがオンになっていて」というのがそういう意味かな？
そうだとしたらすみません。
僕のサーバではzlib.output_compressionの記述は外しても圧縮かかってるから
大丈夫と判断しました。mod_gzip_on Noでzlib.output_compressionオンのほうが
もしかするといいのかもしれませんが。どうでしょうか？

http://modxcms.com/forums/index.php/topic,4425.msg32177.html
↑
今、こちらのほうが気になっています。圧縮するしないは関係なさそうですが。
Solisさんは僕と似たような環境で運用されているようなので、もしよければ
確認いただけると嬉しいです。html-lintやwgetなどで確認できます。
(ページの最下部にエラーが表示されます)

[eastbind]

solisさん

私が使っているサーバーは、compressionがオンになっていて、これを外すとheaderが２度送信されるというエラーが出ますので、levelを0にして同じこと？を実現しました。

これ詳しく教えていただけませんか？どのようなヘッダが二重になってしまったのでしょう？