Why WordPress is minor in Japan MarkupDancing (2008/3/30)

1.MTにはサポート面での信頼性、信頼感がある
2.データベースの利用は高額だった(からDBに依存するWPは問題外)
3.Webプロダクションでは「プログラミング」とはperlでコードを書くことを意味する（つまりperlのMTのほうが日本人には馴染みやすいということ？）
4.日本のWebデザイナーはプログラミング言語が使えない（のでPHPの基本スキルが要るWPは使えない）
5.日本ではフリーソフトウェアの健全なコミュニティが育ちにくい（ということかな？）

既にみんなが気づいている内容が多いですが、2の「データベースは高額だったから」というより、そもそもWordPressをみんな知らなかった。いまだにWebデザイナー向けの雑誌やレンタルサーバのキャッチコピーには「MovableType」はあっても「WordPress」の文字はごくわずか。ほんとに。このブログの訪問者も「WordPressとは」という検索語句が毎日ある。

　
思うに、うちのような地方の小規模Web制作者は、すぐに集まれるような制作者仲間が少ないし、そもそも積極的にコミュニティを形成することに慣れてない(独立独歩でやっているうちに一人で解決することに慣れてしまう)。そうすると入ってくる情報も少なく遅くなる（Webで探せることは自分の知っていることに関連した事以外入って来にくくなる）。だから、初動までにタイムラグができる。つまり地方の中小制作会社にじわじわとWordPressの波が広がっている最中ではない？地方、という括りは変だろうか。。

ちなみに自分がWordPressを初めて知ったのは2年半前。バージョンはME2.0.2。そのさらに2年前にはすでにMTでサイト構築していたけど、XOOPSの名前をちょろっと知っていた程度。

1の「MTにはサポート面での信頼性、信頼感がある」っていうのはあるのでしょう。制作者も日本語ドキュメントも多い。でもむしろ、MTのProNetへ加入するとライセンスを割引価格で購入できるのでそこでもマージンが得られる、ということもあるんじゃないのかな～？と思うんですけど。中・大規模サイトならなおさら…

4の「日本のWebデザイナーはプログラミング言語が使えない→WPはPHPの基本的なスキルがいる」というのは、ごく普通の企業サイトをつくる分には特別PHPの知識は要らないような気がする。ポータルサイトやCGM的なサイトへ応用するなら要るけど。本家サイトにはテンプレートタグの解説があるから。つまりは必要なのは英語力のほう。そういう意味で「wptags.com」の役割は大きかったのだろうけど、今はアクセスできず残念。

whileとかelseとかの語句が心理的な壁を高くしてるのでしょうか。MTはどんなだっけかな？

「テンプレートタグ」って要は、いくつものPHP関数と変数やら定数が自動処理される「オールインワンPHP関数」で、「PHPとはなんぞや」を知らなくても用意されたオプション値を変えるだけでOK…そう考えればMTのタグと変わらないような。

5の「日本ではフリーソフトウェアの健全なコミュニティが育ちにくい」（と勝手に解釈）についてはよく知らない。趣味や”Geek”としてWordPressを追っかけていれば分かったのかもしれませんが、仕事上必要な情報収集＆アウトプットしかしていないので。

WPかどうかわかりませんが、フリーソフトウェアのサポートをボランティアで行うような人が、本の出版を目指したり有名になろうとするとそれをタタクような人がいる…そういうのに遭遇したわけではないけど、なんだか理解できる。

横並びの環境で育ってきた同じ人間に、あびるほどの情報がそそがれ続ける、日本。同じ顔した人間が「タッチの差で抜きんでる」ことに嫉みを覚えるのか？

—

WordPressがWeb制作ツールとして日本でどの程度メジャーになれるのだろう。少なくとも、情報が少ない→利用者が増えない→信頼感がない、と負のスパイラルにならないように、微力ながら自分もがんばっていきたいですが。

自分の中では、世界的に見ればWordPressはものすごくユーザーベースが大きいので、それがすごく大きな信頼感に繋がっている（オープンソースの信頼性に疑問を抱くようなクライアントにもまだめぐり合っていない）。

自分がWPに飛びついた理由は、

1.人と違うツールを使いたい。ひねくれ差別化。
2.可能性に惚れ込んだ。
3.再構築エラーが出ない（笑
4.DBが壊れない。
5.動作が軽い。

使いながら気づいていったのは、

1.足りない機能はPHPで「即時」補える。
2.プラグインが豊富にある、つくれる。
5.WPはDBとのインターフェイス。Webアプリの母艦みたいなもの。

—

こんだけの恩恵を無料で得ているわけなので、Web制作者としても何らかのかたちでオープンソースに貢献しなきゃ、と思います。といっても自分一人じゃプラグインはつくれない（そろそろがんばってみます）。そしたらまずは、制作例をたくさん紹介して、WordPressの可能性になるべく多くのひとに気づいてもらう。そしてノウハウを共有すべく、ブログになるべく具体的に書く。フォーラムで困っている人にコメントしてあげる。そして（スキル的に必要なくても）WordPress本を買う。まだ１冊しか買ってないので全巻買うことにします（…て何冊あるんだろ汗）。

このブログもいまだにシーサーなんだけど（アカウントもってたし検索サイトにインデックスされるのも早かったし、シーサーブログのカスタマイズを頼まれたので勉強に）、このサイト自体がWPの見本サイトみたいになってたほうが話が早いだろう、と思うのでなるべく早くWordPress化します。

■目的：
WordPressブログのコメント欄にて、ブログオーナー（記事のAuthor）が書いたコメントだけ、背景色（その他CSS）を変えて、他のコメンターと区別できるようにする。

■現状：
そのコメントが記事投稿者のものかどうか確認するには、そのコメント投稿者名と記事の投稿者名を照らし合わせる必要がある。

　
■方法：
１．スタイルシートにAuthorコメント用の設定を追加する。

２．/wp-content/themes/使用中のテーマ/comments.php を開き、

このような部分を見付け、下記のように追記。

例：テーマ「EasyAll」の場合15行目

以上。

■解説：
もしコメントのユーザーIDが「1」だったら、そのコメントを囲むdivに「class=”authcomment”」が付加される。この場合の「ユーザーID」とは、WordPressブログの登録ユーザーのID。未登録のユーザーが投稿したコメントのuser_idは「0」になる。phpMyadminでMySQLのデータベースのwp_○○○_commentsをのぞくと、「user_id」という欄に「0」が並び、自分が返信した記事のコメントにだけ「1」が入っている。

しかし登録ユーザーでも未ログイン状態で投稿すると「0」になってしまう（はず）なので注意。

また、ユーザーIDが「4」だったら、上記のコードのif (1 == は「4」になる。

情報源）
How to highlight author comments in WordPress Matt Cutts: Gadgets, Google, and SEO (2008/1/31)
※リンク先の緑色のコメント欄がブログオーナー＝記事オーサーのコメント。

元ネタはこちらのようです→

wordpress.org/support/topic/145946#post-657081

MySQLのデータをバックアップするには何通りか方法があるようだけれど、エックスサーバーではphpMyAdminを使っていました。そしてMacOSX(10.5)のエディタの「mi」。

1. エックスサーバーの管理画面からphpMyAdminを開き、エクスポートにて以下のような設定でダウンロード
   
2. エディタ「mi」で開く→文字化けしている
3. wp_プリフィクス名_optionsの「INSERT」文の中で、「VALUES」という項目の３つ目の引数?が 「rss_」から始まっている行（要するにダッシュボードに標準で読み込まれるフィードの類…サイトには無関係）をすべて削除。これを残しておくと文字化け。のちにインポートでエラーを起こす。また、エディタ上の漢字コード変換でもこの部分以降が変換に失敗する。
4. すべて選択してメニュー＞編集＞選択部分の漢字コード変換＞UTF-8（サイトの文字コード）

■レンタルサーバーの「シーサイドCside」のMySQLをバックアップ
シーサイドのMySQLはShift_JISのようで、以下の手順で解決。

1. WP標準のプラグイン「WordPress Database Backup」を使い、サーバ上に保存する→FTPでダウンロード
2. エディター「mi」で読み込み後メニュー＞オプション＞文字コード修正… にて「Shift_JIS」で再読み込み
3. 先の漢字コード変換でサイトの文字コードに変換

たぶんphpMyAdminでも「Shift_JIS」で読み込む手順を踏めば文字化け解消できると思う。

—
これでエディタ上でも文字化けが直るはずです。

もし途中から文字化けしたままだった場合、どこかにデータベースの文字コード（EUC-JP,Shift_JISなど）では認識できない文字が使われている可能性があります。

例えば最近よく使われるらしい顔文字

これらはUTF-8の文字らしいけど、この文字が原因で変換がうまくいきませんでした。先に書いたとおり、インポートでエラーを起こすし漢字コード変換も失敗するので、仕方なくこの文字だけ削除。判読するのが大変！

以上

WordPressのバックアップについての参考記事（随時更新）
phpMyAdminを使ったWordPressのバックアップ EZ-INFO

【追記：2008/10/26】
機種依存文字？を使っていると、バックアップしたファイルをエディタで開いた時に全体が文字化けしますね。よく見ると「Shift_JIS」などで読み込んでいます（機種依存文字がないときは、ちゃんとUTF-8で読み込んで文字化けせずにエディタ上で表示されます）。なので、画像フォルダのパスやドメインを変更するなど編集作業をする前に、まずUTF-8で読み込み直す必要があります。それでも見た目は文字化けしたままですが、問題ありません。インポート後にはちゃんと正常に表示されます（WP標準のインポート/エクスポート機能で確認しました）。

「RSS 2.0」の場合
feed/
「RSS 0.92」の場合
feed/rss/
「Atom 0.3」の場合
feed/atom/

例）求人サイト「シゴトの森」、カテゴリ＝東京都のAtom

4510m.in/category/地域/東京都/feed/atom/

—
１つのサイトを複数のWPを使って運営している場合、これらRSSフィードを「InlineRSS」などのプラグインを使ってそれぞれのサイドバーなどに呼び出してやれば、シームレスに見せることができますね、簡単に。（もちろんダイレクトにSQLでデータベースから呼び出しても良いです）

■解決方法：
　サーバーのトップディレクトリ（最新サーバーの場合、○○○.xsrv.jp/）【追記:紛らわしい書き方かもしれません…つまりFTP設定でディレクトリを指定する時「/」とだけして接続した先、ということになるでしょうか】に「php.ini」というファイルを置き、以下の１行を記述する。

mbstring.internal_encoding = UTF-8

　テキストエディタでシンプルに上記の一行だけ書いて、ファイル名を「php.ini」として、必ずトップディレクトリに置く。例え同じアカウントで独自ドメインのサイトを複数運用していて（マルチドメイン）、トップディレクトリ以下にドメインごとのフォルダがあったとしてもそれらの上のトップディレクトリに置かないと反映されない。もし既存の独自ドメイン/サブドメインサイトが別の文字コードで運営されているならば、それぞれのディレクトリにさらに、適切に文字コードを指定したphp.iniを置く。

　上記によりWordPressを文字コード「UTF-8」で文字化けなくインストールできる。もしインストール時に文字化けしていたとしても再インストールは必要ない。php.iniを設置したら、文字化けしているであろうブログタイトルや記事を打ち直せば即座になおる。

※上記のphp.iniを置く方法は「sv50」以降のサーバ用で、それ以前のサーバは「.htaccess」ファイルで同様に行う。その場合行頭に「php_value 」を付け加える。

■補足：

　なぜエックスサーバー(Xserver)では標準状態でUTF-8だと文字化けを起こすのかについては、かき集めた情報によれば以下のようなことによるらしい。

・MySQL(データベース)の文字コードが「EUC-JP」固定
・MySQLのバージョンが古いらしく、ネット上で解説されている各種コマンドが効かない？（SET NAMES utf8等）
・PHPの設定「mbstring.encoding_translation」が初期状態で「On」になっている。めずらしいとのこと。

　つまりは、いくらWordPressのインストール時に「UTF-8」を指定しても、データベースに格納される時点で「EUC-JP」になってしまう。従ってその「EUC-JP」のデータが「UTF-8」のWordPress上に読み込まれて文字化けする。

　このあたり、技術者ではないのでこれ以上はわからないが、こういうことを知らずにいると「なぜ文字化けするのか」見当が付かずストレスが溜まる。

■追加実験：

　上記方法で「UTF-8」でWordPressが文字化けせずにインストールできたことを確認後、試しに「php.ini」の中身を削除して空の状態でアップしても…文字化けしないではないか！下の階層に置いてあったphp.iniをすべて削除してもまだ文字化けしない。なのでさらに「php.ini」ファイルを削除してみたら、文字化けした。

　つまりは推測するに、ユーザーのトップディレクトリ「php.ini」があるとサーバーの標準設定がバイパスされる。そしてphp.iniの中身を見る…しかし空なので何もせずに、WordPressのwp-config.phpに記述された「UTF-8」の指定にそって、そのままデータベースにUTF-8のまま読み書きする？
　よく分からないが、php.iniの中身が空でもトップディレクトリに置いてあればWordPressをUTF-8で文字化けなく設置できるみたい。

■エックスサーバーについて：

　格安・高機能レンタルサーバーとして結構有名？な『エックスサーバー(Xserver)』。私も去年から使っていて、１０個ほどの独自ドメインサイトを１つのアカウントで運営している。

無制限機能盛りだくさんのレンタルサーバー – Xserver(エックスサーバー)

　容量1.5GBで月額1,050円、マルチドメイン、メールアカウント無制限、スパムフィルター、MySQLデータベース、WordPress等自動インストール、アクセス解析(awstats)などがすべて無料。それまで使ってきたサーバーに比べれば自由度が高くてコストパフォーマンスも高く、それなりに満足しているんだけれど、ブログアプリ等のインストールで必ず選択する「文字コード」については結構悩まされてきた。結論から言うと、「EUC-JP」ならすんなり問題なくインストールが完了する。「UTF-8」だと標準では文字化けが起きる。また「Shift_JIS」だと、WordPressの場合プラグインで不具合が起きることが多い（RSSの読み込みなどで文字コード変換がうまくいかず文字化けしたり）。

　また現在、個人的に保留となっている問題はphpの最大メモリ容量 = memory_limitについてだが、エックスサーバーのphpのmemory_limitは、標準で15MBの様子。「Gallery2」という巨大なフォトギャラリーアプリをインストールしようとしたが最低16MB必要で、インストールの時点で警告が出て、インストールは作業は完了したもののその後の動作が不完全。たとえば最近試している「チカッパ!」はなんと50MBも使えるので、Gallery2も問題なくインストールできて動作もしている。
　ただその時はphp.iniファイルを下層ディレクトリに入れていたので、今回同様トップディレクトリに置けば反映されるかもしれない。

■参考サイト：
今回の件は無数のサイトを徘徊したが、下記の情報が決定的な情報となった。感謝したい。
「TROUBLE/224 – OpenPNE」
- フリーのSNSアプリ『OpenPNE』のサポートページのようです。
「xserverにUTF-8で設置すると文字化けします」
- WordPress Japanのユーザーフォーラム。

【追記:2008/2/3】
この記事を書いた頃と少し状況が変わってきている？ようです。
以下の記事も参考になると思いますのでメモ。

XserverでのWordpress文字化け解決 旅館業界WEBで稼ぐには(2008/2/2)
v2.2.3をXserverにインストール後、日本語表示がおかしい。 WordPress Japan フォーラム
XserverでWordPressが日本語表示にならない ネット・ライフ（yuuの徒然日記）(2007/12/28)