月別アーカイブ: 2010年2月

サイトC:WordPressをインストール

今回はサイトC(このサイト)にWordPressをインストールするまでの、顛末兼導入ガイドを書きます。MySQLのデータベースは作成してあるという前提(実は今回の事例の場合、契約したサーバRental Orbit SpaceさんがMySQLデータベースは申請を受けて発行という方式をとっていたので、非常に楽でした)かつインストールはウィザードなしで行うという前提で進めます。

まず、何をおいてもWordPressの本体を手に入れなければならないので、日本語版のサイトに行ってダウンロードリンクから落とします。この記事を書いている時点の最新版は2.9.2で、この2.9系のバージョンは日本語文字コードがUTF-8のみに対応しているようです。一方Shift-JISやEUC-JPを使用する際には、過去にリリースされた2.0.x系を利用します。ただし古い系統はメンテナンス期間も終了したようなので、WordPressを使うのならUTF-8環境にする必要があるくらいに捉えておいたほうが良いと思います。

さてローカル環境でファイルを解凍したら、wp-config-sample.phpという名前のファイルを探し、エディタで開きます。このとき、ファイルの中にも書いてありますがメモ帳などのアプリケーションでなく、文字コードを指定して保存できるエディタを使ってください。22行目付近からがMySQLの設定になりますので、あらかじめ用意しておいたMySQLデータベースのデータベース名、ユーザ名、パスワード、ホスト名(web上に公開するならば、契約したサーバのホストネームを入れます。そうでなくローカル環境で使用するなら変更しなくてOKです)をそれぞれputyourdbnamehere、usernamehere、yourpasswordhere、localhostの代わりに入れます。このファイルはwp-config.phpという名前を付けて、選択肢にあればUTF-8N、なければエディタの設定でBOMなしにした上でUTF-8で保存してください(このBOMというのは、UTF-8のファイルの頭につくちょっとした情報ですが、ここでは必要ありません)。

さてこうしてwp-config.phpが加わったフォルダを、ドキュメントルート以下にアップロードします。ブラウザでそのフォルダまでのパスを指定しアクセスすると動きます。以上でインストールの完了です。

このようなインストール手順を、サイトCについては5分程で行えました。以降トラブルもなく動いているので、導入が非常に簡単なCMSであるという印象を個人的に持っています。また、インストール後の画面でどこから手を付けてよいのかが比較的判り易く、はじめてCMSを使う人にもお勧めできるアプリケーションだと思います。

サイトCの制作では、主にWordPress標準のインストール機能で追加ファイルを落としてきて、管理画面上から見た目などを変更するという方法を使います。次回以降はその過程を報告していこうと思います。


プログラム・設定ファイルのコメント書式一覧

個人的によく使うプログラミング言語・設定ファイルのコメント書式を、まとめてメモしておこうと思います。

コメント書式一覧
言語・設定名 コメントの書式 備考
XHTML(HTML)・HTML5 <!‐‐ ここにコメントを書く ‐‐> 複数行も可能です。コメント中の連続したハイフン(‐‐)の使用は禁止されています。
CSS /* ここにコメントを書く */ 複数行も可能です。
PHP // ここにコメントを書く 一行のコメント。複数行はダメ。C++形式。
#ここにコメントを書く 一行のコメント。複数行はダメ。ShellやPerl形式。
/* ここにコメントを書く */ 複数行も可能です。
JavaScript・ActionScript // ここにコメントを書く 一行のコメント。複数行はダメ。C++形式。
/* ここにコメントを書く */ 複数行も可能です。
Objective-C・Swift // ここにコメントを書く 一行のコメント。複数行はダメ。C++形式。
/* ここにコメントを書く */ 複数行も可能です。
SQL ‐‐ ここにコメントを書く 一行のコメント。複数行はダメ。
/* ここにコメントを書く */ 複数行も可能です。
php.ini(PHPの設定ファイル) ; ここにコメントを書く 一行のコメント。複数行はダメ。
.htaccess(サーバアプリケーションの設定ファイル) # ここにコメントを書く 一行のコメント。複数行はダメ。

これからもうちょっと複雑なWEB制作を始めたら、表の項目が増えていく可能性もあります。そして、間違っている箇所を発見したら指摘していただけると非常に助かります。


サイトデザイン初歩の初歩

非常に単純なことなのですが、サイトのGUI部品、タイトルロゴなどの青写真を組み立てるとき、頭の中で考えるよりまずブラウザが立ち上がってるスクリーンショットを保存し、画像編集ソフトのレイヤーにする。その上で部品のデザインを行い配置していく。

恥ずかしながらこれに気付くのに結構かかりました。紙にデザインを描いて、実際画面上でラフ画のイメージが再現されないのは自分の技術不足だと勘違いしていたのですね。

携帯を持っているのに電卓を探して部屋中うろうろしていたような、そんな感じです。


cPanelファイルマネージャに対するいくつかの不満点

以前の紹介記事で、cPanelのファイルマネージャはオフライン環境を一掃できるような多機能なアプリケーションだと書きました。しかしながら、使い込んでいくと判る不便なところもあります。今回は一般的なオフラインアプリケーションと比較して、cPanelが劣っている点について書いてみようと思います。

まずはFTPクライアントの代わりとなる、ファイルマネージャの主要部分についてですが、以下のような不満点があります。

  • 同じディレクトリに同じファイル名のファイルを作成しようとしたとき、代替案を出してくれない
  • ローカル環境からのファイルのドラッグ&ドロップに対応していない

まず上の項目についてはなかなか根深い問題のようで、この仕様に関連しているだろうと思われる不具合がたくさんあります。同名の新規ファイルが作れないことの他、同じディレクトリ内に既存ファイルのコピーが作れない(オフラインのFTPクライアントであれば、大抵は既存のファイル名の後ろに数字や文字列をつけた新しいファイルを作ってくれる)、はては別ディレクトリから同名のファイルを移動してくると、勝手に既存ファイルを上書きしてしまうなどの問題が発生します。これではうっかり操作ミスなどをしてしまった場合は一巻の終わりです。

下の項目も非常に不便な仕様で、ローカルのファイルをアップロードする場合面倒くさいだけではなく、フォルダを丸ごとアップする場合に、一度圧縮などで1ファイルに纏めた上でアップローダを使って上げなければならないという制約がつきます(まあ、アップローダと圧縮・解凍ツールは標準でついていますが)。

次に、付属のエディタであるHTML editor/Code editorですが、以下の点が不十分に感じられます。

  • 拡張子が.htmlでないとHTML editorが立ち上がってくれない
  • 指定文字コードでうまく開いてくれない場合がある。開き直さなければならない

前者は拡張子.tplのテンプレートファイルや、phpコードを含んだhtmlファイル(拡張子.php)をエディットする時に不便です。拡張子に関わらず両方のエディタを選択できるようにしなかったのは、どうにも不可解な仕様に思えます。

以上、総括するならば、オフラインのアプリケーションと比べてかなり大味な作りになっているということが言えると思います。オフラインのアプリケーションであれば、環境設定パネルなどでアプリケーションの挙動をかなり変えられるのが普通ですが、このファイルマネージャのsettingメニューには、文字コードについての確認ダイアログを出すか出さないかの一項目しか存在しませんでした。つまり、オフラインアプリケーションの代わりにファイルマネージャを使うためには、相応の忍耐強さと、アプリケーションの挙動についてある程度予測できる洞察力が必要なのかもしれません。

今回は悪い点ばかりを列挙しました。前回便利な点ばかり挙げたエントリと合わせて、サイト作成環境選びの判断材料に使ってもらえれば幸いです。


サブドメイン設定とシンボリックリンクの作成

前の投稿の続きになります。

サイトAにサブドメインを追加することが決まったので、優等生アプリケーションcPanelを使って設定します。cPanelのDomainsのボックスにSubdomainsがあるのでクリック、サブドメイン設定のページに遷移するので、テキストフィールドにサブドメイン名とサブドメインのドキュメントルートを入力して終わりです。ドキュメントルートとは、サブドメインhttp://××.○○○.com/にアクセスされた時に開くディレクトリのことで、今回サイトAのサブドメインhttp://en.○○○.com/のルートにはhttp://www.○○○.com/enというディレクトリを作り指定しました。

さて、前回のエントリで書きました通り、サブドメイン設定後にある問題にぶちあたりました。サイトAではサイトに共通のスタイルシートをhttp://www.○○○.com/cssにまとめて置いていたのですが、http://en.○○○.com/以下のファイルから相対パス指定でアクセスしようとすると、not foundになってしまうのです。サブドメインのドキュメントルートをhttp://www.○○○.com/enにしているわけですから、cssディレクトリ中の例えばsample.cssというファイルにアクセスするには、相対パスで”../css/sample.css”と指定すれば良いと思っていました。しかしエラー表示を見ると、要求したアドレスの頭がhttp://en.○○○.com/になっています。つまり、サブドメインを作成してしまうとそのアドレスのドキュメントルートにどのデイレクトリを指定しているかに関わりなく、アドレス要求の頭がサブドメインになってしまいそれ以上遡れないようになるのです。

調べてみると、この問題を解決するための考え方には以下の3通りがあるようです。

  • ディレクトリ構成を再考する
  • ファイル指定は常に絶対パスで行う
  • サーバのOSであるUNIXのファイルシステム上で設定をいじる

まず一番上のディレクトリ構成の再考ですが、簡単に言うと大前提である一箇所に纏められたcssファイルの使用をあきらめるということになります。サブドメインに個別のcssデイレクトリをつくって、一部の共通スタイルシートは重複して存在させるようにします。この方法であればサブドメインから遡れない箇所にあるファイルにアクセスしなくて済みます。ただ、当然ながら片方のcssファイルに加えた変更はもう片方に反映されないため、サイト全体に関わるスタイルの変更を行う時には、共通ファイルに複数の版が存在してしまわないよう気をつけなければなりません。

次に、絶対パスの使用です。簡単に言うと相対パスを使わず、ファイルを呼び出す時は必ずhttp://から始まるアドレスを入力するという方法です。PHPなどのスクリプト言語が使用できる環境なら、http://www.○○○.com/の部分を定数として定義、cssファイルなどが呼び出されるときに文字列連結するようにすれば、将来的にドメインを移行することになっても修正箇所が少なくて済みます。

最後のひとつ、UNIXファイルシステムの機能を使う方法は、windowsのショートカット、MacOSのエイリアスにあたるシンボリックリンクを使う方法です。今回の解決法にはこれを採用しました。

とは言えUNIXコマンドの知識は皆無だったので、webで調べながらコマンドを打つ方法では操作を間違えてしまった時に何が起こるのか予想もつかないということで、もう少し簡単で安全な方法を探しました(本当はcPanelに標準でついていてほしい機能だったのですが)。すると、どうやらPHP4以降のバージョンにはシンボリックリンク作成のためのsymlinkという関数が搭載されているようです。

symlink関数は、symlink(引数1,引数2)という書式をもち、引数1にはリンク先(上の例でいうならhttp://www.○○○.com/以下のcssデイレクトリ)、引数2には新しく用意するパスを与えます。ただこの際に行うのはあくまでサーバのUNIXファイルシステムに対する操作なので、http://から始まるパスではなく、サーバから提供されたドキュメントルートのパスを与えてやらなければなりません。このサイトAの場合には、/home/ユーザ名/public_html/がドキュメントルート(http://www.○○○.com/でアクセスできる場所)として与えられていたので、symlink(/home/ユーザ名/public_html/css,/home/ユーザ名/public_html/en/css);という命令を実行してシンボリックリンクを作成しました。

さて、こうしたシンボリックリンクを作成の度に手打ちでphpファイルを修正、ブラウザからアクセスという手順を踏むのは面倒です。そこでフォームから与えられたパスでリンクを作ってくれるphpファイルを作成しました(右クリックメニューからからダウンロードを選択してください。あと圧縮ファイルなので実行時には解凍してください)。

Symlinkcreator.rar(2012.6追記:配布終了しました。代わりにソースコードを書き連ねておきます。)

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>tool_symlink</title>
</head>
<body>
<p><strong>Create a symboliclink of selected file/directory.</strong></p>
<p>Paths like /home/username/public_html/... are required.</p>
<form action="tool_symlink.php" method="post">
<p>Original to a link : <input type="text" name="linkoriginal" /></p>
<p>Jump from this new path : <input type="text" name="jumpfrom" /></p>
<p><input type="submit" value="create" /></p></form>
<?php
if(!empty($_POST["linkoriginal"]) && !empty($_POST["jumpfrom"])){
if(file_exists($_POST["linkoriginal"])){
if(file_exists($_POST["jumpfrom"])){
echo "ERROR : The name you entered for symboliclink is already used.<br /> ";
}
else{ 
symlink($_POST["linkoriginal"],$_POST["jumpfrom"]);
echo "Symbolic link <strong>".$_POST["jumpfrom"]."</strong> to <strong>".$_POST["linkoriginal"]."</strong> is now available.";
}
}
else{
echo "ERROR : The file/directory you have requested as original is not found.";
}
}
?>
</body>
</html>

ちなみにセキュリティ対策は何も行っていないプログラムなので、外部からアクセスできないデイレクトリに置いて使う必要があります。あとこのプログラムによって引き起こされた損害に対して作者は責任を負いません。実際簡単なプログラムなので、無許可で改変して実用化してもらえればと思います。

解決法に辿り着くまで、それから実際にプログラムを完成させるまでかかった時間を、同じ問題にぶつかった人がこれで短縮できればと思っています。


サイトAにサブドメインを設定するべきか

サイトを巡回していると、http://www.○○○.com/××といったwwwから始まるページアドレスの他に、http://××.○○○.comのような任意の単語がドメインネームの前に置かれたアドレスのページをよく見かけます。例えばgoogleであれば、検索のトップページhttp://www.google.com/に対して、google docsのページはhttp://docs.google.com/、google mapsのページはhttp://maps.google.com/のように提供する機能の単語をドメインネームgoogle.comの前につけています。

これがサブドメインと言われるもので、ディレクトリへのパスをそのままページアドレスにする方法に対して有利な点がいくつかあります。具体的には、

  • 深い階層にあるデイレクトリに、短いアドレスでアクセスできる
  • 検索エンジンの検索結果として、1サブドメインにつき1件として扱ってくれる場合がある

一方で、検索エンジンの被リンク数をドメインの評価として加算していくアルゴリズムを考えると、サブドメイン毎に加算ポイントがばらけてしまう状態はSEO的なディスアドバンテージになります。このようにサブドメインでの運営は長所も短所もあるので、実際に導入する場合にはサイトの将来的なプランに沿う選択であるか考えてみる必要があります。

さて、サイトAの計画には、日本語ページの他に英語版のページをつくる予定がありました。この英語版ページにはサブドメインhttp://en.○○○.com/のようなアドレスを設定しましたが、それは以下のような理由によるものです。

  • 日本語版と英語版で提供する機能は違うものを想定している
  • 英語版のアドレスからサイトにやってきた人が、日本語のコンテンツに遭遇してしまうことを避けたい

つまりページの想定している客層が異なるので、不必要な導線は除いておく必要があったのです。例えば英語版を閲覧していた人が存在しないページのリクエストを送ってしまった場合、404エラーのページから自動的に戻る、あるいはアドレスを削って辿り着く先が日本語版ページのトップだと不安になってしまうのではないかと思うのです。

そういうわけで、サブドメインを設定するかどうかの問題は解決しましたが、設定時には予期せぬ落とし穴にハマってしまいました。サブドメイン設定時には気をつけなければならない問題なのですが、それは次のエントリにでも書こうと思います。


cPanelの多機能なファイルマネージャ

サーバ管理ソフトウェアcPanelには、標準で多機能なファイルマネージャが付属しています。

このスクリーンショットで大体何ができるかの説明は済んでしまっているような気がしますが、あえて機能を箇条書きにしてみます。

  • ファイルのアップロード・ダウンロード
  • 新規ディレクトリ、ファイルの作成
  • コピーや移動、名前の変更などのファイル操作
  • ファイルの圧縮・解凍
  • アクセス権の変更
  • コード/HTMLエディタ

このような機能があります。つまり基本的にFTPクライアントでできることがオンラインでできるようになるため、サイト作成のために別途FTPクライアントを用意する必要がありません。

また、最後に挙げたコード/HTMLエディタは出来の良いシェアウェア程度の機能を備えているため、サイト作成の中心的なツールとなり得るポテンシャルがあります。以下にスクリーンショットを何点か用意しました。

左の2点(それぞれcss、phpを編集しています)のスクリーンショットで立ち上がっているのは、code editorというアプリケーションです。一方右の2点は拡張子が.htmlのファイルのときに選択できるHTML editorです。
コードビュー、デザインビューといったHTMLエディタではおなじみの機能も備えています。

さて、こうしたFTP機能と強力なエディタをcPanelは標準搭載しているわけですが、そうなればcPanelを採用したサーバでサイト作成をする場合、従来の作成手順、”ローカルで作成したファイルをサーバにアップロードする”を踏襲することなく、完全にオンラインの作業でまかなえてしまえることになります。この方法ではローカル環境とリモート環境で気付かぬうちに複数の版ができてしまうという問題を解決できるばかりでなく、GoogleDocsのような、自宅、職場、ネットカフェなどの環境を問わず作業ができるという恩恵も受けられます。

ということで、サイトAの作成にはこのcPanelの環境を用いてみることにしました。使い込んでいくうちに足りない部分や不具合などが明らかになってくると思うので、それはその都度このブログで報告していきたいと思っています。

(2012.6追記:サイトの一時閉鎖の影響で、スクリーンショット画像が無しの状態になっています。想像を掻き立ててください)