講師：WordBench札幌の田中さんのセミナー資料はこちらです。
http://another.maple4ever.net/archives/1270/

拙記事ではセミナー内容の捕足、実務で扱うものとしての雑感などを交えます。
まだ3.0をちゃんといじっていないので、3.0についてはあくまで聞きかじりの段階であることはご了承ください。

WordPressはCMS

• 広瀬香美ブログ
• 百式
• 暮らしの手帖

WordPress3.0は6/25時点で1,121,440ダウンロード

WordPressは時系列主体のサイトに強いように思われますが、「暮しの手帖」のような時系列に添わない、個性的な一覧ページを持ったサイト構築も充分可能です。

とは言え、様々な実務案件を経験してきた視点から言えば、静的ファイルとの共存が難しい、テーマファイルの見通しが良くないなどの欠点から多人数で連携して制作するサイトにはあまりおすすめできません。

尚、私のブログもWordPressです。一覧ページの体裁が普通のブログと違っていたり、a-blog cmsベースの本サイトとインクルードで連携していたりします。

どのようなコンテンツマネージメントシステムということを知る にはそのデータ構造を知ることが早道です。
WordPress 3.0 の新機能を交えまして、まずは WordPress の データ構造を紹介していきます。

WordPressのデータ構造（記事情報）

ポストとページの二種類＝post_type

1. ポスト：時系列（日記／新着情報など）
2. ページ：固定的（自己紹介）

ポストとページのメタ情報

• タイトル
• 投稿日・投稿者
• 修正日
• パスワード
• トラックバック先
• 分類情報(カテゴリ・タグ・タクソノミー)
• リビジョン
• 等々

WordPressの記事情報は時系列とカテゴリーによって分類することを前提にした「ポスト（記事）」と、1ページごとに独立した「ページ」に分類されます。

ただ、ページでも時系列の整理が可能だったり、後述の「カスタムタクソノミー」でうまくタグ分類すると、両者の区別はほとんどつかなくなってきます。
この辺りの特徴は、MovableTypeと非常に良く似ています。

カスタム投稿

WordPress3.0からの新機能
ポスト／ページに加えて新しいタイプを定義できる

タイトル不要／日付不要／トラックバックが必要／などなど

旧来のポスト／ページもカスタム投稿のひとつとして
デフォルト実装されている＝再定義ができる

カスタム投稿機能は、マルチブログ以上の目玉機能なんじゃないかと思っています。
上の説明の通り「必要／必要ない項目」を自分で定義することが可能なので「タイトル・本文がなく、カスタムフィールドのみで構成された記事」などの大胆な構成も可能なようです。
MovableType4以降で登場している「表示オプション」に近い印象です。

管理画面上の入力項目の順番設定はできるのか、旧来のプラグインや表示パフォーマンスへの影響はないかなど気になるところもありますが、使いこなせば無償で使える軽量CMSとしての良さが増しそうです。

カテゴリーとタグ

記事に対する抽出条件のひとつ

1. カテゴリー→階層構造を持たせられる
2. タグ→フラットな分類

カスタム分類（タクソノミー）

任意のセット分類を追加できる
1サイトに複数のタグクラウドを生成できる

2.9から機能強化
ただし分類の新規作成はプラグインが必要（custom-post-type-ui）

カスタムタクソノミーは、「複数の独立した階層カテゴリーを作成できる機能」と解釈した方がいいと思います。前バージョンから概念自体は存在していましたが、3.0以降では、管理画面からの設定が可能になりました。

こちらの記事で詳しく説明されている通り、導入の手順が面倒な割に必要性が薄い機能だったりします＾＾；

カスタムタクソノミー(Custom Taxonomy)の導入と使い方 [WordPress 3.0]

その他の情報

コメント
記事に対する外部からのコメント

ユーザー権限
複数のユーザーが投稿できるようにユーザー管理ができる
購読者／管理者／編集者／作成者／投稿者
管理画面のアクセス権限や投稿、修正制限
投稿から公開へのワークフローが持てる

オプション
サイトの動作システム情報

リンク先
他サイトとのつながりを格納する情報／XFNを使える

ポストメタ（カスタムフィールド）
記事に対するここまでで出てきた以外のカスタムメタ情報を持たせる

ユーザー権限については捕足が必要です。
ほとんどの安価なCMSもそうですが、「上司」「部下」のアカウントがあって、部下が更新すると昇任者である上司に自動でメールが送られる…といった機能は、WordPress2.xの段階ではプラグインがなければできません。
MUと統合したWordPress3.0はもしかしたらできるかもしれないのですが、まだ未確認です。すいません。

2.xでの実装方法についてはこちらの記事を参照してください。

WordPress – 公開承認ワークフロー – 新規公開 | Technolog.jp

リンクの「XFN」というのは人間関係を表現したフォーマットなのですが、
なんで恋愛関係だけこんなに充実してますのん
と必要性に疑問を感じるわけですよ。ハイ。

その他の情報続き

マルチブログ
3.0から利用可能
これまでに出てきた情報を複数もたすことで、複数のサイトを持つ

データフロー
管理画面操作からのデータベースへの格納
コメント者からのコメントの投稿
トラックバック／ピンバック
XMLRPC／ATOM経由でのデータベースへの格納

出力系（テンプレートタグ）
WordPressテーマの実態
テンプレートタグはデータ構造をHTMLやRSSで出力する関数群
データの抽出を行うループ系の関数を起点に、条件取得された 情報を取得
現在は主にブラウザ用に簡単に HTML 出力する機能が提供されている

注目していたマルチブログですが、今回のセミナーではデータ構造の説明の一部にとどまりました。
MovableType4、SOY CMSのように管理画面からウィザードを介して作成できるのかと思っていましたが、現時点では外部からの.htaccessの編集などが必要なようです。
サブドメインも想定して設計されているのはありがたいところです。

Wordpress 3.0で複数ブログを使う設定 « lainforest.org

出力系の説明にある通り、WordPressのタグはテンプレートエンジンではなく、PHPの関数です。
なのでテーマにはそのまんま関数を書きます。
PHPをある程度かじれば融通が利くのがありがたいところですが、プログラマさんがWordPressのテーマファイルを見たら、ちょっと面食らうかもしれません。

プラグイン

add_filter／add_actionで既存のタグ／関数に自作関数をフックできる
既存の関数も全てフックされているので不要なものを除外できる

functions.phpでテーマ専用の関数を定義できる

※簡単に実装できる反面、プログラム構造を追うのに慣れがいる

フィルターの例

記事の特定文字列を加工し、HTMLを付与
（記事中の「hiromasa」をタグで囲む）

ショートコード
（[tegaki]〜[/tegaki]で囲んだ箇所がカスタムフォントに変わる）

アクション（template_redirect）
通常のテーマに情報を渡さず、携帯用テーマの処理をさせる（例：Ktai Style）

ウィジェット
サイドバーのウィジェットを追加する

管理画面への機能追加
3.0からの新テーマはヘッダー画像を差し替えできる

時間指定実行（wp_cron）
コアには既に予約投稿の機能がある

必要なプラグインがあったなら「コア機能に対する変更」という視点で
調査を行うと比較的簡単に実現可能

既存のプラグイン修正時もコアのどの部分に介在しているのかを調査し、
そこからソースコードを追うとわかりやすい

WordPressは「フック」という概念でコア関数を管理しています。

既存のタグに新しい関数を定義する「add_filter」と

add_filter( 'the_content', 'hogehoge' );

WordPress内の特定の処理で関数を発動させる「add_action」があります。

add_action( 'wp_head', 'hogehoge' );

「コアのどの部分に介在しているのかを調査し、そこからソースコードを追う」というのが、プログラミングに慣れていないと難しいです。
phpファイルを内部検索できるソフトなどで調べる手もありますが、
WordPressのコアファイルを公開している、こちらのサイトが便利です。

PHP Cross Reference of WordPress

ページ右上にあるサーチボックスからタグ名、関数名を入力するとどのファイルの何行目にコードがあるのか、を調べることができます。

WordPressの魅力

ブログを起源とするプロダクトだがデータ構造がシンプル
特に3.0から基本構造や分類の解放を行っているためCMSとしても使いやすくなった

個性が強いブログサイトを構築する手段としても人気があるので
テーマやプラグインに美術的なものが多く配布されている

個性をだすべく、システムもそれに答える形で拡張されていく
テーマやプラグインからの介在の余地が大きく
様々な要求に応えられるカスタマイズが可能

サイトへの導入実績が多くそのノウハウが得られやすい

WordCamp／WordBenchなどオフラインコミュニケーションも活発で楽しい

WordBenchについて

WordPress の地域コミニュティー
実はWordBench札幌としてのオフライン活動はこのOSC北海道が初めて

参加お待ちしております
http://wordbench.org/

セミナーのレポートは以上です。

田中さんが述べられているように、WordPressはPHPの知識があれば柔軟なカスタマイズができることが魅力です。
このためかデザイナーが介入しやすく、芸術品のようなテーマ、とても無料とは思えないような高度なテーマが多数公開されています。
管理画面の完成度の高さも特筆すべきところです。

一方で「安くて簡単でなんでもできる」という情報が一人歩きしてしまい、WordPressの仕様では困難な案件、ライセンス料をかんがみても他のCMSの方が安心して運用できそうな案件もWordPress前提で来ることが増えているのが、私の悩みだったりします。

そういう意味で、新機能を派手にアピールするのでなく、WordPressを更に詳しく知るための解説に徹した田中さんのセッションは好感を持ちました。

MUと統合し、更に奥深くなったWordPressはこれからも注目すべきCMSだと思います。

Twitterで記事を紹介して下さい（-人-）

ダウンロードはこちら。
Movable Typeでエントリの表示オプションを全ユーザーで同一にする。 – Junnama Online

特に設定はありません。有効にしている間、MTの動作が以下のように変わります。

• システムまたはブログ管理者が「表示オプション」を変更したタイミングで、その内容が全ユーザーに反映される
• 管理者権限のないユーザーの投稿画面には、表示オプションが出なくなる
• プラグイン有効化前に各ユーザーが個別に表示オプションを変更していても、管理者が変更をした時点で強制的に上書きされる

1. MovableType4・5・Power CMS for MTで動作を確認しています。
2. 新規アカウントを追加したタイミングでも同期される機能があったようですが、動作しないようです。現状では「表示オプションを変更したとき」のみ行われます。

かなり実務向けのプラグインなので、機能をざっと書いてもピンと来ない人も多いかもしれません。
必要な場面や技術的な捕足は、追記以降をご覧くださいませ。

MovableTypeの表示オプションの仕様について

MT4以降では、投稿画面の入力項目の表示・並び順を細かく設定することができます。
カスタムフィールドを多用するCMS的な構築には必須の機能ですが、ひとつ面倒なところがあります。

新規で記事を書くときの大まかな「項目の表示」については、各ブログの「設定」→「投稿」で前もって指定できるのですが、
投稿画面右上の「表示オプション」で指定できる「項目の並び順」に関しては各ユーザー個別となります。

つまり、MovableTypeの管理者が
入力しやすいようにカスタムフィールドの項目を整頓していても

更新担当者のアカウントでログインすると、
初期状態に戻ってしまうのです。

ブログやアカウントの数がほとんどないのであれば大した問題ではないのですが、大規模案件などでブログ10個・アカウント10個となってくると、10×10で100回分の表示オプションの設定を行わなければならないのです。

ぶっちゃけやってられま(ry

そんなときに「EntryPrefsFixer」を使うことで、下位ユーザーの環境を管理者側で簡単に整えることができます。
後々アカウントが増えたときの表示オプションの変更回数も、ブログの数だけで済みます。

技術的な捕足

このプラグインは、@Nick_smallworldさんと私(@webbingstudio)のTwitterでの会話を、@junnamaさんが見て作成してくれたものです。

@Nick_smallworldさんに許可をいただいたので、ログを技術情報として追記します。
DBを直接編集することで対応したい人や、同様のプラグインを作ってみたい人は参考にしてください。

【緩募】MovableTypeで、Aさん（もしくはシステム管理者）がカスタムフィールドの並び替えをしたときに、他ユーザー（Bさん、Cさん）も強制的にAさんの並び順にさせる方法をご存じの方、いらっしゃいますでしょうか。 11:56 PM Apr 29th

@Nick_smallworld MTの項目並び替えの件、遅レスですが私も調べたことがあるので、情報流しておきますね。この先しばらく連投になりますが失礼。 10:22 AM Apr 30th

管理画面項目の表示／非表示、並び替えは「mt_permission」テーブルの[permission_entry_prefs]がブログID、ユーザーIDをキーに管理しているらしいです。 #movabletype 10:24 AM Apr 30th

.@Nick_smallworld すいません、これの一個前Replyにしませんでした。…なのでメインユーザーのpermission_entry_prefsを他ユーザーに複製すると並び順は同じになるのではないかと考えられます。 #movabletype 10:25 AM Apr 30th

.@Nick_smallworld このことをサーバー担当の方に伝えたところそれでうまくいったぽいのですが、残念ながら私自身はまだ検証できていません。 #movabletype 10:27 AM Apr 30th

.@Nick_smallworld にっくさんのように「強制的に」と考えている場合、編集のタイミングでプラグインを起動させる／cronか別途プログラム起動で、該当DBを修正させる／という手がある気がします。 #movabletype 10:29 AM Apr 30th

@Nick_smallworld カスタムフィールドの並び順に関して私の方でわかってるのはこのくらいですが、少しでも参考になれば。てゆか誰かプラグイン作ってくれないかなあ。 #movabletype 10:30 AM Apr 30th

@webbingstudio ありがとうございました！ばっちりできました。permissionのほうに定義されていたとは気がつかず「blog_かauthor_の方だろうなー、でも項目が無いなー」と思って探していましたｗ　6:01 PM Apr 30th

@Nick_smallworld あれでできましたかー。結局、項目の表示順は全ユーザーで統一することが多いですよね。今後の案件にも役立ちそうなので、私も試してみます！ 8:52 PM Apr 30th

あと名前出せないのですが、私の検証を元に実際にDBを書き換えて動作確認してくれた当時の某社サーバー担当者様、ありがとうございましたー＞＜。

Twitterで記事を紹介して下さい（-人-）

WordPressは素晴らしいフリーテーマがたくさんあるので、それをいじるだけでもカスタマイズは習得できます。
ですが、実務的なカスタマイズに必要となる「詳しい記事情報を解析する方法」は意外と紹介されていません。

簡単に実験できるテーマもおまけにつけて、ざっくりまとめてみました。
PHPのことはあまりよくわからない…という人たちは、これをとっかかりに学習してみてはいかがでしょうか。

０：記事情報解析用のテーマ「posttest」

これは、記事情報を解析するための構文だけが書いてある、実験用のテーマファイルです。
ブログ用のテーマではないので「index.php」しかありませんがw
この先を読みながら、あなたのブログに反映して試してみてください。

記事情報解析用のテーマ「posttest」ダウンロード

１：サーバー情報を得る

サーバー情報を取得、出力します。
これはWordPressの独自タグではなくPHP標準の関数です。
※第三者が閲覧できるページで実行しないようにしてください。

<?php
	print_r($_SERVER);
?>

２：カテゴリー情報を得る

カテゴリー情報を取得、出力します。
出力内容は「$posts[0]のカテゴリー情報」なので、複数カテゴリーが指定されている可能性もあります。
また、出力結果の記事が一件もないと、この内容もNULLになってしまいます。出力結果がゼロの可能性があるけれどカテゴリーの情報を取得したい…という場合は、ちゃんと引数にカテゴリーIDを明示するようにしてください。【訂正】この関数は引数がありません。すいません。DBから直接取得した方が早いかもしれません（汗）

<?php
	$cat = get_the_category();
	print_r($cat);
?>

３：記事情報を解析

query_posts関数を実行していない状態では、
オブジェクト「$posts」にはそのページに沿った記事情報が入っています。
単純な出力は「<?php while ( have_posts() ) : the_post() ?>～<?php endwhile ?>」でできますが、PHPのforeach関数でも取得することができます。

<?php while ( have_posts() ) : the_post() ?>
<?php print_r ($post) ?>
<?php endwhile ?>

４：抽出条件の上書き

query_posts関数を使用すると、出力される記事の条件を変更することができます。
グローバル変数「query_string」を上書きするのが確実です。
※ID「5」の記事を抽出するようになっています。構文の「cat=5」のところを任意で書き換えてください

指定できるクエリについてはWordPress Codex内「query posts」の解説を参照してください。

<?php
	$Q = "&category_name=&cat=5";
	global $query_string;
	query_posts($query_string . $Q);
?>

５：the_postを再実行後記事情報を解析

query_posts関数を使用後、もう一度
「<?php while ( have_posts() ) : the_post() ?>～<?php endwhile ?>」を実行すると、記事情報が新しく定義したものに変更されます。
（３の後に４→５と実行して内容を比較してみてください）

<?php
	while ( have_posts() ){
		the_post();
		print_r ($post);
	}
?>

６：オブジェクト内容の取得

記事タイトルだけ必要な場合は、「->」でキーを指定することで、文字列で習得できます。
配列のように見えますが、$post['post_title']では取得できないことに注意してください。

<?php
	while ( have_posts() ){
		the_post();
		echo $post->post_title . '<br />';
	}
?>

７：補足

WordPressのpostに入っている値は、全てPHPエンコード処理がされています。
このため、クォーテーションやバックスラッシュが含まれる記事を関数に投入しても問題は起きません。
ただし、HTMLはエンコードされていないので、HTMLタグが反映されると危ない状況で使用する場合は
strip_tags関数やhtmlspecialchars関数を通すようにしましょう。

<?php
	while ( have_posts() ){
		the_post();
		echo strip_tags($post->post_content) . '<hr />';
	}
?>

WordPressはPHPの知識があれば、簡単にカスタマイズできるのが魅力です。
ですが、他のCMSと違ってプログラムを直に扱うため、テーマファイルの見通しが利きにくく、予想外の不具合やセキュリティホールが発生する可能性が高い側面があります。
趣味レベルなら問題ないですが、実務でWordPressを構築する場合は仕様やリスクを考慮して正しく利用したいものです。

Twitterで記事を紹介して下さい（-人-）

前回の記事で書いた通り、地図を追加する機能を標準で持っていないMovableTypeに、それを実装しようとすると、この記事を書いた時点では有力なプラグインがなく、面倒なカスタマイズが必要になります。

あんな長いチュートリアルを書いておいてなんですが、どうしてもMovableTypeを使わなければならない案件でないなら、標準で実装しているCMSを提案した方が、予算・工数の面からも確実というものです。

私が把握している、投稿画面に地図追加機能を実装しているCMSは下記の通りです。

1. a-blog cms
2. concrete5
3. bingo!CMS
4. Jimdo

このうち、bingo!CMSはYahoo!マップ、それ以外はGoogleMapsのAPI Keyを取得する必要があります。

地図の目的地を検索し、中心に持ってきて吹き出しのコメントを入力する、という操作感はどれもほぼ同じです。
尚、冒頭のスクリーンショットはa-blog cmsの画面です（私の本サイトの投稿画面なので、デフォルトとはカラーリングが異なります）。

ただし、四つのCMSは設計思想が微妙に異なっています。
a-blog cmsはMovableType・WordPressと同様に、カテゴリーや時系列のアーカイブでコンテンツを出力する更新方法が基本設計ですが、残りの三つは実際に表示されているコンテンツ内をクリックして、ホームページビルダーやDreamweaverのように、直感的に編集させる更新方法が基本になっています。

コンテンツが少なく、各ページの構成が異なるサイトであれば下の三つの方が構築しやすいですし、前の記事のような、入力フォーマットがが決まっているコンテンツを大量に生成するサイトであれば、a-blog cmsが適していると考えられます。

個人的には、MovableType・WordPressの代替として選択するのであれば、管理画面のカスタマイズのしやすさの点からも、機能面の近さからもa-blog cmsをお勧めしたいところです。

Twitterで記事を紹介して下さい（-人-）

私の場合、制作会社から依頼を請けることが多いので、そこの担当者＝ディレクター、またはその会社の、MovableType／WordPressのスキルを持つ制作の方がコードを見ることがあります。

個人でテンプレートの構築をしていた頃は、変数や独自タグを駆使してけっこう複雑なコーディングもしていたのですが、チーム制作に関わるようになってからは
「自分以外のテンプレート制作者が見ても、理解しやすい構造になっているか」
を考慮するようになりました。

特に質問されることが多いのが、自分以外には見通しが利きにくい、以下の二つです。

• 何度も使い回す関係でモジュール化して、インクルードで読み込んでいる部分
• mt:SetVarやPHPの変数を使用している部分

特にMovableTypeの「mt:Include」には多彩な機能があり、下のようにモディファイアに変数の値を渡したり、

<$mt:Include module="Module_Hoge" foo="Var"$>

（↑読み込み先の「Module_Hoge」モジュールで変数名fooに値Varが渡されます）

「mt:IncludeBlock」という、変数の値を渡すことを前提としたタグもあります。

<mt:IncludeBlock module="Module_Hoge2">
Movable Typeへようこそ！
<mt:IncludeBlock>

（↑読み込み先の「Module_Hoge2」モジュールで変数名contentに値「Movable Typeへようこそ！」が渡されます）

ですが、私はこういった変数の渡し方はできるだけ避けています。

このような変数の渡し方をコード全体に渡ってやってしまうと、モジュール側の方のコードを見て
「あれ？ここで参照されてる、変数fooってなんだろう」
と思ったときに、読み込み元と思われるベーステンプレートを上から下まで探さなければいけなくなります。
繰り返しや条件分岐などの一時変数以外は、わかりにくい場所で変数を宣言するのは避けるべきです。

私の場合、サイト内で頻繁に利用されることがわかっている固定値は、
「mt:SetVars」「mt:SetVarBlock」などを使い、テンプレートの先頭でまとめて宣言してしまうようにしています。

全テンプレートに使用する変数はやはりモジュールとなりますが、少なくとも変数について訪ねられたら
「グローバルテンプレートの『Module_Config』を見てください」
とか
「テンプレートの文書宣言の次辺りに書いてあります」
と、簡単に変数を宣言している場所を答えることができます。

モジュールの呼び出し方に関しても、

と、外側のレイアウト用のdivが残るように、かつHTMLタグを分断しないように呼び出し、各テンプレートのHTML構造を見通せるよう気を付けています。

また、複雑な条件分岐などをしているところでは、mt:IgnoreやPHPコメントなどで説明を添えることも多くなりました。

<mt:Ignore>### ○○のときは△△を表示します ###</mt:Ignore>

これまでのTipsでもう出てきていますが、変数やモジュールの命名に関しても
「Global_」や「Module_」などの接頭語を統一して、それらが何に使われているのかが名前を見ればわかるようにしているのも、テンプレートをわかりやすくするための工夫のひとつです。

…と、何だか高度なことをやっているような書き方をしましたが、これらはシステムそのものを作り、かつ日常的にチーム制作をしているプログラマにとっては、基本中の基本だろうと思います。

「デザイナー」を名乗っていると、デザインをテンプレートで再現することに集中しがちになりますが、HTML/CSSコーディング同様、テンプレートの構築もプログラミングの一種です。
テンプレートコーディングに関しても、より早い構築・改修ができるよう、定期的にブラッシュアップをはかりたいものです。

Twitterで記事を紹介して下さい（-人-）

「a-blog cms」の新バージョン、1.2.0がリリースされました。
主な追加機能は以下の通りです。

1. WYSIWYGエディタの追加
2. 絵文字の入出力に対応
3. ショッピングサイト機能(メール通知のみのシンプルなカートが標準搭載)
4. ルール(使用するテーマの条件分岐)に「正規表現」が追加
5. 出力ソースのクリーンアップ
6. モジュールの追加

入力形式にWYSIWYGが加わったことで、一般のブログやWordに慣れている更新担当者がいる案件にも対応しやすくなったと思います。
制作する立場としては、やはりルールの正規表現対応や、モジュール追加が興味深いところです。
導入事例紹介のページもどんどん厚みを増しているので、今後が楽しみです。

前の記事にもある通り、私＝WebbingStudioは、a-blog cmsのビジネスパートナーになりました。

制作会社ではなく、しかも自分からCMSを選択する機会が少ない個人事業主の私がどうしてa-blog cmsを支援することにしたのかというと、
「制作会社・クライアント双方の意識を変え、成長させる」
可能性に強い興味を持ったからです。

制作会社側の意識

MovableType・WordPress（特にWP）での小規模な構築案件を重ねると、制作者はこんな考え方に慣れてきてしまいます。

• テンプレート化すると、もうDreamweaverなどのオーサリングソフトで編集できない
• HTML・CSSを完全に完成させてからでないと動的部分に手をつけられない
• コンテンツは全てCMSの管理下に置くものだ
• 管理画面・投稿画面は配置が決まっているものだ

大規模な案件を経験するとわかってくることですが、デザイン性が高く、かつクライアントが更新する可能性がほぼないコンテンツを無理にCMSの管理下に置く必要はありません。
ぶっちゃけ、ウェブページテンプレートなんぞなくてもいいのです。
むしろ今後更新依頼をもらえる余地を残しといた方が(ry

一般のブログ的なCMSは、これら静的コンテンツを動的コンテンツと切り分けるのが難しくなっていますが、a-blog cmsは特に意識しなくても、同時にオーサリングソフトで一括管理することが可能です。
（実際、私の本サイトのうち「About」と「Work」は普通の静的コンテンツです）

また、a-blog cmsは投稿画面も制作できるため、いかに更新担当者が作業しやすくするかを考えることで、「インフォメーションアーキテクト」や「アクセシビリティ」に対する意識も持つことができます。
これらは、今後のWEBデザイナー・コーダーに必須のスキルになっていくと思います。

プログラマはCMSに対する考え方が異なるので、彼らが加わるとまた事情が変わってきますが、少なくともプログラマがいない制作会社／プログラマが必要ない案件のワークフローを激変させる可能性を、a-blog cmsは持っているのです。

クライアント側の意識

私のように制作会社から協業依頼を請ける場合、はじめからMovableTypeに決まっている案件がひじょうに多いです。
クライアントが以下のような固定意識を持ってしまっているパターンも散見されます。

• MovableType以外のCMSを知らない
• 管理画面の配置が公開サイトと違う＝CMSとはそういうものだ
• MovableTypeとかいうのが有名だし実績も多いからとりあえずこれを採用すれば無難だ

もちろんMovableTypeは拡張性が高く安定した、良いシステムです。
管理画面の編集も可能です（a-blog cmsほど直感的でないですが）。
ですが、提案する側が「MTを前提としたディレクション」を行ってしまうのは、カスタマイズを扱う私としては、あまり良い傾向とは思えません。
更新手順が複雑になってしまっては意味がないです。

MTと同様に拡張性が高く、かつ設計思想が異なるa-blog cmsを選択肢に挙げることは、クライアントの意識を変えられる可能性もあるのです。

CSS Nite LP6に参加する前から、何らかの国産CMSをMovableType・WordPressと同様にサポートしようと検討してきましたが、私のお仕事の傾向もあって、最終的に、a-blog cmsがメインとなりました。

a-blog cmsは、制作会社とクライアントを「成長させる」CMSです。

a-blog cmsを触ってみてください。

Twitterで記事を紹介して下さい（-人-）

WebbingStudioのメインサイトを、MovableType4からa-blog cmsにベースを変えてリニューアルしました。

商用ブログ ホームページ作成 CMSデザイン 札幌のWebデザイナー | WebbingStudio

a-blog cmsは、Dreamweaverを使ってスムーズな構築ができるのと、管理画面とカスタムフィールドを一括してカスタマイズできる点に惹かれて選びました。
既存のテーマファイルは流用せず、いったん静的コンテンツで作成してからCMS化する、実務的な手順で構築しています。

今後、a-blog cmsのデモサイトとして、カスタマイズした投稿画面、テーマファイル内のコード・モジュール設定の公開などを行っていく予定です。
もちろん私自身もまだわからないことが多いので完璧な内容ではないですが、a-blog cmsを勉強中の方の参考になれば幸いです。

追記以降はデザインの話など。

6月頃に、「これまでの自分がやらなかったデザインに挑戦してみよう」と思ってデザインをリニューアルしたものの、やっぱりそれは本来の私のテイストではないわけで、納得が行きませんでした。
なので今回は、素材配布やFC2の共有テンプレートを作っていた頃の原点に戻り、ベクターグラフィックを多用し、背景素材・イラスト以外を全てモノクロでまとめた、シンプルなサイトにしました。

また、画風が固まってきたのでイラストの案件も受けられるようにと、サイト内にイラストを多用しました。
これまできちんと公開してこなかった自分の顔も、イラストでかなり近いものを載せています。

背景画像はコンテンツごとに異なっているのですが、一部はFC2の共有テンプレートで配布していた素材をリメイクしたものです。

• About　・・・　beads
• Work　・・・　lace
• Information　・・・　cycle

Informationの背景画像(cycle)は、他のコンテンツと雰囲気が異なっています。
子供っぽさを感じる方もいるかもしれません。

これは私が好きな北海道のマジックアワーをイメージして描いたもので、趣味でサイトを運営していたころから繰り返しリメイクしています。
思い入れの強いモチーフなので、敢えて加えました。

最後に、このブログを見に来ている方は気付かなかったと思いますが、IE6非対応となりました。
暇な方はIE6でアクセスしてみてください。閲覧はできますが専用のメッセージが出てひどいことになります。
どこに透過PNGを使用しているかわかって面白いかもです。

最近は、IE7以降へアップグレードする人も増えてきました。
私のメインクライアントは「制作会社」か「ネットリテラシーの高い個人」なので、自分のサイトでは切り捨てる決断をしました。
もちろんお仕事では忌々しいと思いつつも、もうしばらく対応していきますけどね…

相変わらず長い記事を、ここまで読んでいただいた方、ありがとうございます v_v
これからも少しずつ、WEB制作者として精進していきたいと思います。

Twitterで記事を紹介して下さい（-人-）

私の本サイトでは、トップページ下部にTwitterとはてなブックマークの新着を掲載していました。
a-blog cmsに移行する新サイトでも引き継ぐ予定です。

a-blog cmsはテーマファイル内にPHPスクリプトを直接書くことはできませんが、外部のRSSを整形して表示できる「Feed_ExList」モジュールがあります。
これを使えばすぐ移行できる…と思ったのですが、うまく表示できません。

TwitterのRSSは本文が全てURLエンコードされているため、デコードされずそのまま出力されてしまいます。
はてなブックマークはRSS1.0(rdf)形式なので、Feed_ExListモジュールのサポート外です。

2009.11.10追記：
開発元様に、[urldecode]という校正オプションを教えていただきました！
Twitterに関しては、{description}[urldecode] と記述すればFeed_ExListモジュールが使用できます。
リファレンスに追加されていますので、こちらも参考にしてください。

もしかしたら解決方法があるかもしれませんが、今回のところはビルトインモジュールを使うのを断念し、これまで使っていたPHPスクリプトをそのまま自作モジュールに変換する方法を取りました。

追記以降で配布しますので、とりあえずTwitterやはてブの新着を掲載したい方、モジュール作成について勉強したい方はご利用ください。

Getdataモジュールについて

このセットは、下記の外部コンテンツをリストアップするモジュールを追加します。

1. 【Contents】　任意URLのファイル内容全て
2. 【Twitter】　任意IDのTwitter新着
3. 【HatenaB】　任意IDのはてなブックマーク新着（コメントを含む）

「Getdata」モジュールは、こちらからダウンロードできます。
http://webbingstudio.com/souvenir/acms_module/Getdata.zip

モジュールの作成方法は、開発元のコンテンツを参考にしました。

• a-blog cmsのモジュール | 拡張機能の開発 | a-blog cms
• a-blog cmsのモジュールの書き方 その1 － kazumich.log

使用方法

解凍直後の状態では動作しません。
フォルダを、php > ACMS > GET > Getdata　と開いていき、最下層に入っている 「Contents.php」「Twitter.php」「HatenaB.php」の必要な箇所を編集してください。

1. Contents.php・・・読み込み先のURLを指定
2. Twitter.php・・・TwitterIDを書き換える（注意：二ヶ所あります）
3. HatenaB.php・・・はてなIDを書き換える

編集したら「php」フォルダごと、a-blog cmsを設置したディレクトリに転送してください。

テーマファイルへの記述

下記のように記述するだけで動作します。
Contentsは読み込み元がそのまま、Twitter・HatenaBはリンク付きのul要素で出力されます。

<!-- BEGIN_MODULE Getdata_Contents -->
<!-- END_MODULE Getdata_Contents -->

<!-- BEGIN_MODULE Getdata_Twitter -->
<!-- END_MODULE Getdata_Twitter -->

<!-- BEGIN_MODULE Getdata_HatenaB -->
<!-- END_MODULE Getdata_HatenaB -->

注意

※下記の関数が有効になっているサーバーでなければ動作しません。
Contents・・・file_get_contents関数
Twitter / HatenaB・・・file_get_contents関数・SimpleXML関数

※Getdata_Contentsモジュールは、対象のHTMLファイルの内容全てを「そのまま」出力します。エンコード・サニタイズも一切行いません。対象URLの内容を確認のうえ、慎重にご利用ください。

※このモジュールは試作品です。今後のa-blog cmsのバージョンアップで、不要となる可能性があります。
商用・非商用を問わず、自由にご利用ください。

注意に書いてある通り、PHPのfile_get_contents関数は便利ですが、有効にする際は慎重に取り扱わなければいけません。
もしも悪意ある第三者にPHPファイルを改ざんされてしまった場合、サーバー内の重要データを持っていかれてしまう可能性もあるからです。

ですが、a-blog cmsは一般に公開されているコンテンツにPHPスクリプトを記述せず、深い階層で一括管理を行うので、WordPress等のテーマに直接PHPを書けるCMSよりもやや学習コストがかかる分、安全と言えます。

開発元のブログや私のモジュールを見ればわかりますが、単に出力するだけならとても簡単に作れます。
（テキストをランダムに出力するとか）
皆さんも挑戦してみてください。

Twitterで記事を紹介して下さい（-人-）

「WebSite expert」26号でも巻頭特集が組まれ、
イメージキャラ「まめ蔵」も舌好調（夜はツンデレ属性に変化する）のSOY CMSですが、私が本サイトを置いているエックスサーバーは動作環境を満たしていませんでした。

会社に要望を出しても、個別対応は承っておりません、のつれない返事。
それなら無理やり設置してやる！と
「エックスサーバーにSOY CMSをインストールする」という検証記事を書いたのが数か月前。
インストールまでは成功したのですが、管理画面の不具合が直らず断念していました。

そんなSOY CMSが、先月の1.2.6へのバージョンアップで、ついにエックスサーバーでも正常に動作するようになりました！
インストーラーなし・SQLite版で基本的な動作を確認しています。
開発の皆様、ありがとうございます。

設置手順は以前書いた記事と変わりませんが、不具合を回避する作業がひとつ増えます。
SOY CMSフォーラムのスレッドを更新していますので、詳細はこちらをご参照ください。

エックスサーバー(X20)にインストールする方法について

また、正常に動くようになったとはいえ「動作環境を満たしていないサーバーに強引に設置している」という状況は変わりません。
設置する場合は、使用予定の機能・プラグインをチェックしなおしてくださいね。

Twitterで記事を紹介して下さい（-人-）

個人の非商用に限り、a-blog cms は無料でご利用頂ける事になりました | a-blog cms

これまで30日間限定の試用までしかできなかったa-blog cmsが、個人非商用であれば自由にダウンロード・利用できるようになりました。
評判がいいらしいけど、忙しくて30日じゃ検証しきれない…と思っていた方、とりあえず趣味で使ってみたいんですが、という方は是非お試しを。

ちなみに私は、30日間の試用期間ではほとんどいじれなくて結局ライセンス取っちゃいましたwちきしょうめwww

今回のアップルップルさんの英断を、私は金銭面とは違うところでとても期待しています。
私が把握している範囲では、a-blog cmsというのは「じわじわ良さがわかってくる」CMSであるからです。

a-blog cmsは「Web制作者のためのCMS」と銘打たれています。
特にアピールされているテンプレート仕様や、投稿画面もカスタマイズできる点などを見ると、なるほどと思います。

ですが、スキルがあればなんでもありになりつつあるMovableTypeやWordPress、やたら構築方法がわかりやすいSOY CMSと比べると、「何がどういいのか」をなかなか一言で説明できない面があります。

その「じわじわくる良さ」の例をひとつ。

二人以上のチームを組んでお仕事をしている制作会社は多いと思います。
大規模なCMS構築の場合、制作を始める段階でテンプレートの構成等をきちんと書類化して、擦り合わせをしてから始めるのですが、諸々の事情で、かなりの確率で途中変更が入ります。

そのひとつ、
「特定のカテゴリーの記事を書いたときだけHTMLの構造を変えたい」
という話になり、その構造を変える範囲が広い場合。

CMSがMovable Typeの場合で、ディレクターがコーダーにどう指示を出すかを考えてみました。

意味がわかんねえよという人すみません…
MovableTypeは専門用語多いんで…＠＠；

これが、a-blog cmsだった場合、たぶんこうなります。

どこが違っているかわかるでしょうか。

まず「条件分岐」について全く触れていません。
a-blog cmsには「ルール」という機能があり、特定の条件下で表示するテンプレートを、管理画面側でごっそり変えてしまえるのです。
（もちろん、変わる箇所が少ない場合は他のCMSと同様のテンプレート内条件分岐が使えます）
なので、コーダーにテンプレートさえアップしてもらえば、あとはディレクターが管理画面に入って
「カテゴリーが○○のとき」「bbb.htmlをテンプレートに使用する」
という設定を追加するだけなのです。

もう一点が
「画像のリンク切れについて触れていない」のと
「putしてと指示している」ことです。

Dreamweaverでは、FTP等を使ってサーバーにファイルをアップすることを「PUT」と呼びます（コマンドラインと同じですね）。

「PUT」は、SOY CMSのカスタマイズ解説のときにも触れましたが、サーバーとローカルの構造を同じに保ったままファイルをアップします。
なので、実際のサイトルートとは違う箇所にテンプレートをアップしなければならない一般のCMSでは「PUT」を使うことができません。
テンプレートができたらドラッグか他のFTPソフトでアップして画像やリンクが切れてないかチェック…となるわけです。

ですが、a-blog cmsはいろいろなところで紹介されている通り、画像やJavaScriptも含め、全てのサイト構造を崩さないままテンプレート化できます。
なので、Dreamweaverのサイト設定時に
「サイトのルート＝a-blog cmsのテンプレートを置くディレクトリ」
とすれば、あとは画像のチェックもほとんど必要なく、更新しては保存→PUT（自動化してもいいかもしれないです）でサクサク進められるのです。

私のようにひとりで作業するのであれば、自分の中でワークフローが確定していればいい訳ですが、多人数の場合は意思の疎通が大変です。
それを大幅に軽減できる可能性があるというのが、a-blog cmsのすごいところであり、なかなか他の人に説明しようとしたとき、わかってもらえないところです。

とにかく皆さん、なんか作ってみてください。
放置サイトがあるなら、それを動的化してみるだけでもいいと思います。

「もう、MTでいいじゃん」というjunnamaさんの名言があります。
まあそれも確かに正論ですが、
「これでいいのか？」
「もっと良い作業の進め方があるのでは？」
「この案件には別のCMSの方が良くね？」
と考える機会を持つことが、この流れの速い業界では必要なことと思います。
いいじゃんなどと言っていいのは、junnamaさんのようにそのCMSにどっぷり浸かる覚悟がある人だけです。

a-blog cmsは、「用語の統一」が徹底している点も評価できると思います。
マニュアルインデックスを見ると、ほとんどの主要な独自タグにタグ名と口語名が併記されています。

CMSの細かいところについて、人にメールや口頭で説明するのはなかなか難しいものです。
こういった地味でも重要なポイントが、今回のoneライセンス自由化でもっと評価されてほしいと思います。

Twitterで記事を紹介して下さい（-人-）