テンプレートをこのデバイスにはこっちを表示、あのデバイスにはあっちを表示、と変える必要があることがあります。
実現する手段はまぁ色々あります。

が、下記の条件にマッチする手段がなかなか見つからないので自分で書きました。

• テンプレートの設定は変えたくない
• 特定のデバイスで表示するときに一時的に変えるだけ
• フォルダは通常のテンプレートと同じフォルダで管理したい

-

さて、Wordpressをクライアントワークに使っていると、管理画面のロゴにクライアントのロゴを入れたくなると思います。

しかし、たったそれだけのためにやたらと高度な管理画面のカスタマイズ用プラグインを導入するのもいささか面倒くさい。それに、プラグインでロゴを変えてしまうと、DB側にその情報が保存されるのでテスト環境から本番に持って行ったときに設定をやり直したりする必要が出てきて、これもまた面倒くさい。

ということで、今回はプラグインにたよらずにテンプレ側からロゴを書き換える手段をご説明しようと思います。これならテンプレを本番環境に入れるだけで管理画面のロゴも変わってくれるのでらくちんです。

さて、管理画面の左上のロゴはHTML内で id=”site-title” でマークアップされています。
ということはCSSで#site-titleと書けばロゴ画像などのスタイルの上書きができるということです。ただ、単純にテンプレのCSSに書いても、管理画面側ではそれは読み込まれないので、管理画面側に書いたCSSを埋め込まれるようにしなければいけません。

ということで下記のコードをテンプレートフォルダ内のfunctions.phpに追加します。
これにより管理画面が表示された際に、footerの後ろに下記の<style>タグが埋め込まれて、既存のCSSが上書きされ好きなロゴを設置することができます。

※ *〜〜*の所は適宜適切なものに置き換えてください。

function add_admin_style () {
$style = <<<___END___
<style type='text/css'>
#site-title {
display: block;
text-indent: -1000px;
background-image: url(../wp-content/themes/*テンプレ名*/*ロゴファイル名*); 
background-repeat: no-repeat; 
width: *ロゴの横幅*;
height: *ロゴの縦幅*;
}
/* ヘッダの余計なモノを消す */ 
#header-logo, #privacy-on-link { display: none; }
</style>
___END___;
echo $style;
}
add_action('admin_footer', 'add_admin_style');

ついでにログイン画面にあるロゴも変えてしまいましょう。

ログイン画面のロゴは #login h1 a で指定できるので、下記のコードをfunctions.phpに追記することで上書きが可能です。

function add_login_style () {
$style = <<<___END___
<style type='text/css'>
#login h1 a {
    background-image: url(wp-content/themes/*テンプレ名*/*ロゴファイル名*);
    width: *ロゴの横幅*;
    height: *ロゴの縦幅*;
}
</style>
___END___;
echo $style;
}
add_action('login_footer', 'add_login_style');
</code>

ということで、お手軽にテンプレ側からロゴを書き換える方法のご説明でした。

なお、原理的には footerにstyleタグを加えているだけですので、ロゴ以外のCSSも当然書き加えることができます。文字色を変えたり余計なものをdisplay:noneで消したりと、応用範囲は広いと思います。管理画面のCSSをいじりたくなったら、ぜひこの方法を思い出してみてください。

ではでは、@nihimoto でした。
何かご質問等などあればtwitterまでお気軽にどうぞ。

P.S.

それにしても、プラグインの保存先が基本的には全部DBなのはなんとかならないものでしょうかね。
全プラグインで統一的なフォーマットで設定値を吐き出せるような処置があれば、テスト環境から本番環境への移行を気にして、無理やりテンプレ側にデータを記載する必要がなくなるのですが・・

WordPressは非常に使い勝手がよく、トライアドでもサイトを構築する際にはお薦めをさせてもらってます。
デフォルトのままでも良いのですが、せっかくなのでクライアントごとにカスタマイズした方が、ビジネスをしていく上で効率よく活用できるサイトになるかなと。
そこで、トライアドでも利用しているプラグインを紹介していこうかと思い、その１としてこれを。

■Adminimize
Wordpressはデフォルトでユーザーに権限を割り当てられます。

・管理者
・編集者
・投稿者
・寄稿者
・購読者

これでも十分かと思いますが、編集者でもカスタム投稿を利用していると、ここは不要だとかここは必要だとかなるわけです。
管理画面に表示・非表示させる項目や投稿の細かな権限設定など、ちょっとオーバースペック気味ですがあると便利なプラグインです。

使い方はいたって簡単で、管理画面 > プラグイン > インストール済みプラグインで有効化してあげるだけ。
そうすると、設定のメニューにAdminimizeという項目が表示されます。
ちなみに、管理画面の一部はこんな感じ

チェックボックスにチェックをするとその機能がoffになる仕組みなので、非常に簡単に操作できデザイナーの方が作業するときも簡単に扱えます。
画像はデフォルトのWordpressにプラグインを入れただけなので特にメニューに変わりがないですが、カスタム投稿タイプを利用したときはメニューが表示され管理することができるようになります。

例えば、制作の都合上カスタム投稿タイプを利用した際に、権限の違いでカスタム投稿タイプのメニューを非表示にさせたい時があると思います。
その時に、制作会社が管理者権限を持ち、クライアントが編集者権限を割り振り、Adminimizeで不要な項目を編集者権限には非表示と設定してあげることができます。
こうすることで、うっかり操作ミスで削除などの事故などを未然に防ぐことができ、また、クライアントにしても不要なメニューがないだけで非常に管理しやすくなると思います。

非常に小さなことですが、こうすることでサイトのメンテナンス性が向上し、運営者（クライアント）にとって有益なサイトになると思います。

ただ、昨今の制作事情を考えると・・・

表示部分により制作の時間を費やしたい！
管理画面（ユーザー権限）のカスタマイズ費用までは請求できない！

と、なりなかなか管理画面の制作費まで予算が回らないのが現状です。
そんなときに、Adminimizeは非常にありがたいプラグインになっています。

と、いろいろ書いてきましたが、管理画面をカスタマイズできるプラグインはこの他にたくさんあります。
ではなぜ、管理画面をカスタマイズするプラグインはたくさんある中でこれを紹介したのか。
実は理由があってこのプラグインを紹介しました。
その理由については・・・次回に紹介します。

-

さて、Wordpressで記事の投稿画面をカスタマイズして、投稿記事の内容に合わせて便利に投稿できるようにするツールとして、定番のカスタムフィールドテンプレートというプラグインですが、もちろん私どもも使わせていただいております。感謝感謝。

しかしながら、ちょっと不満な点が出てきてしまいました。

このカスタムフィールドテンプレートというプラグインの設定値はDB側に保存されます。

ということは、インストール後は設定が空っぽなので環境毎に設定を行う必要が出てきてしまい、少々面倒くさい。まだ一人でやっているうちはいいのですが、複数人で作業をしておりテスト環境が分散してしまうような時はなおさらです。

できれば、カスタムポストタイプやカスタム分類などと同様に、設定値をテンプレファイル側でもてないだろうか？そうすればテンプレのコピペだけで全ての環境に設定を反映することができます。

と、いうことで、強引になんとかしてみました、というのが今回のネタになります。

-

やり方を大雑把に言うと、このプラグインはDBのオプションに、custom_field_template_dataという名前で設定値をまとめて保存しているので、プラグインが起動する前にその設定値をテンプレ側で用意した値に差し替えてあげればOK。
ということで、テーマフォルダ内のfunction.phpに下記を追記します。

function overwrite_custom_field_template_data () {
    $custom_field_template_data = get_option('custom_field_template_data');
    $custom_field_template_data["custom_fields"] = array(
        array(

            // 有効/無効スイッチ
            "disable" => 0, // 1: 無効  0:有効

            // テンプレートタイトル
            "title" => "サンプル",

            // テンプレートインストラクション
            // * 説明？？？
            //"instruction" => "", 

            // 投稿タイプ
            // * デフォルトの投稿タイプによって適用範囲を指定する
            // * 投稿:"post"  固有ページ:"page" 両方:""
            //"post_type" => "post",

            // カスタムポストタイプ （カンマ区切り）
            // * カスタムポストタイプで適用範囲を指定する
            //"custom_post_type" => "post1,post2",

            // Post ID （カンマ区切り）
            // * POST ID（記事番号）で適用範囲を指定する
            //"post" => "111", // POST ID 指定

            // カテゴリーID （カンマ区切り）
            // * カテゴリで適用範囲を指定する
            //"category" => "cat1,cat2", // カテゴリ指定

            // ページテンプレートファイル名 （カンマ区切り）
            // * 使うテンプレを指定できる????
            //"template_files" => "moge.php",

            // テンプレートコンテンツ:
            // * 使用するカスタムフィールドの設定
            // * 使用できる値は設定画面の「オプションリスト」を参照してください
            "content"   => <<<___END___
# 「カスタムフィールドテンプレートオプション」項の設定はwp-content/themes/functions-common.php によって上書きされています。管理画面からは更新できませんのでご注意ください。

[Plan]
type = text
size = 35
label = Where are you going to go?

[Plan]
type = textfield
size = 35
hideKey = true

[Hidden Thought]
type = textarea
rows = 4
cols = 40
tinyMCE = true
htmlEditor = true
mediaButton = true

[File Upload]
type = file
___END___
        ),
    );

    // var_dump(get_option('custom_field_template_data')); // debug
    // delete_option('custom_field_template_data'); // debug
    update_option('custom_field_template_data', $custom_field_template_data);
}
overwrite_custom_field_template_data();

※ //から始まる行はコメントです
※ 一部の設定値がコメント化されているので、必要がある場合には//を外して有効化してください
※ 設定内容はもちろんあなたのブログに合わせて変えてください
※ 設定値の書き方はコメントで説明している通りか、設定画面の同一の設定値名と同じです

これで、管理画面側で行われた設定値が、このテーマフォルダ内のfunction.phpに記載した設定値で上書きされるようになりました。同一のテーマを使っている限りいつも同じカスタムフィールドテンプレートの設定になります。

環境毎に設定を行ったり、設定内容を周知しなくてもいいので大変便利ですね。

ではでは。

-

本日はjQueryMobileネタで一つ。

jQueryMobileはお手軽にスマートフォンサイトっぽくしてくれる便利なものですが、デザインのカスタマイズを高度に組み込んでると、強制的に適用してくるスタイルが邪魔になったりしませんか？
しかもスタイルが適用されるクラス名とかがわからないので、解除するのもなかなか厄介なんですよね。

実はあのスタイルは、jQueryMobieのJavascriptをロードした際に、自動的に専用のクラス名を各要素に割り振り、そのクラス名に対してjQueryMobileがスタイルを適用しているので、普通にスタイルシートに書いただけだと、後からスタイル上書きされちゃうんですよね。

今回はこの問題に対処する方法を説明してみたいと思います

-

まず、第一の方法は data-role=”none” 属性を使います。
要素に対してdata-role=”none”と書くことで、その要素へはスタイル指定が行われず、ブラウザのデフォルトのまま表示されます。

たとえば図の入力欄で言えば、

<input type=”text” name=”20″ value=”" size=”20″ data-role=”none” />

と、こうなります。
jQueryMobileの基本機能の一つとして持っているものなのでおすすめです。

-

ただ、この方法は、一個の要素にだけ適用するならいいのですが、たくさん要素があって全部にいちいちdata-role=”none”を書くのはいかにも面倒くさい。

そんな時は下記のコードをheaderタグの中に書いてあげてください。

<script type="text/javascript"><!--
$(document).bind('mobileinit',function(){
    $.mobile.page.prototype.options.keepNative
        = ".data-role-none, .data-role-none *";
});
// -->
</script>

※このコードは必ず jquery-***.js の読み込みと、jquery.mobile-***.js の読み込みの間に記載してください。jsの実行順が違うと動作しません。

スタイルシートのセレクタの形式でkeepNativeという設定値に記載すると、その要素に対してはスタイルの適用が行われません。そこで、keepNativeにdata-role-noneクラスと、その子要素全てを指定しています。

これにより、たとば <form action=”index.php” method=”get” class=”data-role-none”> というformタグを書けば、そのフォーム内の要素は全てスタイルが適用されません。formでなくても<div class=”data-role-none”>〜</div> とかでもいいと思います。

状況に応じて、data-role=”none” と class=”data-role-none”を使い分ければそれなりに便利になるかなと思いますので、試してみてください。

なお、JS内のセレクタは状況に応じて自由に書き換えられますので、追加したければカンマ区切りで自由に追加して問題ありませんし、邪魔なら削除しても問題ないです。

-

以上となりますが、いかがでしたでしょうか。

本件に関しまして何か情報や質問がありましたら @nihimoto までご連絡いただけるととてもうれしいです。よろしくお願いいたします。

-

※ちなみにFirebugsなどの開発ツールを使えば、jQueryMobile動作後の特殊クラス名を割り出すことはそんなに難しくなくできるので、それのクラス名に対してスタイルを適用すれば上書きは可能です。ただ、なぜか上書きできない場所もあったり、共用で使ってるクラスもあったり、トラブルの元になるのであまりおすすめはできません。

※参考：Preventing auto-initialization of form elements
http://jquerymobile.com/demos/1.0b2/#/demos/1.0b2/docs/forms/docs-forms.html

※あとついでにですが、このdata-role以外の部分のデザインはdata-role=”page”を割り当てているタグにdata-theme=”xyz”などの存在しないdata-themeを指定してあげると、大部分のデザインが解除されます。特に色指定あたり。それでも取りきれないのは先述のクラス名割り出しからのスタイル上書きをするしかないっぽいけど・・（未確認）

ついでに、テレビ買ったこと無い歴も32年に伸びました。たぶん50年くらいまで行けるんじゃないでしょうか。がんばります。

-

さて、今回のネタはWordpressについてです。
wordpressは非常に便利に使えるCMSなのですが、時折融通が効かなくて苦労します。
特に 融通が効かないと思うのは、ビジュアル／HTMLエディタです。

勝手に<p>タグ付けるわ、連続する<br />タグを<p>にまとめるわ、<iframe>タグは削除するわ、なかなか堅苦しい仕様です。もちろん文法的にはそうあるべきなんですが、もう少し臨機応変にやってくれよと言いたくなります。

これらの問題は、昔からある問題なので、当然のことながら先達たちがプラグインを作ったりして対処方法を用意してくれています。ありがたいことです。

-

ところが、スマートフォン対応のサイトを作るに当たって、jQuery Mobileを使ったテンプレートを作ってみたところ、あまり例のなさそうな（Google調べ）トラブルに遭遇しました。

jQuery Mobile ではタグに独自の属性値の data-role=”page” などをつけて、各タグのjQuery Mobileの中での取り扱いを決めていくのですが、これをなんとWordpressのエディタは削除してしまいます。

確かにHTMLの中では正しい記法ではないので(data-*** という書き方は HTML5 では Custom Data Attributeという正しい記法だそうです)消されても文句は言えないのですが、それでは困るので対処してみたいと思います。

-

対処方法としては、data-roleやdata-themaなどのひとつひとつの属性値に対処したりするのは調べる手間がもったいないので、エディタのデフォルトの設定を変えて、「どんな属性値でも許可する」という変更を加えてみたいと思います。

そのために下記のコードをテンプレートのfunctions.phpに貼り付けます。

if ( !function_exists('pnd_allow_all_attr') ) {
    function pnd_allow_all_attr ($init) {
        $ext_elements = '';

        $target_elements = array(
        'a', 'b', 'base', 'big', 'blockquote', 'body', 'br', 'caption', 'dd', 'div', 'dl',
        'dt', 'em', 'embed', 'font', 'form', 'h', 'head',  'hr', 'html', 'i', 'img', 'input',
        'li', 'link', 'meta', 'nobr', 'noembed', 'object', 'ol', 'option', 'p', 'pre', 's',
        'script', 'select', 'small',  'span', 'strike', 'strong', 'sub', 'sup', 'table',
        'tbody', 'td', 'textarea', 'tfoot', 'th', 'thead', 'title', 'tr', 'tt', 'u', 'ul',
        'iframe'
        );
        $target_attr = array(
            '*'
        );

        foreach ($target_elements as $target_element) {
            $ext_elements .= ",".$target_element."[".implode('|',$target_attr)."]";
        }

        if ( !empty($ext_elements) ) {
            if ( !empty($init['extended_valid_elements']) )
                $init['extended_valid_elements'] .= $ext_elements;
            else
                $init['extended_valid_elements'] = trim($ext_elements, ',');
        }

        return $init;
    }
    add_filter( 'tiny_mce_before_init', 'pnd_allow_all_attr', 100 );
}

これでWordpressのエディタは、コード内のリストに含まれるタグでは、どんな属性値が渡ってきてもそれを消したりしないようになりました。

簡単に動作を説明すると、WordpressのエディタはTinyMCEという別のオープンソースのプロダクトを、多少のカスタマイズを加えつつ取り込んでいます。

このTinyMCEというエディタは多様な設定を持っていて、エディタ内で取り扱うべき正しいHTMLタグや属性値がなんなのかも設定値として持っています。その設定値をextended_valid_elementsという値で上書きできるので、ここに考えられるHTMLタグを全部、属性値は「*」を渡す処理を作っています。

そしてadd_filterでエディタの初期化が行われる都度その処理が行われるようにすることで、属性値が一切削除されなくなります。

-

と、言うことで、これでjQuery Mobile等の独自属性値を使う時に、エディタがそれを消す問題は解決できます。ぜひお試しいただき、何かご要望やご意見などありましたら@nihimotoまでご連絡ください。

それと、今回はテンプレ関数側に追加する形で説明を行いましたが、これでは導入が面倒なので機会を見て正式にプラグイン化しようと考えています。プラグイン化しましたら改めてこのブログで報告いたしますのでぜひご利用ください。

ではでは 。

まずはゴーストが起きる前の現象になります。
なぜかって？
ゴーストの前はもっと分かりやすくレイアウト崩れが起きたからです。
3コラムのレイアウトをfloatを利用して実現しようとしました。
レイアウトのためにdivでコンテンツを囲い、widthで幅を設定してからfloat:left;をそれぞれに設定しました。
コンテンツ自体は横並びになってくれましたが・・・一番右側のboxで不可思議なことが発生しました、画像がdivの外に大きくはずれて表示されました。

書いたソースコードはコレです。

<div class="clearfix">

<!-- left box -->

<div class="BoxLeft">

<h3>タイトル</h3>

<p>説明文</p>

<h4>サブタイトル</h4>

<dl>

<dt>定義語</dt>

<dd>説明</dd>

</dl>

</div>

<!-- end left box -->

<!-- center box -->

<div class="BoxLeft">

<h3>タイトル</h3>

<p>説明文</p>

<ul>

<li>注意書き</li>

<li>注意書き</li>

</ul>

<p><img src="img/image01.jpg" alt="" /></p>-->

</div>

<!-- end center box -->

<!-- right box -->

<div class="BoxRight">

<h3>タイトル</h3>

<p>説明文</p>

<ul>

<li>注意書き</li>

</ul>

<p><img src="img/image02.jpg" alt="" /></p>

</div>

<!-- end right box -->

</div>


特に問題ないと思いますが、IE6でfloatを指定している要素に、marginを設定するとバグが発生することは覚えていたので、すべてpaddingに修正して再度確認してみました。

・・・直りません。

何が問題か検討がつかず、順番を変えてみたりしましたが、見事に一番右側に配置したときにだけこの問題が表示されました。

う〜ん、こうなれば常套手段としてdiv内の要素を非表示にしてみようとコメントアウトしていきました。

<div class="clearfix">

<!-- left box -->

<div class="BoxLeft">

<h3>タイトル</h3>

<p>説明文</p>

<h4>サブタイトル</h4>

<dl>

<dt>定義語</dt>

<dd>説明</dd>

</dl>

</div>

<!-- end left box -->

<!-- center box -->

<div class="BoxLeft">

<h3>タイトル</h3>

<p>説明文</p>

<ul>

<li>注意書き</li>

<li>注意書き</li>

</ul>

<p><img src="img/image01.jpg" alt="" /></p>-->

</div>

<!-- end center box -->

<!-- right box -->

<div class="BoxRight">

<h3>タイトル</h3>

<p>説明文</p>

<ul>

<li>注意書き</li>

</ul>

<!--<p><img src="img/image02.jpg" alt="" /></p>-->

</div>

<!-- end right box -->

</div>

 

ここで、新たな問題が発生しました!!!
なぜか、最後のdiv内にある文章の末尾がboxの幅を超えて表示されてしまいました。

ソースコード上にもこの文字は記述されていないので、試しにカーソルで選択してみると実際に記述されているところがハイライトされて、3文字の部分はハイライトすらされません。

う〜ん、謎です。

ただのレイアウト崩れだと思っていたら、こんなに謎な現象にはまってしまうとは思ってもいませんでした。

現状を整理して考えると、
・横並びOK
・横幅OK
・IE6でfloat利用の際のmargin設定のバグOK

考えられるすべを試してみました。
しかし、一向に改善されないこの問題に疲れてきました。
そこで、とりあえず、画像は表示しなくてはならないので、画像をいっそのこと背景画像としてcssで設定してみました。

<!-- right box -->

<div class="BoxRight">

<h3>タイトル</h3>

<p>説明文</p>

<ul>

<li>注意書き</li>

</ul>

<!--<p><img src="img/image02.jpg" alt="" /></p>-->

</div>

<!-- end right box -->

</div>

↓↓↓↓↓

<!-- right box -->

<div class="BoxRight">←このクラスに背景画像を設定

<h3>タイトル</h3>

<p>説明文</p>

<ul>

<li>注意書き</li>

</ul>

</div>

<!-- end right box -->

</div>

なんと、問題なく表示されました。
あの不可思議なゴースト現象もありません。

解決!!!

と、言いたいところですが、ここだけ画像を背景にしてしまうのは何か気持ち悪い・・・
背景画像にして問題なくて、ソース上に書くと問題があるということからもう少し探ってみました。

大きな違いは・・・

コメントアウト

レイアウト崩れの際に、画像をコメントアウトしていました。
また、今回は、ソースにコメントアウトでコンテンツについて丁寧に記述していました。
※いつもはここまで丁寧に記述はしませんでした・・・

恐る恐るコメントアウトを外していくと・・・

<div class="clearfix">

<div class="BoxLeft">

<h3>タイトル</h3>

<p>説明文</p>

<h4>サブタイトル</h4>

<dl>

<dt>定義語</dt>

<dd>説明</dd>

</dl>

</div>

<div class="BoxLeft">

<h3>タイトル</h3>

<p>説明文</p>

<ul>

<li>注意書き</li>

<li>注意書き</li>

</ul>

<p><img src="img/image01.jpg" alt="" /></p>-->

</div>

<div class="BoxRight">

<h3>タイトル</h3>

<p>説明文</p>

<ul>

<li>注意書き</li>

</ul>

<p><img src="img/image02.jpg" alt="" /></p>

</div>

</div>

なんと!

問題なく表示されました!

ゴーストも表示されず、レイアウトも崩れることなく思ったとおりに表示されました。
便利だと思っていたコメントアウトの記述が、IE6では裏目にでたということですね。
本当にこれで問題解消か確認してみようと、検索をしてみたらなるほど同じような現象の方が結構いました。

■結論
解決方法としては、floatを利用している要素にあるコメントアウトを削除することで解消
IE6に対応するときは、コメントアウトまで疑うべし!

IE6はすでにサポートも終了していて、Microsoftも新しいブラウザにアップグレードするように促しています。
ただ、日本の企業はまだIE6を利用しているところも多いので、なかなか切ることができないのが現状ですね。

tableレイアウトからcssレイアウトから変化したときのように、こんな時代もあったねとIE6のバグも過去の産物になってほしいですね。

これまでの仕事でたくさんの「お知らせ」管理システムや「イベント告知」システムなどを構築してきましたが、これらのシステムは表示するシステムを作る工数は大きくないものの、更新するシステムを作る工数は非常に大きなる傾向があります。
しかし、Googleスプレットシートでデータの更新・管理ができるのであれば、丸ごとGoogleスプレッドシートに依存することで、更新システムにかかる工数を０にできます。

↑ 管理用のGoogleスプレットシートの画面、エクセルと似たような感じです

↑ 表示している画面。管理用のシートを読み込んでいます（サンプル）

もちろん、個々の事情に合わせて最適の管理画面を用意した場合に比べ、Googleスプレッドシートの画一的な画面は、使い勝手は落ちます。しかし、エクセルと似たような操作法なので一般の方からも馴染みやすい形でデータを管理できるのではないでしょうか。コストを考えればこの機能で十分CMSとしての役割を果たせるケースも多いはずです。選択肢の一つとしてこの手法を持っておくことは、とても有意義なことだと思います。

このページでは、流れや考え方の説明と共に、すぐに使えるソースコードのサンプルも置いておきますので、個人商用限らずご自由にご利用ください。（たいしたサンプルではありませんが・・）

-

はじめに. システム概要

システムの大雑把な仕組みは簡単に言えば下記の２つになります。

更新用システム＝Googleスプレットシートを公開設定で１つ作成して、この中にウェブサイト上で表示したいデータを全て書き込む（Sample）
表示用システム＝上記のCSVファイルを読み込んで整形してHTMLとして表示するPHPプログラムをサイト内に埋め込む

簡単に言えばこれだけのことなります。非常にシンプルです。

以下、手順の説明になります。

-

手順1. 更新システム＝Googleスプレットシートの準備

まず、サンプルのGoogleスプレッドシートを下記に作成しておいたので御覧ください。

Sheet for CMS
※編集権限は解放しておりませんが、本来はエクセルのような形で編集が可能です

1行目に項目名、2行目以降にデータという形でデータをシートに格納して更新していくことになります。もちろん項目名はカスタマイズ可能ですし、行も必要なだけ追加して問題ありません。更新作業の際には新しい行を上か下に挿入して更新を行うことになります。

さて、シートを作ったら実際にこのデータを外部から読み込むための準備をします。
使用する機能は、Googleスプレットシートの「ウェブに公開」という機能です。スプレットシートの右上に「共有」ボタンがありますので、ここをクリックして「ウェブページとして一般公開」を選択しましょう。

そうすると下記のような画面が出てくるので、「変更が加えられると自動的に再公開する」のチェックを外してから、「公開開始」ボタンをクリックしてください。

すると、「公開データへのリンクを取得」が有効になるはずです。

有効になったら一つ目のプルダウンで「CSV」を選択、２つ目のプルダウンで公開したいシートの名前（デフォルトなら「シート１」を選択してください。これで下のボックスの中のURLが公開用のCSVファイルのURLになるはずです。
このURLを表示側のプログラムで読み込むことになりますので、コピーして取っておいてください。

後はこのシートの中に必要なデータを記入していき、CMSの公開に備えましょう。

※なお、運用を開始した後にデータを更新した際には、「今すぐ再公開」ボタンを押すことでCSVデータが更新されます。

-

手順2. 表示システム＝CSV読み込み用PHPプログラムの設置

CSVデータの準備ができたら、今度はそれを表示するためのプログラムをあなたのウェブサイトの中に埋め込む必要があります。やることはCSVを読み込んで整形してHTMLを出力するだけなので、プログラム言語はなんでも構いません。PHPやperlはもちろん、Javascriptでもできると思います。

今回はPHPでサンプルを作成してみました。
下記にサンプルを設置してありますので、一度御覧ください。
設置サンプル
ダウンロードはこちらから
Smaple Csv loader for CMS

サンプルは下記４つのファイルで構成されます。

• トップページなどで使う「最新◯件のリストを出力する」サンプルのindex.php
• 「お知らせ一覧」などで使う「現在のページの◯件を出力する」サンプルのlist.php
• 「お知らせ詳細」などで使う「指定した行のお知らせの内容を全て表示する」サンプルのdetail.php
• 上記３つのファイルから読み込まれるライブラリファイルの csvloader.inc.php

上記のファイルから必要な箇所をコピペして、ご自分のサイトに張ってください。各ファイルの先頭にCSVファイルのURLが書いてありますので、これを前の手順で作成したCSVのURLがに書き換えてください。またcsvloader.inc.phpは必ずコードを張ったファイルと同じフォルダにコピーしておいてください。

うまくいけば、手順１で作成したCSVの中身がご自分のウェブサイト内に取り込まれて表示されているはずです。

※サーバー上でphpの allow_url_fopen がONになっていないと、http経由でのファイルの読み込みができないため、エラーが発生してしまいますので注意してください。

-

まとめ

ということで、非常にお手軽に簡易CMSを設置できたと思います。
提供しているサンプルの制作にかかった時間も、数時間と非常に短時間ですみました。（デザインやデータがシンプルだったという理由もありますが）

最後に、簡単にこの手法のメリット・デメリットをまとめてみます。

メリット

• 短時間・低コストでCMSを設置できる
• エクセルに近い感覚でコンテンツの更新ができる
• Googleアカウントで編集権限を管理できる

デメリット

• 認証が必要なデータでは使用できない（CSVのデータが一般公開されてしまうため）
• Googleスプレットシートではテキストデータ以外の管理はできない
  （ただし、FlickrやYouTubeなどの画像・動画ファイルをアップロードできる外部サービスを利用して、HTMLの貼りつけコードを取得してしまえば、この問題は回避することができます）
• 一度Googleのサーバーにデータを取りに行ってから画面を表示するので若干遅い
• Googleのサーバーがダウンすると一緒にダウンすることになる（めったに無いとは思いますが・・）

と、こんな感じです。

いかがでしたでしょうか。
これで全てのCMSを代用できるとは思いませんが、コストを抑える必要があるときに有用な選択肢の一つにはなるはずです。ぜひ覚えておいてください。

ご意見ご感想などございましたら @nihimoto までお願いします。
ではでは。

WordPressをCMSとして使う方法はうまくプラグインを使いまくればかなり便利に使えます。
Wordpress以外のCMSを使う理由なんてほとんど無くなってしまいます。

ということで、さっそくまとめてみます。

-

「投稿」と「固定ページ」を使い分ける

「投稿」はまさにブログの記事のように日付やカテゴリでまとめて分類される、蓄積されていく記事を投稿するためにあります。「固定ページ」は常時存在して増減のそんなにない、まさに「固定されたページ（そのまんま）」の為にあります。

一般的な企業ページで言えば「お知らせ」や「ニュース」や「製品情報」などは投稿で作り、その他の「◯◯について」や「アクセス」などは固定ページで作るのが定石です。
アーカイブなどの機能もそれを前提に機能が設計されています。

-

テンプレートはばっさり編集

WordPressのテンプレートはwp-content/themes/フォルダの下に置いてあります。楽をするためにデフォルトテーマのtwentytenあたりを丸ごとコピーして、それをベースにつくるのがオススメです。
しかし、twentytenはデフォルトのテーマだけに、様々な状況に対処できるように大量のソースコードが埋まっています。ブログとして機能させたり、古いデータを引き継いだり、コメントを受け付けたりするには必要なコードだったりするのですが、単純にCMSとして使いたいだけの場合にはほとんど不要です。

ということで、いらなそうなコードはバッサリ削除してしまいましょう。だいぶ管理しやすくなります。
私も実際に要らないコードを削ってみたら半分以上無くなってしまいました。

※追記5/30
ばっさり削除するくらいなら元々余計なものの無いテーマをベースにすればいいじゃん、そう思った方、下記のサイトではそういった方用の、余計なものがばっさり取り除かれたNakedなテーマが紹介されています。

10 Blank/Naked WordPress Themes Perfect for Development

-

投稿内容の自動整形はうっとおしい

CMSとして使う場合、固定ページの本文にHTMLを記載することが多いと思います。しかし、WPの標準の自動整形機能が働いていると、本文を表示するときに勝手に<p>や<br>を埋め込んでしまい、レイアウトが崩れてしまう可能性があります。それに対処するため、自動整形機能をOFFにする PS Disable Auto Formatting というプラグインを導入します。

しかし、これでも少し問題があります。
これによって自動整形をOFFにすると、当たり前ですが自分で<br>を入れなければ改行されません。サイトの製作者が管理しているうちはそれでいいのですが、当然HTMLの知識の無い担当者に受け渡すこともあるでしょう。その時<br>がないと改行が反映されない、というのは更新のハードルを上げてしまいます。

その問題に対処するために、「投稿」機能の時だけテンプレートに php に nl2br 関数を埋め込んで改行を反映させてあげるのがオススメです。「投稿」にだけ導入するのは、先述のとおり「投稿」は「お知らせ」などに使うケースが多く、管理者以外が投稿をする可能性が高いためです。逆に「固定ページ」は固定されているページなので、大抵の場合更新はあまり発生せず、改行が反映されなくてもあまり問題ありません。

さて、改行を反映させるには、具体的には loop.php の下記の部分を

the_content();

次のように書き換えます

if (is_single()) {
  print nl2br(get_the_content());
} else {
  the_content();
}

これで、投稿の時だけ改行が反映されるようになりました。

-

携帯へ対応させる

携帯への対応はKtai Styleというプラグインを使うのが定石です。これを使えば携帯でサイトにアクセスされた場合に、携帯用のテーマで表示ができます。

しかし、これによってテンプレートのPC／携帯の出し分けは出来るのですが、肝心の投稿や固定ページの本文を出し分けることはできません。PC用にHTML＋CSSでバリバリ書いた本文を作ってしまうと、それが携帯で表示されるととんでもないことになってしまいます。

この問題に対処するために、今度は PC Ktai content selecter というプラグインを使います。これを導入すると[pccontent]PC用の記述[/pccontent]や[ktaicontent]携帯用の記述[/ktaicontent]などと、PCと携帯用にかき分けができます。これにより、PC用に書いたHTMLをそのまま携帯に表示されては困るようなところだけ、携帯用の記述を書き分けることで対処ができるようになります。

-

お問い合わせフォームは・・

企業のサイトを作る、といえば必ず付いて回るのがお問い合わせフォーム。Wordpressには ContactForm7 という優秀なメールフォーム用のプラグインがあり、しかもモバイルにも対応出来ます。
・・が、どうもこのフォームは制約がありすぎて、クライアントの要望に応えにくいのです。

なのでお問い合わせフォームは独自にPHPでフォームを作ります。しかし、せっかくWordpressで作っているので独自に作ったPHPもWordpressの中に収めたい。そこで Exec-PHP というプラグインを使用します。
これを使えば記事本文中にPHPのコードを書けばそれが実行されます。お問い合わせフォーム用のコードを投稿内容に書いてしまえばOKです。
（もちろん相応のPHPの技術は必要ですが。それが無い方は素直にContactForm7を使っていいと思います）

-

データはバックアップを取りたい

最後に更新作業が管理者の手を離れて一般の担当者レベルの仕事になると、誤った操作によって投稿やページが壊われてしまうことが心配になります。これはもちろん投稿者のアカウントのできる作業を限定したり、マニュアルを作って間違えないようにする、など予防策を十分に巡らすことで対処するべき問題です。

しかし、それでも不安が残る場合は定期バックアップを取ることがオススメです。それに、バックアップがあればサーバーがクラッシュしたときも安心です。

こういう時に便利なのは WP-DBManager というプラグインです。これを導入するとボタン一発でその時のDBの中身をバックアップできます。さらに、バックアップは定期的に自動実行が可能です。さらにさらに、バックアップしたデータをメールで管理者に送信されるようにすることもできまう。

※追記5/30
が、WP-DBManager は英語のプラグインです。機能的に問題ないのですが、クライアントに渡したときに若干の不安がのこります。また、メールでバックアップを送信するとメールの件名が化けてしまい、気持ち悪いことになります。
そこで下記サイトの手順でプラグインを日本語化、さらに別の手段でPHPのソースコードを書き換えて、メールの件名の文字化も直してしまいましょう。
WordPress – WP-DBManager 日本語化ファイル | Technolog.jp – ICTウェブマガジン
WP-DBManager のメール文字化けを解消する | 犬小屋にて

-

さてさて、いかがでしたでしょうか。
ここまでが実際の構築案件で使った技術の組み合わせの説明でした。

この手法であれば工数も大きくならずにPC携帯両対応のサイトが作れます。もちろん、案件は様々なので、場合によってはいろいろ臨機応変な対応は必要になることがとは思いますが、大分融通の効くやり方ではないでしょうか。

ということで、この手法でお安くHPを作りたい方は nishimoto@the-triad.jp までぜひお問い合わせください。（突然営業モードで失礼）

また、他に何か知りたいことなどありましたら @nihimoto までご連絡ください。よろこんで追記等させていただきます。（こちらはマジメに）

■使用感
用途が読書に絞られているので、非常にシンプルです。
キー配置などは独特ですが、片手でもつことを想定されたボタン配置でストレスなく本を読むことができます。
端末自体も軽く、全体のサイズも丁度よい絶妙なサイズ感です。

■Kindle Store
書籍を購入するには、Amazon.comアカウントを利用してKindle Storeから本を購入します。（そこからしか購入できません）
このStoreですが、カテゴライズなどをしているので書籍名を知らなくてもなんとなく辿っていくと、Amazonのいつものリスト形式で本が表示されます。
どんな内容だろうと思ったときに便利なのが『Try Sample』ボタンで、サンプルが読めるだけだろうと思って試してみたら・・・
なんという読み応えのあるサンプルでしょう！！
結構なページ数を読むことができるので、本屋で立ち読みをしている感じで本を読めます。
iPadで電子書籍を読もうと思った時は、中身がわからないので購入することはありませんでした。
無料版もあるのですが、そもそも有料と無料というカテゴライズでわかれているので見つけるのも難しく・・・
で、購入はしなかったのですが、Amazonのサンプルを読んでしまうとほぼ買ってしまいますｗ
まあ、本だけにターゲットを絞っているので優秀なのは当たり前かもしれませんね。

■なぜKindle？
iPhone、iPad、Androidにアプリがありますが、なぜいちいちKindleを購入するのか？
自分が選んだ最大の理由は、目が疲れないこと。
iPadのディスプレイをずっと見ていると目が相当疲れてしまい、長文をずっと読み続けるというのはできないなと感じていました。
そんな時に、電車でとなりに立っていた人がKindleを持っていて、その画面を見てビックリ！なんて文字が読みやすいのかと。
まあ、暗いとまったく画面が見えなくなってしまうのですが、そこは暗いところで本を読むなということで割り切りました。

■Webについて
KindleにはWebKitベースのブラウザが搭載されているので、webサイトを見ることができます。（当然白黒ですが・・・）
ただ、画面が白黒ですしディスプレイの構造上リフレッシュが遅いので、Ajaxでグリグリ動かすとかGoogle Mapなどのスクロールは厳しいですね。
まあ、読書間隔でニュースサイトを見たり、Blogを閲覧したりする分ではこれでも十分かなと思います。

意外とブラウザは優秀でJavascriptもちゃんと動作します。
asahi.comのグローバルメニューもマウスオーバーでサブカテゴリーが表示されますが、ちゃんと再現できていました。
iPadやXOOMなどのタブレットと違って、端末右下の十字キーでカーソルを操作するのでJavascriptもマウスカーソルを充てる感じで違和感ないです。
まあ、このカーソル移動も画面のリフレッシュが遅いので時間は掛かりますが・・・

■3G通信について
契約なしで3G通信ができるのはかなりのメリットです。
3G通信ができれば、ちょっとした時間に本を探して購入することができます。
webサイトの閲覧がいつまで出来るかわからないですが、普通にブラウザでWebサイトを閲覧できます。
他のサイトで知ったのですが、docomoとSoftBankの回線を利用しているみたいなので、W-CDMA方式の通信方式を採用しているみたいです。

と、Amazon Kindleを購入してまだ1週間程度ですが、購入後の雑感としてはこんな感じですね。
購入した書籍は他のデバイスと共有できるのかなどは、試せていないので今後も引き続き検証していきます。
それから、購入動機の英語の勉強も頑張ります！
@ksmonkey