twentytwelveとMobile Detectorによるスマホ対策

WordPressのバージョン3.5もいよいよ正式リリース間近(12月12日に日本語版がリリースされた)。今回のバージョンの目玉のひとつは、標準テーマのTwenty Twelveだが、実は、WordPressの正式リリースを待たずして、Twenty Twelveを先行ダウンロードできる。

Twenty Twelveでは、PCやスマホなどのデバイスに応答して、表示を最適化するレスポンシブデザインが採用されており、このテーマをカスタマイズすれば、誰でも簡単にスマホ対応のテーマを作ることができるのだ。

左のスクリーンショットは、このサイトのテーマをTwenty Twelveに変更して、iPhone4S上で表示したもの。

ご覧のとおり、シンプルで機能的なテーマなので、スマホやタブレットのことだけを考えるなら、このまま利用しても問題はない。

ただし、これをPC用のテーマとしも使うとなると、少々話が違ってくる。ヘッダーにロゴを入れたり、ナビメニューの位置を変えたり、何かとPC用にカスタマイズしたくなる。カスタマイズの程度にもよるが、場合によっては、スマホやタブレットでの表示が崩れることだってある筈だ。

また、PCで非レスポンシブデザインテーマを使っていて、これがとても気に入っている場合、レスポンシブ化のためだけに、Twenty Twelveをベースにテーマを書き換えるのかどうかという問題も起こるかもしれない。

そんなときお薦めしたいのが、Twenty TwelveとMobile Detectorというプラグインの組み合わせによるスマホ対策だ。
Continue Reading…

WordPressとCodeIgniterを連携させる3つの方法

人気のPHPフレームワークCodeIgniterとWordPressを連携させるプラグインWP Code Igniterが登場した。このプラグインは、WordPressをCodeIgniterで構築されたWebアプリの一部として利用できるようにするもので、MVCアーキテクチャのなかのViewとしてWordPressが統合されるという仕組みになっているようだ。

さっそく試してみたのだが、このプラグインはまだテスト段階ということもあって、私のUbuntuローカル環境では動作しなかった。そこで、他にもWordPressとCodeIgniterを連携させる方法はないかと調べてみると、あちこちでいろいろな試みがなされているようだが、大きく分けると次の3つに分類できる。

  1. プラグインを通じた統合(WP Code Igniterの場合がこれ)
  2. テーマとfunctions.phpを利用した統合
  3. CodeIgniterのルートディレクトリ内にWordPressのフォルダを作って統合

上記の方法のうち、2番目の方法でチャレンジしている人が多かったようだが、その方法は千差万別で、使用しているCodeIgniterのバージョンも比較的古いものが多い。

CodeIgniterのViewをテーマ内から利用しようという発想は、シンプルで解り易いのだが、WordPressとCodeIgniterの両方に精通していないと実現は難しく、構築後のメンテナンスも大変そうだ。

WordPressとCodeIgniterの最も簡単な連携方法

ということで、最後に残った3番目の方法だが、これが一番原始的な方法で、ほとんど説明の必要がないほど単純明解だ。

例えば、CodeIgniterのルートディレクトリにblogという名前のフォルダを作り、そこにWordPressをインストールすれば作業はこれで終わってしまう。

唯一懸念される問題は、CodeIgniter側でWordPressをインストールしたフォルダと同名のコントローラーを作った場合だが、デフォルトの状態で使う場合は問題はない。通常、CodeIgniterでblogコントローラーを作った場合は、サイトアドレス/index.php/blogでアクセスすることになる。これに対してWordPressのフォルダへのアクセスは、サイトアドレス/blogとなるので、両者が衝突することはない。

CodeIgniterのindex.phpを消去したい場合

ただし、デフォルトの状態が気に入らないという人も当然いるわけで、SEO対策上もよろしくない。この問題については、CodeIgniterのユーザーガイドでも、「index.phpを消す方法」として紹介されいる。ルートディレクトリに次の内容の.htaccessを置けば解決する。

RewriteEngine on
RewriteCond $1 !^(index\.php|images|robots\.txt)
RewriteRule ^(.*)$ /index.php/$1 [L]

なお、この設定をした場合、WordPressをインストールしたフォルダと同名のコントローラーがCodeIgniter側にあるときは、CodeIgniterのコントローラーが優先されることになってしまうが、WordPressをインストールしたフォルダのblogをコントローラーに支配させないために、上記の.htaccessの2行めを次のように変更すれば問題は解決する。

RewriteCond $1 !^(index\.php|images|robots\.txt|blog)

本当はSeezooCMSやPyroCMSでもいいのだが

以上で、index.phpも消えてすっきりする。この方法だと、固定ページをCodeIgniterで作り、ブログはWordPressを利用するという使い方ができるだろう。番外編として、WordPressのルートディレクトリにCodeIgniterのsystemフォルダやapplicationフォルダを置くという方法もあると思うが、この場合は、WordPressの管理画面とデータベースのみを利用してサイト構築はCodeIgniterで行うことになると思う。

もちろん、最初からWordPressとCodeIgniterを連携させようなんて考えないで、「素直にCodeIgniterで構築されたSeezooCMSPyroCMSなどを使えばいいんじゃない」という考え方もあるだろう。まあ、多分それが正解だろうが、いくらCodeIgniterが気に入ったからといって、使い慣れたプラットフォームはなかなか捨てられないということもある。

また、3番目の方法なら、たぶんWordPress以外のCMSでもうまく行くと思うので、いろいろと試してみると、思いもかけない組み合わせが見つかるかもしれない。

ただし、現段階ではあくまでもお試しレベルなので、予期せぬ問題を孕んでいる可能性はある。実際のサイト構築などに応用するときは、くれぐれも自己責任でお願いしたい。

無料版のWPMLを利用したサイト多言語化

WordPressを多言語化するプラグインWPMLの最新バージョンが有償化していた。旧バージョンの2.0.4.1まではこれまで通り無料で使えるようだが、最新バージョンに、無料版はない。

CMS版が79ドル、ブログ版が29ドルとなっている。個人的な感想としては、個人のブログを多言語化するのに29ドルかかるというのは、何だか高いような気もするが、企業サイトを多言語化する費用が79ドルで済むといわれると、こちらは逆に安く感じてしまう。

企業・団体のサイトの場合は、責任の所在はがっきりしていた方が喜ばれる傾向が強いので、79ドルに1年間のサポートとアップグレード保証が含まれているとなれば、高い買い物ではないかもしれない。

とはいえ、せっかくオープンソースのWordPressを使っているのだから、できれば無料で済ませたい思う人も多い筈。

そこで、以下、旧バージョンのWPMLで使ったサイトの多言語化について情報を集めてみた。

旧バージョン(無料版)のWPMLのインストール方法

無料版のWPMLのインストール方法は次のサイトが詳しい。

なお、無料版の場合、リンク表示ウィジェットなど、WPMLに対応していないものもあるが、こうした箇所は、テキスト・ウィジェットなどで代替すれば何とかなる

無料版WPMLで多言語化できない箇所への対応

リンク表示ウィジェット以外にも、無料版WPMLでは対応していない箇所があるので、そこは、手作業で、多言語化しなければならない。

言語によるHeader画像などを切り替えなどは、次のサイトが参考になった。

無料版のWPMLが対応していない部分を多言語化(この場合は日英二ヶ国語化)するときのポイントは、次のとおり。

1. ルートディレクトリにあるwp-config.phpから次の行を探す。

define ('WPLANG', 'ja');

2. 上記の行を次のとおり書き換える。

// 言語判定(ブラウザの言語設定とGETの両方を確認)
if (preg_match('/^ja/i', $_SERVER['HTTP_ACCEPT_LANGUAGE'])) {
     $locale = "ja";
     define ('WPLANG', 'ja');
     if(htmlspecialchars(@$_GET["lang"] == "en")) {
          $locale = "en_US";
          define ('WPLANG', 'en_US');
     }
} else {
     $locale = "en_US";
     define ('WPLANG', 'en_US');
     if(htmlspecialchars(@$_GET['lang'] == "ja")) {
          $locale = "ja";
          define ('WPLANG', 'ja');
     }
}

3. header.phpやhome.phpなどで言語による切り替えを行いたい部分に、次のような条件分岐を記入する。

<?php if ($locale == "ja"): ?>
     /* 日本語モードの時表示したい記事やヘッダー画像などをここに入れる */
<?php else: ?>
     /* 英語モードの時表示したい記事やヘッダー画像などをここに入れる */
<?php endif; ?>

なお、トップページに独自のレイアウトで表示させたい場合、例えばhome.php(バージョン3.0以降ならfront-page.phpでもよい)を利用しているとしたら、get_template_part関数を応用して次のように書いておくと分かりやすいかもしれない。

<?php get_header(); ?>
<div id="container">
  <div id="content" role="main">
    <?php if ($locale == "ja"): ?>
      <?php get_template_part('home', 'jp'); ?>
    <?php else: ?>
      <?php get_template_part('home', 'en'); ?>
    <?php endif; ?>
  </div>
</div>
<?php get_sidebar(); ?>
<?php get_footer(); ?>

あとは、home.phpと同じ階層にhome-jp.phpとhome-en.phpを作り、前者に日本語の内容、後者に英語の内容を記述すれば、2ヶ国語対応となる。対応言語が増えてくると、役に立つかもしれない。

今のところWordPressのバージョン3.2.1でも問題なし

以上で、無料版のWPMLによるサイトの多言語化の簡単なまとめだが、この方法で多言語化したテストサイトのWordPressのバージョンを3.2.1に上げてみたが、今ところ問題なく動作している。

ただ、この無料版WPMLは、今後のバージョンアップは行われないようなので、WordPressのどのバージョンまで対応するかは未知数。

もちろん、簡単なサイトならWPMLなどのプラグインを頼らない多言語化もありだろうが、プラグインを含めた多言語化まで考えるなら、有料版を購入した方が安くつくかもしれない。

マルチサイトで使えるwp-jquery-lightbox

このサイトのWordPressの現在のバージョンは3.01で、プラグインとしてLightbox2のバージョンをインストールしているのだが、実は、同じ3.01でもマルチユーザー化されたWordPressでは動作しない。

というわけで、Lightbox2の代替プラグインとして、wp-jquery-lightboxをお試し中。プラグインの新規追加から検索すれば、インストールできる。

複数のマルチユーザー化されたWordPressでお試し中だが、今のところ問題なく動作している。

Ubuntu10.10で起きたWordPress.com Statsの不調

Ubuntu 10.04から10.10にバージョンアップして以来、Firefox上のWordPress.com Statsの調子がずっとおかしかった。折れ線グラフがでるべきところが、何も表示されずに、次のようになる。


最初は、WordPress.com Statsの問題だとばかり思っていたが、Ubuntu版のChromeでは問題なく動作する。さらに、Ubuntu10.10を新規インストールしたPCでは、Firefox上でも問題なく動作しているのだ。

右クリックしてみると、本来Open Flash ChartのAbout画面が出ないといけないところに、Gnashの設定画面が出てくる。そこで、Gnashを一旦削除してみることにした。Synapticパッケージマネージャからgnashを検索して完全削除すると、次のファイルもいっしょに削除された。

  • browser-plugin-gnash
  • gnash
  • mozilla-plugin-gnash
  • swfdec-mozilla

削除したファイルの内容からいうと、ある意味当然なのだが、事態はさらに悪化して、何も表示されなくなった。

次に、Firefoxを削除(完全削除)して、Gnashといっしょに再インストールしてみたが、結局何も変わらなかった。

というわけで、その日は一旦諦めたのだが、翌日、このPCを立ち上げるとWordPress.com Statsがいつもの調子に戻っていた。

Gnashを再インストールしたのが良かったのか、Firefoxだったのかは分からないが、まあ、ここは結果オーライということで、同じような症状でお悩みの方は、一度試してみていただきたい。

WordPressの緊急事態に備えてWP-DBManager

一昨日、納品間近のサイトがクラッシュして、大慌て。それでも、こまめにデーターベースのバックアップを取っていたことで、大事には至らなかった。

個人のブログの場合、投稿データだけなら、コントロールパネルのツール→エキスポートからバックアップを取ることはできるが、これではプラグインの設定まではバックアップできない。

そこで、データベースのバックアップということになるのだが、まめな人は、レンタルサーバーのコントロールパネルからphpAdminでMySQLにアクセスして、エクスポートすればよい。エクスポートの仕方は、WordPress Codex日本語版の下記のページに書かれている。

WordPressのデータベースのバックアップ

WordPressの復元

上記のページでは、phpAdminを使わない場合として、プラグインWP-DB-Backupを使ったデータベースのバックアップ方法が紹介されているが、個人的には、WP-DBManagerの方が使いやすいのではないかと思っている。

現時点でのWP-DBManagerの最新バージョンは、2.6で、WordPress3.01にも正式対応している。有志の方による日本語化ファイルも配布されている。

プラグインの新規追加から、WP-DBManagerを検索すれば簡単にインストールできる。ただ、有効化した直後、いきなり以下のような警告が発せられるので、少しだけドッキリするかもしれない。 Continue Reading…

ドメインキングを弄ってる間にQuick Cacheが復旧

申し込んだまま放置していたドメインキングに、テスト用のWordPressを手動インストール。しばらくして、Quick Cacheはインストールできるだろうかと思い、ドメインキング上のWordPressで試したら、すんなりと成功。

でも、こんな警告メッセージが表示された。

You need PHP v5.2+ to use the Quick Cache plugin.

どうやら、Quick Cacheは、PHPのバージョン5.2以上でないと動作しないと言っているようだ。そこで、Quick Cacheを無効化して、WP Super Cacheをインストールしてみたところ、今度は、WP Super Cacheはセーフモードでは動かないという警告が出た。ちなみにドメインキングのPHPのバージョンは5以上5.2未満(正確にはバージョン 5.1.6)のようだ。

動的にページの生成を行うWordPressの場合、ページ表示の高速化のために、キャッシング用のプラグインは必須といってもいい。どちらのプラグインも使えないというなら、ドメインキングでWordPressを運用するのは諦めようかと思うほどだが、あれこれコントロールパネルで設定を弄っていたら、意外に簡単に問題が解決した。

コントロールパネルからドメインを選択して、設定をクリックし、サービスの項目にあるPHP対応で、「’safe_mode’ を有効(On)にする」のチェックボックスを外すと、この問題はあっさりと解決する。あとは指示通りにフォルダやファイルのパーミッションを変更してやれば、WP Super Cacheはきちんと動作した。

なお、このブログを運用しているさくらのスタンダードプランのPHPのバージョンは、5.2.14なので、どちらのプラグインも問題なく動作している。

Quick CacheからWP Super Cacheに緊急避難

Quick Cacheを2.2.6にバージョンアップしようと試みているのだが、次のようなメッセージが発せられて、バージョンアップできない状態が続いていた。




バージョン2.2.5のままでも問題なく動作しているが、もう2日間もこういう状態が続いているので、今日は、Quick Cacheをいったん削除して、再インストールするという方法を試みてみた。ところが、事態はさらに悪化。いったん削除したら最後、新規インストールはできないという結果に終わってしまった。

というわけで、WP Super Cacheを有効化して、こちらに緊急避難。いきなり警告メッセージが出たが、指示されたとおりにwp-contentのパーミッションを755に変更したら警告は消えた。

久しぶりにWP Super Cacheを使用しているのだが、昔よりも初心者に易しくなったような気がする。

PHP ExecutionがWordPress3.0.1でも動作

以前、ブログの記事や固定ページでPHPコードが使えるプラグインとして、Exec-PHPについての記事を書いた。この記事でも触れたように、Exec-PHPは優れたプラグインで、安定性にも定評があるのだが、使用するに当たってはビジュアルエディタをオフにしなければならないという欠点があった。

私の場合、ほとんどHTMLエディタしか使わないので、特に気にならなかったのだが、それでもときどき、ビジュアルエディタを使いたくなることもある。

そこで、ビジュアルエディタと両立できるプラグインとして、本日PHP Executionをお試しインストールしてみた。インストール後、PHPコードを埋め込んだ記事をビジュアルエディタで編集するとこうなった。



記事下のPHPという画像の部分にPHPコードが書かれていて、HTMLエディタに切り替えると、コードが表示される。また、セキュリティ上の問題が生じないように、記事中のPHPを編集したり実行できる人に制限を加えることができるようにもなっている。

前回Exec-PHPをインストールする際にも、どちらをインストールするか迷ったが、WordPress.orgの動作投票で、Exec-PHPが15対2でWordPress3.0.1で動作するとなっていたのに対して、PHP Executionは投票数が2で、情報不足となっていたため、Exec-PHPを選んだ。

他にも、ビジュアルエディタと両立できるプラグインとして、 Inline PHPなどがあるが、何も手を加えずPHPコードを書き込めば良いPHP Executionに対して、こちらは、PHPコード部分をexecタグで囲むという方式となっている。

この辺りは、好みの問題もあるだろうから、いろいろと試してみるとよいと思う。

WordPressの投稿でPHPが使えるExec-PHP

ブログの投稿内で、PHPコードを実行できるプラグインExec-PHPをインストールしてみた。以前、同じような機能を持つrunPHPというプラグインを試したことがあったが、現在は作者のホームページも閉鎖されていた。

Exec-PHPはプラグインの新規追加から簡単にインストールできるが、投稿や固定ページを編集しようとすると、次のような警告が出る。


この英文の警告は、簡単に言えば、「ビジュアルリッチエディターを使用すると、せっかく書き込んだPHPコードが消えますよ」という意味だ。対処法としては、ユーザーの「あなたのプロフィール」でビジュアルリッチエディターをオフにするか、Deactivate Visual Editorというプラグインを使って一時的にオフするかのどちらかだ。 Continue Reading…