Dreamweaver のテンプレートを適用したページは、テンプレートの方で設定した「編集可能領域」の中身しか編集できません。
でも、例えば「body 要素に id を設定して、ページごとやカテゴリーごとに変えたい」なんてこともよくある話で、じゃあそのために編集可能領域の範囲を広げたり新たに追加したりするのも面倒ってもの。
そんなときは、特定の要素の属性を各ページで変更できるようにテンプレートで設定できます。

というワケでその手順。

（ちなみに、バージョンは CS4 です）

テンプレートを設定

body 要素の id 属性を変更できるようにした場合。

1. テンプレート（.dwt）を開き、body 要素に id 属性を設定する。
2. body 要素にカーソルを合わせた状態で、［修正］−［テンプレート］−［属性を編集可能にする…］を選択する。
   
   （メニュー自体がグレーアウトしてる場合があるんですけど、何が原因かよく分かってません……。編集可能領域を設定したら直ったりしますが……）
3. 「属性を編集可能にする」のチェックを入れ、ラベル（例：bodyID）と初期設定の値（例：index）を入力する。属性は「ID」、タイプは「テキスト」を選択しておく。
   
4. </head>の前に「<!– TemplateParam name=”bodyID” type=”text” value=”index” –>」が挿入され、body 要素の id 属性値が「@@(bodyID)@@」になっていれば成功。

属性は id じゃなくても class などが（たぶん src とか href とかでも）設定可能。
タイプも、その属性に合わせて選ぶのが良さげです。
（僕は今まで id くらいしか使ったことがないので詳細は分かりませんが）

各ページで属性値を変更

1. ページのファイル（.html）を開き、［修正］−［テンプレートプロパティ…］を選択する。
   
2. 設定したラベルを選択して、その値を入力する。
   
3. </head>の前にある「<!– InstanceParam name=”bodyID” type=”text” value=”index” –>」の value の値が入力した内容に変化すれば成功。

当然のことながら、ソースを直接いじっても変化しません。
必ずメニューから操作しましょう。

尚、この機能はネストされたテンプレートでも有効です。
つまり、サイト共通のテンプレートと、カテゴリーごとにテンプレートを作成していた場合、共通テンプレートで上記設定をしておけば、カテゴリーごとのテンプレートで body 要素の id 属性値を変更することができ、それをベースにページのファイルを作ることができます。

逆に、ネストされたテンプレートを適用していても、ページごとに属性値を変更したい場合もあると思います。
そんなときは、ネストされた（ここの例ではカテゴリーごとの）テンプレートを開いた状態で、「属性値を変更」の手順で選択した［修正］−［テンプレートプロパティ…］のダイアログを開き、「ネストされたテンプレートによる制御を許可」のチェックを入れてください。

</head>の前のタグが「<!– InstanceParam name=”bodyID” type=”text” value=”index” passthrough=”true” –>」になり、body 要素の id 属性値も「@@@(bodyID)@@@」になります。
これで、ネストされたテンプレートをベースに作られたページでも、属性値を変更することができます。

設定方法

yuga.js の「外部リンクは別ウィンドウで開く」という機能は、デフォルトでは a 要素にのみ適用されます。
その記述がされているのは、以下の箇所（バージョン 0.7.1 で 148 行目）。

var e = $('a[href^="http://"]').not('a[href^="' + uri.schema + '://' + uri.host + '/' + '"]');

つまり、「a 要素の href 属性に、先頭が http:// の文字列が設定されていたら」という条件になっているわけです。
（ちなみに後半の「.not」以降は、URL が同じドメインだった場合、別ウィンドウで開く対象から外す、という処理（「ドメイン」って言っていいのかどうか分からないですけど））

なので、ここに条件を追加してやれば、a 要素以外でも別ウィンドウで開いてくれるようになるわけですね。
結果として、以下のようになります。

var e = $('a[href^="http://"], area[href^="http://"]').not('a[href^="' + uri.schema + '://' + uri.host + '/' + '"]');

作業内容としては、コピペしてカンマでつないで「a」を「area」に書き替えるだけです。

仕組みとしては単純なので、必要に応じて色々対応できそうですね。

逆に、「異なるドメインへのリンクでも、別ウィンドウで開く対象から外したい」という場合は、別記事に書いてますのでそちらをご覧ください。
»yuga.js で、別ウィンドウで開かないドメインを追加する方法。

小ネタでした～。

Mac での操作方法を書いてるので、Windows の方は（もし何か違っていたら）適宜似た感じの項目で読み替えてください。
あと、使ってるバージョンは 3.2.0 です。
（最新版は 3.2.1 が出てるようですが、まぁ大きく変わってることはないはず）

［ページ設定］は何処に？

印刷するときの余白を設定したり、ヘッダーやフッターを設定したりするとき、オフィスは［ファイル］−［ページ設定］というメニューを使います。
ところが、OOo の［ファイル］に［ページ設定］は存在しません。
［ファイル］−［プリンタの設定］にも、［OpenOffice.org］−［設定］にも、期待する項目は出てこないのです。

じゃあどこにあるのかというと、［書式］−［ページ］です。

オフィスと比べると、項目の種類や名前が違っていたりしますが、概ね同じことができるはずです。

例えば、用紙のサイズや余白、縦向き／横向きの設定。

あと、拡大縮小の設定（倍率を入力したり、印刷するページ数に合わせて自動的に倍率を調整したり）も。

ここでは「Calc（「Excel」に相当）」を例に挙げましたが、「Writer（「Word」に相当）」や「Impress（「PowerPoint」に相当）」も［書式］−［ページ］からオフィスの［ページ設定］と同じような操作ができます。

知ってたら何てことないことなんですけどね。
よく使うところなので、もうちょっと直感的に分かるようにしてもらえたらなぁ、なんて思います。
ツールバーのボタンにデフォルトで入ってても良いと思うんですけど。

Google Analytics でレポートを見ているとき、「URL だけじゃ分かりづらいなぁ。タイトルも表示されないかなぁ」と常々思っていたワケです。
（「タイトル別のコンテンツ」では表示されるんですけどね。というか、それでしか表示されない）

が、URL にパラメータを直接（ムリヤリ?）追加してやることで、ページタイトルを URL と一緒に表示させることが出来るんだそうで。

方法としては、「上位のコンテンツ」などを表示しているとき、URL の「ID=XXXXXXXX」の後に「&segkey=request_uri|page_title」を挿入するだけ。
なぜかこの位置以外に挿入しても画面が切り替わってくれませんでした。
順番なんて関係あるんですかね。不思議。

「上位のコンテンツ」以外にも、「コンテンツの詳細」とか「閲覧開始ページ」とか、あるいは「トラフィック」の方の「キーワード」とかでも表示することができました。
ただ、若干動作がおかしくなる場合もあるので、現時点ではあくまで「参考データ」くらいに考えておいた方が良いのかも知れません。
（だからまだ標準では表示できないようにしてるのかな）

元記事はこちら↓。
»Google AnalyticsでURLとページタイトルを同時に表示させる方法 | 海外SEO情報ブログ・メルマガ

で、今回、勢いでざっくりとまとめてみたのでついでに公開します。
本当にざっくりなので抜けもあるだろうし「それくらい書かんでも分かるわボケ」なものもあるでしょうけど、まぁそれは追々。
ディレクトリ名やファイル名として使用することを前提としているので、文法とかは全く考慮してませんので悪しからず。

最近、医療・病院関係のサイトに仕事で関わることが多いので、後半はほとんどそれ関係です。

あと、英訳／和訳をするときにいつも利用させてもらってるのは「スペースアルク」さんです。
単語そのものの訳はもちろん、例文も豊富で非常に分かりやすいのです。
いつも頼りにしてますよ。あざーす。

思い付いたら追加・修正していきます。
「これも入れた方が良いよー」というのがあれば、コメント欄にでも放り込んでください。

• 同一ドメインにおいて（仮に「http://www.hoge.jp/」とします）
• Firefox で保護されていない特定のページ（「http://www.hoge.jp/〜」）から保護されている特定のページ（「https://www.hoge.jp/〜」）へリンクしたとき
• 「一部しか暗号化されていない」という状態になる
• そのページをリロードすると、その事象は解消される（すべて保護されている状態になる）
• 同じリンク元ページの別の箇所から、まったく同じ URL にリンクしても、上記のような事象は発生しない（すべて保護されている状態になっている）
• リンク先 URL を直接入力したり、他のページからリンクしても、やっぱり事象は発生しない
• つまり、特定のページの特定の箇所にあるリンクでのみ、事象が発生している（再現性あり）
• IE、Safari、Google Chrome といった他のブラウザでは特にそういったことは起こらない
• 逆に Opera では、どの保護されていないページ（「http://www.hoge.jp/〜」）からであっても、保護されているページ（「https://www.hoge.jp/〜」）へリンクした場合、「保護されてはいません」となる
• Opera の場合、Windows ではリロードすると解消される（保護されている状態になる）が、Mac だとリロードしても解消しない（URL を直接入力してもダメ）
• このサイトは PHP で構築されていて、ファイル名によって「http://」と「https://」を 302 リダイレクトで切り替えている（「info.php?〜」なら「http://」、「edit.php?〜」なら「https://」という具合）

という感じです。
もう、まったく意味が分からないんですけど……。

Web ページを表示するときには、まず HTML やら CSS やら JavaScript やら 画像やらをダウンロードする必要があります。
それら各ファイルを圧縮することで転送量を小さく抑え、結果的にパフォーマンス向上（時間短縮）に繋げましょう、というお話。
ページのつくりにもよりますが、70～80% くらいフツーに圧縮されちゃいます。強力。

自宅サーバーや専用サーバーを使ってる場合は Apache の設定を直接いじることも可能ですが、今回はとりあえずパス。
httpd.conf あたりを触ることになるんでしょうけど。

あと、「gzip」とは何ぞや、というのも、正直よく分かりません。
昔から使われてるし一番普及してるし圧縮率も高いし使用制限とかもフリーだし標準化もされてるし、っていう感じなので、あまり深く考えず乗っかった方が良さげかな、と。

.htaccess での gzip 圧縮設定方法

さて、gzip 圧縮するには、「mod_deflate」モジュールを使います。
（ただ、これは Apache 2.x 系の場合で、Apache 1.3 とかの場合は「mod_gzip」を使うそうです）
で、これを .htaccess で設定するワケですが、ただ圧縮するだけなら以下の一行を書いてアップするだけでOK。

AddOutputFilterByType DEFLATE text/html text/css application/x-javascript

他にも色々細かく設定できるみたいなんですけどね。圧縮率とか。
そんなにこだわらず「圧縮できりゃいいや」っていう（僕みたいな）人ならこの一行で充分でしょう。

「AddOutputFilterByType DEFLATE」の後に、圧縮の対象とするファイルの形式（メディア・タイプ、コンテント・タイプ）を指定します。
上記の指定は HTML と CSS と JavaScript の3種類で、画像は対象から外しています。
（jpg や gif やもともと圧縮してますし、png も一応最適化してるので、gzip 圧縮したところでそれほど効果は望めない）
まぁ、通常はこの 3 つで大丈夫なハズ。

ちなみに、PHP のページについても、「text/html」に含まれてます。
デフォルトでそうなのか、meta タグで「content=”text/html; charset=UTF-8″」というような設定をしているからなのか……。
詳しいことは分かりませんけど。

圧縮できてるかどうかの確認は、Firebug の「接続」タブや「YSlow」でも出来るのですが、↓のような便利なサイトもあります。

»GIDZipTest: Web Page Compression (Deflate / Gzip) Test – GIDNetwork

URL を入力したら、圧縮可否だけでなく、圧縮率やレスポンスヘッダーまで表示してくれます。

注意点など

アクセスのたびに圧縮して転送して……ということを繰り返すので、ユーザー数によってはサーバーにかなりの負荷がかかることも有り得ます。
サーバーのスペックや Web システムとの絡みもあるのでケースバイケースになるんでしょうけど、もし動作が重くなったりした場合は別な方法を検討した方が良いかも知れません。

WordPress で gzip 圧縮

WordPress が入ってるサイトに↑の方法を試してみたら、「Internal Server Error」が発生。
どうしたものかと思ったら、そのままズバリのプラグインがありました。

»WordPress › GZIP Output « WordPress Plugins

管理画面から「GZIP Output」を検索して、インストール→有効化するだけです。
設定は特に無し。いや便利。

WordPress 本体のバージョンについては、2.8.3 までしか動作確認されてないっぽいのですが、2.9.2 と 3.0 に入れても（今のところ）ちゃんと動作してます。

参考サイト

• mod_deflateでgzip圧縮 – Develop with pleasure!
• ホームページの表示を高速化する – Live Commerceドキュメント
• mod_deflate – Apache HTTP サーバ
• ＠IT：mod_deflateによるコンテンツの圧縮転送（2/3）
• YSlowでウェブサイトのパフォーマンスを改善： gzip圧縮を有効にする – builder by ZDNet Japan

発生した現象はタイトルの通りですが、テーブルに設定した線が、Firefox で見てみると表示されたりされなかったりするのです。
「されたりされなかったり」とは言っても、表示のたびに結果が変わるということではなく、再現性はあります。
ただ、文字サイズを変えたり行間を変えたりパディングを変えたりすると、表示される線と表示されない線が違ったりするということです。
色々な数値を微調整していけばすべての線がちゃんと表示されるポイントがあるかも知れませんが、環境が異なればまた結果も変わってくるでしょうし、根本的な解決にはなりません。

というワケで、色々試した結果、以下のような方法に落ち着きました。
かなり無理矢理ではありますが、今のところ正常に（？）表示されています。

原因は「border-collapse: collapse;」？

ネットで調べまくってもいまいち情報が無かったので、Firebug を使って一つ一つプロパティをいじりながら確認してみました。
すると、どうやら「border-collapse: collapse;」が原因らしいことが判明。
テーブルごとに設定するのが面倒なので、「border-spacing: 0;」と一緒に「border-collapse: collapse;」を table タグセレクタで一括設定してるんですが、これを Firebug で外すと線が表示されたのです。
（もちろん線の重なりが解除になるので太くなっちゃいましたが）

じゃあ、この現象が起こってるテーブルだけ「border-collapse: separate;」にすれば良いのかも。
という仮説を検証するため、「border」の設定方法を若干メンドくさい方法に変更。
つまり、元々は「border」で四辺をいっぺんに設定していたものを、table 全体とセルごとの設定に一辺ずつ振り分けたワケです。

うん、分かりにくいですね。
以下、まとめ。

【元々】

table {
	border-collapse: collapse;
	border-spacing: 0;
}
th,td {
	border: 1px solid #000;
}

【修正後】

table {
	border-collapse: collapse;
	border-spacing: 0;
}
table.hoge {	/* 線が表示されなかったテーブル */
	border-collapse: separate;
	border-top: 1px solid #000;
	border-left: 1px solid #000;
}
th,td {
	border-bottom: 1px solid #000;
	border-right: 1px solid #000;
}

結果、見事成功。
これで、Firefox でも全ての線が表示されるようになりました。

やっぱり IE 対策は必要

ところが、それで完全解決とはいきません。
毎度毎度の登場、IE6 が顔を出します。今回は IE7 もご一緒でした。

上記の設定をしたところ、何とセル同士の間に隙間ができたのです。
IE8は無事。ということは、IE6 と IE7 のバグ……？　またかよ……。

とはいえ、今回の元々の原因は Firefox にありますので、Firefox にだけ上記の設定を適用することにしました。

それが以下。

【最終版】　※設定の仕方が間違ってたので修正しました。[2010-05-19]

table {
	border-collapse: collapse;
	border-spacing: 0;
}
table.hoge {	/* 線が表示されなかったテーブル */
	border-top: 1px solid #000;
	border-left: 1px solid #000;
}
html:not([lang*=""]) table.hoge {	/* Firefox用ハック */
	border-collapse: separate;
}
th,td {
	border-bottom: 1px solid #000;
	border-right: 1px solid #000;
}

Firefox にだけ適用するハックって何種類もあるみたいなんですが、何となく安定してるっぽいので今回はこの方法にしてます。
（参考：逆引きCSSハック(IE8,Firefox,Opera,Safariを含めたブラウザ別CSSハック) | Liquid Paper Clips）

とりあえずこれで終了。
根本的な原因が不明なのがアレですし、ハックで決着っていうのもアレですが、まぁ一つの参考にしてみてください。
他のスタイルとの競合とかもあったりするかも知れませんしね。

しかし、バグは IE だけにしてほしいもんですなー。

PLESK 上の操作で設定できたら良いんですけど、こういう細かい設定は SSH を使わないとできないみたいですね。
色々事を進めていくと、「PLESK は初心者向け」という意味がよく分かってきます。

さて、日付がおかしい原因はというと、FTP サーバーに利用されている「Proftpd」というヤツの初期設定で「TimesGMT」が ON になっていること、のようです。
んー、まぁ、要するにデフォルトの設定がローカルのタイムゾーンではなくて世界の標準時になっちゃってる、ってことですね。たぶん。
で、それをローカルのタイムゾーンに変更してやれば（「TimesGMT」を OFF ってやれば）OK、と。
（ちなみに「GMT」については wikipedia とかに詳しく載ってます）

肝心の変更方法については、とりあえず参考にしたページを列挙していきます。
正直よく分かってないですし、しかもどれが決定打になったのかすらハッキリしないので。
具体的なことは各リンク先をご覧ください。

SSH の使い方

とりあえず SSH が使えない事には話になりません。

僕の場合は Mac OSX なので「ターミナル」を使いました。
各環境によって様々あるので、探してみてください。

• FAQ/SSH/ログイン方法 – Plesk Wiki
• Windows用定番SSHクライアント「Tera Term」の使い方

まず、ログインに関しては、

# ssh （ユーザー名）@（ホスト名）

でいけると思います。
パスワードを求められるので、それを入力したらログイン完了。
ユーザー名やパスワードは、レンタルサーバーであれば契約時にサーバー会社から情報が来ているはずです。

ログインしたら、root 権限を持つ「スーパーユーザー」になっておきます。

# su -

ここでもパスワードを求められるので、ログイン時と同じく用意されたパスワードを入力します。
ひょっとしたら必要ないかも知れないんですが……。
念のためです。念のため。

あと、今回の操作で必要となる主な SSH コマンドを挙げておきます。
その他や詳細はリンク先を参照ください。

↓ディレクトリの移動（例：「/etc」ディレクトリへ移動）

# cd /etc

↓ファイルの編集（例：「proftpd.conf」というファイルを vi エディタで開く）

# vi proftpd.conf

指定したファイルが無い場合は新規作成してくれるみたいです。
あと、編集終了は「Esc」キーなんですが、これを押しただけでは特に何も表示されません。
その後に続けて終了時のコマンドを打ち込むことで処理してくれます（下記リンク先参照）。

↓終了処理

# exit

コツとしては、いざというときの「終わり方」を先に知っておいた方が良いと思います。
慎重に、慎重に。

• Telnet/SSH のUnix コマンドプロンプト一覧表 Apache httpd.confファイル編集、バーチャルホストviテキストエディタ

設定ファイルの編集

さて、ここからが本番なんですが、もう細かいことは書きません。
誤解を招いてもいけないので。

とりあえず僕が実際に試した順番で載せておきます。

• SWsoft 株式会社 POS – Point of Sales & Support – Virtuozzo, Plesk, SiteBuilder, HSPC, PEM – 全体的なプラットフォーム
• FAQ/Web/FTPがおかしい – Plesk Wiki

僕の場合、後者の設定をした段階で状況は改善されました。
FTP クライアントで表示をリロードするだけで、ちゃんとした日時で表示されるようになります。

ただ、後者だけで良かったのか、2つとも設定したから解決したのか、そのあたりは分かりません。
「元に戻して検証」なんて、恐くて出来ませんしね……。

慎重に、お試しください。

サーバーによっては、コントロールパネル（管理画面、以下「コンパネ」）がサイトと同じ階層（FTPで見えるところ）にあったり、全然別のURLなのにあたかも同じサーバーに乗っかってるような設定になっているところがあります。
（すんません。何を書いてるか自分でもよく分からないんですが、同じ状況になった人なら分かってくれると思います。たぶん）

で、そんな場合に SOY CMS のルート設定をすると、コンパネにアクセスできなくなったりすることがあるワケですね。
僕の場合は「404 Not Found」エラーになりまして、SOY CMS で設定した「見つかりません」ページが空しく表示されるばかり。
試しにルート設定を外してみると、コンパネにアクセスできるようになります。
再度設定すると、やっぱりまたアクセスできない。

うーん……、ルート設定に原因があることは間違いないみたい……。
これは困った。

……んですが、いろいろ試していると運良くうまくいく方法があったので、備忘も兼ねてご紹介しておきます。

自動生成された「.htaccess」を編集して、除外してやる

僕が関わっていた件の場合、コンパネのディレクトリ（というかURL）を特定することができました。
ということは、「ルート設定」の対象からこのディレクトリだけを除外してやれば良いはず。
ということは、「ルート設定」をしたときに SOY CMS が自動的に生成する「.htaccess」を編集すればいけるんじゃないか。
と踏んだワケです。

ちなみに、SOY CMS が自動生成する「.htaccess」は次の通り。

# @generated by SOY CMS at 2010-04-05 18:24:54
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME}/index.php !-f
RewriteCond %{REQUEST_FILENAME}/index.html !-f
RewriteCond %{REQUEST_FILENAME}/index.htm !-f
RewriteCond %{REQUEST_URI} !/index.php/
RewriteRule ^(.*)$ index.php/$1 [L]
#---SOY CMS end of htaccess file --

じっくり見てみると……。

お、「!/index.php/」てのがありますね。
「!」って、正規表現で言うところの否定ですよね。
ということは、たぶん「/index.php/」じゃなかったら、って意味ですよね。
だったら、ここに除外したいディレクトリを入れたらいけんじゃね？

という感じで、以下のようにしてみました。

# @generated by SOY CMS at 2010-04-05 18:24:54
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME}/index.php !-f
RewriteCond %{REQUEST_FILENAME}/index.html !-f
RewriteCond %{REQUEST_FILENAME}/index.htm !-f
RewriteCond %{REQUEST_URI} !/index.php/
RewriteCond %{REQUEST_URI} !/hoge_conpane/
RewriteRule ^(.*)$ index.php/$1 [L]
#---SOY CMS end of htaccess file --

ビンゴ！

うまくいきました。
コンパネも表示されるようになりましたし、ルート設定も問題ないようです。
（もちろん他にも色々調べたり検証したりしたですって。単なる当てずっぽうじゃないんですって）

もし書き方がおかしかったり、もっと良い方法があれば教えてください。
見ての通り、詳しい方ではないので。

とりあえず今回はディレクトリ（というかURL）を特定できたので、「そこを除外すればOK」という単純な方法で解決できました。
が、それ以外のケースもあるでしょうから、それはまたぶつかったときに考えたいと思います。
（いや、考えないといけないことがないことを祈りますけど）

雑感など

それにしても、ルート設定って、SOY CMS 内で管理してる特定のサイト（ディレクトリ？）にだけ効果があるものだと思ってたんですけど、そうでもないんですね。
サーバーのことを分かってる人からすると「なーにを今さら。ケッ！」って感じなのかも知れないですけど、僕のように「CMS の導入は出来るよ。でもカスタマイズはほとんど出来ないよ」というくらいのレベルの人間にとってみたら、今回のような事象は非常にビックリなのです。
いや、本当に焦った……。

日々勉強、そして経験、ですなぁ。