WordPress で簡単に OGP の設定を行う方法

Open Graph Protocol (OGP) についての記事は小難しいものが多いように見えたので触らないでおいたのですが、とりあえず対応するにはセマンティックな meta タグを埋め込むぐらいの話のようなので、これは対応せねばと思いました。 今回は WordPress を OGP に対応させるためにしたことをまとめます。

Facebook for WordPress プラグインを使うのがお手軽

OGP 対応で一番簡単なのは公式プラグインである Fackbook for WordPress をインストールすることです。 インストールしただけで特に設定をしなくても OGP 対応タグを記事中に埋め込むようになります。 「いいね」ボタン等の機能は無効にしておくことができ、埋め込む App ID の指定もできます。 公式プラグインという安心感があるので OGP 対応が目的の場合も Facebook for WordPress を選択するのが、良いように思います。

私の場合、App ID は今回初めて取得しました。 まだ、十分に調べることが出来ていませんが、App ID を記事に埋め込むことで様々な機能が有効になるので、きちんと設定しておくべきです。

以下 Facebook のサイト上で行うアプリ設定についての話です。 記事に埋め込んで機能させるためには、その記事を公開するサイトのドメイン (ここなら hetarena.com) を App Domains として設定しておかねばなりません。 また、App Domains に設定するためには、そのアプリと Facebook 統合方法でその URL が使われていなければなりません。 何にも設定しないと App Domains 登録でエラーになるので、例えば「Website with Facebook Login」のサイト URL として https://hetarena.com/ を設定しておきます。 こうすることで App Domains にも hetarena.com を設定できるようになります。

できるだけシェイプアップしたい

本当に簡単に済ませるのであればここまでで、ここから先はこだわりの話です。 OGP 対応のみが目的のとき、Facebook for WordPress の出力する余分な JavaScript が記事に埋め込まれるのが気になります。 そこで、Facebook for WordPress のソースを見てみると、OGP 対応は open-graph-protocol.php というファイルの Facebook_Open_Graph_Protocol というクラスだけを使えば済むことに気が付きました。 app_id と locale は呼び出し元クラスの情報を使っているのですが、以下のように強引に書き換えてしまいます。 my app id は自分 App ID です。 locale については特にデバッガーもエラーを吐かないので、省略しました。

--- a/includes/open-graph-protocol.php
+++ b/includes/open-graph-protocol.php
@@ -121,12 +121,7 @@ class Facebook_Open_Graph_Protocol {
                        self::OGP_NS . 'type' => 'website'
                );

-               if ( isset( $facebook_loader ) ) {
-                       if ( isset( $facebook_loader->locale ) )
-                               $meta_tags[ self::OGP_NS . 'locale' ] = $facebook_loader->locale;
-                       if ( isset( $facebook_loader->credentials ) && isset( $facebook_loader->credentials['app_id'] ) && $facebook_loader->credentials['app_id'] )
-                               $meta_tags[ self::FB_NS . 'app_id' ] = $facebook_loader->credentials['app_id'];
-               }
+               $meta_tags[ self::FB_NS . 'app_id' ]  = 'my app id';

                if ( is_home() || is_front_page() ) {
                        $meta_tags[ self::OGP_NS . 'title' ] = get_bloginfo( 'name' );

あとは functions.php に以下を入れます。 open-graph-protocol.php へのパスは適切に書きましょう。

require_once( '/path_to_ogp/open-graph-protocol.php' );
add_action( 'wp_head', array( 'Facebook_Open_Graph_Protocol', 'add_og_protocol' ) );

これで余分な出力はなくなり、OGP の meta タグのみ出力されるようになりました。

…とここまで書いてアレなのですが、埋め込まれている JavaScript に重要な働きがあることがわかりました。 fb_xd_fragment がログに残る件がらみなのですが、詳細は別記事でご確認ください。 そういうわけでこのようにクラスを切り出して使うのはお勧めしません。 Facebook for WordPress をそのまま使いましょう。 (この段落は 2012/12/4 追記)

アイキャッチイメージを記事に設定する

Facebook for WordPress (Facebook_Open_Graph_Protocol クラス) の動作では、記事に設定された「アイキャッチ画像」の情報を image プロパティとして埋め込みます。 Facebook のデバッガーによれば縦横 200px 以上のイメージをきちんと設定しておくことが推奨とのことです。 これまでアイキャッチ画像は使っていなかったので、新たに 200px 四方のロゴをアップロードして全ての記事のアイキャッチ画像として設定することにします。

(2013/1/20 追記: もっと手軽な方法がありました。)

まず、記事に見える形で表示したくないので、テーマファイルから以下の行を削除しました。

<?php the_post_thumbnail(); ?>

続いて記事へのアイキャッチ画像の設定ですが、面倒なので SQL で実行することにしました。 以下の SQL 文はアイキャッチ画像が設定されていない post/page に対して ID 654 の画像をアイキャッチ画像として設定するためのものです。

START TRANSACTION;

INSERT INTO wp_postmeta (post_id, meta_key, meta_value)
SELECT id, '_thumbnail_id', 654
FROM wp_posts
WHERE post_type IN ('page', 'post')
AND NOT EXISTS
(SELECT * FROM wp_postmeta
 WHERE meta_key = '_thumbnail_id'
 AND wp_postmeta.post_id = wp_posts.id);

COMMIT;

何か失敗したときに Rollback ができるようにトランザクションを有効にして実行しています。 これで image プロパティも meta タグとして埋め込まれるようになりました。 これらを実行する時は、画像 ID だけでなくテーブル名も自分の環境に合わせてください。 マルチサイト環境ならば wp_2_postmeta、wp_3_postmeta、… となりますね。

これで「簡単な」なのかという声が聞こえそうですが、やっている内容に比べたら簡単にやっているのではないでしょうか…。(苦しい)

WordPress 用プラグイン Standard Widget Extensions を公開しました

WordPress のウィジェットの動作を拡張するためのプラグイン「Standard Widget Extensions」を公開しました。 既にWordPress.org のリポジトリに登録済みです。 私にとって Thin Out Revisionsに続く 2つめの WordPress プラグインです。

現バージョンで提供している機能はウィジェットというよりサイドバーの拡張用という感じですが、以下の内容をお手軽に実現できます。 Twenty Twelve/Twenty Eleven であればデフォルト設定のままで動きます。

  • Accordion Widget (開閉するウィジェット)
  • Sticky Sidebar (スクロールが止まるサイドバー)

スクロール関係については世の中にサンプルやら部品があふれているのですが、境界でぎこちない動作になるものが多く、レスポンシブ Web デザインやサイドバー伸縮との組み合わせを考えると結局自分で作った方がよいと思い開発しました。 ちなみにレスポンシブ Web デザイン対応という点では、ウィンドウ幅が指定された値より小さくなると機能が無効化されます。

開閉動作もありふれてますが、見出しのアイコンを変えたりできるので JavaScript の苦手な人がちょっと使うのには便利だと思います。 独自の CSS は最低限にしてテーマのスタイルをそのまま使用するようにしています。 以下は Twenty Twelve/Twenty Eleven/Twenty Ten に適用した場合の例です。 そのままではマージンが大きいので微妙かも知れませんが、最低限の追加スタイルということを理解していただけると思います。

Standard WE

動作についてはこのサイトの左側にあるサイドバーを見ていただくのが一番早いと思います。 WordPress 標準テーマの Twenty Twelve/Twenty Eleven/Twenty Ten で動作確認していますが、メインカラムとサイドバー、ウィジェットの ID/クラス名を設定することができるので、標準テーマと同じつくりのテーマであれば対応できると思います。 もし、興味があれば、是非 WordPress の管理メニューから検索してインストールしてみてください。

以下、プラグインのホームページです。

SoundCloud と WordPress

SoundCloud にアップロードしたトラックを WordPress のブログ記事に埋め込むには公式の SoundCloud Shortcode プラグインが便利です。 しかし、iOS の Safari でも表示可能なように HTML5 で出力するには気をつけなければならない点があります。 以下手順をまとめます。

SoundCloud プラグインをインストールすると「設定」-「Sound Cloud」でセットアップ画面を表示できるようになります。 まず、この中で Widget Type を HTML5 に選びます。

Setting

しかし、これだけでは不十分です。 リンクの形式は http://soundcloud.com/hetarena-com/saw-square ではなく、http://api.soundcloud.com/tracks/69089521 の形式でなければなりません。 この数字を見つける簡単な方法としては、SoundCloud.com 上の該当トラックで「Share」-「WordPress Code」で示されるコードを確認すれば良いです。

Share Track

「WordPress Code をそのまま貼り付けては?」という声も聞こえてきそうですが、油断すると「iframe="false"」というパラメータが入っていて Flash の埋め込みになってしまいます。 ちなみに私は設定画面で Auto Play = false、Show Comment = false として以下のようなタグコードを埋め込んでいます。

[soundcloud]http://api.soundcloud.com/tracks/66034316[/soundcloud]

というわけで見やすくなったので「ソフトシンセ時代のシンセサイズ入門」を是非ご覧ください。 あと、リバースシンバルの作成例つきの「Groove Agent ONE でマイキットをつくろう」も!

以下の記事を参考にさせていただきました。

エプソンプリンターとうまく付き合う

エプソンのパーツセンター

子供達は印刷するのが大好きです。 特に 5歳の娘はシルバニアファミリー等のサイトの塗り絵で遊んで大人には違いのわからないほど繊細な(?) 作品をたくさん出力しています。彼らはインク代など気にしませんから、きちんと制限枚数を伝えておかない大変なことになります。 しかも、手書きのお絵かき用紙もプリンタの用紙カセットから取り出したりして、結構乱暴に扱っています。 誰かは定かでないのですが (こういう時、子供達は皆そろって「知らない」と言います)、気がつくと排紙トレイのツメが折れてしまい、すぐに抜けてしまう状態になっていました。

うちのメインのプリンターは 2008年発売のエプソン製 EP-901A です。 部品を取り寄せようと思い、最初は修理窓口に連絡したのですが、そこでは部品の提供はしていないとのことで「パーツセンター」の連絡先を教えてもらいました。 パーツセンターに連絡を取ると代金引き換えで送付してくれるとのこと。 排紙トレイは 4段で 1セットとなり、それより細かい分売はしないそうです。

パーツセンターの連絡先は Web では公開されておらず、受領書返送用封筒も一緒に送られたりするのでエンドユーザーというより販売店向けのようです。 代金は全部込みで、1,186円也。 この 1,186円の内訳は聞かなかったのですが、ほとんどが配送料+代引手数料のようなので、余裕があれば店舗で取り寄せを頼むと良いでしょう。

いずれにせよ、パーツセンターの存在は知っておくと良いと思います。 必要があれば修理窓口で問い合わせてみてください。

ちなみに排紙トレイのパーツは EP-901A のものと現行品で溝の部分が若干変わっていて、3段分付け替えると用紙カセットの中に落ちやすくなります…。

買い換えのタイミング

先日、喪中葉書を印刷しようとして給紙がうまくいかず、焦って新しく EP-804AR を購入してしまいました。 この時は、

  • 印刷品質が劇的に向上することはなさそう
  • 無線 LAN 対応やメモリーカード類からの直接プリント等周辺機能も飽和気味

と考えて、1世代前のものでも十分と判断し昨年モデルの EP-804AR にしました。 16,000 円台で十分安く買ったと思いきや、価格.com の履歴を見ると 1世代前のモデルでも 11月から値上がりしていることがわかります。

ADF が調子悪かったり、出力に筋が入りやすくなったりしていて「使えるけどどうだろう…」というような場合は、どうせ買うのであれば季節変動で最安値の 8月~10月を狙って買い換えると良いと思います。

ちなみに赤モデルなのは Amazon のお急ぎ便で買えるのがこれだけだったからです。 ADF は ScanSnap があるので、不要としました。

その他いろいろ

その他、気づいたことをざっくばらんに書きます。 今更というのもありますが。

  • マニュアルを良く読むと出ていますが、インクは抜いてもオッケーなのですね。 昔の記憶で抜いちゃまずいと思いこんでいました。
  • 購入直後は製品付属のセットアップ用インクでないとダメですね。 EP-901A の使いかけインクで EP-804A をセットアップしようとしましたがエラーになってしまいました。
  • 今年のモデル (EP-905A/EP805A) から使用インクが変わっています。
  • 今更ながら下トレイにも葉書を入れられることに気づいたのですが、自動切り換えはしてくれないですね。
  • ソフトウェアをインストールする時に、既に旧製品用のソフトウェアが導入済みだと標準インストールを選んでも個別の製品についていちいちアンインストールの実行確認をされるので、放置しておくわけにいきません。 最初に古いソフトウェアをアンインストールしておくと良いのかも知れません。

エプソンプリンターと喪中葉書の相性はかなり悪い

この年末・年始は喪中なので欠礼の葉書を出さねばなりません。 郵便局の喪中欠礼用葉書 (胡蝶蘭) を買って宛名・文面はプリンタで印刷しようとしました。 我が家のプリンタは EP-901A です。 カミさんが文面データを作り出力していたのですが、給紙がおかしいと言い始めました。 様子を見ると確かに紙送りされません。 音から判断すると、ローラーが空回りするだけで紙を吸い込んでくれないようです。

4年使っていることもありプリンターの故障を疑ったのですが、結論としては買った葉書がまずかったようです。 こちらにも苦労されている方がおられますが、胡蝶蘭の葉書とEPSON のインクジェット複合機は相性が悪いみたいです。 今までこんな経験はなかったので、プリンターのせいにするのはちと酷な気がします。

で、今回はどうしたかと言うと…。

korokoro

クリーニング用の粘着ローラーが役立ちました!

見た目ではわかりませんが、先のリンクで「粉が付いている」という情報があったので、試しに葉書の裏表をコロコロしてみたところ、100% とはいかないものの大分まともに給紙されるようになりました。 ただし、そこら辺をコロコロして、粘着力を弱めてからでないと大変なことになってしまうので気をつけましょう。

何にせよ、EP-901A/801A 系プリンターのユーザーは日本郵便の (印刷用でない) 普通紙の葉書は避けて、各社からインクジェット用として売られているもの買った方が良さそうです。 一度使ってしまうと問題なかったはずの紙の給紙も怪しくなります (元に戻りますが)。 喪中葉書も早めに出さなければと思うと焦りますよね。

そう、焦って EP-804A 買っちゃったんだよなあ。 まあ、新品買ったからわかったってのもあるけど…。

perl Expect を Windows で使用する

私は TeraTerm マクロよりも Expect 派なのですが、「今さら Tcl ってのもねぇ」というところもあるわけで、最近はもっぱら perl の Expect モジュールを使っています。 布教活動を行うには希望があればすぐに他の人の使っている Windows にインストールできるようにしておかなければならないので、今日は perl Expect を動かすための作業をメモ書きしておきます。 と言っても何が必要か知っていれば結構簡単に動いちゃうんですけど。

ActivePerl には該当するパッケージが無いので Cygwin で cpan コマンドからインストールして使います。 Strawberry Perl にはビルド環境があるようなので、IO::Tty が用意できれば同じように Expect もインストールできると思いますが未検証です。

Cygwin 関連パッケージインストール

Cygwin のデフォルトインストールで不足しているものは次のパッケージです。 これらを追加インストールします。

  • make
  • perl
  • perl-IO-Tty

Expect のインストール

あとは cpan コマンドで Expect をインストールするだけです。 cpan コマンドの初回起動時はいろいろありますが、あっちこっちで説明されているのでここでは割愛します。

$ cpan

cpan shell -- CPAN exploration and modules installation (v1.960001)
Enter 'h' for help.

cpan[1]> install Expect

これで Expect を使えるようになります。 コマンドを打って出力結果を整形する場合などは、本家 Expect より perl を使った方が楽だと思うので、興味があれば試してみてください。

インド英語を聞き取るためには

前に英語学習に関連するエントリーをいくつか書きましたが、大きなメッセージとして「100% を目指さない」ということをお伝えしてきました。 「知らない単語をなくすこと」、「すべて聞き取れるようにすること」というようなところを目指すのではなく、100% でなくてもやりとりを通して意思疎通ができるようになればそれで十分でないかと。

自分がそう思うようになったのは、アジアの英語に接する機会があったからかも知れません。 彼らの英語はときどき英語に聞こえないことがあります。 が、彼らは全くそれを気にしないし、むしろ堂々と話します。 それを見ていると我々のしゃべる英語が Japanese-English (Janglish) と呼ばれようが気にする必要はないように思えるのです。

まあ、その辺の話は前にも書いているのでそこまでにして、今回の話はその隣にある「英語教材のリスニング用音源の発音は綺麗過ぎる」という問題についてです。 英会話の実践の場ではアジアの英語が電話の向こうから聞こえてくるような場面が多いわけで、いくらアナウンサーがしゃべる英語を聞き込んでいてもなかなか厳しいものがあるわけです。 特に顕著なのがインド人相手の場合で、彼らはたいてい早口で、油断していると全く英語に聞こえなくなってしまうのです。 IT 関連の仕事をしているとインド人の英語を聞く機会は多いので、何とかしたいと思っていました。

というわけで、この「インド英語のリスニング」をアマゾンで見つけたときは「待っていました!」という感じでした。 このような本が出版されるということは、同じように感じている人が一定数いたのだと思います。

本の内容について簡単に触れます、 Part 1 で「インド英語概説」としてインド国内の言語状況や教育についてまとめられおり、Part 3 の「インド英語表現集」もありますが、メインはあくまでも Part 2 (+ CD) の「インド英語のリスニング」、すなわち音源+英会話スクリプトとその解説の部分です。 ボリューム的にも Part 1 と Part 3 はそれぞれ 20ページ程度で残りは Part 2 です。

収録された会話は実践的な場面を想定したもので以下の 4つのパートに分類されています。

  1. インドへ出発・到着
  2. ビジネス編
  3. 生活編
  4. 観光編

実践の場だともっと早口だよなあ、とは思いますが、それでもこれだけヒンディー語が混ざっているとやはり聞き取りは辛いです。 「Accha, accha!」と言われても「あちゃー…」という感じでしょうか (親父ギャグ)。

実践を想定しているため、全てインド人と日本人の会話になっています。 ですので半分が日本人のしゃべる英語なのですが、ここはインド人同士の会話も増やしてインド英語の割合を増やして欲しかったと思います。 それでも、速さにしてもボリュームにしてもインド英語に慣れるためには十分でしょう。 これでは不十分と言えるレベルであればインターネット上にいくらでも音源を見つけることができると思います。

念のため書いておきますが、TOEIC 対策としては全く意味がありませんw

Linux のログイン認証に Active Directory を使う

Linux の認証に Active Directory を使うよう設定することがありました。 備忘録としてまとめておきます。

何ができるようになるのか

今回は WinBind という Samba のコンポーネントを使って Linux と Active Directory を連携させます。 これを使用すると Linux 上のユーザー/グループ管理に Active Directory を用いることができるようになります。 具体的には以下のことができるようになります。

  • Active Directory に登録されたアカウントとグループを使って Linux にログインすることができるようになります。
  • 事前に個々のユーザーを各 Linux サーバーへ登録する必要はありません。 /etc/passwd や /etc/groups は全くいじりません。 また、ホームディレクトリは sshd 等で最初にログオンしたときに自動生成されます。
  • Active Directory の RID をそのまま uid/gid として用います。 これにより、複数の Linux サーバー上でも一意の uid/gid を使ってユーザー/グループを識別することができます。
  • passwd コマンドを使って Active Directory に登録されているパスワードを変更できます。

uid/gid の扱いについて補足します。 Active Directory 上のユーザー/グループを Linux 上の uid/gid にマップさせる方法はいくつか用意されていますが、今回は Active Directory の RID (SID のドメイン内相対識別部分) を用いる方法を採用します。 idmap_rid と呼ばれる方法です。 ただし、マルチドメイン環境では RID は一意にならないため、シングルドメイン環境での運用が前提となります。 マップ方法にはその他にも tdb (テーブルによるマッピング。デフォルトの方法) や ad (AD 上のユーザー属性を読む。いちいち属性を設定しなければならず管理が面倒) 等があります。 信頼関係を構築していたりマルチドメイン環境ではこれらが必要となりますので興味があれば調べてみてください。

設定方法

設定方法については実は Microsoft の「Active Directory を使用して Linux クライアントを認証する」という記事に詳しく解説されています。 ビルドの部分は飛ばして良いので、まずこれを読んでいただければと思います。 ここではこの記事を補足のみ書きます。

DNS 関連

DNS は Windows ドメインの名前が引けるように /etc/resolv.conf を設定しなければなりません。 一番簡単なのは DNS として Windows のドメインコントローラーをしてしまうことでしょうが、環境によっては DNS サーバーの構成を見直す必要が出てくるかもしれませんね。 また、ホスト名はきちんと設定しておきましょう。 「localhost」という名前のコンピューターが AD に登録されてしまった、などということのないように…。

ホームディレクトリの自動作成

先に紹介した Microsoft の記事中 /etc/pam.d/system-auth の pam_mkhomedir の umask の指定はちょっと怪しい感じがします。 例えば自分のみアクセス可能 (700) なホームディレクトリを作成するには以下のようにします。

session     optional      pam_mkhomedir.so skel=/etc/skel umask=0077

krb5.conf の設定

system-config-authentication を実行した後は krb5.conf で kdc = * となってしまうと思いますが、このままではまずいようです。 以下のようにドメイン名を指定します。

[realms]
 EXAMPLE_DOMAIN.LOCAL = {
  kdc = example.local
 }

Windows の DNS にはドメイン名の A レコードも用意されており、ドメインコントローラーのホスト名を使うよりもこの例のようにドメイン名を使った方が可用性が高くなります。 (マニュアルを見るとこのケースは設定がなくても動作しそうですが、未検証です)

端末エミュレータ上で動作する設定ツール

先の記事では system-config-authentication が使用されていますが、X が利用できない場合、authconfig-tui や authconfig コマンドを利用することができます。 下は authconfig-tui の画面です。

authconfig-tui

ID マップについて

ID のマップについてもう少し詳しく説明します。 Windows の RID とは SID の一部でそのドメインの中で一意となるオブジェクトの識別子です。 Windows で通常発行される RID は 500 以降なのでそれをそのまま uid/gid 使います。 以下は SID の例ですが、このうちの最後の 500 が RID となります。 RID はユーザー/グループ等のオブジェクトが作成されるたびに連番で割り当てられていきます。

S-1-5-21-917267712-1342860078-1792151419-500

以下は 500 以上の RID についてそのまま uid/gid としてマップするための smb.conf の設定です。

idmap domains = EXAMPLE_DOMAIN        (samba 3.3 以降はこの行は削除)
idmap config EXAMPLE_DOMAIN:backend   = rid
idmap config EXAMPLE_DOMAIN:base_rid  = 500
idmap config EXAMPLE_DOMAIN:range     = 500 - 10000

今回はこの RID をそのまま uid/gid として使いますが、もちろん Linux のローカルユーザー/グループと衝突しないようにしなければなりません。 すなわち 500 以上の uid/gid は Linux システム上に存在していないという前提です。 もし、Linux 上のローカルアカウントで 500 以上の uid/gid も使うのであれば range をうまく調整する必要があります。 「Administrator (= 500) のマップなど不要!」というケースは多いかも知れませんが、ログイン時に所属グループがきちんと gid にマップできないとログインできないので、’Domain Users’ (= 513) がマップできないと恐らく困ると思います。

うまく行けば id コマンドで以下のようにユーザー情報を取得できるようになるはずです。 AD 上に RID = 1110 で ad_user というアカウントが登録されている想定です。

$ id ad_user
uid=1110(ad_user) gid=513(domain users) 所属グループ=513(domain users) context=user_u:system_r:unconfined_t

ちょっと考えればわかりますが、そのままでは AD ユーザー全員がログインできるようになってしまいます。 アクセス制御は Windows のグループを用い、認証を行う各サービスで適切に行わなければなりません。 例えば ssh ログインを制限するのであれば /etc/ssh/sshd_config に AllowGroups の設定を入れます。 あるいは pam_winbind のオプションに require_membership_of というパラメータがあるので、これを使ってそもそもの連携するグループを絞ってしまっても良いかもしれません。(ただし動作未検証)

ちなみに smb.conf の設定ではネストされたグループの扱いのためのフラグもあります。 デフォルト値は Yes です。

winbind nested groups = Yes

Linux と Windows の混在環境では、このように Active Directory を活用することができます。 一発でうまく設定できないかも知れませんが、ハマった時は一時的に tdb を利用して問題を切り分けしてみると良いと思います。

Twenty Twelve を使い始める前に知っておきたいこと

Twenty Twelve は近々リリースされる WordPress 3.5 の新しい標準テーマで、3.5 のよりも一足先にリリースされています。 このブログもこの 11月より Twenty Twelve ベースのテーマに衣替えしました。 その中で気付いた点などまとめましたので、Twenty Twelve を使ってみようという方は是非ご一読ください。

Mobile-First Responsive Web Design

Twenty Twelve はレスポンシブ Web デザインを採用しており、更にモバイルファーストのコンセプトで実装されています。 具体的にどういうことかと言うと、CSS のメディアクエリを使ってブラウザのサイズによって表示内容を変えているのですが、スタイルシートファイル (style.css) の中で以下の順でスクリーン用スタイルが定義されています。

  1. 幅の狭いスクリーン用のスタイルをメディアクエリなしで定義
  2. min-width: 600px を指定して幅広いスクリーン用のスタイルを定義
  3. min-width: 960px を指定して更に幅広いスクリーン用のスタイルを定義。ここからは背景が広がるだけ。

つまり一番幅の狭いスクリーン (=モバイルデバイス) 用の定義を最初に行い、スクリーン幅の広いデバイスについては追加でスタイルを足すというやりかたです。 何故、このようにモバイルデバイスを優先するかというのは様々なところ (例えばここここ) で説明されているのでここでは繰り返しません。 注意したいのは PC 用のレイアウトを行うときはメディアクエリの条件式でくくられたスタイルに手を入れなければならないということです。

IE7/IE8 ユーザーは Twenty Twelve Version 1.0 だと悲しいことに

ここでピンと来た方もいらっしゃるかも知れませんが、Internet Explorer の 8 以下のバージョンはメディアクエリをサポートしていません。 なので、Twenty Twelve の Version 1.0 を使ったサイトを IE7/IE8 でブラウジングするとメニュー表示がモバイル用と同じになっちゃいます。 このあたりデモサイトではきちんと表示されるのですが、あれはどうやら手が入っているようです。 普通に Version 1.0 を入れると IE7/IE8 では下のような表示になります。 メニューに注目してください。 (それでも微妙な IE 個別対応はしているので 2カラムレイアウトにはなっています)

Twenty Twelve on IE7/IE8

Twenty Twelve 1.0 をリリースした時点では IE7/IE8 に関してはモバイルデバイスと同等のルックスを提供する方針だったようです。 しかし、私のサイトの場合、閲覧に使われているブラウザの中での IE8 以下バージョンの割合はサイトアクセス全体の 2割強で無視できない数字であり、きちんとしたメニューバーを表示したいところです。 これはグローバルで見ても同様だったようで、 最初の方針は不評を買い結局 IE8/IE7 のナビゲーションメニューがきちんとサポートされることになりました。 WordPress 3.5 公式リリースには反映されるはずですが、すぐに対応が必要な方は既に修正済みとなっている WordPress 3.5β2 の中の Twenty Twelve のみを取り出して使うと良いでしょう。 (3.5β2 そのものを使うことはお勧めしません。もっと言うと多分あなたがこの記事を見ている頃には 3.5 がリリースされているような気がしますw (注: 3.5 は 12/5 リリース予定))

IE6 はさらに悲しい

更にいまだに IE6 を使用されている方々もいます。 そこで手元の IE6 を使ってテストしたところ、Twenty Twelve テーマそのままではフォントの問題で日本語が表示されませんでした。

いまどき IE6 を使っている方々はきっとレイアウトなど気にしないのだろうと推測できますが、さすがに内容が見えるぐらいにはしておきたいところです。 「スターハック」という IE6 のみのスタイルを変える有名なテクニックを使ってフォント指定に ‘MS Pゴシック’ を追加します。 なお、Twenty Twelve のスタイルシートに直接手をいれるのではなく、まずは子テーマを作ってカスタマイズするのがお勧めです。

* html body {
  font-family:  "\FF2D\FF33\20\FF30\30B4\30B7\30C3\30AF", Osaka, Helvetica, Arial, sans-serif;
}

* html body.custom-font-enabled {
  font-family:  "\FF2D\FF33\20\FF30\30B4\30B7\30C3\30AF", Osaka, "Open Sans", Helvetica, Arial, sans-serif;
}

* html .entry-content code,
* html .comment-content code,
* html .entry-content pre,
* html .comment-content pre {
        font-family: "\FF2D\FF33\20\FF30\30B4\30B7\30C3\30AF", Osaka, Consolas, Monaco, Lucida Console, monospace;
}

ついでに Osaka フォントも加えて、(意味がないと思われる) 元のフォント指定も残していますが、この辺は詳しくないし、所詮 IE6 用スタイルということで深く考えないことにします。 また、style.css の先頭に念のため以下の行を入れておきました。

@charset "utf-8";

これで無事 IE6 でも日本語が表示されるようになりました。

フォントサイズ指定について

style.css の中を覗いてみるとフォントサイズの指定には rem が使われています。 これは CSS3 から追加された単位で、root + em すなわち root 要素のフォントサイズに対しての相対値になります。 最初に以下のように指定されているので、1rem = (16px * 87.5%) = 14px となります。 ここで 16px は (最近の主要な) ブラウザのデフォルトフォントサイズです。 このようにユーザー環境のフォントサイズを考慮して絶対値でなく相対値でサイズ指定するのが最近の標準的なやり方のようです。

html {
        font-size: 87.5%;
}

さて、これ以降実際のサイズ指定には 1つの要素に対して下のように px 指定と rem 指定の 2つの指定が行われています。

    font-size: 11px;
    font-size: 0.785714286rem;

このように指定方法の異なる 2行をこの順で書いておけば rem を認識しない古いブラウザは px 値、認識すれば rem 値でスタイリングされます。 rem 値が一瞬よくわからない小数値になっていますが、先の 1rem = 14px で計算した値となっています。 11/14 ということですね。 自分で手を入れるときもこのスタイルを踏襲しましょう。

幅の指定について

もう一つわけのわからない小数値に幅の指定があります。 こんな感じの記述です。

    width: 65.104166667%;

Twenty Twelve では 960px 以上になるとコンテンツの幅は広がらず背景が広がるようになっています。 レスポンシブであるために上のように width が%値で指定されていますが、これは 960px になったときのピクセル値を元に計算された値で、この例では最大表示で (960px x 0.65104166667 = 625px) ということです。

IE 対応

β2 での変更で HTML タグの記述は以下のように出力されます。

<!--[if IE 7]>
<html class="ie ie7" dir="ltr" lang="ja">
<![endif]-->
<!--[if IE 8]>
<html class="ie ie8" dir="ltr" lang="ja">
<![endif]-->
<!--[if !(IE 7) | !(IE 8)  ]><!-->
<html dir="ltr" lang="ja">
<!--<![endif]-->

ここで指定されている .ie/.ie7/.ie8 をセレクタとして使って実際のスタイリングは css/ie.css の中で行われています。 .ie は IE7 と IE8 の 2つに対してのみ適用したいスタイルを指定するときに使います。 先のスターハックと合わせれば IE6/IE7/IE8 向けの個別調整ができますね。 まあ、Mobile First Responsive Web Design の考え方からするとピクセル単位の配置にまでこだわる必要はないと思うので、ほどほどにして良いと思います。

その他

Twenty Twelve は HTML のソースも CSS ファイルも比較的読みやすいと思いますので、気に入ったら是非カスタマイズに挑戦してみてください。 それと、ページ編集画面からテンプレートとして ‘Front Page Template’ や ‘Full-width Page Template, No Sidebar’ が選べるようになっていますが、これらのソースを見ると Widget エリアの使い方などの参考になると思います。

さて、このブログのテーマも Twenty Twelve ベースのものに変えました。 しかし、広告を入れると元があっさりしすぎているのでもう少し線を濃くしたりする等の調整が必要なようです。 また、そもそも英語で見栄えが良くても日本語になっただけで印象が変わってしまう、というのもあります。 まだまだ調整は続く、という感じです。

また、さんざん Mobile First Responsive Web Design と強調した割りに、結局スマートフォン向けは WPtouch Pro の使用を継続しています。 Twenty Twelve のモバイル向け表示時のメニューボタンが気に入らないのと、モバイル回線でのレスポンスがどうなるか見えないのが理由ですが、折を見て一本化できるか検討してみようとは思っています。 ナビゲーションメニューのスタイリングの仕方を覚えねばということですかねぇ。

Hetarena.com リニューアル

テーマを Twenty Twelve ベースのものに変えてみました。 まだまだ調整不足な部分はあると思いますが、100% 完璧なものになることはないように思うので、きりのいい月初に変えてしまいます。

ベースがレスポンシブ Web デザインなのでなるべくそれを踏襲してはいますが、当面スマートフォン用のページはいままで通りの WPtouch を用いた表示を継続します。

今後も Hetarena.com をよろしくお願いします。