なんとか生きながらえております。
相変わらずフレッシュな情報もご報告もなく…すっかり私の生存報告的なブログになっちゃって（笑）。

今月に入ってからいろいろとあわただしく、仕事はもとより、休みの日は休みの日でなんやかんやとやることがあり、各方面には大変な不義理をしてますね。ごめんなさい。もうちょっとで落ち着くはずです。落ち着かせます。固い決意。

ちょっと仕事の話

で、仕事の話になりますが、ちょっとメモ。

コーディングしてると、「これはどうしたらいいのかな？」って迷うときがあります。
デザインうんぬんかんぬんではなくて、HTML でページの内容を作っていく際の話。

伝えたい内容を表すためには、どんなふうに情報を整理したらよいんだろう？
わけ隔てなく、みんなにわかりやすく、使いやすくするためには、どうしたらいいんだろう？
どんな順番で、どんなタグを使ったらいいんだろう？
そもそも、ウェブサイトを作るときにいちばん大切なことってなんだろう？

それらを突き詰めていくと、めっちゃ根本的なものが私にはぜんぜん足りなくて、それができないことにはサイトなんて作れなくね？と思ってます。最近とみにそう思う。

で、迷ったら作った HTML をもう一度見直して、考え直してみたり。それでちょっとだけ突破口が見えるときもありますが、「いやーワカンネ」ってときもあります。むずかしいことはいっこもしてないのに、私にとってはむずかしい。

うっすら思うこと

私が目指しているものは（と書くととてもおこがましいが）、みんなが仲良くなるウェブサイトを作ることです。人もブラウザも検索エンジンも。ことばで表すとなんとも頭悪そうなかんじですが（笑）、そうなったらいいなぁと思うのですよ。

無茶かもしれんし、限界はあるかもしれませんが、今の時点でできる限りのことはやりたいし、もっといろんなことを知りたいし、できるようになりたい。

一歩どころか半歩かもしれませんけど、そいでもね、ちょっとずつできるようにしてこうと思いますですよ。チリも積もれば大和時代ですから。やらなきゃ始まりませんし、なにも生まれません。

という感じで、今月も半ばを迎えようとしてますが、がんばります。押忍。

いきなり疑問を投げかけちゃうのですが、みなさんはウェブサイトを印刷するときに、ウェブページに表示されている文章はもちろんのこと、画像からなにから、ディスプレイに表示されているすべて、そのまんまを印刷できた方がいいなぁとお考えでしょうか。

たとえば、遊園地にいくとして、電車でいくなら○○線で○○分、○○駅で下車、徒歩○○分。
車でいくなら国道○○線で○○交差点を左折、所要時間○○分、駐車場はココ、などという文字の情報。
それに加えて、地図の画像とか Google Maps などで表示される情報。

これら、つまり目的地までの道のりを文字で表現したものと地図が印刷できていれば十分なのでしょうか。
それとも、できればブラウザ上で表示されているサイトロゴまわりのデザインやメニューボタン、文章を装飾している画像も印刷したいのでしょうか。

ユーザが知りたい情報って、どこまでなんだろう

印刷用 CSS は、ウェブページを印刷した際に、読みやすいように最適化するためのものです。なので、普段私たちが見ているウェブサイトの見栄え（デザイン）とは、必ずしも同一ではありません。

文書構造を (X)HTML でしっかり作りこみ、視覚的なデザインを パソコンで見るウェブページ向けの CSS（media=”screen” で指定したもの） で構築したウェブサイトの場合、CSS で画像置換や背景画像の指定など、必ずなんらかの操作をしています。だけど私が知る限りでは、CSS で画像を背景的な役割（デザイン的に、という意味。しつこいけど念のため）で使用した際、それらは印刷したときには紙の上には表示されません。

私個人としては、読む人に伝えたい情報、読む人が知りたい情報さえ印刷できれば、そこにはデザイン的なものは必要ないんじゃないのかなーとおもってたんですが、ページをそのまままるごと印刷したいとおもっている方も意外に多いよね…とか、ふとおもったのですよ。そんなの、私だけの勝手な思い込みかもなぁって。実際にそのような要望をうけることがあったものですから、どうしたものか、と、仕事をしているバージョンの私は、あれこれ試行錯誤しとるわけです。

ディスプレイ上に表示されているすべてを印刷するとなれば、文章はともかく、使用している画像もすべて HTML ソースとして書き出さねばなりません。実際のとこ、必要な箇所には画像ソースを HTML 文書内に書きますが、デザインに関していえば、あくまでもブラウザ上での視覚的なデザインをするための役割として CSS という存在があるわけだから、すべてを HTML に書き出すことはしません。というか、そんなのまずないでしょうし、HTML 文書として NG といった方が正しいかも。

印刷用 CSS のために、HTML と CSS の本来の役割を無視するのはちょっとなぁ…とおもったりします。時間と労力をかけて目的を果たせたとしても、印刷物として出力したときに、そこにどれだけの価値があるんだろう、とか。考えちゃう。極端な話ね。

だけどだけど、きっちりかっちり「見たまんま」を印刷したいときだってあるわけですよね。

そんなときはユーザ側でスクリーンキャプチャして印刷するとか、ブラウザの設定ですべてを印刷できるようにする。
制作者側としては最初から PDF 化したデータを用意するか、スクリーンキャプチャした画像を別に用意する。

とかおもったんですが、前者は手間ひまかかってめんどくさい（＝スクリーンキャプチャやブラウザの設定のやり方がわからない、そのまま印刷できればいいのに！というユーザの思い）、後者の場合、PDF を見るためにアクロバットリーダがいちいち立ち上がるのがイヤだとか、画像にしたら文字がつぶれて読みにくいとか、どっちもどっちなんですよね…

ユーザの思いと制作者の限界

なので、そんなことをあーでもないこーでもないと考えてるうちに、いやー答えが出ないなぁという思いに私は至っているわけですが、どうなんでしょうね。

ユーザとしては、めんどくさい手順を踏まずに印刷したい。その中には、必要なことが印刷されていればまったく問題がないという人もいれば、いやいや全部印刷していこうよとおもっている人もいる。

だけど、実際問題、制作上での限界があります。それは技術的な問題でもあるし、ブラウザ的な問題でもある。できるだけウェブページを読む人には内容をわかりやすく、環境を選ばず使いやすくしてあげたいという気持ちはモチのロンであるけど、でもでも。でも、なんですよ。だから答えが出ない。というか、わからない、といったほうが近いのかも…

どっかで妥協点を見つけるか、もしかしたら私が知らないだけで「そんなの楽勝でできるよー」な答えがあるのかもしれません。だとしたら単なる勉強不足でごめんなさい、なのですが…ほんと、どうなんだろう。

手に入れるまでの顛末はおいといて、現在私の iPhone にインストールしてあるアプリをメモ。
7月30日現在、6個しかインストールしていないうえに（笑）、どれも人気のあるものばかりですから、まったく参考にならないでしょう。ゴメンネ。余計なものは入れたくないんだといういいわけもしておきつつ…

Twitterrific （リンクをクリックすると、iTunes が立ち上がります）

Safari を立ち上げて Twitter にアクセスするより、単独のアプリのほうが速かろうということで。Twitter 系のアプリは、ほかにもいろいろ出ていますが、定番をおさえておけばいいかという安直ぶり。

でもほんとは TwitKu みたいなアプリがほしいところ。Twitter と Jaiku にクロスポストしてることがほとんどなので、そんな便利グッズがあればいいなーと。ま、ほかにあるのかもしれませんけれどね。なければないでどうにでもなるし、私は使う一方なのでぜいたくはいいません（笑）。

• Twitterrific のサイト

WordPress for iPhone （リンクをクリックすると、iTunes が立ち上がります）

WordPress を使ったブログのエントリが書けちゃうもの。でも、ちゃんと動かない…けど、いつかのために。
それはそうと、このブログも iPhone/iPod touch 向けにようやく最適化しました。遅。

• WordPress for iPhone のサイト

iview （リンクをクリックすると、iTunes が立ち上がります）

Tumblr と FFFFOUND! のブラウジング、ポスト、Tumblr では reblog ができます。

私は Tumblr のアカウントしか作ってないので Tumblr のみの感想になりますけれど、iview で表示されるのは写真だけです。テキスト、引用、動画などの表示は一切なし。でも、パソコンのブラウザで見るより、写真が断然きれいに見えて楽しいんですのよ（iPhone の画面がきれいなせいもあるけど、画面いっぱいに写真が表示されるとやっぱり違う。というか、Windows 使ってるせいだな…）。単なるTumblr のビューワーとしてもよいのではないかと。

ただ、ちょっとハングアップし気味です。次回アップデートに期待。

• iview のサイト

駅探エクスプレス （リンクをクリックすると、iTunes が立ち上がります）

iPhone には GPS 機能がついているし、Google Transit とかもあるからそれで十分じゃね？と思うのですが、さくさく動くうえに、乗り換え時刻、料金、所有時間のほかにも各路線（モチのロンで JR だけでなく私鉄や東京メトロも含む）の時刻表や運行情報なんかも表示されるのでかなり便利。札幌や福岡の地下鉄にも対応しています。

「設定」で有料特急は含むか否か、航空会社はどのラインを使うか、乗り換え時間は「せかせか」、「普通」、「ゆっくり」、「もっとゆっくり」の中から選べて、運行情報は各路線が細かく設定できます。

将来的には有料化する方向のようです。

• 駅探エクスプレス のサイト

PhotoShare （リンクをクリックすると、iTunes が立ち上がります）

はてブで知って速攻入れたアプリ。写真共有サービスってやつですかね。iPhone で撮った写真をテキトーにポストしてます。パソコン向けのウェブサイトもあります（下記のリンク先）。

私が使ってるアプリの中では、唯一のソーシャル系。なんだかんだでいちばん使ってるアプリです。いろんな人の写真も見られるし、「家族」、「友人」、「フォロー」でカテゴライズしておくことも可能。お気に入りのユーザを見つけたら、フォローしとくとまとめて見られるってわけですね。ひととおり探してみて、何人かの方をフォローしてます。なんかいいたかったら、コメントもつけられるようになっています。

撮った写真の公開レベルは（ということばが的確かどうかわかりませんが）、「非公開」、「家族と共有」、「友人と共有」、「全員に公開」の中から選ぶことができます。

• PhotoShare のサイト

Exposure （リンクをクリックすると、iTunes が立ち上がります）

Flickr にポストしてある写真のビューワー。自分、コンタクト、人気の写真をずらりとリストアップ。sets や Favorites も見られます。
ただ単に見る用ですかね。Safari を立ち上げるより速いか、ということでインストールしてあります。

• Exposure のサイト

これからがもっと楽しいのだと思う

とまぁ、こんなかんじで弱々しいですね、ほんと。有料のものは、まだいっこも入れていないというね…。ゲームなんかも入れてないし。使いこなしてるかっていったら、そんなことはぜんぜんない。まったくない。

でもまーまーまーですよ。今の私には十分こと足りてると思います。おもしろいもの。それでいいんじゃまいか。
アプリは別にしても、メールや iTunes、iPod はふつーに使ってるし、出先でいんたーねっつもそれなりにしていると思うので…ってなんのいいわけだろう。

ヘビーなユーザはごにょごにょやってますからもっと楽しくなるんでしょうし、これからおもしろいアプリもたくさん出てくるでしょう。まだ500種類くらいしかないもんねぇ。今も十分楽しいのですが、これからなのでしょうね。

まずは旅のおともに、ひまつぶしに、ちょっと人に自慢しちゃったり的な使い方で楽しんでいこうと思ってます。お盆には実家に帰る予定なのですが、実家がねぇ、いまだにダイアルアップでどーにもこーにもめんどうなんで、iPhone がありゃなんとかなるだろうということで、またいいわけをしてこのエントリを終わることにします。

私もそのようにしたんですが、「wordpress」 フォルダに WordPress をインストールした場合だと、サイトの URL は http://www.hogehoge.com/wordpress になるわけで。特にディレクトリをわける理由がなければ、「wordpress」というサブディレクトリ名を取っ払って、http://www.hogehoge.com で表示させたいのが人情というものですよね。

ということで、WordPress の設置ディレクトリとは異なるディレクトリで URL を表示する方法をメモしておきます。
ここでは http://www.hogehoge.com/wordpress から http://www.hogehoge.com に変更する、という前提で話を進めます。

1. 管理画面　「設定」→「一般設定」の「ブログのアドレス（URL）」を希望のアドレスに書き換えて保存。
   ex.) http://www.hogehoge.com
2. ルートディレクトリに、WordPress 本体がおいていあるディレクトリの index.php,.htaccess を移動する。
3. ルートディレクトリに移動した index.php を編集する。

＜変更前＞
<?php
/* Short and sweet */
define('WP_USE_THEMES', true);
require('./wp-blog-header.php'); ※ここが変更箇所
?>

4行目　require(’./wp-blog-header.php’); を require(’./○○○○/wp-blog-header.php’); と書き換えて保存。（「○○○○」は、WordPress 本体をインストールしてあるディレクトリ名）

＜変更後＞
<?php
/* Short and sweet */
define('WP_USE_THEMES', true);
require('./○○○○/wp-blog-header.php');
?>

この index.php は、WordPress 内部の動作命令すべてを受け取るファイルです（wp-blog-header.php から読み取っている）。なので、ここで編集した index.php から wp-blog-header.php へのパスを WordPress 本体がインストールされているサブディレクトリをはさんだパスに変更する、ということになります。

4. .htaccess のパーミッションを書き込み可能にする。（mod_rewrite ルールの変更。書き込み可能にしておけば、自動的に .htaccess の中身を変更してくれます。mod_rewrite ルールは手動で書き換えることも可能です。手順 6 を参考にしてください）

.htaccess の変更前のソースは以下。

＜変更前＞
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /○○○○/index.php [L] ※ここが変更箇所
</IfModule>
# END WordPress

.htaccess の中身を確認。以下のように書き換わっていれば OK。

＜変更後＞
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L] ※書き換わった状態
</IfModule>
# END WordPress

手順 2 で説明したように、変更前は /○○○○/index.php を読み込ませていましたが、ルートディレクトリ直下に移動した /index.php を読み込ませるように.htaccess で操作しています。

5. http://www.hogehoge.com/○○○○/wp-login.php からログインしなおす。
6. パーマリンク設定をデフォルトから変更していた場合、再度保存しなおす。
   ※手動で .htaccess を書き換える場合には、管理画面のいちばん下に書き換えるためのソース（↑上のソース）が出力されますので、それを.htaccess にコピペして保存します。
7. 新しいサイト URL にアクセスし、正常に表示されるか確認。
8. .htaccess のパーミッションを書き込み不能に戻す。

流れとしては、こんなかんじです。

自分でやってみた感触としては、やはり WordPress 本体のつくりがわかってないとダメじゃん、ってのと、.htaccess の使い方というか、.htaccess の働きもきちんとわかったうえで使わないといけない、ということでした…

結果的にできちゃえばいいんでしょうけれど、なんかね、されるがままにされちゃった、やったらこうなっちゃった、ってのがいちばんきもち悪い（笑）。そんなの全然身についてないもの。なので、あれこれ探ってみるのがいいな、と思いました。失敗したら元に戻せばいいんだし。

わからないままおわる、そんなのはイヤだ、といったのはアンパンマンでしたね。そういうことです。

WordPress のバージョンアップ手順

1. 全データ（WP本体まるごと、データベース）をバックアップ。
   WP本体は FFFTP でダウンロードし、ローカルに保存、データベースはデータベースの管理画面からバックアップ。
2. 使用しているプラグインをすべて止める。
3. wp-admin フォルダ･･･フォルダごとすべて削除、新しいバージョンをアップロード。
4. wp-includes フォルダ･･･フォルダごとすべて削除、新しいバージョンをアップロード。
5. wp-content フォルダ･･･フォルダ内の index.php →新しいバージョンアップロード（上書き）する。
   ほかのフォルダの詳細は以下。
   （※使用状況はユーザごとに異なるので、すべてにあてはまるとは限らない。言語ファイルを使っている場合や、プラグインのインストール状況にもよるので要注意）
   • languages フォルダ･･･いったん、フォルダごと削除。新しいバージョンをアップロード。
   • plugins フォルダ･･･そのままでOK。
   • themes フォルダ･･･基本的にはそのままでOK。
     ただし、defalt や classic などの、もとから入っているテーマを使用している場合は、新しいバージョンをアップロード（上書き）する。
   • uploadsフォルダ･･･ここに画像データなどを入れている場合は、絶対に削除しないこと。
6. WP本体のあるルートディレクトリに置いてある、wp-config.php、.htaccess 以外のファイルをすべて削除、新しいバージョンのファイルをアップロード。
   当然、wp-config.php、.htaccess はそのまま残す。
7. http://hogehoge.com/WP本体設置ディレクトリ/wp-admin/upgrade.php にアクセス。
   データベースの更新が問題なく終われば、自動的にダッシュボードへのログイン画面へ移動。
8. プラグインを有効化、最新バージョンでも使えるか確認。
   アップグレードできるようならモチのロンでしておく。
9. 私の場合、パーマリンクをカスタム構造にしてあるので、その設定を更新。
   .htaccess を書き込みできるようにパーミッションを変えておけば、WPが自動的にパーマリンクの設定の変更をしてくれる。
   このあと、.htaccess を書き込み不可に戻すのを忘れない。
10. サイト内のページすべてが問題なく表示されるか確認。
11. おわり。

• 参考ウェブサイト ： 『WordPress のアップグレード/詳細 – ps*wiki』

wp-config.php も

上書きしてはならぬ、という wp-config.php 自体も、そのままにしてちゃダメです。
セキュリティをしっかり守るためには、ほったらかしはいかんですよね…

• 参考ウェブサイト ： 『WordPress.org 公式ブログ｜WordPress 2.5.1』（和訳）

プラグインの管理

使用中のプラグインに関しては、WPの最新バージョンで動くかどうか、ひとつひとつ検証しつつ、再実行します。
大して数も入れてないから、さして苦でもなかろう。

とりあえず自分の手を動かしてみる

WPのバージョンアップを自動的に行ってくれるプラグインもあるのですが、勉強中の身ゆえ、なんでもかんでもプラグインに頼らず、手動でもできるようになっておきたいな、ということでメモっときました。
手間をかけることなく、それで時間が短縮されるなら、このようなツールを使えばよいと思うんですけどね。ま、そこはそれ、これはこれってことで。
WPのバージョンアップを自動的に行ってくれるプラグインは、以下のサイトでダウンロードできます。

• 参考ウェブサイト ： 『WordPress Automatic Upgrade plugin update』