Google Analytics でレポートを見ているとき、「URL だけじゃ分かりづらいなぁ。タイトルも表示されないかなぁ」と常々思っていたワケです。
（「タイトル別のコンテンツ」では表示されるんですけどね。というか、それでしか表示されない）

が、URL にパラメータを直接（ムリヤリ?）追加してやることで、ページタイトルを URL と一緒に表示させることが出来るんだそうで。

方法としては、「上位のコンテンツ」などを表示しているとき、URL の「ID=XXXXXXXX」の後に「&segkey=request_uri|page_title」を挿入するだけ。
なぜかこの位置以外に挿入しても画面が切り替わってくれませんでした。
順番なんて関係あるんですかね。不思議。

「上位のコンテンツ」以外にも、「コンテンツの詳細」とか「閲覧開始ページ」とか、あるいは「トラフィック」の方の「キーワード」とかでも表示することができました。
ただ、若干動作がおかしくなる場合もあるので、現時点ではあくまで「参考データ」くらいに考えておいた方が良いのかも知れません。
（だからまだ標準では表示できないようにしてるのかな）

元記事はこちら↓。
»Google AnalyticsでURLとページタイトルを同時に表示させる方法 | 海外SEO情報ブログ・メルマガ

で、今回、勢いでざっくりとまとめてみたのでついでに公開します。
本当にざっくりなので抜けもあるだろうし「それくらい書かんでも分かるわボケ」なものもあるでしょうけど、まぁそれは追々。
ディレクトリ名やファイル名として使用することを前提としているので、文法とかは全く考慮してませんので悪しからず。

最近、医療・病院関係のサイトに仕事で関わることが多いので、後半はほとんどそれ関係です。

あと、英訳／和訳をするときにいつも利用させてもらってるのは「スペースアルク」さんです。
単語そのものの訳はもちろん、例文も豊富で非常に分かりやすいのです。
いつも頼りにしてますよ。あざーす。

思い付いたら追加・修正していきます。
「これも入れた方が良いよー」というのがあれば、コメント欄にでも放り込んでください。

• 同一ドメインにおいて（仮に「http://www.hoge.jp/」とします）
• Firefox で保護されていない特定のページ（「http://www.hoge.jp/〜」）から保護されている特定のページ（「https://www.hoge.jp/〜」）へリンクしたとき
• 「一部しか暗号化されていない」という状態になる
• そのページをリロードすると、その事象は解消される（すべて保護されている状態になる）
• 同じリンク元ページの別の箇所から、まったく同じ URL にリンクしても、上記のような事象は発生しない（すべて保護されている状態になっている）
• リンク先 URL を直接入力したり、他のページからリンクしても、やっぱり事象は発生しない
• つまり、特定のページの特定の箇所にあるリンクでのみ、事象が発生している（再現性あり）
• IE、Safari、Google Chrome といった他のブラウザでは特にそういったことは起こらない
• 逆に Opera では、どの保護されていないページ（「http://www.hoge.jp/〜」）からであっても、保護されているページ（「https://www.hoge.jp/〜」）へリンクした場合、「保護されてはいません」となる
• Opera の場合、Windows ではリロードすると解消される（保護されている状態になる）が、Mac だとリロードしても解消しない（URL を直接入力してもダメ）
• このサイトは PHP で構築されていて、ファイル名によって「http://」と「https://」を 302 リダイレクトで切り替えている（「info.php?〜」なら「http://」、「edit.php?〜」なら「https://」という具合）

という感じです。
もう、まったく意味が分からないんですけど……。

Web ページを表示するときには、まず HTML やら CSS やら JavaScript やら 画像やらをダウンロードする必要があります。
それら各ファイルを圧縮することで転送量を小さく抑え、結果的にパフォーマンス向上（時間短縮）に繋げましょう、というお話。
ページのつくりにもよりますが、70～80% くらいフツーに圧縮されちゃいます。強力。

自宅サーバーや専用サーバーを使ってる場合は Apache の設定を直接いじることも可能ですが、今回はとりあえずパス。
httpd.conf あたりを触ることになるんでしょうけど。

あと、「gzip」とは何ぞや、というのも、正直よく分かりません。
昔から使われてるし一番普及してるし圧縮率も高いし使用制限とかもフリーだし標準化もされてるし、っていう感じなので、あまり深く考えず乗っかった方が良さげかな、と。

.htaccess での gzip 圧縮設定方法

さて、gzip 圧縮するには、「mod_deflate」モジュールを使います。
（ただ、これは Apache 2.x 系の場合で、Apache 1.3 とかの場合は「mod_gzip」を使うそうです）
で、これを .htaccess で設定するワケですが、ただ圧縮するだけなら以下の一行を書いてアップするだけでOK。

AddOutputFilterByType DEFLATE text/html text/css application/x-javascript

他にも色々細かく設定できるみたいなんですけどね。圧縮率とか。
そんなにこだわらず「圧縮できりゃいいや」っていう（僕みたいな）人ならこの一行で充分でしょう。

「AddOutputFilterByType DEFLATE」の後に、圧縮の対象とするファイルの形式（メディア・タイプ、コンテント・タイプ）を指定します。
上記の指定は HTML と CSS と JavaScript の3種類で、画像は対象から外しています。
（jpg や gif やもともと圧縮してますし、png も一応最適化してるので、gzip 圧縮したところでそれほど効果は望めない）
まぁ、通常はこの 3 つで大丈夫なハズ。

ちなみに、PHP のページについても、「text/html」に含まれてます。
デフォルトでそうなのか、meta タグで「content=”text/html; charset=UTF-8″」というような設定をしているからなのか……。
詳しいことは分かりませんけど。

圧縮できてるかどうかの確認は、Firebug の「接続」タブや「YSlow」でも出来るのですが、↓のような便利なサイトもあります。

»GIDZipTest: Web Page Compression (Deflate / Gzip) Test – GIDNetwork

URL を入力したら、圧縮可否だけでなく、圧縮率やレスポンスヘッダーまで表示してくれます。

注意点など

アクセスのたびに圧縮して転送して……ということを繰り返すので、ユーザー数によってはサーバーにかなりの負荷がかかることも有り得ます。
サーバーのスペックや Web システムとの絡みもあるのでケースバイケースになるんでしょうけど、もし動作が重くなったりした場合は別な方法を検討した方が良いかも知れません。

WordPress で gzip 圧縮

WordPress が入ってるサイトに↑の方法を試してみたら、「Internal Server Error」が発生。
どうしたものかと思ったら、そのままズバリのプラグインがありました。

»WordPress › GZIP Output « WordPress Plugins

管理画面から「GZIP Output」を検索して、インストール→有効化するだけです。
設定は特に無し。いや便利。

WordPress 本体のバージョンについては、2.8.3 までしか動作確認されてないっぽいのですが、2.9.2 と 3.0 に入れても（今のところ）ちゃんと動作してます。

参考サイト

• mod_deflateでgzip圧縮 – Develop with pleasure!
• ホームページの表示を高速化する – Live Commerceドキュメント
• mod_deflate – Apache HTTP サーバ
• ＠IT：mod_deflateによるコンテンツの圧縮転送（2/3）
• YSlowでウェブサイトのパフォーマンスを改善： gzip圧縮を有効にする – builder by ZDNet Japan

発生した現象はタイトルの通りですが、テーブルに設定した線が、Firefox で見てみると表示されたりされなかったりするのです。
「されたりされなかったり」とは言っても、表示のたびに結果が変わるということではなく、再現性はあります。
ただ、文字サイズを変えたり行間を変えたりパディングを変えたりすると、表示される線と表示されない線が違ったりするということです。
色々な数値を微調整していけばすべての線がちゃんと表示されるポイントがあるかも知れませんが、環境が異なればまた結果も変わってくるでしょうし、根本的な解決にはなりません。

というワケで、色々試した結果、以下のような方法に落ち着きました。
かなり無理矢理ではありますが、今のところ正常に（？）表示されています。

原因は「border-collapse: collapse;」？

ネットで調べまくってもいまいち情報が無かったので、Firebug を使って一つ一つプロパティをいじりながら確認してみました。
すると、どうやら「border-collapse: collapse;」が原因らしいことが判明。
テーブルごとに設定するのが面倒なので、「border-spacing: 0;」と一緒に「border-collapse: collapse;」を table タグセレクタで一括設定してるんですが、これを Firebug で外すと線が表示されたのです。
（もちろん線の重なりが解除になるので太くなっちゃいましたが）

じゃあ、この現象が起こってるテーブルだけ「border-collapse: separate;」にすれば良いのかも。
という仮説を検証するため、「border」の設定方法を若干メンドくさい方法に変更。
つまり、元々は「border」で四辺をいっぺんに設定していたものを、table 全体とセルごとの設定に一辺ずつ振り分けたワケです。

うん、分かりにくいですね。
以下、まとめ。

【元々】

table {
	border-collapse: collapse;
	border-spacing: 0;
}
th,td {
	border: 1px solid #000;
}

【修正後】

table {
	border-collapse: collapse;
	border-spacing: 0;
}
table.hoge {	/* 線が表示されなかったテーブル */
	border-collapse: separate;
	border-top: 1px solid #000;
	border-left: 1px solid #000;
}
th,td {
	border-bottom: 1px solid #000;
	border-right: 1px solid #000;
}

結果、見事成功。
これで、Firefox でも全ての線が表示されるようになりました。

やっぱり IE 対策は必要

ところが、それで完全解決とはいきません。
毎度毎度の登場、IE6 が顔を出します。今回は IE7 もご一緒でした。

上記の設定をしたところ、何とセル同士の間に隙間ができたのです。
IE8は無事。ということは、IE6 と IE7 のバグ……？　またかよ……。

とはいえ、今回の元々の原因は Firefox にありますので、Firefox にだけ上記の設定を適用することにしました。

それが以下。

【最終版】　※設定の仕方が間違ってたので修正しました。[2010-05-19]

table {
	border-collapse: collapse;
	border-spacing: 0;
}
table.hoge {	/* 線が表示されなかったテーブル */
	border-top: 1px solid #000;
	border-left: 1px solid #000;
}
html:not([lang*=""]) table.hoge {	/* Firefox用ハック */
	border-collapse: separate;
}
th,td {
	border-bottom: 1px solid #000;
	border-right: 1px solid #000;
}

Firefox にだけ適用するハックって何種類もあるみたいなんですが、何となく安定してるっぽいので今回はこの方法にしてます。
（参考：逆引きCSSハック(IE8,Firefox,Opera,Safariを含めたブラウザ別CSSハック) | Liquid Paper Clips）

とりあえずこれで終了。
根本的な原因が不明なのがアレですし、ハックで決着っていうのもアレですが、まぁ一つの参考にしてみてください。
他のスタイルとの競合とかもあったりするかも知れませんしね。

しかし、バグは IE だけにしてほしいもんですなー。

PLESK 上の操作で設定できたら良いんですけど、こういう細かい設定は SSH を使わないとできないみたいですね。
色々事を進めていくと、「PLESK は初心者向け」という意味がよく分かってきます。

さて、日付がおかしい原因はというと、FTP サーバーに利用されている「Proftpd」というヤツの初期設定で「TimesGMT」が ON になっていること、のようです。
んー、まぁ、要するにデフォルトの設定がローカルのタイムゾーンではなくて世界の標準時になっちゃってる、ってことですね。たぶん。
で、それをローカルのタイムゾーンに変更してやれば（「TimesGMT」を OFF ってやれば）OK、と。
（ちなみに「GMT」については wikipedia とかに詳しく載ってます）

肝心の変更方法については、とりあえず参考にしたページを列挙していきます。
正直よく分かってないですし、しかもどれが決定打になったのかすらハッキリしないので。
具体的なことは各リンク先をご覧ください。

SSH の使い方

とりあえず SSH が使えない事には話になりません。

僕の場合は Mac OSX なので「ターミナル」を使いました。
各環境によって様々あるので、探してみてください。

• FAQ/SSH/ログイン方法 – Plesk Wiki
• Windows用定番SSHクライアント「Tera Term」の使い方

まず、ログインに関しては、

# ssh （ユーザー名）@（ホスト名）

でいけると思います。
パスワードを求められるので、それを入力したらログイン完了。
ユーザー名やパスワードは、レンタルサーバーであれば契約時にサーバー会社から情報が来ているはずです。

ログインしたら、root 権限を持つ「スーパーユーザー」になっておきます。

# su -

ここでもパスワードを求められるので、ログイン時と同じく用意されたパスワードを入力します。
ひょっとしたら必要ないかも知れないんですが……。
念のためです。念のため。

あと、今回の操作で必要となる主な SSH コマンドを挙げておきます。
その他や詳細はリンク先を参照ください。

↓ディレクトリの移動（例：「/etc」ディレクトリへ移動）

# cd /etc

↓ファイルの編集（例：「proftpd.conf」というファイルを vi エディタで開く）

# vi proftpd.conf

指定したファイルが無い場合は新規作成してくれるみたいです。
あと、編集終了は「Esc」キーなんですが、これを押しただけでは特に何も表示されません。
その後に続けて終了時のコマンドを打ち込むことで処理してくれます（下記リンク先参照）。

↓終了処理

# exit

コツとしては、いざというときの「終わり方」を先に知っておいた方が良いと思います。
慎重に、慎重に。

• Telnet/SSH のUnix コマンドプロンプト一覧表 Apache httpd.confファイル編集、バーチャルホストviテキストエディタ

設定ファイルの編集

さて、ここからが本番なんですが、もう細かいことは書きません。
誤解を招いてもいけないので。

とりあえず僕が実際に試した順番で載せておきます。

• SWsoft 株式会社 POS – Point of Sales & Support – Virtuozzo, Plesk, SiteBuilder, HSPC, PEM – 全体的なプラットフォーム
• FAQ/Web/FTPがおかしい – Plesk Wiki

僕の場合、後者の設定をした段階で状況は改善されました。
FTP クライアントで表示をリロードするだけで、ちゃんとした日時で表示されるようになります。

ただ、後者だけで良かったのか、2つとも設定したから解決したのか、そのあたりは分かりません。
「元に戻して検証」なんて、恐くて出来ませんしね……。

慎重に、お試しください。

サーバーによっては、コントロールパネル（管理画面、以下「コンパネ」）がサイトと同じ階層（FTPで見えるところ）にあったり、全然別のURLなのにあたかも同じサーバーに乗っかってるような設定になっているところがあります。
（すんません。何を書いてるか自分でもよく分からないんですが、同じ状況になった人なら分かってくれると思います。たぶん）

で、そんな場合に SOY CMS のルート設定をすると、コンパネにアクセスできなくなったりすることがあるワケですね。
僕の場合は「404 Not Found」エラーになりまして、SOY CMS で設定した「見つかりません」ページが空しく表示されるばかり。
試しにルート設定を外してみると、コンパネにアクセスできるようになります。
再度設定すると、やっぱりまたアクセスできない。

うーん……、ルート設定に原因があることは間違いないみたい……。
これは困った。

……んですが、いろいろ試していると運良くうまくいく方法があったので、備忘も兼ねてご紹介しておきます。

自動生成された「.htaccess」を編集して、除外してやる

僕が関わっていた件の場合、コンパネのディレクトリ（というかURL）を特定することができました。
ということは、「ルート設定」の対象からこのディレクトリだけを除外してやれば良いはず。
ということは、「ルート設定」をしたときに SOY CMS が自動的に生成する「.htaccess」を編集すればいけるんじゃないか。
と踏んだワケです。

ちなみに、SOY CMS が自動生成する「.htaccess」は次の通り。

# @generated by SOY CMS at 2010-04-05 18:24:54
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME}/index.php !-f
RewriteCond %{REQUEST_FILENAME}/index.html !-f
RewriteCond %{REQUEST_FILENAME}/index.htm !-f
RewriteCond %{REQUEST_URI} !/index.php/
RewriteRule ^(.*)$ index.php/$1 [L]
#---SOY CMS end of htaccess file --

じっくり見てみると……。

お、「!/index.php/」てのがありますね。
「!」って、正規表現で言うところの否定ですよね。
ということは、たぶん「/index.php/」じゃなかったら、って意味ですよね。
だったら、ここに除外したいディレクトリを入れたらいけんじゃね？

という感じで、以下のようにしてみました。

# @generated by SOY CMS at 2010-04-05 18:24:54
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME}/index.php !-f
RewriteCond %{REQUEST_FILENAME}/index.html !-f
RewriteCond %{REQUEST_FILENAME}/index.htm !-f
RewriteCond %{REQUEST_URI} !/index.php/
RewriteCond %{REQUEST_URI} !/hoge_conpane/
RewriteRule ^(.*)$ index.php/$1 [L]
#---SOY CMS end of htaccess file --

ビンゴ！

うまくいきました。
コンパネも表示されるようになりましたし、ルート設定も問題ないようです。
（もちろん他にも色々調べたり検証したりしたですって。単なる当てずっぽうじゃないんですって）

もし書き方がおかしかったり、もっと良い方法があれば教えてください。
見ての通り、詳しい方ではないので。

とりあえず今回はディレクトリ（というかURL）を特定できたので、「そこを除外すればOK」という単純な方法で解決できました。
が、それ以外のケースもあるでしょうから、それはまたぶつかったときに考えたいと思います。
（いや、考えないといけないことがないことを祈りますけど）

雑感など

それにしても、ルート設定って、SOY CMS 内で管理してる特定のサイト（ディレクトリ？）にだけ効果があるものだと思ってたんですけど、そうでもないんですね。
サーバーのことを分かってる人からすると「なーにを今さら。ケッ！」って感じなのかも知れないですけど、僕のように「CMS の導入は出来るよ。でもカスタマイズはほとんど出来ないよ」というくらいのレベルの人間にとってみたら、今回のような事象は非常にビックリなのです。
いや、本当に焦った……。

日々勉強、そして経験、ですなぁ。

※まだ書き切れてませんが、とりあえずアップします。

2/27（土）に「CSS Nite in KANSAI, LP1 〜CMS POWER USER’S SUMMIT 2010〜」というイベントに参加してきました。
ちょっと遅くなっちゃいましたが、簡単にレポート（というか感想文）をまとめておきます。

イベントの概要

今回は CSS Nite in OSAKA と CSS Nite in KYOTO の合同イベントのため、「CSS Nite in KANSAI」という名前になっているそうです。
その名前から分かる通り、規模としてはかなり大きなイベントでした（最終的な参加者は約240人！）。

今回のイベントの最大の特徴は「ユーザー目線からのセミナー」であること。
つまり、CMS の開発者が「こんな機能があるよ！　こんなに便利だよ！」という話をするのではなく、実際にその CMS を使っている人が「こういうシーンではこういう使い方ができるよ！」ということを紹介してくれるのです。

意外と、こういう形式のイベントって少ない。
そして、こういう形式の方が、聞いている人にとってはタメになるというか、実際に使うイメージを掴みやすかったりします。
今後も、こういう形式のイベントをどしどし開催して欲しいですね。

会場は、「TKP大阪梅田ビジネスセンター 14階 ホール14A」。
本編が 14:30〜18:30 、懇親会が 19:00〜21:00 というタイムスケジュールでした。
（結局 21:40 くらいまでみんな残ってましたけどね）

具体的な進め方

4 つの架空事案に対して、4 つの CMS による解決策・実現策をプレゼンしていく、という流れでした。

4 つの架空事案とは、こちら↓。

1. MISSION1.既存サイトにCMSを一部組み込む低予算・即納サイト
2. MISSION2.ケータイ連動型、若者向けサイト：ネイルサロン
3. MISSION3.多重コンテンツサイト：不動産屋さんの物件管理
4. MISSION4.ログイン機能付きECサイト：カフェサイトでお取り寄せグルメ販売

で、今回登場した CMS はこちら↓。

• Movable Type（スピーカー：黒野明子さん）
• WordPress（スピーカー：太田樹さん［め組］）
• a-blog cms（スピーカー：勝又孝幸さん［データファーム］）
• SOY CMS（スピーカー：藤井正明さん［有限会社レーベ 代表取締役］）

1 の事案に対してまず 1 つの CMS によるプレゼンが行われ、その後に他の CMS についても簡単なプレゼンがある、といった感じ。
1 つのセッションが約 45 分で、メインの CMS のプレゼンが大体 25 分→その他が 5 分ずつ→時間があれば質疑応答、というくらいの時間配分だったかと思います。

始まる前は、1 つの事案に 1 つの CMS と思っていたんですけどね。ちょっと意外でした。
全 CMS の説明が聞けた分、情報量も多くて比較もしやすくなった反面、ちょっと時間的にキツかったかな、とも思います。
もうちょっと深く聞きたいことや質疑でツッコミたかったところもあるんですけど、まぁしょうがない。
この辺りはイベントの趣旨やターゲットによって変わっていくと思うので、今後に期待です。

ちなみに、架空の事案があるということは架空のクライアントもあるということで、各セッションにはその架空クライアントに扮した方々がコスプレで登場していました。
最後のセッションで鷹野さん（！）がシェフの格好で出てきたときは、ちょっとした歓声も。
今回のような長丁場では特に、こうした“遊び心”みたいなのは大事ですね。

さて、ようやく次からが各セッション（MISSION）の具体的な内容です。
「長ぇし面倒くせぇよ。もっと分かりやすくまとめろよ」って方は、総合的な感想・まとめへどうぞ。

window.open() なんかで開いたサブウィンドウを、テキストリンクやボタンで閉じるための方法です。

HTML でウィンドウを閉じる

HTML ではこんな書き方をするヤツですね。

<a href="javascript:window.close();">このウィンドウを閉じる</a>

input タグを使う場合は、こんな感じ。

<input type="button" value="このウィンドウを閉じる" onClick="window.close()" />

Flash でウィンドウを閉じる

AS2 であれば、

on (release) {
getURL("javascript:window.close();");
}

と書けば動いてくれました。
（但し、MacOS9 + IE という古い環境では落ちることがあるそうで、「FLASH-JP」のCLOSEボタンやJavascript:window.close();で強制終了に詳細と対応策が載ってます）

AS3だと getURL が使えません。
というか、そもそもの仕様が大幅に見直されているので、書き方もかなり変わっています。
詳しいことはよく分からないので、とりあえず結論だけ。
以下のように書けば、ウィンドウは閉じてくれます。

close_mc.addEventListener(MouseEvent.CLICK, closeClick);
function closeClick(evt:MouseEvent):void {
	ExternalInterface.call("window.close()");
}

イベントリスナーを設定して、関数を呼び出すのはお約束。
で、Javascript を ActionScript と絡めて使いたいときは、「ExternalInterface.call」を使えば良いようです。

window.close() だけじゃなく、他の Javascript についても、「(“〜”)」の部分を書き替えれば使えるみたいですよ。
まぁもちろん引数とか色々使うことの方が多いでしょうから、もっと複雑になってくるんでしょうけど。

window.close() のように単体で完結できる関数は、意外にもこんなシンプルなスクリプトで実現することができます。

ローカル環境では動作しない？

これ、ちょっとハマってしまった現象です。

具体的に検証した訳ではないんですが、どうもローカル環境では上記スクリプトは動作してくれないようです。
恐らく、Javascript 関連が動いてくれません。たぶん全滅。
alert ですら動いてくれませんでした。
（僕の環境は、MacOSX 10.4, Flash CS3, Firefox 3.5。Safari でも動かなかったような気がします）

それに気付かず、自分の書いたスクリプトが悪いんだと思い込んで試行錯誤すること数十分……。
光明が見えてきたのは、以前にサブウィンドウを開く方のスクリプトを使った別のデータを使って試していたとき。
間違いなく動作することを確認したはずなのに、まったく反応せず「あれ？　動いてたはずじゃ……？」となったワケです。
ローカルではウンともスンとも言わなかった「閉じる」ボタンが、サーバーにアップした途端、順調に（？）動いてくれました。

でも何で今まで気付かなかったんだろう……。
何かがバージョンアップしたときに何かの仕様が変わってしまったのか、それとも偶然サーバー側でしか確認していなかったのか……。
謎…………。

皆様も、お気を付けて。

詳しくはこちら↓の公式ブログ記事をどうぞ。
WordPress | 日本語 » WordPress 2.9

日本語版も即日リリースされたみたいです。早っ！
WordPress | 日本語 » WordPress 2.9 日本語版リリースのお知らせ

2.8 へのバージョンアップが多少地味めだったのに対し、今回はかなり大幅に変わったんじゃないでしょうか。
というより、「分かりやすい」という表現の方が適切かも知れません。

今回の目玉は、何と言っても画像編集機能。
「画像の切り抜き・編集・回転・反転・拡大縮小ができるように」なったそうです。
しかもこれから更に機能が追加・改善されていく模様。
楽しみな反面、何でもできちゃうと無茶な使い方をするユーザーさんが増えないか、そのあたりがちょっと心配。

それから、動画の埋め込みもかなり簡単になったそうです。
まだ試してませんが、動画共有サイトの URL を入力すると埋め込みコードに変換してくれるんだそうですよ。
You Tube、Daily Motion、Blip.tv、Flickr、Hulu ……と対応サイトはかなり多め。
こちらも今後のリリースで増えていく予定とのこと。

動画の埋め込みについてはこちら↓（英語）。
Embeds « WordPress Codex

その他にも改善点は数えきれないほど……。
一般ユーザーでも使いやすいシステムへ、という意識が感じられますね。
前からそうかも知れませんが、今回はちょっと違う気配。
何となくですが、来年あたりから WordPress の位置付けというか使われ方が変わってくるような気がします。何となくですが。

もちろん制作側にとっても、プラグインの管理が分かりやすくなったり、嬉しいところはたくさんあります。

注意点として、データベースの要件が変更になり、 MySQL 4.1.2 以上が必要になりました。
ま、MySQL 5 に対応してるところも多いですから、これはほとんどのサーバーで問題ないんじゃないでしょうか。
（でも一応確認はしときましょう）

では、この記事をアップしたら、僕も 2.9 へアップグレードしていきますよ。
（とりあえず何かあっても大丈夫なヤツから……）

追記

何と、現在使っているデータベースが MySQL 4.0 だということが判明しました！
つまり、2.9 へのアップグレードができません！
さくらインターネットのスタンダードプランをお使いの方、気を付けて！！

というワケで速やかに MySQL 5.1 への移行を進めたいのですが、残念ながらさくらの方で移行ツールやマニュアルは提供されていないようです。
なので、自力でやらなしゃーない、と。
怖ぇなぁもぅ……。

ただ今ググりまくってるのですが、やっぱり直接データベースやらテンプレートやらのエクスポート（バックアップ）→データベース切り替え→新しい環境でインポート、しか手は無さそう。
まぁ公式サイトのヘルプページにもバックアップの仕方が載ってたりするので、その辺りを参考にやってみます。

終わったらその手順を書く、かも。