サイトでヘッダーやフッター、サイドカラムなどのページの共通で表示するときには、直にHTMLを書かずにDreamweaverのテンプレートやライブラリ、もしくはPHPでincludeすることが多いと思います。

僕も誰が主にファイルを編集することになるのか、サーバー環境はどんなものか云々考えて使い分けています。Dreamweaverのテンプレートに落ち着くことが多いのですが、どういう理由でそのようにしているのかを紹介していきます。

Dreamweaverテンプレートはこんなときに便利

Dreamweaverのテンプレート機能は以前にもいくつか紹介してきました。

その中でもテンプレートで運用してすごくやりやすかった点がいくつかありました。

テンプレート変数でメタ・OGPまわりの抜けをなくす

head内に書くtitle要素やmetaディスクリプション、キーワード、OGP周り、表示が確認しやすいh1のページタイトルをDreamweaverの変数として利用しました。

h1を入れる理由は入力したかどうかを簡単にチェックしやすいからです。h1が入っていない状態でブラウザプレビューをすると、ブラウザでは確認しにくいtitle要素やmeta周りなどの情報を入力したかどうかも同時にチェックすることができます。

必ずこれらの変数はセットで入力します。
これをバラバラで後から決めて入力すると、確認は各ページのテンプレートプロパティで確認したり、ソースコードを直接みるなど非常に面倒かつ時間がかかる作業になってしまいます。そのため必ず変数はまとめて一気に入力するように自分にルールを設けています。

テンプレートの条件式でパンくずリストの一元管理

WordPressならプラグインを使ったり、直接処理を書くことで簡単に作れるパンくずリストですが、静的ページで1ページ1ページを丁寧にやろうとすると、一貫性が取れなかったり親カテゴリーのラベルが変わったときに1ページ1ページ確認しながら作業する必要が出てくるのでとても大変です。

しかしパンくずリストもDreaweaverのテンプレートで制御可能です。階層が深すぎるページだと条件式を書くのが大変ですが、しっかりと値を管理すれば数百ページまではこれで制御可能です。

テンプレート上では以下のように記述します。

<ul>
<li><a href="/">HOME</a></li>
<!-- TemplateBeginIf cond="_document['category'] == 'category1'" --->
<li><a href="/directory1/">カテゴリー1</a></li>
<!-- TemplateEndIf -->
<!-- TemplateBeginIf cond="_document['category] == 'category2'" -->
<li><a href="/directory2/">カテゴリー2</a></li>
<!-- TemplateEndIf -->
<li><em>@@(_document['ページタイトル'])@@</em></li>
</ul>

そして、テンプレートを適用したファイルに変数を「category1」としたとき、

<ul>
<li><a href="/">HOME</a></li>
<li><a href="/directory1/">カテゴリー1</a></li>
<li><em>ページタイトル</em></li>
</ul>

変数を「category2」としたとき、

<ul>
<li><a href="/">HOME</a></li>
<li><a href="/directory2/">カテゴリー2</a></li>
<li><em>ページタイトル</em></li>
</ul>

Dreamweaverのテンプレートタグをよく知ってる方なら気づくかもしれませんが、TemplateIfClauseは使わないようにしてます。テンプレートのタグ自体が長いのであまり増やしたくない、if ifでもif elseでも出力するHTMLは変わらないので分かりやすくなるようにif ifという形でまとめてます。

サイドカラムの条件分岐

全ページ共通のサイドカラムもテンプレートを使って効率化をはかります。ページ数が多いサイトだと、サイドカラムもページのカテゴリーに応じて表示を切り替えることもよくありますね。

ここでもテンプレートの条件式を入れることで、表示の切り替えも簡単にできます。

<div id="sub">
共通で入れる内容
<!-- TemplateBeginIf cond="_document['category'] == 'category1'" --->
カテゴリー1で表示する内容
<!-- TemplateEndIf -->
<!-- TemplateBeginIf cond="_document['category'] == 'category2'" --->
カテゴリー2で表示する内容
<!-- TemplateEndIf -->
共通で入れる内容
<!-- /#sub --></div>

テンプレートを使用せずにページ新規に作る度にライブラリを挿入してヘッダーやフッター、サイドカラムをページを作っているサイトもありますが、意図しない誤操作で改行やスペースが入りやすくことがあるので、個人的にライブラリの使用はかなり限定しています。理由は後ほど。

システムページに埋め込む際のコンテンツ作り

CMSのプレビュー機能で確認をするにしても、HTMLタグはもちろん、CSSも画像も一緒にアップすることが多くて、その都度アップしながら確認するのは面倒です。

また静的なHTMLでページを組んだとしても、管理画面ではどこからどこまでコピーして管理画面に貼り付ければいいのかを「<!-- ここからコピー -->」のようなコメントを探すのも面倒です。CMSやECサイトでHTMLタグを丸ごと管理画面上から入力するようなケースでもDreamweaverのテンプレートが楽です。

テンプレートでは編集可能領域があります。.dwtファイル上では

<!-- TemplateBeginEditable name="content" -->〜<!-- TemplateEndEditable -->

テンプレートを適用したページでは

<!-- InstanceBeginEditable name="content" -->〜<!-- InstanceEndEditable -->

という形で囲まれている箇所がDreamweaver上でテンプレートを適用したページで編集ができる場所です。

編集ができない箇所はコードビューでは違うカラーリングになったり、デザインビューではカーソルを置けなかったり選択できなくなります。

この特性を生かして管理画面上で入力ができる箇所を再現するためにDreamweaver上で再現し、静的にHTMLのプレビューが実現できます。静的なHTMLになるのでCSSや画像も一旦ローカルのものを参照して、プレビューの手間を減らせられます。

ライブラリとはこう使い分ける

たまに他社から更新を引き継いだサイトでライブラリしか使っていないところを見ると、もうちょっと知れば活用できるのにと思うところです。僕は次のようなポイントを考えて使っています。

ライブラリの特長は単純なHTML出力しかできないこと

テンプレートとライブラリが大きく違うのは、変数に応じて表示するHTMLを変えることができない点です。つまり、テンプレートの変数からは独立した表示をするようなときに使います。テンプレートプロパティから独立したHTMLの塊になるので、テンプレートを適用したページの編集可能領域で共通したHTMLを書くような場合に向いています。

僕がライブラリを使った例だと、ランディングページでよく見かけるページ途中に表示するお問い合わせボタンを表示したり、アイテム数が20ぐらいのECサイト規模の金額表示にもライブラリを使って制御管理していました。

まとめると、編集可能領域の上部・下部から少し離れたページ中に何度も挿入したり、ページをまたいで共通表示をするような箇所に挿入しています。

余談:ライブラリでヘッダーやフッター・サイドカラムを作らない理由

ライブラリは共通箇所を表示するにはとても便利です。しかし、ヘッダーやフッター・サイドカラムをそれぞれライブラリとして挿入すると、サイト全体でdivの構造が変える必要が出てきたとき、ライブラリの外にあるdivを全ページを一つ一つ編集するといった手間がかかってしまいます。

また構築時にライブラリでこれらのパーツを作ると、それ以外のdivの構造をいちいち覚えておかないといけないので、場合によってdivの閉じ忘れが発生しやすい状況が生まれやすくなります。他にも運用時でもdivの構造が変わったときに検索置換がしにくく、結局そこまでやるならテンプレートのほうが適切ではと考えています。

PHPのincludeとの使い分け

共通パーツを表示するにはもうひとつPHPのinclude関数を使って外部ファイルのHTMLを読み込むものがあります。Dreamweaverのライブラリと機能面で重なることが多いのですが、僕は意図的に使い分けています。

そもそもサーバーでPHPが動くのか

まずはサーバーでPHPが動くのか確認します。
長いことサーバー契約の見直しをしていないサイトだと、PHPが使えないサーバーもまだあります。他にも、サイトのカテゴリーごとにいろんな制作会社を使ってサイトを運用している企業ではページ数も巨大なことがほとんどなので、影響範囲からかセキュリティ上PHPをそのまま書いても大丈夫というところはほとんどありませんでした。

ライブラリを使わずPHPを使う場合

PHPで共通箇所を表示するのはDreamweaverのライブラリと非常に似ていますが、出力方法は状況に応じて変更しています。

まずひとつは更新頻度とサイトのボリュームが多い場合。
Dreamweaverのテンプレートもそうですが、元のファイルとなるテンプレートやライブラリファイルを書き換えると、適用しているファイル全てのHTMLファイルが書き換えられるのでページ数に応じてサーバーに転送するファイルの数は増えていきます。

しかし、PHPはファイルを一つ書き換えてサーバーに転送すると、全ページに反映できるので規模がやたらと大きなサイトでは転送の手間を大幅に減らせられます。

次に自分以外の人がファイルを頻繁に編集する可能性がある場合。
Dreamweaverのテンプレートやライブラリでは、サーバーに転送するHTMLの数が増えやすくなっていまいます。複数人で編集する場合、声かけさえしていればいい話でもありますが、互いに案件に関わる時間帯を知っていないとエンジニアが書いたコードをデザイナーが消してしまうといったことも予想できます。

1ファイルで共通箇所の変更が済むという特長を生かして、共通パーツをPHPで呼び出すことでファイルの先祖返りが置きにくくなります。

PHPを使うデメリット

デザイナーにとってPHPを使うデメリットはサーバーを組まないとローカル環境でプレビューすることができないことに尽きます。そのたびにサーバーにアップして確認する必要が出てきます。何度もブラウザ確認する場合は回数が多いとかなり面倒です。

ちなみにDreamweaverだと、デザインビューにも反映されるのはちょっと嬉しいですね。

場合によっては組み合わせ

それぞれ何を採用するとどんなことが楽になって、どんなところに弊害が起こりやすいのかを考え、組み合わせて使うとサイト構築がミスの数を減らせながら効率的になる場合がほとんどです。

最近だと、大枠をDreamweaverのテンプレート機能を使ってサイトのdiv構造を書いてテンプレートの条件式でPHPのincludeで呼び出すファイルを変更するといったこともありました。

コンテンツエリアでは静的ページがメインなのでエンジニアが触ることがないので編集可能領域内にライブラリを配置して静的な共通箇所を制御し、サイドカラムではプログラム制御が必要だったので、パーツごとに別ファイルにして、コンフリクトしにくい構造を作りました。

<div id="main">
<!-- TemplateBeginEditable name="コンテンツ" --><!-- TemplateEndEditable -->
<!-- TemplateBeginIf cond="_document['コンテンツフッター'] == true"><コンテンツエリアのお問い合わせボタンをライブラリ><!-- TemplateEndIf -->
<!-- / #main  --></div>
<div id="sub">
<?php include("../block/sub_header.php"); ?>
<!-- TemplateBeginIf cond="_document['caegory'] == 'category1'" --->
<?php include("../block/sub_category1.php"); ?>
<!-- TemplateEndIf -->
<!-- TemplateBeginIf cond="_document['caegory'] == 'category2'" --->
<?php include("../block/sub_category2.php"); ?>
<!-- TemplateEndIf -->
<?php include("../block/sub_footer.php"); ?>
<!-- /#sub --></div>

ファイルごとにincludeするファイルを書いていくと、法則性がわかりにくくなりますが、テンプレートの条件分岐を使うことで明文化に近い状態で見せることもできるようになります。

まとめ

まとめると使い分けるポイントはこのような感じです。

  • 1. PHPが動くサーバーか
  • 2. 構築中は自分以外の誰がファイル編集をして、更新後はどのようなスキルの人がファイル編集をするのか
  • 3. 静的ページの更新が多いサイトなのか

どれも共通箇所の表示には便利な反面、ファイル転送の際・ブラウザでの確認のしやすさ一長一短ですね。案件の状況をよく観察したり、ディレクターやエンジニアと確認した上で、突然の変更に耐えられる環境構築をしていきましょう。