2200 WordPress, Joomla, Drupal, … Websites Load Time Comparisons PAGE LOAD TIME (2009/1/10)

やはり、MovableTypeは静的なページ出力ということで、一歩抜きん出ている感じでしょうか。いずれにしても数十ページやそこらでは大して差はでないですが。そして意外にもWordPressはページ数が増えても好成績…に見えますね。

サーバの性能（CPUやメモリ）や使用しているJavaScriptの数によっても全然変わってくるので、まぁ目安に過ぎないでしょうけれどね。下手なVPSや安い専用サーバなんか借りると自由度が高いかわりに低スペックだったりするので、月額1000円以下の共有サーバのほうが快適だったり。このブログが設置されているのは『エックスサーバー／X10（月額1,050円）』のサーバ番号：sv69ですが、サーバのスペックは、Core2 Duo E6600 ( 2.40GHz )、メモリ4GB。もっと新しいsv166だと、Xeon E3110 ( 3.00GHz )、メモリ8GB。

それから、今時のサーバなら大丈夫だと思いますが、WordPressの場合、PHPのmemory_limitは32MB以上は必要です（ソースの中にも書いてあったような気が…）。以前は、サーバのデフォルトが8MBというサーバもありましたが、そうするとPHPのエラーが出力されたり、画面が真っ白になったり、やたら遅く感じたり…。

php.ini の記述例

.htaccess の記述例

※たいていはトップディレクトリに置きます。
※いずれもサーバ側が設置を許可している必要あり。

まだあまり模索していないですが、結論から言うと、とりあえず下記のようにすれば出来ています。

1. テストサーバーを用意する（WordPressをインストールする）
   同一サーバーの別階層に別のWPをインストールすればOK。 
2. テンプレート（例：index.php）の冒頭でwp-config.phpを読み込む
   <?php include(‘../../../wp-config.php’); ?>
   <?php get_header(); ?>
   ….. 
3. プレビューの度に「ライブビュー」ボタンをOn/Offする

Adobeの新しいシリーズ「CS4」の中で、Webオーサリングソフトウェア「Dreamweaver CS4」の新機能の１つは「ライブビュー」という機能。

これは、従来ならファイルを編集後FTPでUP→ブラウザでリロード、という手順で行っていた確認作業をDreamweaver内に内蔵されたWebブラウザで行い、作業を効率化を図れる機能。注目すべきはその内蔵ブラウザの描画エンジンが、Safariなどでも採用されている「WebKit」が使われているので、かなり本番に近いプレビューができること。”使える”機能になっています。

ということで、早速WordPressのテンプレート編集につかえないかな〜と考えたわけですが、使う前から薄々懸念されることがあります。

WordPressに限りませんが、CMSのテンプレートって、それ単体では完結していなくて、header.php/index.php/sidebar.php/footer.phpなどに分かれてることが多いですね。なので、index.phpだけ「ライブビュー」でプレビューしたところで、HTMLページを構成するヘッダーもフッターも備えていないのでエラーが発生します。

ではなぜWordPressの本番サイトはエラーを起こさず、ページが生成されるかといえば、index.php内の冒頭get_header()を、ページ下部にてget_sidebar()、get_footer()というWordPress独自の関数が挿入されていて、これをきっかけに各テンプレートがいわば”合体”しているわけです。

「じゃあDreamweaverもget_header()を実行してくれればいいじゃん」

という話が出てきそうですが、そんな関数Dreamweaver自身は知る由もなし。WordPressの独自関数なので。

（この辺、DWの拡張機能として提供されたら便利ですねぇ…ちなみにget_header()をinclude(‘header.php’)に置き換えると無事実行されます、WPではなくPHPの関数なので。ただ弊害があるかどうかはわかりません）

このget_header()…関数がこのindex.phpテンプレート内に定義されていれば無事実行できますが、実際はWordPressの別ファイルに定義されています。結果として、冒頭に書いたように、WordPressの”根っこ”のファイルでもある「wp-config.php」ファイルを読み込んだところ、ページ形成に必要な情報が呼ばれてどうにかページを形成できました。

しかしこれをそのまま本番サイトにアップするとエラーが発生します。

※２のライブビューをOn/Offしないと反映されないのは使い方が間違っているのか仕様なのかバグなのかわかりません。

ということで、実用的な方法を模索したいと思いますが、すでにご存知の方は教えて下さいっ<(__)>

【追記】JavaScriptなどブラウザ側で実行されるスクリプトの編集こそ効果を発揮しそうです。PHPはサーバ側で実行するスクリプトなので、編集後は当然サーバーに何らかのかたちでアップロードしない限り実行できないですから。。。command+shift+u（アップロード）、commant+tab（アプリ切り替え）、command+r（リロード）のほうが早くて確実？

WordPress 2.6.x “Duplicate Custom Field” Issue alexking.org (2008/9/6)

2.6から備わった「Post Revisions」機能による影響のようですが、使用するプラグインが、記事を保存する時に実行されるsave_postというフックが持つ２つのパラメータの内、$postではなく$post_idを使っている場合に複製される問題が起きるようです。

記事のリビジョンは、リビジョン自体がオリジナルの記事とは別の$post_idを持っています。そしてそのリビジョンを保存する時に、オリジナルの記事を保存する時と同じsave_postというフックが実行されるため、$post_idというパラメーターを参照した時に「リビジョンの」$post_idを読み、結果「カスタムフィールドが未登録」と判断されて、追加されてしまうようです。

保存後その記事の編集画面を開くと、オリジナル記事に保存されたカスタムフィールドと各リビジョンに保存されたカスタムフィールドが同時に表示され、ダブって表示された状態になります。

—

MT形式のインポート機能をカスタマイズして、エクセルから複数のカスタムフィールドを持つ大量の記事をインポートしていたところ、いくつかの記事でこの「カスタムフィールドが複製される」現象が確認され、原因を調べ始めたところでした。しかしどのタイミングで複製されたのかはっきりわかっていないんです。WP上で記事を再編集しても複製されるわけではありません。インポートに失敗した時なのか。カスタムフィールド追加の部分のコードの書き方が悪いのか？

—

この問題を抱えるプラグインの、とりあえずの解決方法として、以下のような方法が提示されています。

add_action('save_post', '（関数名）', 1, 2);

save_postフックの$post_idだけじゃなく$postというパラメーターも利用できるようにして、
カスタムフィールドを追記する部分の関数の先頭で、

if ($post->post_type == ‘revision’) {
return;
}
（従来のコード）

「もし（保存しようとしている記事が）リビジョンだったら何もしない」と付け加える。2.6以降、オリジナル記事ではなくリビジョンの場合はpost_typeに「revision」という値も持つようになったのでそれで判断できるようです。

WordPressに多機能でキレイなメールフォームを簡単に追加できるプラグイン「cforms II」を触っていて、ちょっとトラブルにハマったのでメモ。プラグインの詳細は別途紹介したいと思います。

■遭遇したこと：
メールが送信できない。「少々お待ちください」のメッセージで止まってしまう。

■原因：
プラグインをインストールした後、WordPressの階層を変えたため。

プラグインをインストール時のWPの位置）

その後変えたWPの位置）

※ドメイン直下

　
■起きていたこと：
/cforms/lib_ajax.php の取得に失敗。プラグインインストール時にcforms IIが自動でlib_ajax.phpへのパスを/cforms/js/cforms.jsの６行目に設定してくれていたものが、そのまま残っていた。
つまり、インストール時に

と自動的に設定されたが、WPの階層を変えてもその部分はそのままだったため、ファイルが見つからずにエラー。

■行った作業：
/cforms/js/cforms.jsの６行目

を

に修正して上書きアップロード。

ブラウザのキャッシュを空にして再起動。

以上

■ひとこと：
cforms IIのインストール直後に、管理画面＞cforms IIに何やら注意書きのような以下のメッセージがちゃんと出てたんですよね…問題なく送れてたのでほとんど見てませんでした。

WPのディレクトリ変更後はメッセージも表示されなくなって、すっかり頭から抜けておりました。おまけに、ちょうどサーバ側のPHPのバージョンを４から５に変えたりしたので、そっちか？？と悩んでみたり。。といっても30分程度のことでしたが。

Firefoxのアドオン「Firebug」のコンソールで確認すると上記ファイルが「404」と表示されて気がつきました。

サイト公開直前にWPの階層を変えた時などは要注意ですね。

※あと、ロリポップ（レンタルサーバ）では初期状態ではPOSTメソッドが許可されていないために送信失敗するようです。こちらをご参照ください→
※日本語翻訳ファイルも上記サイトで配布されています。

WordPress(2.1以上)の投稿画面に標準で備わっているボタン類…実はこれ、全部表示されていないんです。
そしてなんと、キーボード操作で簡単に拡張機能を表示/非表示できるんです。

↓普通、インストール後はこうなのが…

キーボード操作で、

Windowsの場合）
Firefox「alt + shift + v」
IE「alt + v」

Macの場合）
Firefox「control + v」

↓こうなる。

ボタン類が拡張されました。
もとに戻すには、先ほどのキー操作か、拡張された２段目の左端のボタンで隠せます。

ちなみにMacの「Safari」でもビジュアルエディタが使えるようになったみたいでこのイースターエッグも有効…ですが、エディタ自体の動作が不安定ですね。

#バージョンME2.2.3で確認しました。

【追記】
バージョン 2.3～ではこれらのボタンは標準？のようですね？

www.solo-technology.com/blog/2007/01/31/wordpress-21-more-editor-options/

情報源）
WordPress 2.1 – extra tools for your editor Websitetology(07/3/29)

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でデータベースから呼び出しても良いです）

しかし今、あるお客のサイト（2.0.10で構築）で長めの記事タイトルを付けたところ、リンクエラーになってしまった。

具体的には「…７月のおすすめコース」というタイトルが、２２文字目までは正常でその後が「…７月のおす%e6」のようにエンコードに失敗して、リンクエラーとなる。

これを別のver2.2のブログで同じ記事タイトルで試したところ、「…７月のおす/」とカットされながらもリンクは正常。

WordPressを日本語URLで運用するなら2.0.x系は注意が必要です（避けた方が良いかも）。
また、日本語URLのSEO効果を意識してタイトルを付けるなら22文字以内に含めないといけませんね。

WordPressの投稿画面ではコメントタグ＜！– 中身がコメントアウトされます–＞が使えないようです。深くは検証していませんが、あるユーザーが画像（imgタグ）をコメントタグで囲んだところ、そのコメントタグ以降の投稿内容が表示されずに（テンプレート部分は表示される）、サイトのレイアウトが大きく崩れてしまいました。プレーンなHTMLファイルで同様の書式を試したところ、特に問題なくコメントアウトされて、画像を隠すことができました。

WordPressの追記機能である＜！– more –＞や改ページ＜！– nextpage –＞とコンフリクトするんでしょうか。とりあえずメモしておきます。