WordPress
2011年07月31日

WordPress 3.2 リリースパーティー in Tokyo
午後から勉強会もあったのだが、私は夕方のパーティから参加。
さすがWordPress! マイクロソフト社のカンファレンス会場 を パーティだけでもいっぱいにしている。
勉強会も盛況だったようだ。
WordPressはよくMTと比較され、「オープンソースでSA社のようなサポートがない...」と言われるが、WordPressだってAtomic社と言う会社が管理しているし、サードパーティになるがサポートもある。
ドキュメントも「WordPress Codex 日本語版」ちゃんとしている。
なにより、WordPressには、WordBenchなどのコミュニティがある。
このコミュニティがまたいい。
(といいつつ、2年前に入っているのに参加していなかった)
WordPressのパーティに参加するのは、これが2回目。
まぁオフ会も交ぜると3,4回にはなるだろうか。

いい雰囲気といっても変な意味ではない。
野心あふれる若い情熱と技術力ある者達がいい感じの集っている。
とかくこういう集まりに行くと、単に著名人の回りに集まってしまい、話題が偏る。
しかし、昨夜のパーティはそうではなかった。
WordPressの集まりは、私のような企業ユーザもいれば、自分のブログのためにと言う一般ユーザ、これから世に出て行こうとするデザイナー達、そしてWordPressを長年愛してきている人たち。
その中で、技術的な話もすれば
枕投げの話があったり
経営的な話があったり
人生相談があったり
それがいい感じを醸し出している。
そうそうこのパーティの主役は、なんと言っても「WordPress 3.2 'Gershwin'」
バージョンを重ね、単なるブログから、より複雑な分野まで利用できるCMSとなっている。
ただ WP3.2は未だPHP 5.2.4に対応するレンタルサーバでなければ使えない。
今、メインで使っているXServerも、PHP 5.2.14やPHP 5.3.3を使おうと思えば使えるので、WP3.2にアップグレードすることはできる。
ただXServerの標準インストールは未だ対応していないし、PHPの切替もも必要である。
2011年7月現在では、先行したシステムと言えるが、すぐにWP3.2.xに移っていくだろう。
とにかく昨夜のパーティは楽しかった。
2010年08月04日
内容的には細かい修正のようです。
そういえば、あすまるとBeLiveのホームページのWPも最新版にしました。
今まで使っていたCPIのVPSの一つを閉じ、X-SERVERの方で管理することにしたのです。
結構、WP2.8.6に独自に作ったプラグイン(未公開もの)を入れていたので、WP3.xは大丈夫か心配していました。
しかし『案ずるは産むが易し』
修正箇所もなく、案外すんなり移行完了。
あすまるもBeLiveも、問題なく動いています。
さて、前回 WP3.0の新規インストールで再検証したのですが、今回は『マルチサイト』について試して見たいと思います。
今まで『マルチサイト』といえばWordPress MUという別系統のワードプレスだったのが、WordPress本体でできるようになりました。
『マルチサイト』の方法はCodexにあります。
ここではやり方というより、どこが変化するのか不親切検証をしてみたいと思います。
なお、サーバはX-SERVER X10、サブディレクトリ型で検証してみます。
そうそう、WPの『マルチサイト』対応は、Apacheのmod_rewriteを多用します。
対応しないサイトでは難しいでしょう。
wp-config.phpを編集して、「マルチサイトの許可」を指示します。
define ('WP_ALLOW_MULTISITE', true);

さて、ここで「ネットワーク」の設定です。
画面での設定箇所は2箇所
・ネットワークのタイトル
・管理者のメールアドレス
な〜んだ。簡単じゃない...と思ったあなた。これで終わりではないのですよ。
次いきましょう。

すると、いろいろなことが書いてあります。
- 『blogs.dir』をwp-content下に作りなさい。
- wp-config.phpに『マルチサイト』に関する記述を加えなさい。
- 定数「MULTISITE」でマルチサイト宣言
- 定数「SUBDOMAIN_INSTALL」をfalseにしてインストールを止める
- 変数「$base」でワードプレスのベースディレクトリを設定
- 定数「DOMAIN_CURRENT_SITE」でサイトドメインを宣言
- 定数「PATH_CURRENT_SITE」でサイトルートパスを宣言
- 定数「SITE_ID_CURRENT_SITE」で初期サイトIDを宣言
- 定数「BLOG_ID_CURRENT_SITE」で初期ブログIDを宣言
- .htaccesにリライト宣言を追加しなさい。
- リライトベースとindex.phpの取り扱い
- 各サイト毎のアップロードファイルのリライト
- 各サイト毎の管理画面のリライト
- wpフォルダの処理
1の『blogs.dir』は自動生成でもいいのではないかと思うのですが、まぁ特別なWordPressだから仕方ないか。
因みに、『blogs.dir』は追加されたサイトのアップロードファイル等が納まるところ。
サイトを追加し、画像等をアップすると、『blogs.dir』下にサイトIDのディレクトリ+「files」が追加され、その下に納まる仕組み。
3のリライト宣言と組み合わされ、ソース上は「(サイトURL)/files/...」となる。
2のwp-config.phpでは、『マルチサイト』に関する多くの宣言がある。
しかし、言語指定がありません。
実はwp-config.phpの「WPLANG」は、初期サイトにのみ適用されます。
そのため、追加されたサイトは最初 英語版です。なぜ引き継がないのでしょう。
または「WPLANG_CURRENT_SITE」宣言があってもいいのではないかと思うのですが...
WordPressのリライト宣言にはなぜか「QSAフラグ」がついていません。
「QSAフラグ」は付けるべきではないのか。
管理画面に『特権管理者』メニューが追加されました。
wp-config.phpや.htaccessがいじれれば、結構簡単ですね。
『特権管理者』メニューには下記のサブメニューがあります。
- 管理
- サイト
- ユーザ
- テーマ
- 設定
- 更新

なぜなら、「初期設定言語」がここにあるからです。
私はこれに気付かず、いきなりサイトを追加したら、英語版になってしまいました。
もちろん、各サイトで言語設定は可能なのですが、自分以外のユーザに管理をゆだねるのならば、その方の利用する言語に最初に設定しておかないと、ちょっとパニクるかもしれませんね。
「メディアアップロードのボタン」も設定しておいた方がいいでしょう。
「画像がアップロードできない」といわれかねませんから。
さぁ、サイトを追加します。
追加して気付いたのですが...オプションで下記の設定があります。
なんでしょう?
- 一般公開
- アーカイブ化
- スパム
- 削除
- 成人向け
まず、主テーブルの違いは以下の通りでした。
- {$table_prefix}blog_versions
- {$table_prefix}blogs
- {$table_prefix}registration_log
- {$table_prefix}signups
- {$table_prefix}site
- {$table_prefix}sitemeta
さて、なぜ『site』と『blogs』が分かれているのでしょう。
【site】
- id
- domain
- path
【blogs】
- blog_id
- site_id
- domain
- path
- registered
- last_updated
- public
- archived
- mature
- spam
- deleted
- lang_id
きちんと調べていないので、私見ですが『site』は一個だけ登録されています。
子サイトを追加すると、その追加状況は『registration_log』に追加されます。
分からないのが、『signups』と『blog_versions』
『registration_log』『signups』と『blog_versions』の3つは、『blogmeta』のようなテーブルを作れば、対応できたのではないかと思う。
『blogs』内の子サイトの状況も、『blogmeta』で扱った方が融通性が高いWPッぽいのだけどなぁ
※『blogmeta』のようなテーブルは現在ないよ。
『blogs』は、各子サイトの状態がはいっています。
各子サイトの詳細設定は下記のテーブル群に納まるようです。
では、各子サイトはどうなのかというと、以下の通り。
- {$table_prefix}{$blog_id}_commentmeta
- {$table_prefix}{$blog_id}_comments
- {$table_prefix}{$blog_id}_links
- {$table_prefix}{$blog_id}_options
- {$table_prefix}{$blog_id}_postmeta
- {$table_prefix}{$blog_id}_posts
- {$table_prefix}{$blog_id}_term_relationships
- {$table_prefix}{$blog_id}_term_taxonomy
- {$table_prefix}{$blog_id}_terms
しかし、MUとの互換性のため、サイトとブログ、ネットワークの扱いが煩雑になっている見たいですね。
テーブル上のsite = (呼称)ネットワーク
テーブル上のblog = (呼称)サイト
さて、WP3.0から新設されたカスタム投稿タイプは、どのようになるのでしょう。
これについては、カスタム投稿タイプを扱えるようにするプラグインで試すしかありません。
プラグインがどのように対応するかですね。
ということで、プラグインについては次回。
BeLiveで作ったプラグインの検証も必要ですから。
では
2010年06月29日
WordPress 3.0 “Thelonious”
※日本語解説「WordPress 3.0「セロニアス」」
が公開されました。
日本語化も精力的に行われ、6月22日には日本語版もリリースされました。
ハイライトを読むだけでも...さすがメジャーバージョンアップ。
(詳細は 3.0 の Codex ドキュメンテーションページ )
大変魅力的なことが書かれています。
特に気になるところが多く、つくってきたプラグインもテストする必要があるので、まずは最新版を「お試し」します。
今回のハイライトの一つ、「マルチサイト対応」については通常インストール後に行うことなので、今までのバージョンがインストールできるサイトならば問題ないのではないかと思います。
※CPI Xシリーズで試しただけです。他の環境については保証できません。
最初のページ、セットアップ設定ファイルのページには、特に変更点は内容です。(文言の違いまでは確認していません)

ユーザ名がここで指定できるようになっています。
もちろんパスワードも指定できます。
パスワード指定は必須ではなく、空だと自動生成されます。
後はログインまで今までと同じでした。

ハイライトにもあるように、デフォルトテーマが「Twenty Ten」に変わっています。
ヘッダーの画像の下には「ページナビ」がついています。
これを書いていて気がついたのですが、左図は1024×768のノートPCで見た場合です。
ヘッダー画像が幅広のためか、今度のデフォルトテーマは低解像度のクライアントだと必ずスクロールが出るようです。
でも、シンプルだけどセンスいいですね。
テーマタイトルが「Twenty Ten」ということは、来年は「Twenty Eleven」って言うテーマが出たりして

- メニュー
- 背景
- ヘッダー

ウィジェットなどにカスタムメニューとして追加する機能のようです。
さてこの機能を「Twenty Ten」以外で対応させるには...
Codexには「テーマの function.php ファイルに適切なコードを挿入することができます。」(Codexより)とあるのですが...
まだ解読できていません。

こちらは使用するテーマのfunctions.phpに「add_custom_background();」を適切に配置するだけで、管理画面に「テーマ>背景」が追加されます。
やってることは、wp_headフック等でスタイルを追加しているみたいです。

こちらも使用するテーマのfunctions.phpに「add_custom_image_header」関数を追加するのですが...背景より複雑のようです。
呼び出しは「header_image」関数をimgタグ内で呼び出すといった感じのようです。
こんな感じでデフォルト状態を管理画面で変更するだけでも、デザイン変更が簡単にできそうです。
しかし、さすがメジャーバージョンアップ
変更点はこれだけではないようです。
例えばカスタムポストタイプやMUとの統合など
あと自作プラグインとの相性も調べなければならない...
とにかくやることいっぱいです。
とりあえず、今日は「インストール」と「新テーマ」について記しておきます。
2010年01月15日
しかし、このプラグインは、PC上のブラウザ(Javascriptが使えるもの)ならOKなのだが、携帯からのアクセスには対応していない。
そのため、これまではトリッキーな形でアクセス解析させるよう独自のプラグインを作っていた。
しかし、改めてGoogle Analysticsの設定をしていたら...
どのような方法かと言うと「サーバに嘘をつかせる」方法を使っていた。
つまり携帯からのアクセスであるとわかった場合、サーバが知り得るブラウザ情報をサーバが携帯に代行してGoogleに通知すると言うモノである
これが結構面倒なのである。
そのため、独自プラグインの中にその仕掛けを仕込んでいた。
そのせいか、Google Analysticsの「株式会社あすまる」の設定がなぜかなくなったので、追加作業を行った。
そこで、Google Analysticsのトラッキングコードの設定方法が変わっているのを発見。
携帯対応のトラッキングコードが追加されているのである。
そこで、この携帯対応のトラッキングコードを使ってみることにした。
そこで「何をトラッキングしますか?」で「携帯電話向けのサイトにコードを貼り付けます」のコードをコピーして、適当なテキストファイルにひとまず貼り付けておく。
コードの書いてあるテキストエリアは2つあるので両方同じテキストファイルに貼り付ける。
携帯電話向けのサイトにコードを貼り付けます」の注意書きには「下記のコードをコピーして、解析するすべてのページの最初の <html> タグの直前に貼り付けてください。」とか「下記のコードをコピーして、解析するすべてのページの </body> タグの直前に貼り付けてください。」と書いてある。
が!
とりあえず同じテキストファイルの中でOK
なぜなら、そのままでは使えないから。
どうやらPHPのスコープの取り方に問題があるのか、そのまま使っても上手くなかった。
そこで「function googleAnalyticsGetImageUrl() {」と書いてある行を「function googleAnalyticsGetImageUrl($GA_ACCOUNT, $GA_PIXEL) {」と書き換え、そのすぐしたのグローバル宣言をコメントアウト
そして「$googleAnalyticsImageUrl = googleAnalyticsGetImageUrl();」を「$googleAnalyticsImageUrl = googleAnalyticsGetImageUrl($GA_ACCOUNT, $GA_PIXEL);」と書き換える。
ついでにWordPressのプラグインによっては相対パスではまずいので、その下のimgタグのsrc属性に「<?php bloginfo('siteurl'); ?>/」を追加
このように変更をした後、テキストファイルをPHPファイルとして名前を変える。
私の場合、PCもPHPファイル化したので「analyticstracking.php」で統一して、PCと携帯を別々のディレクトリにおいた。
このあと、Google Analysticsから「ga.php」をダウンロードし、サイトのルートにおく。
そして、WordPressの場合、プラグインかテーマ内のfunctions.phpに「wp_footer」フィルタを使ってフッター部分に「analyticstracking.php」をインクルードするようにした。
なお、あくまでも私的なメモである。
そのため、大変不親切な書き方をしている。
また、絶対上手く行く方法かどうかはわからない。
たぶん、これで上手くは行くと思う。
そのため、あくまでも参考まで。
2010年01月05日
画像の編集機能などが搭載されたものである。
しかし、これまでバージョンアップされる度に使っていたプラグインやテーマが使えなくなることが多かった。
そこで、現在開発中であったり、運用中のシステムのバージョンアップをすべきかどうかを確認する為、WP-2.9を試すことにした。
まずは、あすまる/BeLiveで開発したプラグインが正常に動作するかの確認を行い、その結果を記録する。
まずはそれからテストすることにした。
テストには、CPIのテストサーバにWP-2.9をインストールし、それぞれのプラグインを使用/停止させて問題ないかチェックする。
- 自動整形を解除するプラグイン「WP-UnFormating」
→ ○自動整形の解除、PHPコードを含む置換 ともに問題なし。 - PHPのPearのパスを追加する「WP-Pears」
→ ○sample.phpのインクルードを行ったところ、問題なし。 - iniファイルを利用できるようにする「wp-IniFileLoad」
→ ○sample01.ini〜sample03.iniを呼び出す。問題なし。 - 各サイドバーWidgetにCSSクラスやアクセス権など、新たな属性を追加する「Extra Widget Properties Set」
→ △機能的には問題なし。但しローカライズ(日本語化)がされない。
公開されているものについては、WP-2.9でも問題なく機能することを確認。
ただ、「Extra Widget Properties Set」のローカライズ(日本語化)が上手く行かないことについては調査が必要である。
また、まだ公開していないが、とても便利なプラグインも多々ある。
その中で、これまで開発しているうちに、共通化すべき機能であるが、それだけでプラグインを作るほどのものでないものを「あすまる専用プラグイン」として、蓄積している。
まずは、この「あすまる専用プラグイン」からテストを行った。
その結果、主要な機能の確認だけだが、WP-2.9でも問題なく動作した。
そのほかにも、未公開ではあるが、画期的な機能を持つプラグインがいくつかある。
それを確認したのだが...ある重大な問題にぶつかってしまった。
それを解決する為には、どうしてもWPのソースを改良するしか手立てはないものであった。
続きを読む
2009年09月26日
もちろん、社外秘及び契約に関わるものはかけないが、そうでないものは書き残したいと思っていた。
だから、「開発雑記」を書くことにする。
ただ、それでも必要とする機能が見つからず、新たにプラグインを作ることは多い。
今まで作成した中で、公開しているものもある
☆PHPのPearのパスを追加する「WP-Pears」
☆iniファイルを利用できるようにする「wp-IniFileLoad」
☆各サイドバーWidgetにCSSクラスやアクセス権など、新たな属性を追加する「Extra Widget Properties Set」(現在、WP2.8.x用に修正中)
それ以外にも、各開発依頼用に作成したものや、当社開発案件共通のプラグインなど、たくさん作成している。
ただ、開発中のものや案件独自のものは、公開はできないものがある。
公開できない理由はそれだけではないのだが...
その中に、あすまるの開発の根幹となるプラグインがある。
名前は「common templates」
(まぁ、名前だけではこのプラグインが、なぜすごいかは理解されないからいいか)
このプラグインの開発はもう3年も前になる。
サブ機能やWordPress本体のバージョンアップによる調整を続けてきたが、基本は3年前に既にできあがっている。
元々、公開するつもりで作ってきた。
なぜ、公開しなかったのか...
それは、プラグイン コンペに出す為 ... のつもりでいた。
ただ、「プラグイン コンペ」の時期が来たときに限って、でら忙しかったり、WP本体がバージョンアップされ、新しい仕様に合うか確かめたりしている間に時期を逃してしまった。
そうしているうちに、このプラグインが仕事の根幹となるものになり、公開は取りやめた。
つまり、普通のページを特別な機能を持ったテンプレートを指定することで、機能を追加できる。
しかし、デザインはそのまま、あるいは希望するデザインテンプレートにすることができる。
つまり、ページを進化することができるのだ。
今のところ、この特別な機能を持ったテンプレートは、3種類だけ。
ドラクエでいえば
☆レミラーマ
☆アバカム
そのほか、このプラグインは、ページや投稿、カテゴリーを条件に合わせてドレスアップさせる機能も持っている。
このプラグインは、最新のWP2.8.4でも、問題なく稼働する。
とにかく、私にとっては欠かせないアイテムである。
続きを読む
2009年04月14日
WordCamp Tokyo 2009
へ行ってきました。
会場は、葛西区民会館。
そうです、川さえ越えればすぐのところ。
自転車で行こうか東西線で行こうか、迷いながら駅に向かっていたら、名刺を忘れたことに気づき、引き返す羽目に
参加者の中では、メチャクチャ近い方なのに...遅刻しました。
(東西線も遅れたしね)
やっぱり、自転車で浦安橋を越えるべきだった。
なお、このWordCampの模様は、WordPress.tvに、掲載されるそうなので もし行けなかった方はそちらを待てば、内容がわかると思います。
というか、英語がさっぱりわからなかった。
そのため、Mattの基調講演などが...日本語にできなくて、わからない。
みんなが笑っているところが...わからない。
WordCamp.tvで、字幕付きで掲載されるそうだから、それを見てもう一度復習しなければ...
今回もう一つ、Ktai Styleの作者 ゆりこさんの講演も参加目的の一つ
このプラグイン無くしては、あすまる制作の携帯対応は無いと言っても過言ではない。
とにかく、このKtai Styleプラグインは、すごいんです。
その作者がどんな方かなぁ...想像通りの方でした。
持って行った「株式会社あすまる」の名刺は全部配ってきました。
あすまるの名刺よりも、やっぱり効果的なのは
イベントするなら『いべんとじょぶ!』
イベント専門求人サイト 掲載料0円
参加するとポイントももらえるよ
携帯からもOK
http://evtjob.net/
これを携帯で見せたのが、ウケた。

「え〜ッ、これ WordPressですか?」
「WordPressでこんなのできるんだ」
もちろん例のゆりこさんにも、「Ktai Style ショーケース でユーザ事例として出してください」なんてお願いをしたりして
お声をかけさせていただいた方々
今後とも私共々「株式会社あすまる」と「いべんとじょぶ」をよろしく
本当はさっさと移したいのだが、サブドメインが...
それに「株式会社あすまる」のホームページもどうにかしないと
あれもWordPressなのに、その面影無し。
「あすまる日記」を載せなくては...
少し余裕ができたら、英会話を習うかなぁ
これから「株式会社あすまる」も世界に打って出なければならない。
AUTOMATTICとの提携とか、海外の展示会に出たりとか
世界制覇は...まだ遠いかも
2008年04月18日
Wordpressに興味のない方、というよりほとんどの方は読み飛ばしてぇ!!
【技術メモ】Wordpressの重複コメント対策
困りました。どういうことかというと...
Wordpressで、重複コメントなどがあると、強制的にWordPressのエラーページを生成してしまいます。
いろいろと調べると
「comment_flood_filter」というフィルタがあった。
リファレンスを調べてみると、
コメントの殺到を検知したときに実行され、
just before wp_die is called to stop the comment from being accepted.
wp_dieが実行される直前にコメントの受け入れを停止する。
Action function arguments:
実行関数の引数:
time of previous comment,time of current comment.
前のコメントの時間,カレントコメントの時間
だそうだ。
でも...重複コメントのときは...やはりwp_dieに一直線!!
困った!!
ということは...
wp_include/functions.phpのwp_dieを調べてみる。
やっぱり

バージョンごとの違いはあるものの最新の2.5を含めて、htmlを生成してdie関数で後の処理を全部殺している。
困った!!
確かにこの方法はエラー対策には確実ではある。
しかし、強制的で融通が利かない。
誰かいいアイデアはないかと調べると、WordPress本家のExtend-Ideaで「Themed Error Pages」(英語)という方法が紹介されていた。
http://hackademix.net/2007/07/31/themed-error-pages/
ドメイン名がちょっと怖いね。
このページを見ると、生成されるページの代わりに別途用意するエラーページに書き換えて、結局 dieする。
でも、この方法ではただエラーメッセージを置換しているだけで、どんなエラーメッセージになるのかは関知していない。
特定のエラーメッセージに対処したいときなどには向いていない。
そこで、同じようにfunctions.phpをハックするならば、別の方法があるのではないかと思った。
もう一度「wp_die filter」でググってみた。
http://trac.wordpress.org/ticket/6589
おぉー!! バージョン2.6用に10日前に「wp_die」が提案されている!!
wpDieFilter.patch を見る。
確かに、この方法でwp_dieフィルタは有効である。
....でも、お披露目は2.6からかぁ
しゃぁない。この方法を先に入れてみるか
これならば、特定のメッセージに対してだけ、適用するフィルタを作ることができる。
でも、ページそのものを書き換えたら、そのままdieしても大丈夫なのだろうか?
これは試すしかない!!
まず、patchの内容を目的のWordPressのfunctions.phpに入れる。
(バージョンが古いので、そのままパッチが使えません(T_T))
で、重複コメントを入れてみる。
まだフィルタを追加していないので、問題なく(?) WordPressのエラーを出した。
次に「wp_die」フィルタをadd_filterで追加してみる。
(引数を一つ増やしました!! $admin_dirです。せっかく管理画面かどうか調べているんだから)
if( !empty( $admin_dir))
return $message;
if( $message == __('Duplicate comment detected; it looks as though you\'ve already said that!')){
$message = '残念!! もうコメントしたがね!!';
}
return $message;
}
add_filter( 'wp_die', 'blv_wp_die');
結果、
「残念!! もうコメントしたがね!!」
第1関門OK!!
でも、結局はエラーページはWordPressが作っている。
じゃあ、とりあえずdieしてみますか。
if( !empty( $admin_dir))
return $message;
if( $message == __('Duplicate comment detected; it looks as though you\'ve already said that!')){
$message = '残念!! もうコメントしたがね!!';
die($message);
}
return $message;
}
add_filter( 'wp_die', 'blv_wp_die');
よーし!!
ついでだ!!
if( !empty( $admin_dir))
return $message;
if( $message == __('Duplicate comment detected; it looks as though you\'ve already said that!')){
header('Location: ../');
die();
}
return $message;
}
add_filter( 'wp_die', 'blv_wp_die');
OK!!
なぜかURLはそのままだったが、行きたいページに逝ってくれた。
使える!!
ただ、もう少しエラー元を特定できればいいのに...
でも、とにかくこの方法を改良していけば、対応可能だろうなぁ
今日はこれでOKとしよう。
2007年07月24日
WordPressでGoogle MapsなどのAJAXを利用しようとした場合、どうしても文字コードをUTF-8で作成しなければならない。
しかし、現在 BeLiveが借りているサーバ「CPI」では、内部文字コードはEUC-JP、データベースはujisの設定となっている。
そのため、2007年7月 現在は無理矢理WordPressのプログラムを変更して、UTF-8で使用できるようにした。
※詳しくは「びぃらいぶの記録」 2006年12月12日 「【技術メモ】WordPressをUTF-8でインストールする(完結編)」
しかし、このような使い方では以下のような弊害があった。
- プログラムの改変が前提になる
- バージョンアップ時に対応できるか不安がある
- プラグイン利用に不安がある。
- 表示文字コードのみの対応なので、検索等が追従できない。
そんなとき、通りすがりさんから有益な情報を得る。
ただ、検証することもなく、そのままにしていた。が...
とあるWEBシステムの作成を今頼まれている。
そのWEBシステムをどのCMSをベースに作るべきか...1ヶ月ほど悩んだ。
XOOPSで行くべきか?
GeekLogで行くべきか?
ショッピングカートに似ているから、ZenCartがいいか?
Jumulaやらいろいろとあるなぁ
もちろんMTも候補であったのであるが...
そしてGeekLogを導入してみてはと...試すことにした。
しかし、GeekLogはUTF-8環境でないと、まともに動かない。
またインストール手順がめちゃめちゃやっかい。
結局、EUC-JP環境でWordPressをCMSベースとして開発をはじめることにした。
しかし、やはり依頼主から「Google Maps」などのAJAXの利用を求められ、UTF-8環境下のWordPressを再度、検討しなければならなくなった。
実は、インストールがうまくいかなかったGeekLogは、ある副産物を残してくれた。
それはCPIのサーバでもUTF-8環境にすることができると言うことである。
詳しくは「[WordPress]CPIのサーバでUTF-8で設定する方法」を見て欲しい。
なお、この記事を書くにあたり、金内氏のブログ「我流天性 - がらくた屋」の記事を参考にさせて頂いた。感謝感謝
これにて
【技術メモ】WordPressをUTF-8でインストールする(その1)
【技術メモ】WordPressをUTF-8でインストールする(完結編)
と続けてきたが、この記事にてこの件は一段落としたいと思う。
さあ、これでWordPressの道が大きく開けた。
次回は今まで作り貯めてきたプラグインを公開したいと思う。
続きを読む2006年12月12日
さて、前回の続きですが...
直す方法を見つけました!!
※2006.12.13 WordPressのユーザフォーラムにて指摘を受けました。
この方法MySQLが4.0x下での対応方法のひとつです。
もう一度、前回のおさらい
内部コードがEUC-JPのレンタルサーバにて、WordPressをUTF-8で扱いたい場合の対処方法をいろいろなサイトや掲示板を参考にして自分なりに直してみました。
どうしてもGoogle MapsやAmazonを使ってみたかったので...
原因は内部文字コードがEUC-JPであること。
私のサイトはCPIでPHPは標準で4.4.1です。
MySQLは4.0と5.0が使えるます。
ただMySQLの4.xだとphpMyAdminからclient_charsetにはUTF-8を指定できませんでした。
MySQL5.0だとUTF-8を指定できるのですが、WordPress自体エラーを頻発します。
そのため、MySQL4.xで続けることにしました。
なお、WordPressはMEの2.0.5です。
ここまでが、前回の条件でした。
※上記でMySQL5.0でエラーが起きるようなことを書きましたが、あくまでも私の調べた状況下での結果です。
すべてにおいて起こるわけではありません。
それで、前回はwp-includes/wp-db.phpに無理矢理、UTF-8に変換する部分を付け加えました。
【問題提起】
この方法では、実は解決に至りません。
以下のような問題が残っているのです。
- [表示]-[テーマエディタ]などのデータベースではなく、ファイルを編集するページでは対応不可能。
- プラグインによっては、対応できない。
(「seo-title-tag」プラグインでは文字化けした)
といったところです。
となると、wp-includes/wp-db.phpは一時的なものになります。
可能性から考えると、POSTされた値をUTF-8として扱わなければならないわけです。
各ソースを調べると...すべてPOSTされた値を直接使っていました。
そのため、すべてに文字コード変換を入れることは無理。
しかも、新しいプラグインやテーマを適用させた時には、それらにも対応させなければなりません。
このままでは、直すことは困難です。
でも、直す方法を見つけました。
2006年12月10日
内部コードがEUC-JPのレンタルサーバにて、WordPressをUTF-8で扱いたい場合の対処方法をいろいろなサイトや掲示板を参考にして自分なりに直してみました。
どうしてもGoogle MapsやAmazonを使ってみたかったので...
※2006.12.12 この方法は一時的なものなので、このあとの記事を参考にしてください。
【技術メモ】WordPressをUTF-8でインストールする(完結編)http://blog.belive.jp/archives/50862109.html
原因は内部文字コードがEUC-JPであること。
私のサイトはCPIでPHPは標準で4.4.1です。
MySQLは4.0と5.0が使えるます。
ただMySQLの4.xだとphpMyAdminからclient_charsetにはUTF-8を指定できませんでした。
MySQL5.0だとUTF-8を指定できるのですが、WordPress自体エラーを頻発します。
そのため、MySQL4.xで続けることにしました。
なお、WordPressはMEの2.0.5です。
PHPの設定オプションを変更するには、.htaccessにphp_valueなどを書き込む方法があります。
しかしCPIでは、.htaccessにphp_valueなどを入れるとエラーになるので、wp_config.phpに同じような条件を入れることにしました。
いろいろと試したところ、次のようにしたらうまくいきました。
まずはWordPressそのものは、インストール時に「UTF-8」でインストールします。
(すでにEUC-JPで作成されている方は、必ずDBのバックアップをとってください。一度消したのちの再インストールです。)
でないとユーザの権限などが化けます。
MySQLのテーブルを調べてみると、MySQLの内部コードがEUC-JPでもUTF-8で無理矢理登録してやれば上手くゆくようです。
そのため、インストール時に「UTF-8」にする必要がありました。
一旦、インストールしたらwp-config.phpを編集します。
【オリジナル】
mb_language("Japanese");
mb_internal_encoding("UTF-8");
【編集後】
ini_set("output_buffering","on"); //2006.12.09 add
ini_set("mbstring.encoding_translation","off"); //2006.12.09 add
ini_set("output_handler","mb_output_handler"); //2006.12.09 add
ini_set("default_charset","UTF-8"); //2006.12.09 add
mb_language("Japanese");
mb_internal_encoding("EUC-JP");
ini_set("mbstring.http_output","UTF-8"); //2006.12.09 add
ini_set("mbstring.http_input","auto"); //2006.12.09 add
ini_set("mbstring.substitute_character","none"); //2006.12.09 add
これは.htaccessに同じように書いても同様であると思います。
では、問題は何か?
どうやら、POSTされた変数が内部コードのEUC-JPになっていて、MySQLに書き込まれる際にEUC-JPで書き込まれることです。
書き込まれたデータが、UTF-8で取り出されれば良いのですが、取り出すときもEUC-JPのままです。
2006年12月05日
現在、ビジネスチャンネルを拡大しようといろいろな試みをしています。
その一つが、ホームページの作成です。
もちろんこのBeLiveのです。
このBeLiveのサイトを持って、すでに1年半。
BeLiveを始めて3四半期が過ぎてます。
なのに未だに、このブログをホームページ代わりにしているのは、ビジネスをする上でも恥ずかしい限りです。
当初は、「Xoopsを使って...」と考えていましたが、xoopsはとっても優れたCMSだと思うのですが、どうもBeLiveそのものを上手く表現できませんでした。
そんなとき、「ホームページにWordPressを使ってみました。」に書いたとおり、ホームページ作成の依頼を受け、CMSとしてWordPressを使いました。
そこで好印象を持ち、BeLiveのホームページ作成をこれで行くことを決定。
現在、レンタルサーバのグレードアップとともに作成を急いでおります。
そうそう、宣伝なのですが BeLiveはCPIのレンタルサーバを代理販売しています。
CPIは、少々お高いですがプロユースの信頼性の高いレンタルサーバです。
BeLiveでは、そのCPIのレンタルサーバを最大20%オフ*で販売することができます。
※メニューやオプションによって、割引率は異なりますのでご了承ください。
もちろん、ホームページなどのお手伝いを含めて行っていますので、興味のある方はご連絡ください。
連絡先は
BeLive 代表 近藤雅昭
tel:03-5201-3974 / fax:03-5201-3712
request@belive.jp
です。
そのほか、いろいろと挑戦中です。
また決まりましたらご報告します。
それと、先日 VMWare ESXサーバのデモセミナーへ行ってきました。
これからの企業内におけるサーバ構築には、仮想化は切っても切れないアイテムだと思います。
そして仮想化技術は、大きな企業だけでなく、我々のような小さなところにとっても、今後大いにメリットをもたらしてくれると考えられます。
上手くビジネスにできればなぁ。
2006年09月29日
先月、クライアントのホームページを作り直す依頼を受けました。
まだ最終調整はしていますが、そのホームページがほぼ完成し、一応昨日より旧ページと入れ替えて公開しています。
クライアントはオルサー・ラマザン氏。高田馬場で『ヴァッシアット89』という占いのお店をやっています。
今回は知人の紹介で、そこのホームページのリニューアルを行うことになりました。
そして、これがそのホームページです。http://www.vahsi-at89.com/
高田馬場にある、トルコからきた オルサー ラマザン 先生の占いのお店。数字とカードで占います。
さて、今回の作製において各ページを一つずつ手作りするのではなく、『WordPress ME』をベースに作ることにしました。
この記事はその作製に関する感想と反省点、先日出席したWordPress Meの東京オフ会について書きたいと思います。
先に『WordPress ME』をベースにホームページを作った感想は...Good!!でした。
細かな話に入る前に、WordPress Meの東京オフ会についても書いておきたいと思います。
続きを読む
大変盛況な会でした。オフ会という形でしたが、もしあれが居酒屋ではなく、オシャレな店でやったら...いや、あの雰囲気だったからこそよかったんだと思います。
後に出てくる書籍の著者や編集者の方々や、PukiWikiを作られた方、ビジネスブログに燃えている方や長年WordPressを活用されている方など
ためになる話を、酒の力も借りながら、和気藹々と時間を忘れて語り合えたことはとっても有意義でした。
幹事を務められた方々に感謝し、お知り合いになれた方々に感謝します。
また次回も参加して大いに意見交換したいと思います。