Dreamweaverのテンプレート（DWT）でbaseタグを使う際に注意すること

ウェブ屋のmodx指南 MODxの使い方・設定TIPS

以下は、必ずしもmodx限定ではなく、Dreamweaverのテンプレート（DWT）から生成するページで、<base>タグを使う場合に、注意したほうが良いことです。

<base>タグは、<head>内の編集可能領域「head」など(*1)に入れることになると思いますが、これより前に、CSSのパスなど入っていると、そこには<base>タグが効かず、レイアウトが崩れたりします。

つまり、具体例として、編集可能領域「head」に<base>タグを入れる場合、

<link href="css/hogehoge.css" rel="stylesheet" type="text/css" media="screen,print">
<!-- TemplateBeginEditable name="head" --><!-- TemplateEndEditable -->

はダメで、

<!-- TemplateBeginEditable name="head" --><!-- TemplateEndEditable -->
<link href="css/hogehoge.css" rel="stylesheet" type="text/css" media="screen,print">

ならOK！ということです。

ちなみに、フレンドリーURLを使う場合など、modxではテンプレートに<base>タグを入れておかないと、相対パスで記述したリンクやCSSの階層があわなくなってしまうことがあります。

以下のmodxのタグを入れて置くと、modxが自動的にサイトルートのアドレスに置き換えてくれます。

<base href="[(site_url)]" />


(*1)「head」以外に他の編集可能領域を作って入れても構いません。また、編集可能領域「doctitle」に入れても良いかもしれませんが、問題があるかどうかは確認してません。

Google Analytics で、modxのリンク（ダウンロード）をカウントする。

MODxの使い方・設定TIPS

Google Analyticsを使っているサイトで、PDFファイル等のダウンロードもカウントしたいということがありますが、ファイルにはGoogle Analyticsのタグを入れられないので、他にカウントする方法が必要ですね。

Google Analyticsでは、ファイル毎に、例えば「/hugahuga/hogehoge.pdf」のような、擬似的なページアドレスを作って、これでカウントするという方法が提示されています。（後述のリンク参照）

modxのリッチエディタ（TinyMCE等）でファイルにリンクを設定する場合、リンクの挿入/編集ウィンドウの「イベント」タブに「onClick」があるので、そこに

pageTracker._trackPageview('/hugahuga/hogehoge.pdf');

のように入れるということで、これを行うことができます。
※ちなみに、この方法では、右クリックで保存された場合はカウントできません。

▼Google：サイトからのファイルのダウンロード (PDF、AVI、WMV など) をトラッキングするにはどうすればよいですか。
http://www.google.com/support/googleanalytics/bin/answer.py?hl=jp&answer=55529

リソースブラウザでサムネイルができない

MODxの使い方・設定TIPS

modxのリソース（ドキュメント）作成時に、TinyMCE等のリソースブラウザでかなり大きな画像をアップした際、サムネイル画像ができないことがありました。
一覧表示にサムネイル画像の枠やファイル名、各種ボタン等あって、サムネイル画像の中身だけが無い状態です。

クリックして選択することができ、選択した画像はちゃんと挿入されるので、致命的な問題とまでは行かないレベルの不具合です。
modxの画面やイベントログには何もでないし、サーバのエラーログにも何も残りません。

結論を言うと、原因はメモリ不足でした。
この場合JPEGだったので、「imagecreatefromjpeg」というPHPの関数がメモリ不足で落ちていたのです。

で、今回の場合、memory_limitが32Mに設定されていたので、
「.htaccess」でとりあえず

php_value memory_limit 64M

等と設定してメモリ制限を緩めたらサムネイルが生成されました。

いやらしいことに、メモリの使用量は、どうも、画像のファイル容量で決まるのではないようです。
詳しいことはわかりませんが、画像をメモリ上に展開する等で大きなメモリを使ったりするようなので、どちらかというと画像の解像度（幅×高さ）が影響しそうな気がします。（未調査）

ウェブ屋にとっての理想のCMSとは（OSCに参加して）

ウェブ屋のCMS

オープンソースカンファレンス 2009 Tokyo/Fallに、初日（それも途中まで）だけですが、参加してきました。http://www.ospn.jp/osc2009-fall/

何はともあれ「CMS」カテゴリーの展示が多かったですね。各種のUnixやLinux、多くの自作OSまで含む「OS」カテゴリーと同等の数で、「CMS」と「OS」が二大カテゴリーという印象でした。
CMS関連のセミナーにも3件ほど参加して、CMSのことを色々と考える良い機会になりました。

ということで、このブログの本来の大きなテーマである「ウェブ屋のCMS」の観点から、我々のような中小規模のウェブ屋にとって、どういうCMSが理想的かをちょっと考えてみました。前提としては、「企業サイトの制作・運営を請け負う／ウェブデザイナーがデザイン／企業担当者様が更新する」といったあたりです。

思いつきなので、考慮が足りないところもあるでしょうし、私の想定できない色々なケースもあるでしょうから、感想はもちろん、異論・反論、補足、ツッコミ、その他…、みなさんからコメントいただけると嬉しいです。

サイト制作（編集）作業を変えない・増やさないCMS

サイトの制作は、Dreamweaver等の制作ツールを使ってされていることが多いと思います。（本当かどうか知りませんが、シェア8割とか9割とか言われたりしますし、書店に行っても書籍の数は圧倒的ですので、以下は、Dreamweaverを前提で話を進めさせていただきます）

お客様への確認は、DreamweaverのFTP機能でテストサイトにアップして閲覧していただく。（もしくは、コンテンツ一式を圧縮して送るということも？）チェックバックが返ってきたら、Dreamweaverで修正・アップして再度確認。OKが出たら、DreamweaverのFTP機能を使って、本番アップ。
というような流れかと思います。（FlashやFireworks等も使うとは思いますが、ここではそれらもDreamweaverに含むと考えてください）

ちなみに、ヘッダーやフッター、グローバルメニュー等、複数ページにわたって共通な部分は、Dreamweaverのテンプレート機能やライブラリ機能を使って合理的に管理されているかと思います。（使ったことがない人は使ってみてください。非常に便利な機能ですよ。）

さて、CMSを導入した場合、以下のような部分はお客様に入力していただくことになります。

  • 商品カタログ等の定型化されたページなら、各入力項目
  • 非定形ページなら、個々のページのタイトルや記事本文

しかし、それ以外のすべての部分、トップページ、ヘッダー、フッター、グローバルメニューはもちろん、コーナー毎のサブメニューやCSS、パン屑リンクや一覧ページのフォーマット、商品カタログ等の定型化されたページのフォーマット、ブランディングページ等の特にデザインが重要なページ、等々…は、我々ウェブ屋が作ってCMSに設定しなくてはなりません。

一般的なCMSの場合、以下のような作業が必要になります。

  1. Dreamweaverで作ったページから、CMS用の部品を作る。
  2. 作ったCMS用の部品をCMSに設定する。
  3. 変更が発生した場合に、以下のどちらかを行う。
    • Dreamweaverで変更して、１〜２を繰り返す。
    • CMS用部品を直接変更し、CMSに設定する。ただし、（お客様含めて）ページデザインを事前に確認したり、今後、Dreamweaverで編集することは、あきらめる。

わかる人はわかると思いますが、これらは、デザイナー等が、普段やらない（やりたくない）性質の作業です。
つまり、ツールで確実に作業することのできない危険な手作業の上、作業の結果を視覚的に確認できないので、ミスがすぐに顕在化しない可能性があり、慣れていないし、やりたくないので、ミスを起こしやすく、ストレスにもなります。

ですので、

であれば（上から順に）理想に近いCMSと言えるかもしれません。

普通のサイトが、普通に作れるCMS

経験上、たいていのCMSは、実務で使えるようになるまで時間がかかりますし、時間をかけたところで、一人で多数のCMSに精通するということも限度があります。（若くて元気で頭が良い人は別かもしれませんが）

かといって、たとえば、TYPO3チーム、Drupalチーム、XOOPSチーム、…のように、それぞれのCMS専門チームを編成してノウハウを蓄積するなんてことは、中小のウェブ屋にとっては、とても無理な話ですね。

つまり、色々なCMSの概要を理解して、お客様にあわせた最適なCMSを提案するということはできるとしても、色々なCMSの実装ノウハウを身につけて、お客様にあわせた最適なCMSを実装するということは、けっこう難しいというのが現実だと思います。（少なくとも、少人数・短期間では非現実的）

なので、自社が受注する可能性の高い分野のサイトに最も適したCMSを選んで、仕事を通じて実装ノウハウを蓄積していく。ということが重要になってきます。（最初は一つのCMSから始めて、二つ、三つと徐々に増やしても良いでしょう）

もし、苦手分野のサイトの受注があったら、潔く、その分野に精通している他の企業に頼みましょう。

こういった視点から考えると、一般的な企業サイト等の受注が多いのであれば、普通のサイトが普通に作れるCMSが（最初に選ぶには）理想的なCMSだと思います。（コミュニティサイトとか、何かのサービスサイトのような特別な機能が必要なサイトを受注することが多いようなウェブ屋は別ですが）

たとえ、機能豊富なCMSを使ったとしても、実際に使わない機能の方が多いと思いますので、後述しますが、勉強等の投資コストも含めて、トータルで判断することが必要ですね。

サポートが充実しているCMS

ある程度、自社でノウハウを蓄積したとしても、何から何まで、すべての問題を自力で解決するというのは、中小のウェブ屋では、まず無理でしょう。

そうなると、開発元やサードパーティ、コミュニティのサポートが必要になってきます。そういったサポートが充実していることが重要だと思います。

運用環境の選択肢が広いCMS

中小のウェブ屋では、レンタルサーバーやサーバーホスティングを利用することが多いかと思います。

最新バージョンのプログラム言語や特定のDBでしか動作しないとか、一般的ではない特定のモジュールや特別な設定が必要である等の動作環境が厳しいCMSは、コストが割高になったり、サポートが得られなかったりと、デメリットが多くなりがちですね。

トータルで見て、コストが適正であるCMS

有償CMSのライセンス費用はもちろんですが、ライセンスが無料であっても、サポート（こちらが受ける）費用やサーバー費用などのランニングコスト、勉強時間、書籍、勉強会等にかかる投資コスト、個々の制作や設定・カスタマイズにかかる作業コスト、マニュアル作成、お客様の研修、カスタマーサポート（お客様に対する）作業コスト等、自社の受注する案件に対して、適正なコストになるかどうかを判断することが重要ですね。

たとえば、管理画面の仕様上の制限があって、お客様の操作ミスを、こちらがその都度フォローしなければならないのであれば、カスタマーサポートの作業コストは大きくなります。
また、ちょっとしたテンプレートの変更であっても、ページを修正してお客様に確認していただき、修正内容をCMSに反映するという作業が煩雑であれば、変更作業にかかるコストが大きくなります。
それぞれ、お客様との関係、社内の作業フローや体制、CMSの特徴等が、うまくかみあうような選択をする、もしくは、仕事のやり方を変えてコストがあうようにする等が重要ですね。

お客様にあわせて、管理画面をカスタマイズできるCMS

お客様に更新していただくのですから、管理画面が使いやすいに越したことはありません。これは、お客様への研修やカスタマーサポートといったコストにも影響があります。

ただ、オープンソースCMSでは、ほとんどのCMSで、HTMLエディタに、TinyMCEやFCKeditorが使われていますし、商用CMSでも同様の機能が実装されていて、このあたりは大差ないような気がします。また、ログイン中に閲覧しているページから編集を始められるような機能は、多くのCMSが採用していますので、このあたりも大差があまりなくなっているような気がします。

ですので、基本的な機能で差が出てくるのは、新規にページを作る操作と、既存ページを検索して編集するというところになってくるかと思います。

これも、お客様によっては、高機能を望まれる方と、シンプルでいつも使う機能だけあれば良いという方と、別れてくるかと思いますので、このあたり、お客様に合わせてカスタマイズできるというのが、理想的かと思います。

信用があるCMS

実際に使われるお客様でも、どのCMSを使うかに、あまり関心を持たれないことも多いかと思います。「御社が選ぶCMSならそれで良い」というお客さまも多いかと思います。

しかし、中にはそうでないお客様もいらっしゃるでしょうし、何か問題があれば選んだこちらの責任になりますね。

そのような際、世間的に信用があり、実績の多いCMSなら、お客様も納得していただけるかもしれません。

レイアウトやデザインの制限がないCMS

ウェブページとして（HTMLやCSSで）表現できるものが、CMSを使うがために表現力を落とすということは、大きなデメリットになります。

また、自由に表現するために、特別なノウハウが必要となるケースもありますが、そのノウハウを得るための投資コスト、特別な作業を行うための作業コストが大きくなり、これもデメリットとなります。

さらに、これらにより、デザイナーがいらぬ神経を使って、能力が充分に発揮できなかったり、ストレスになることもあります。

※追記

2009-11-02 21時半頃）
「レイアウトやデザインの制限がないCMS」を追加しました。

ウェブ屋のmodx指南-0000【ページ制作のツボ】

ウェブ屋のmodx指南 MODxページ制作のコツ

普通にDreamweaver等で制作したページは、たいていの場合は、modxで使えます。ただ、何が「普通」かは、人によって違う事もありますし、ちょっとしたことで、よりよく使う事ができる等、お勧めの方法もあります。

以下に、modxを使う際の（modxに限らないことがほとんどですが）、ページ制作のコツのようなことを書いておきます。それぞれ、三段階でお勧め度を表していますので、参考にしてください。

  • エンコードは「utf-8」（推奨度：★★★）
  • 拡張子は統一する（推奨度：★★★）
  • 一覧などは同じタグの繰り返しにする。（推奨度：★★★〜★★）
  • CSSは、記事本文＝bodyとして設定する（推奨度：★★）
  • 控えファイルを作っておく（推奨度：★）
推奨度：★★★

特別な理由がない限り、この通りにした方が良いです。ヒキダス流では、これが前提条件となっています。

推奨度：★★

この通りにしなければ、問題があるとまでは言いませんが、可能であるなら、総合的に考えて、このようにした方が良いと思われます。

推奨度：★

こうすれば、よりよく使うことができる、もしくは、こういう使い方もあります。というようなものです。


詳細を以下に説明します。

■エンコードは「utf-8」（推奨度：★★★）

「utf-8」は、今や最も標準的なエンコード（Windowsのメモ帳もUTF-8に対応していますね）なので、敢えて言う必要もないかもしれませんが、今でも、シフトJISやEUCを使ってページ制作をされる方も少なくないようなので、そういう方は注意してください。
「utf-8」以外では、正常に表示されない箇所が出る可能性があります。

■拡張子は統一する（推奨度：★★★）

modxでフレンドリーURLを使って、各ページのアドレスを「http://www.hogehoge.com/fugafuga/humuhumu.html」のようにする場合、modxで設定できる拡張子は一つですので、各ページの拡張子は「.html」、もしくは、「.htm」など、どれか一つに統一しておきます。

■一覧などは同じタグの繰り返しにする。（推奨度：★★★〜★★）

これは、modxに限らず、ブログでも他のCMSでも、多くのシステムで共通ですが、一覧表やリスト等で、（Ditto等を使って）自動的に繰り返す部分は、最初から最後まで同じタグ（同じ属性）の繰り返しにすべきです。

▼よくない例
繰り返しの途中に、例外的なタグ（この場合</tr><tr>）が入っています。

<table>
<tr>
<td>1.○○○○○</td>
<td>2.○○○○○</td>
<td>3.○○○○○</td>
</tr>
<tr>
<td>4.○○○○○</td>
<td>5.○○○○○</td>
<td>6.○○○○○</td>
</tr>
：
</table>


▼あまりよくない例
特定の1件だけ、特別な属性を持っています。

<div class="first_row">1.○○○○○</div>
<div class="row">2.○○○○○</div>
<div class="row">3.○○○○○</div>
<div class="row">4.○○○○○</div>
<div class="row">5.○○○○○</div>
：


▼よい例

<dl>
<dt>2009.00.00</dt><dd>1.○○○○○</dd>
<dt>2009.00.00</dt><dd>2.○○○○○</dd>
<dt>2009.00.00</dt><dd>3.○○○○○</dd>
<dt>2009.00.00</dt><dd>4.○○○○○</dd>
<dt>2009.00.00</dt><dd>5.○○○○○</dd>
：
</dl>


▼よい例
行を折り返す（tableの代替）例です。（※CSSの書き方は非推奨）

<style type="text/css">
.cell {
	float: left;
	width: 100px;
}
</style>

<div style="width:400px;  clear:both;">
<div class="cell">1.○○○○○</div>
<div class="cell">2.○○○○○</div>
<div class="cell">3.○○○○○</div>
<div class="cell">4.○○○○○</div>
<div class="cell">5.○○○○○</div>
：
</div>

■CSSは、記事本文＝bodyとして設定する（推奨度：★★）

リッチテキストエディタ（RTE：TinyMCE等のWYSIWYGエディタ）で編集する際、編集中のテキストには、bodyに効いているCSSがあたります。

ページ制作をする際、記事本文などに、

<div id="content">
ここに本文が入ります。ここに本文が入ります。ここに本文が入ります。
</div>

のように、特別にIDを指定してCSSを当てる方も多いようですが、できれば、記事本文以外の、ヘッダー、フッター、メニュー、パン屑等は、それぞれに、idやclassでCSSを指定するようにして、記事本文は、bodyそのままのCSSを使うようにすれば、リッチテキストエディタで編集する際に、実際の表示に近い状態で編集することができます。

■控えファイルを作っておく（推奨度：★）

modxに組み込んだファイルを、たとえば、テンプレートなら「modxt_hogehoge.html」のようなファイル名にして保存しておきます。
こうしておけば、Dreamweaverで、Dreamweaverのテンプレートやライブラリを使っている場合はもちろん、一括置換などで、ヘッダーやメニューなどの共通部分をメンテナンスする場合でも、普通のページと同様に処理ができます。
該当ページで何か変更する必要があれば、このファイルを変更して、ソースをmodxに貼り付けるようにします。

DittoのページングをYahoo!Japanっぽくシンプルにする

MODxの使い方・設定TIPS Ditto＆Reflect

modxスニペット「Ditto」のページングは、ページ数が少ない間は良いのですが、ページ数が多くなってくると、そのままページ番号がずらずらと並ぶだけで、使いにくくなってきます。
現状のDittoには、10ページ毎にまとめる等の機能がありませんので、直接ソースに手を加えて改造するしかありません。

まず、ページングの仕様ですが、（Google仕様も検討しましたが、最大20ページ出るのは、ちょっと多すぎだと思うので、）以下のような現在のYahoo!Japanの仕様を参考にしました。（Bingになったらどうなるかわかりませんが）

              • -

・全体で10ページ以上ある場合、10ページ分の番号表示
・現在のページより小さい側に5ページ、大きい側に4ページあれば、これを表示

つまり、7ページ目から全体がシフトする

例） 　　 [1] 2 3 4 5 6 7 8 9 10 次へ>
　　<前へ 1 [2] 3 4 5 6 7 8 9 10 次へ>
：
　　<前へ 1 2 3 4 5 [6] 7 8 9 10 次へ>
　　<前へ 2 3 4 5 6 [7] 8 9 10 11 次へ>
：

              • -

■改造方法
modxに同梱のソース
assets/snippets/ditto/classes/ditto.class.inc.php
のpaginateメソッドの以下の2箇所にコードを追加挿入します。

１）

if ($inc != $start) {

（modx1.0.0Jの場合は1123行目、0.9.6.3の場合は1113行目）の直前に

			if ($x < $min_x) {
				continue;
			}
			if ($x > $max_x) {
				continue;
			}

を追加挿入。

２）

for ($x = 0; $x <= $totalpages -1; $x++) {

（modx1.0.0Jの場合は1120行目、0.9.6.3の場合は1110行目）の直前に

		$max_paginate = 10;
		$max_previous = 5;
		$cur_x = floor($start / $summarize);
		$min_x = $cur_x - $max_previous;
		if ($min_x < 0) {
			$min_x = 0;
		}
		$max_x = $min_x + $max_paginate - 1;
		if ($max_x > $totalpages - 1) {
			$max_x = $totalpages - 1;
			$min_x = $max_x - $max_paginate + 1;
		}

を追加挿入。

オープンソースカンファレンス2009 Kansaiに、MODｘ CMS JAPANで出展しました。

MODx関連情報

2009年7月10日(金)、京都で行われた「オープンソースカンファレンス2009 Kansai」に、セミナーとブース展示に、MODx CMS JAPANとして出展しました。
セミナーには24名の方に参加いただき、展示ブースにも多数ご来場いただきました。当日、足をお運びいただいた皆様、ありがとうございました。

簡単ですが、以下、当日のレポートです。
ほんの一部ですが、セミナーや展示に使った資料を、→こちら「制作済みHTMLページをmodxで更新するデモ」に掲載しましたので、参考にしていただければと思います。

■セミナー（16:15〜17:00）

中小サイト構築でビジネスするならMODx

対象者：サイト構築にかかわる人、関心のある人
デザイナーが作ったページをそのまま使えるMODxなら、サイト制作のスキルがそのまま生かせます。
構造も自由。Flash、Ajax、PHPで拡張も、社内・社外の協業もスムーズ。
ウェブ制作会社の事例を交えながら紹介します。

[,left]
前半は私（kazuike）が、以前他のCMSを使った際の苦労話などしつつ、制作済みHTMLページをmodxで更新するデモや、新着情報更新、リスト表示（CSVで更新）、店舗検索・施設検索、商品検索、レシピ集、modx以外のもの（RSS読み込みライブラリ、Flashブログパーツなど）との連携など、弊社ヒキダスでの事例をいくつか発表させていただきました。
後半は、MODx公式モデレータのthrさんから、modxの動向、統計情報を交えた業界（CMS市場）の動向などを発表していただきました。(写真は、thrさんの発表風景)
発表の後、時間いっぱいまで質疑応答となり、終了後も多数の方の質問があったり、関西以外の他の地域の方も参加されていて、真剣に求めてこられている方が多いと感じました。
実に9割の方が、サイト構築にかかわっている方で、そういう意味では、こちらが想定していた方々に参加していただけたと思います。
また、4割の方がmodxを知らなかったそうですが、アンケートを見る限り、使ってみようと思われたり、何らかの興味を持っていただけたようです。
ただ、すでにmodxをお使いの方には、もの足りないものだったようで、今後、情報交換会や勉強会のようなことも企画していきたいと思いました。

■展示ブース（6階CMSコーナー）

CMSを探されている方、すでにmodxを使われている方、他のCMSをお使いの方、他の出展者の方、…、様々な方にお越しいただきました。私とthrさんだけだったので、対応しきれなかったこともありましたが、多くの方とお話できて、お互いにとても有意義であったと思います。（特にthrさんには大活躍していただきました）



午前中は小雨でした。当初は、近所ということもあり、PCを弊社オフィスから手持ちで運ぼうと思っていましたが、雨が降っていたので車を使いました。後から考えると、ここで体力を使わなくてよかったと、しみじみ思います。
次の機会には、もっと多くの方にご協力いただけるように、関西のmodxの輪が広がるよう、努力していきたいと思います。