Google

« 2008年03月 | メイン | 2008年05月 »

2008年04月30日

AdSens:ついに$100

Google AdSenseがついに$100に達した。開始からの記録を簡単に記してみると下記のとおりである。

  1. 2007年01月27日:AdSenseに承認された
  2. 2008年01月03日:$50に達した時にPINコード通知が届いた
  3. 2008年04月22日:-US$105.48支払い済み

少しXHTML+ＣSSの知識もついて、ブログの体裁を変更してみたりした事がAdSenseのカウントアップに多少影響しているものと思われる。 思い返してみれば最初はトップページに1つAdSenseを設置するので精一杯だった。徐々に知識がついて個別ページにも設置してみたり、カテゴリーページにも設置してみたりと段階的にブログをいじってきたからだろう。

私はアフィリエイターではないので、必要以上にはAdSenseに執着するつもりはないのだが、やっぱりカウントアップされると、それだけ見て貰えているんだなと感じて嬉しいものだ。バリバリにサイトをカスタマイズするつもりも無いから、これ以上のペースアップはないと思うが、強いて言えば内容を濃くして行く事で人の役に立てる情報を発信できたらと思っている。

初めての小切手が届くの楽しみ～（ｗ

投稿者 sasapurin : 10:32 |Webブラウザ | コメント (0) | トラックバック

2008年04月29日

Firefox:Firebug

普通のインターネットユーザー（変な言葉だな）はこんなものに興味はないと思うが、多少なりともWeb制作なり、Webページのカスタマイズ、Blogのカスタマイズに手を出した人にとっては、確実に役立つであろうFirefoxのプラグインがある。

Firebug-Web Development Evolved for Jpanese

嬉しい事に日本語版があるので、英語の苦手な日本人でも気軽にこのプラグインの恩恵にあずかれる。具体的に何が出来るかという概要は上記リンク先を読めば分かる事だが、私が試してみて便利だと思った点をこのエントリーの続きに記そうと思う。 

 

機能のON/OFF 

このプラグインをFirefoxに導入すると、メニューの「ツール」に「Firebug」という項目が追加される。機能のON/OFFはここから出来る（もしくはF12キー押下）と覚えておけば、後はやってみると話が早いので是非やってみていただきたい。

HTMLブロックの解析

まずは超基本的な機能。自分のHPなどがあれば構造を理解していると思うので実験には最適である。とにかくお気に入りのサイトを表示してみて欲しい。FirebugをON（F12キー）するとブラウザの下の方に情報を表示するエリアが現れる。もしくは新しいウィンドウで表示（Ctrl + F12）しても良いだろう。使い勝手からすると新しいウィンドウに表示した方が便利だと思われる。やっぱりデュアルディスプレイが理想だな。

左側の部分はタブで切り替えられるが、HTMLの構造を調べるのでHTMLにしておく。具体的にはXHTMLのブロック構造を閉じたり開いたりする事で非常に見やすく階層的に「ソース」を読むことが出来る。もちろん一番最初に出てくる<HTML></HTML>というブロックが大親分になるので、そのブロックの中にある<HEAD></HEAD>と<BODY></BODY>タグが次の子分のブロックになるだろう。それらの左にある[+]をクリックすればブロックを開いて更に中の子供のブロックタグを掘り起こして参照して行くことが出来る。これでXHTMLの構造を解析することが容易に行えるはずだ。

この基本的な機能は<DIV　ID="hogehoge"></DIV>などと言うパターンの閉じ忘れ、もしくは変なところで間違えて閉じてしまったという間違いを探す際などの省力化に役立つと思われる。なぜこんな事を書くかと言うと、私は一ヶ月だけだがWeb制作の会社に勤めて仕事に携わったことがあるのだ。もちろんたったの一ヶ月だからXHTML+CSSの深い理解を身に着けるという当初の目的は達成できなかったのだが、現場の実情を肌で感じることが出来たのだ。その際、CSSで体裁を整えているページが微妙に崩れていたりするのを発見し、その原因を調べると大抵は</div>が変なところにゴミとして残っていた為だったり、逆に</div>が足りなかったりするというケースに遭遇した。その時にこのFirebugを知っていれば直ぐに原因を突き止められたのだろうが、その時は残念ながらFirebugを知らなかった為に、ソースを整形するツール（インデントを付ける）で、インデント位置が合わないところを探して修正したりしたものだ。

もちろんその様な「地味」な作業は私だけではなかった。人によってはタグの閉じ忘れが無いかどうかを調べる為にソースをプリントアウトして対を調べながらボールペンで地道にチェックしていた。なぜならタグの閉じ忘れが無いか？正しい場所で対になっているか？はXHTMLの基本中の基本だからだ。しかし手作業を否定するつもりは無いが理屈を理解している人はもっと楽していわゆるバグを見つける能率を上げた方が良いだろう。そんなニーズにも応じてくれるのがこのFirebugである。DreamWeaverにも近い機能は備わっているが、HTMLタグの対を調べるまでは至らない様である（使い方が悪いのかな？）。とにかく無償で利用できるFirebugのシンプル操作でそれが容易に行える点は評価に値する。

（IEでも同等の機能を有するものがあるらしいがそれは別途）

HTML構造の視覚的把握

この機能を使おうとすると、広い画面がどうしても欲しくなる。デュアルディスプレイ環境必須と思えてくる。画面の狭い画面の人はF11キーを押して最大化してから作業をするなどしてなるだけ広い画面で作業すると良いだろう（ALT+TABでウィンドウを切り替えるなど各自工夫すべし）。HTMLブロックの任意の部分にマウスポインタを重ねると、ブラウザで表示している解析対象の表示のどの部分なのかが、ハイライト表示されることに気づくだろうか？例えば<DIV ID="banner">タグなら大抵はバナー部分、<DIV ID="footer">ならフッター部分、<DIV ID="copyright">ならコピーライト部分がハイライトすると思う。こうやって視覚的な確認が行えるのも初心者には嬉しい機能だったりする。もちろんXHTMLソースを読んで直ぐに理解できちゃう人には遊び的な要素だったりするのだろうが。

しかしそんな事は言わせないのもFirebugだったりする。実は逆のことも出来ちゃうから凄いのだ。「調査」ボタンをクリックしておいてから、調査対象のブラウザ画面にマウスポインタを重ねてみる。すると要素を枠で囲んでくれて、それに対応するHTMLブロックがハイライトされる。画面を構成している要素がどこに記述されているのか簡単に探すことが出来るのだ。これは非常に便利だと思うので、ベテランさんでも使い出すと止められない機能だと思う。確実にソースの可読性が上がるだろう。

CSS情報の参照

Firebugが提供してくれる機能はもちろんそれだけではない。Firebug情報エリアの右側には、CSSの情報が表示されていると思う。任意のタグブロックを選択して反転表示させると、CSSエリアにそのブロックに定義されているCSS情報が一目瞭然で確認できる。CSSは優先順位があり自分で決めた記述ルールにしたがっていればある程度見通しが利くものだが、人が定義したものだと把握に苦労するものである。（実際、私が働いていたWeb制作現場のボスでさえ、人の書いたCSSは読みづらいと嘆いていた）そんな苦労もFirebugがあればかなり省力化できるのではないだろうか？優先順位で無効にされたCSS記述には消し線が入って無効になっていることがしっかり読み取れる。なんて親切な設計だろう。

おまけにCSSの値を変更することが出来てしまう。もちろんブラウザ上だけの話なので、元になるCSSを最終的には編集しなくてはならないが、気軽に色々試してみても元のCSSには被害が無いという点だけでも安心ではないだろうか？更にCSSの値を変更する際はただ編集出来るだけではなく、オートコンプリートで候補がリストアップされるのもありがたいことである。一気に作業効率が上がると思うし、CSSの理解を深める学習ツールとしても有効だと思う。気になるサイトを見つけたらF12を押してFirebugを起動し、心行くまでCSSをカスタマイズしてみて理解を深めると良いだろう。きっとその内CSSを深く理解できると思う。

レイアウト

CSSにまだ慣れていない私は、ボーダーとかパディングとかややこしいなと思ったりする事が多いのだが、この機能を使うと視覚的にピクセル情報などが確認できるので、非常に嬉しく思ったりする。なぜなら実際に数値を動かしてみてその結果をブラウザで表示している分析対象のページに反映できるからだ。例えば左マージンの数値を増やしてみたらどんどん右によってきたりして、なるほどこういうことなのかとあっさり理解できてしまったりして、初心者の理解を助けるツールとしても使えると思うのだ。もちろん上級者は緻密なレイアウトを設計する為に使えば良い訳で、それがPHP+SQLの情報から動的に作られたページだったとしてもブラウザでXHTML+CSSとして表示されている訳だから、容易にCSSを調整して数値を決めることが出来るのだ。このような方法はDreamWeaverでも出来ないんじゃないかな？（テストサーバとか設定すれば出来そうな気はするがそこまで使いこなせていないし何しろ個人で新しいバージョンを買うには高すぎるでしょ！）とにかくCSSレイアウトの微調整には欠かせないツールとなりそうだ。

スクリプト

私はこのジャンルは非常に苦手なので使うことはないと思うのだが、Javaスクリプトのソースも簡単に読める様だ。分かる人が読めば直ぐに判るものらしいから、容易にJavaスクリプトを表示させられるのは便利ではないだろうか？私はJavaスクリプトを読んでもさっぱり理解できないのでこの機能だけは全く使ってないと言っても良いだろう。分かる人は使って楽して下さい。

ネットワークの監視

こんな機能まで実装されてるの？と驚くしかない機能だと思う。Webサイトのコンテンツは色々なファイルから構成されていて、Webブラウザがその言い代えればパーツをどの様な順番でどれくらいの時間で集めている（読み込んでいる）かを時系列グラフで表示してくれる。更にキャッシュの状態だとかHTTPヘッダ情報まで見られちゃう訳で、もし自分以外の人が使うと自分のサイトがちょっとヤバイ位丸裸にされてしまうのではないかと不安に思うくらいである。

と言う訳で、技術系の人ならこの類のツールは手放せないことになるだろうと思う。Webの構造の事をもっと知りたいという人や、Webデザイナー達も必須だと言えるだろう。私は最近CMSを使う事にはまっているので、苦手なPHPを解析する為の足がかりとしてXHTMLソースをしっかり読み取るのが課題だと感じ、構造解析の為にはFirebugが手放せないツールとなっていたりするのだ。

投稿者 sasapurin : 23:57 |Webブラウザ | コメント (0) | トラックバック

2008年04月28日

WordPress:Google地図を表示する

お店関係のサイトを作る上では地図情報は必須とも言える項目。出来ればGoogle MapsをWordPressでも扱えるとうれしいな。そんな訳で検索してみたら早速それらしいプラグインが見つかった。

lightweight-google-maps

試してみたらそれほど難しくは無かったのでこれを使わせていただくことにした。検索したら使い方情報はいっぱい見つかるし、添付ドキュメントもしっかりしているから、今さら私が解説するまでもないだろう。

詳しくは添付Readmeを読むとして、要点だけ備忘録しておく

まずは下準備で地図表示用の固定ページを準備してからプラグインの導入と設定をする。

  1. 新規に固定ページを作成しタグを埋め込む
    <div id="gmap_menu"></div>
    <div id="google_maps"></div>
  2. プラグインを導入する
  3. GoogleのAPIキーを設定する（URLをチェックされているのでGoolgeに登録する必要あり）
  4. プラグインの設定で、固定ページのID番号（数字）を指定する

引き続き実際の地図情報を投稿ページで一つずつエントリーして行く。

  1. 新規に投稿ページを作成する
  2. カスタムフィールド：[Lat_Long]というフィールド名でマーカー座標を指定する
  3. 任意の説明文などを付けて投稿する
  4. 投稿したエントリーに小さな地図が表示される
  5. 位置情報マーカーをクリックすると上記で作成した固定ページの大きな地図にジャンプする。

プラグインの設定（設定>Google Maps）から下記の設定が行える。 

あとはガシガシ投稿し、[Lat_Long]というカスタムフィールド名に座標を指定しておけば、投稿に地図が自動で入るので非常に便利である。なおカスタムフィールドは一つ作ってしまえば、二つ目からはプルダウンメニューで選べるのでフィールド名を忘れても大丈夫。問題は座標の調べ方かも知れない。色々あるらしいがGoogle Mapsから調べるのが確実なのだろうか。

投稿者 sasapurin : 19:08 |WordPress | コメント (0) | トラックバック

WordPress:ユーザー権限

ここ数日の検証で、WordPressによる個人商店向けサイト構築が出来そうだと判ったので、恐らくWordPressで行くことになりそうだ。そうなったら運用のことも考えなくてはならない。せっかく細部を作っても、使い慣れていない運用者がうっかり構造を壊してしまったら元もこもないからだ。

幸いWordPressには複数のユーザー登録が出来、更に権限を設定することが出来る。ちょっと分かりにくいのでユーザー管理ページにそれぞれの権限の説明を書いておいて欲しいと思うのだが、（現状マニュアルは英文だし）難しいのだろうか？

それはさておき、それなりに調べてみたので備忘録しておく。

とか調べてみたが、何気に検索をしてみたら凄く分かりやすく整理して下さっているサイト発見。
参考サイト：ユーザーの追加 - ユーザー管理 - WordPressの使い方

さて実際にユーザーを作って権限を設定してみた。それぞれのユーザーでログインすると、WPのメニューが少なくなっている。つまり出来ることが制限されているという事が確認できる。ブログとして使わないのであれば、管理者と編集者だけで事足りそうだな。

投稿者 sasapurin : 15:04 |WordPress | コメント (0) | トラックバック

WordPress:インストール直後の設定

WordPressのインストールはSQLの接続さえ出来てしまえば超簡単なのでここでは割愛しておく。

問題はインストールが終わり、adminでログインしてからの設定だ。デフォルトのままでは色々と使いづらい点があるので、試行錯誤してみた結果使いやすいと感じた設定を備忘録しておく。もちろんこれが最適というわけではないので、これはあくまでも自分の為の備忘録である。

パーマリンク構造のカスタマイズ

デフォルトのパーマリンク設定だと、？が入ったりして何かとイメージが悪いURLになってしまう。真っ先にこいつをカスタマイズしておきたい。 「設定」＞「パーマリンク設定」から行える。

カスタム構造：/%category%/%post_id%.html

その他の設定：アップロード

デフォルトだと、アップロードファイルは、wp-content/uploadsに保存される。そしてそのディレクトリ内に年月ベースのフォルダが生成されて、画像ファイル等が区分けされる仕組みとなっている。もちろんこの機能は整理の為に助かる便利な機能なのだが、「商品カタログ」などを後から追加した場合に全く違うディレクトリに保存されてしまうので、下記項目のチェックを外して整理されないようにする。もちろん同名ファイルは保存できなくなることは覚悟の上だ。

アップロードしたファイルを年月ベースのフォルダに整理　のチェックを外す

カテゴリーの管理

ブログ系CMSをHP作成ツールとして使用するにおいて、カテゴリーはメニューの項目に該当する部分なので、真っ先にカテゴリーを設定しておく。例えば「お知らせ」とか「会社概要」とか「製品紹介」だとか。そこで重要なのは、必ずカテゴリースラッグを小文字アルファベット、数字、ハイフンだけで設定しておくことである。カテゴリースラッグを設定しておくと、この文字がURLに適用されるので、パーマリンク構造のカスタマイズで設定した

%category%

に置き換わる仕組みになっているからだ。例えば上記の例だと「お知らせ」カテゴリーに「info」と設定したとする。101のIDを持つ投稿をした場合、下記の様になってくれて、一般のサイトのようなURLになる。

例：http://www.example.com/info/101.html

同様にリンクカテゴリーにもカテゴリースラッグが設定できるので、面倒と思わずにアルファベットで設定しておくことをお薦めしたい。この項目を設定していないとカテゴリー名を日本語で記しておいた場合、意味不明の長ったらしいURLになりかねない。（Firefox等では日本語URLになるがIEでは訳の分からない文字列になってしまう）。

まだWPを理解仕切れていないが、とりあえずデフォルト設定からいじっておきたい項目は以上のようなところだと思う。

投稿者 sasapurin : 14:30 |WordPress | コメント (0) | トラックバック

小規模サイト向けCMS:「WordPress」

WordPressと言えばブログと言う印象が強いのだが、実際に小規模サイト用のCMSとしてカスタマイズできないものか試行錯誤していると、WordPressも十分小規模サイト用のCMSとして、ベースになることが最近ようやく理解できた。複雑なサイトや複数ユーザーでの運用を考えればWordPressでは事足りないケースも想像できるが、たとえばSOHOやフリーランス、個人商店などの事業紹介用として使う程度なら十分利用できるだろう。

WordPressを試用してみて気づいた点を記してみようと思う。

まず、WordPressを使うために必要な環境である。
  1. PHPが使えること
  2. MySQLが使えること
  3. Webサーバ（Apache等）が使えること 

正確にはWordPress日本語サイトで確認して欲しいのだが、比較的要件は低いと感じられる。いわゆる自宅サーバの様に好き勝手できる環境ならLAMPやWAMPで余裕だし、レンタルサーバでもMySQLが使用出来るなら恐らく大丈夫ではなかろうかと思う。私はチカッパレンタルサーバで試してみた（15日試用）が非常に快適だった。既にCMSの普及度があがっておりレンタルサーバでSQLが使える事は当たり前になってきているので敷居は低いと思われる。

次に動作について調べてみる。 

ネットで下調べすると、Movable Typeに比べると動作が重い（遅い）という情報を読むことが多々ある。しかし私が自宅のサーバ及びチカッパで試してみた限りでは圧倒的にWordPressの方がレスポンスが良く全く逆の結果に驚いてしまった。MTの場合は静的なページを生成する「再構築」の待ち時間も無視できない。投稿数が多くなると案外これがストレスとなることが多いからだ。WPはアクセスのその都度動的にページを生成するため「再構築」という概念は無く、ページ生成の手間や待ち時間は発生しない。その代わりページへのアクセスが多ければ多い程、SQLサーバへの負担がかかるという予想は出来る。人気サイトを作ってしまった場合は、レンタルサーバでは転送量制限にひっかかる可能性は否めない。

いずれにしろ、これらのことからSQLのレスポンスが大きく影響していると思う。悔しいかな我が家の自宅サーバよりもチカッパの方が速くて快適だった。我が家のサーバは何しろ古い（K6-450MHz）から当然と言えば当然なのかも知れない。ちなみにMySQLは別のマシン（K6-350）で動かしている二台構成だ。OSはLinuxとFreeBSDの最小構成から作ったもの。極力軽く仕込んである。

さて、WordPressで出来ることと特徴的な事を書いてみようと思う。

  1. テーマ（デザイン）が簡単に切り替えられる
  2. テーマ（デザイン）が豊富にネット上で配布されている（但し日本語は少ない）
  3. テーマ（デザイン）をカスタマイズできる（ほんの少しだけPHPを理解する努力が必要）
  4. プラグインで拡張できる
  5. 投稿とは別に独自ページを作成できる
  6. トップページを固定することが出来る
  7. カスタムフィールドを使用出来る

もちろんこれ以外にも特徴はあるのだが、オープンソースの無償ソフトウェアでここまでのことが実現されているのは非常にありがたいことである。MTもMTOSというオープンソース無償版を提供しているが、私にとっては圧倒的に軽いWPの方に魅力を感じる。MTは大手サイトにも対応させるべく既に大きく重くなりすぎたのではないだろうか。カスタマイズするにもかなり複雑な構造になっているため、構成を把握するのが困難である。もちろんMTは商用のCMSだから当然なのかも知れないが、それを考えた時にはWPのようなシンプルな構造を理解する方が近道で、ほんの少しだけPHPの雰囲気を感じ取ることが出来たらMTOSよりも手軽に自分の目指すサイトを作れるのではないかと思う。小規模、個人利用に向いているのはWPの方だと思える。

もちろんMTで色々なサイトを作ってきた人にとっては、慣れたMTOSは当たり前の選択肢だとは思う。そして日本の多くの企業の場合は、完全なオープンソースよりも有償版を好む傾向が強い。企業ユースではユーザーサポートなり保障を重視することが多い。Microsoft社の製品が普及したのが一例だろう。しかしそこまでのスキルの無い人にとっては、MTは大きすぎる仕組み故理解が容易ではなく、WPをチョイスする方が近道を通ることが出来ると私は思う。

さて、問題と言うか課題もある。テーマが世界中で作られて配布されているWPだが、多くは英語もしくはそれ以外の国の言語である。英語でも苦労するのに例えばドイツ語だったりすると、ローカライズには苦戦を強いられる。その現実を知ると多くのWP初心者は、ほぼ間違いなくWPを敬遠することになるだろう。事実私がそうであった。しかし少し調べてみると別の事実も見えてくる。WPは世界中で最も多く使用されているブログ系CMSである。つまり多くの国の人たちが自分の好みに合うようにカスタマイズして使っているのである。ドイツ語のテーマを気に入った人がフランス語にローカライズしている事も想像できる。 ということは日本語も同じ事と考えてよいのではないだろうか？

ここでは、そのためのはキーワードしか記さないが、WPではgettextを使った文字列置き換えの仕組みを採用する事で多言語に対応する様に元から配慮されている。PoEditというツールを使えば比較的容易に翻訳（文字列置き換え）作業が出来る様な仕組みになっている。ただ残念ながらgettextを使う事を考慮したテーマはまだ少なく、hogehoge.potファイルを同梱していないテーマが多い点はこれからの課題ではないかと思う。恐らくテーマ作成のためのガイドラインが十分周知されていないのだろう。しかしそういう仕組みがあるから、積極的に活用すれば日本語ローカライズを自分で比較的少ない労力で行うことも出来るし、自分流の翻訳や好きなメッセージに変えてしまうことも出来るという訳である。弱みを強みに変えることも発想次第で十分可能と言える。カスタマイズする余地が残されていると言っても良いからこれは必ずしも弱点とはいえなくなってくる。

まだ使ったことの無い方の為にWP本体で案内されているThemeサイトをご紹介しておこう。膨大な数のテーマがあるので、お気に入りが見つかるか探してみると良いだろう。

 WordPress テーマディレクトリ

 

WPは比較的軽いPHPアプリケーションである。この軽快さを実現しているのは、WP本体を構成しているPHPファイル群と、表示系PHPファイル群（テーマファイル）を分離している点だろう。同様にプラグインも分けられている。つまり多くの場合は表示系をカスタマイズすれば十分要件を満たすことが出来るであろうから、好みに合うテーマファイルを探してきて、Themeフォルダにアップロードして読み込ませ、テーマを切り替えれば骨組みは出来上がってしまう。構成ファイルにApacheからの書込み権限を与えておけば、WP上から「デザイン＞テーマエディタ」とすれば、スタイルシートや各PHPファイルを編集することが可能であり、後はCSSをいじったり、PHPファイルをいじったりすれば比較的少ない労力でお望みの入れ物を作り上げられるだろう。

もちろん、WPでは出来ないこともあるだろうが．．

 

さて、WordPressというブログ専用とも思われるCMSを敢えて「小規模サイト向けCMS」と題してみた訳だが、私は一週間弱使ってみた感触から、ちょっとした企業のホームページや、個人商店の案内と商品紹介などは十分出来るという確信を持った。もちろんメールフォームを設置したいとか、Google Mapsを表示したいとか言うニーズも出てくるだろう。それらはプラグインで実現出来るので比較的少ない労力で実現出来るからあまり問題ではないと気楽に考えてよいと思う。

まずはWordPressというCMSをいじってみることをお勧めする。ネットに膨大にあるテーマを探してきてどんどん入れ替えてみて欲しい。そうすると不満点などが見えてくる。それを解決する方法を探してみれば、ネット上で色々な情報が検索できる。恐らくMT3系から移行して大きくなりすぎたMT4系（MTOS4系）に比べれば見通しも良くPHPの初歩知識だけで対応可能だと思う。何よりもテーマを手軽に入手できるという点はMTとは全く違う手軽さを提供してくれる。テーマには色々なテクニックが使われており、それがそのままサンプルになるから、ちょっと努力するだけでテクニックを学べる（盗める）というのは何よりも魅力ではないだろうか？お金が発生するMTでは企業ノウハウは企業秘密であり、これはまず有り得ない。

私はJoomla!にも興味を持っているが、近道を通るために今はWordPressのより深い理解に努めている。個人＆小規模のニーズには十分こたえてくれるシンプルなCMSだと言って間違いないと思う。後は使う人のアイディア（発想）次第で色々なことが出来るだろう。日本でもMTやWP使いの有名な方が色々なテクニックを惜しみなく公開して下さっているから、安心して試して見ると良いと思う。WPユーザーが日本でも増えてくれば、MTとの勢力図が変わってくるかも知れないし、今はそれをちょっと期待したい心境である。

投稿者 sasapurin : 12:20 |CMS , オープンソース系 | コメント (0) | トラックバック

2008年04月22日

Joomla!：1.0系-管理画面にログインできない

Joomla!1.0.15での話だ。

知人のためにVine Linux 4.2でJoomla!を使ってサイト構築すべく、PCを預かって作業を始めた。Joomla!はFreeBSDサーバでも使っているから、なんとなくだがセッティングの仕方は分かったつもりでいた。しかしやはり罠があった。インストールが終わった直後だというのにadminでログイン出来ないのだ。

状況としてはVine Linuxをインストール後、殆どaptでインストールできる必要と思われるものを入れた。いわゆるLAMP関係の細かいパッケージまで記すとかなりくどくなるので割愛する。

Apache2,MySQL,vsftpd,PHP5,myphpAdmin

Vine Linux 4.2の場合、/etc/php/php.ini が設定ファイルだが、基本的にここはいじらないようにしてみた。Joomlaには、htaccess.txtが添付されているから、.htaccessとしてコピーし必要なところだけコメントアウトを外せば有効になるからだ。しかしこの作業のお陰で.htaccessでphpの設定がいじれるのを発見したというか学べた。Apacheのすばらしいところをまた一つ発見だ。

それはさておき、この環境でjoomla_1_0_15JP_Stableをインストールしてみたのだが、無事にセッティングが終わって、adminのパスワードが決定し、管理ページにログインしようとすると弾かれてまたログイン画面に戻されてしまう状況に遭遇してどうしようも無くなった。間違ったパスワードを入れると違うメッセージが表示されるので、認証は通っている感じだ。

検索したらそれらしい質問がJoomla!フォーラムで投稿されているが、アカウントを登録したのにメールが送られてこない上、やはりフォーラムでのやり取りが気に入らない（妙に偉そうなのが鼻につく）のでそんなフォーラムには行かないで自力で解決することに決めた。フィードバックしようかなとも思ったのだが、なんだかなぁという感じだ。どうせまだJoomla!を使い続けるかどうか分からないし、知ったかぶりの「エラソ」は大嫌いだから単独行動しよう。オプソだからそれも許されるでしょ？それが変だと言うのなら通いやすいフォーラム運営を考えて欲しいものだ。

結果的には「PHPの設定が関係していた」ことが分かったのだが、それは続きに記そう。

幸いというか、家のFreeBSDサーバでは快調にJoomla!が稼動している。この動いている環境を比較に使わない手は無いだろう。

余談ながら私はPHPやらPerlやらRubyやらSQLやらには興味が無く、プログラミングは素人同然である。しかしサーバー屋としてはある程度の知識を持っていなければならないので、苦戦しながらも勉強はしている。コーディングに興味が無いというほうが正しいのかな。いずれにしてもこういう言語特有の知識は殆ど無く素人同然である。

しかし、ネットで調べた方法を使えば、動いている環境と、問題のある環境の違いを調べる方法位は思いつくもんだ。少しPHPをいじったことのある人なら気づくだろう。いわゆるphpinfo.phpを使ってみるのだ。別にファイル名は同じでなくても良いが、Joomla!を公開しようとしているディレクトリにPHP設定の診断用スクリプトを保存しておいて、それにアクセスすればPHPの設定が見えるということは有名な話だし基本だと思う。具体的には下記の様になっている。

phpinfo.php
--------------
<?
phpinfo();
?>
--------------

たったこれだけの呪文を唱えてやるだけでカラフルなPHP情報画面が表示される。今回はセッション関係の問題だとやまを張って調べてみることにした。なぜならフロントサイトにはログインできるのに、バックサイト（管理画面）にログインできないことから、特殊なセッションを張っているせいだと思ったからだ。FreeBSD、Vine LinuxそれぞれのJoomla!公開ディレクトリに、phpinfo.phpを設置してWebブラウザで表示させてみた。そしてsessionのセクションを一項目ずつ比較していく。いくつか違いがあったがその中でも気になったのは下記の項目だった。

FreeBSD 6.2環境

session.use_cookies On On
session.use_only_cookies Off Off
session.use_trans_sid 0 0

Vine Linux 4.2環境

session.use_cookies On On
session.use_only_cookies On On
session.use_strict_mode On On
session.use_trans_sid 0 0

まずFreeBSD 6.2環境には、session.use_strict_modeが無い。こいつが臭いなとまず思った。しかしsession.use_only_cookiesがOffとOnでは大違いだ。このどちらかだなと疑いをかけた。

一般的にPHPの設定は、php.iniで行うのだと思っていたが、先述の通り.htaccessで制御できることが分かったのでなるだけ元は触りたくないなと、.htaccessで調整することにした。もちろん試験的に行うのならphp.iniでやっても良いと思うが、グローバル設定ファイルだから、どこをいじったか忘れないように注意が必要である（ちゃんとメモしておこう）。

.htaccessに下記のような記述を加えると、php.iniをいじらなくてもそのディレクトリだけに設定を反映できる。

php_value session.use_strict_mode 'off'

Vine Linux 4.2環境

session.use_cookies On On
session.use_only_cookies On On
session.use_strict_mode Off On
session.use_trans_sid 0 0

この設定が効いた！手順的には先にsession.use_only_cookiesをOffにしてみたのだが変化がなくて元に戻し、session.use_strict_mode をOffにしてみたら、あっさりログインできたという状態だ。

ではこのsession.use_strict_modeとはどういうものなのだろうか？非常に気になる。こんなところはいじってないので、Vine Linux 4.2の場合は、デフォルト設定ではJoomla!が動かないということになるのではないだろうか？ちなみにVine Linux 4.2の場合は、/etc/php/php.iniの終わりの方にVine独自設定がなされているから真っ先に確認することをお勧めする。おそらく日本語を使うためのチューニングだと思うが、思わぬワナにはまる可能性ありだ。

Strict Session管理パッチ

こちらに詳しいことが書かれていて、どうやら過去の流れ的にPHPのセッションを厳密化する機能なりパッチを追加したといういきさつがあったようだ。そしてこのモードはONにする事を推奨すると書かれている。不安になることを書くなぁ～

いずれにしても動かないんじゃ仕方ないし、FreeBSDではパッチが当たってない様なので、session.use_only_cookiesをOnにしておくことで妥協することにした。session.use_strict_mode まではやらなくて良いでしょ？よく分からないけど動かないんじゃ仕方ないし。という訳でFreeBSDの方は少しセキュアになり、Vineの方は少しセキュリティが甘くなった感じで結果オーライというところか。

投稿者 sasapurin : 15:00 |Joomla! | コメント (0) | トラックバック

Outlook ExpressでHotmailが使用できなくなる

HotmailをOutlook Expressで利用する機能が有料化

私はHotmail（com）アカウントを現在も3つ使わせて貰っており、Outlook ExpressでHTTPアクセスさせている。Hotmailは一定期間アクセスしないとアカウントが無効になってしまうため、思い出した時に手軽にログインさせられるOutlook Expressは非常に助かるのだ。 

今日、Microsoft Outlook Express チームから、「Outlook Express サービス変更のお知らせ」と言うメールが届いた。どうやらかねてから廃止になると言う噂のHTTPアクセス（WebDAV）機能が廃止されてしまうらしい。

より使いやすい新方式のプロトコルの採用に伴い、まことに勝手ながら、2008年6月30日をもちまして Outlook Express によるDAV プロトコルを経由した Hotmail 電子メール アカウントへのアクセスサービスを終了することにいたしました。サービス終了後は、Outlook Express を使用して Hotmail の受信トレイにアクセスできなくなります。

これは非常に困ったことである。Hotmailサーバ側の仕様変更だからどうしようもない。なんとかならんのか？と思ったらメールの文章はこう続いている。

引き続き、電子メール クライアントから Hotmail の受信トレイにアクセスをご希望の方には、新方式のプロトコルに対応した電子メール クライアントの Windows Live メール をご紹介します。Windows Live メールは、Outlook Expressに似た操作感とインターフェイスで、Hotmail を含む複数の電子メール アカウントを同時に管理できる無料の電子メール ソフトウェアです。Hotmail と その他のWeb メールサービス、さらにISPの電子メールなどをすべてひとつのソフトウェアで管理できるのでとても便利です。
Hotmail やその他のWindows Live サービスとシームレスに連携しており、ユーザー名とパスワードを入力するだけでお使いのHotmailアカウントに自動的にリンクされます。リンクが完了すれば、電子メールや連絡先にそのままアクセスができます。

要するにWindows Liveメールを使いなさいということだろう。まだベータの頃に使った記憶があるのだが、ハッキリ言ってよい印象が残っていない。.NET系のランタイムライブラリをインストールしなくてはならなかったと記憶している。そしてそれがまた非常に重かったからだ。非力な（古い）Windows 2000パソコンでは辛すぎる。家はまだWindows 2000パソコンが現役である。

問題はプロトコルだ。新方式のプロトコル名は？

そう思ってメールを読んでいると見慣れない名前を見つけた。どうやらこれが新方式のプロトコルらしい。Thunderbird辺りが対応してくれたら仕方なくでもメーラーを移行させるのだが。（Outlook Expressを使うのは、それがWindowsに組み込まれているからに他ならない。敢えて他のメーラーをインストールする必要が無いからだ。コンパネからアンインストールしようともOutlook Expressは本当の意味ではアンインストールできていないらしいから、使わない手は無いでしょ？）

DAV の代わりに使用されるプロトコルは何ですか。
DAV に代るものとして、マイクロソフトではDeltaSynchという新しい、さらに効率的なプロトコルを開発しました。これは特に大きな電子メール 受信トレイについて DAV よりもはるかに優れています。このプロトコルによって、クライアントは、前回電子メール サーバーにアクセスした後に行われた変更分だけをダウンロードすることができます。これは、DAV のようにフォルダごとに毎回すべてのヘッダーをダウンロードするよりも効率的で、パフォーマンスに優れています。

新しい Windows Live メール クライアントはどこからダウンロードできますか。
新しいクライアントはこちらからダウンロードできます。

システム要件を確認しよう。
げげ、Microsoft Windows XP SP2 または Windows Vista．．．．

Windows 2000 終わったね

Thunderbird辺りにDeltaSynchが実装される(アドオンが公開される)のを期待するしかなさそうだ。とにかくWindows 2000でも動作して、DeltaSynchをサポートしてくれて、出来れば軽いメーラーが出てくることを願う。もっとも6月30日までにはきっと無理だろうけどね。DeltaSynchをGoogleで日本語検索してもまだ数件しか引っかからないし有力な情報は無い。

投稿者 sasapurin : 12:06 |Windowsアプリ , Windows系 , コンピュータ | コメント (0) | トラックバック

Joomla!：1.0系-adminのパスワードが飛んだ！

非常に不本意なのだが、Joomla!1.0.15にadminで管理ページへログインできなくなった。不可解だがフロントサイトにはログインできるのだ。まぁ結果的に解決してこうやって書き込みをしているから問題はクリアできたのだが、なにやらJoomla!にはまだバグが多数あるような気がする。（笑

パスワードはメモっていたので間違っているはずは無いのだがどうにも受け付けてくれなくなったからやりようがない。データベースのデータが破損することもあるらしくそういう時にこういうことが起こることもある様だ。仕方が無いのでパスワードをリセットする方法を検索したところ、たどたどしい日本語訳のサイトが引っかかった。趣旨は読み取れたので何とかなりそうだ。

これは貴重なので備忘録しておこう。

Mambo / Joomla passwords cannot be recovered as they are set using a one-way hash function (MD5).

マンボ/ joomla回復することはできず、パスワードの設定を使用しているとして片道（ md5 ）をハッシュ関数です。 しかし彼らの新しい価値観をリセットすることができます。

The user information is stored in the MySQL database (obviously) in the mos_users (for MAMBO) or jos_users (for JOOMLA).

ユーザの情報は、 mysqlデータベースに格納さは、 （明らかに） mos_users （マンボ）または接頭辞（またはジョスモス）を設定することもできますし、お客様のシステムに違う名前かもしれない。

In phpMyAdmin select the database for your Mambo / Joomla system on the left combo-box.

phpmyadminでデータベースを選択して、お客様のマンボ/ joomlaシステムの左側のコンボボックスです。 次にmos_users選択して（または、必要に応じて）テーブルと選択して閲覧する。 アイコンをクリックして編集（鉛筆）は、システム管理者のユーザー名は、どこの行です。

In the password row under Function column set the function to MD5.

下の行列関数は、パスワードを設定する機能のMD5です。 選ばれた値を設定してパスワードを入力します。 保存すること（をクリックして行く）と設定は完了です。

Using MySQL commandline or GUI
With MySQL you can execute the following command in mysql command line or gui:
UPDATE mos_users SET password = MD5( ‘ Your Password‘ ) WHERE username = ‘admin’; Note: ChangeYour Passwordto your password (obviously).

MySQLのGUIを使用してコマンド行または
で、次のコマンドを実行することができますMySQLのMySQLのGUIをコマンドラインまたは：
パスワードの設定を更新mos_users =のMD5 （ 'パスワード' ）どこにユーザー名= '管理者' ;
注：お客様のパスワードを変更してパスワードを（明らかに） 。

やってみた事は続きに記す。

phpMyAdminを起動して、目的のデータベースを開くのは言うまでもない。phpMyAdminをインストールしておいて良かったぜ！

問題はadminのレコードがどのテーブルに記録されていてどう扱えばよいかだ。

英文と滅茶苦茶な翻訳のおかげで雰囲気は掴めたから、phpMyAdminで開いてMD5で保存しなおせば大丈夫だろうという根拠もない想像の世界で納得しながら作業を始めた。

問題のレコードは、「jos_usrs」に入っているはずだ。左側で「jos_usrs」をクリックすると、右側に構造が表示される。これをみてもちんぷんかんぷんなので、とっととタブを「表示」に切り替える。するとレコードの内容が表示される。かなりうれしい感じだ。

レコードを選択して、鉛筆アイコンをクリックすると編集モードに切り替わる。心拍数が上がる。下手してデータベースをぶっ壊したらマッサラからやり直しだ。汗が出そうだが慎重に作業を進める。要はフィールドと値をしっかりチェックしながら確認すればよい話だ。

このパスワードの呪文のようなところに、新しいパスワードを平文で入力し「関数」から「MD5」を選択すると平文を暗号化してくれる仕組みらしい。くれぐれもちゃんとコピーしておいて復旧させられるようにしてから作業をする事をお勧めする。私はSQLはさっぱり分からない素人である。

慎重に確認した後で保存をクリックすると、英語で説明しているような感じのSQL文が表示される（微妙に違うが）。要するにSQL文が理解できればコマンド操作でちょいちょいなのだろうが、素人にはそれば無理である。とにかくそれが終わったらもう反映されているので、adminでログインしてみると、見事にログインすることが出来た！という訳だ。

良かったログインできた～　この記録が誰かの役に立つことを！

検索ワード
Joomla!、adminパスワード忘れ

投稿者 sasapurin : 12:00 |Joomla! | コメント (0) | トラックバック

Joomla!：1.5系その2-推奨設定

Joomla!1.5.2のインストールの続き

推奨設定で下記の様な警告が出ている。エラー表示がオンになっていると駄目らしい。

ディレクティブ 推奨 現設定
セーフモード: オフ オフ
エラー表示: オフ オン
ファイル アップロード: オン オン
マジッククウォートランタイム: オフ オフ
Register Globals: オフ オフ
Output Buffering: オフ オフ
Session auto start: オフ オフ

同じく.htaccessの最終行に下記を追記した。

php_flag display_errors Off

そしたら推奨設定どおりになった。これで文句ないでしょ？

ディレクティブ 推奨 現設定
セーフモード: オフ オフ
エラー表示: オフ オフ
ファイル アップロード: オン オン
マジッククウォートランタイム: オフ オフ
Register Globals: オフ オフ
Output Buffering: オフ オフ
Session auto start: オフ オフ

蛇足ながら、Joomla!1.0.15に付属していたhtaccess.txtからphp.ini絡みで.htaccessに記述してphp.iniを制御するのに使えそうな記述を抜粋しておく。これは自分の為の備忘録も兼ねているからだ。もちろん誰かの役に立てばそれはそれで嬉しい。一目瞭然だが、値を指定したりする場合は「php_value」、スイッチの様にON/OFFする場合は「php_flag」を使うようだ。

php_value default_charset UTF-8
php_value mbstring.language neutral
php_value mbstring.internal_encoding UTF-8
php_value mbstring.http_input auto
php_value mbstring.http_output pass
php_value post_max_size 10M
php_value upload_max_filesize 10M
php_value session.save_path './tmp'

php_flag display_errors On
php_flag register_globals Off
php_flag magic_quotes_gpc On
php_flag magic_quotes_runtime Off
php_flag file_uploads On
php_flag magic_quotes_sybase On
php_flag output_buffering Off
php_flag mbstring.encoding_translation Off

投稿者 sasapurin : 09:00 |Joomla! | コメント (0) | トラックバック

phpMyAdmin最高！

SQL（エスキューエルではなくシーケルと読むらしい）に関してど素人の私である。未だにSQLというものがよく分からない。でもMySQLは無くてはならないデータベースだ。じゃないとLAMPだとかの環境が作れなくてキョービのCMSは動作させらないからだ。

そんなMySQLをWebブラウザから視覚的に操作できる様にしてくれるツールがphpMyAdminである。こいつは本当に最高である。実は正直言って今まで怖くていじれなくて、ユーザーパスワードの設定をしたり、データベースを新規に追加したり削除したり、それ位のことしか使えていなかった。

しかし、必要に迫られるとやるしかないという状況に追い込まれる訳で（大抵はトラブルシューティングとかイレギュラーなことがきっかけ）、少しずつ覚えていくものなのだと思う。そんな私もまたポカをやってしまいphpMyAdminに助けられたのである。

さて、なぜphpMyAdminを使わなくてはならなくなったのか？

それはJoomla!1.0.15を止めて、1.5.2に移行する決断をしたからである。SSHでサーバにアクセスしDocumentRootで下記のコマンドを実行してしまったのです。

$ rm -Rf *

つまり全て削除してしまうという恐ろしいコマンド。どうせJoomla!1.0.15は少しカスタムしただけで使ってないしと思いながら思わずやってしまったのだ。削除した直後ふと思い出した。Joomla!1.0.15のインストールで躓いたところや、トラブルシューティングのことなどをJoomla!自身に記しておいたことを！

やってしもたと後悔しながらふと冷静に考えた。MySQLに保存されているではないかと。幸いデータベースの方はまだ触れていない。もしかしたら取り返すことが出来るかも知れない。そう思ってphpMyAdminを起動してJoomla!のデータベースにアクセスした。エントリーのテーブルを表示させてみたところそれらしいエントリーが記されている。しかし文字化けして内容は読み取れない。日本語は化けてしまうみたいだ。これでは意味がないではないか。

あ、そういえばHOMEに文字コードを選ぶプルダウンメニューがるな！

家のアイコンをクリックして一度HOMEに戻る。そしてプルダウンからUTF-8日本語を選択してから、再度Joomla!のデータベースにアクセスし、テーブルを表示させた。見事に文字化けは解消されてエントリーの内容が少し読める。必要なエントリーを探し出して鉛筆アイコンをクリックすると編集画面になる。そこでデータベースに登録されているレコードを全て操作できる。つまり文章もコピー出来る！

と言う訳で無事にJoomla!に投稿しておいたエントリーを拾い出すことに成功した。あちこちに分散しているからこういううっかりミスになるんだなと、このブログに投稿することにした。今までSQLなんてデータの入れ物程度にしか思っていなかったが、直接操作できるとかなり便利な事を覚えてしまった。そんな重要で難解なSQLを手軽に操作させてくれるphpMyAdminはやっぱり最高だなと思った限りである。どおりでレンタルサーバでもユーザーの操作用として使われているはずだわな。

 

投稿者 sasapurin : 00:30 |オープンソース系 | コメント (0) | トラックバック

2008年04月21日

Joomla!：1.5系その1-事前インスタレーション確認

Joomla!1.5.2をインストールする。

Webサーバに構成ファイルをFTPでアップロードして、トップページにアクセスすると自動的に「http://www.hogehoge.com/installation/index.php」へリダイレクトされる。

早速エラーというかサーバー設定が駄目だと言われた。

PHPバージョン >= 4.3.10 はい 
- zlib compression サポート はい 
- XMLサポート はい 
- MySQLサポート はい 
MB languageのデフォルト いいえPHP mbstring language が 'neutral'に設定されていません。.htaccessに 'php_value mbstring.language neutral' を追加すると設定出来ます。 
MB string overload off はい 
configuration.php 書込み可 はい

Joomla!1.0.15で学習しているので、htaccess.txtを.htaccessにリネームしてエディタで開き、上記メッセージに書かれている通り一番最終行に

php_value mbstring.language neutral

と追記したらOKになった。

PHPバージョン >= 4.3.10 はい 
- zlib compression サポート はい 
- XMLサポート はい 
- MySQLサポート はい 
MB languageのデフォルト はい 
MB string overload off はい 
configuration.php 書込み可 はい 

投稿者 sasapurin : 22:23 |Joomla! | コメント (0) | トラックバック

2008年04月20日

WordPress

WordPress 2.5を試してみた。既に自宅のサーバはAMP環境が出来ているので、あっけなくインストールが終わり使い始める事が出来た。この手軽さはブログツールとしては最強と言って良いかも知れない。
Movable Typeの様にXHTML+CSSの知識だけではカスタマイズ出来ないが（ちょっとカスタムしようと思うとPHPの知識が多少なりとも必要）、ブログと割り切って使うならこの軽さ、見通しの良さは捨てがたい魅力だと思う。探してきたテンプレートを割り切って使うのであればこれほど手軽なブログシステムは無いだろう。

Movable Typeを使ってきた身としては、とにかくメチャメチャ軽い動作に驚いてしまった。動作はMovable Typeの様に再構築で静的なページを作らない為、PHPの処理が重いと遅くなるという評判であったが、我が家の様なショボイ型遅れのPCをサーバに仕立てている環境でも快適である。度々再構築しなくてはならない時などは待ち時間が長く嫌になるくらいだから、再構築の必要が無いというのはかなり魅力的だ。ブログツールとして使うだけなら、多くのテンプレートとプラグインがあるのでこの機会に乗り換えてしまおうかなと真面目に思っている。

WordPressには他のブログからの移行を手助けするツール（インポート機能）が実装されている。Movable Type、TypePadももちろん対応している。ただし残念な事にインポート処理を行うと途中で止まってしまい移行が上手く出来ない。Movable Typeからエクスポートしたファイルのサイズが大きすぎたかなと確認したところ1.7MB程度であった。WordPress側ではファイルサイズ2MB以下とされている為、1MB以下になるよう分割してみたのだがそれでも上手く読み込んでくれず途中で止まってしまう。30秒のタイムアウトで弾かれたと言う趣旨のメッセージが表示されるが何が原因なのかよく分からない。問題となったphpファイルの何行目と言う所まで表示されているのだが、phpのソースを見てもさっぱり分からない（分かるはずがない）。

とにかくこの軽さは特筆ものだと言えるし、大きく重くなり過ぎたMovable Type 4系の見通しの悪さ（構成ファイル数も滅茶苦茶多い）と比べると奇跡のような軽さを実現したオープンソースアプリケーションだと思う。これはPHPが苦手だとか言って食わず嫌いしている場合ではないなと思い直し、PHPの基本知識程度は理解しようと努めている今日この頃である。このブログは近い日にWordPressに移行すると思う。

投稿者 sasapurin : 19:30 |CMS | コメント (0) | トラックバック

Joomla!：1.0系その3-ディレクトリとファイルパーミッション

ディレクトリとファイルパーミッション

こいつもちょっと躓きやすい。概念が分かってしまえばなんて事ないのだが、説明が貧弱過ぎるから、カット＆トライしてみるしかないのだ。だから私が試してみて出来たことをここに記しておくので、ここを読んだ人は近道を通って欲しい。

administrator/backups/ Unwriteable
administrator/components/ Unwriteable
administrator/modules/ Unwriteable
administrator/templates/ Unwriteable
cache/ Unwriteable
components/ Unwriteable
images/ Unwriteable
images/banners/ Unwriteable
images/stories/ Unwriteable
language/ Unwriteable
mambots/ Unwriteable
mambots/content/ Unwriteable
mambots/editors/ Unwriteable
mambots/editors-xtd/ Unwriteable
mambots/search/ Unwriteable
mambots/system/ Unwriteable
media/ Unwriteable
modules/ Unwriteable
templates/ Unwriteable

見事にパーミッションが制限されていて、書き込みが許可されていない。

この項目だけは、一個ずつパーミッションを見直していかないと駄目っぽい感じだ。

[root@www html]# ls -la
drwxrwxr-x 15 sasapurin apache   4096  4月 7日 20:22 ./
drwxr-xr-x  7 sasapurin apache   4096  4月 7日 11:55 ../
-rw-r--r--  1 sasapurin apache   5851  4月 7日 19:44 .htaccess
-rw-r--r--  1 sasapurin apache 104874  4月 7日 19:37 CHANGELOG.php
-rw-r--r--  1 sasapurin apache   3429  4月 7日 19:37 COPYRIGHT.php
-rw-r--r--  1 sasapurin apache   4376  4月 7日 19:37 INSTALL.php
-rw-r--r--  1 sasapurin apache  17977  4月 7日 19:37 LICENSE.php
drwxr-xr-x  9 sasapurin apache   4096  4月 7日 19:37 administrator/
drwxr-xr-x  2 sasapurin apache   4096  4月 7日 19:37 cache/
drwxr-xr-x 16 sasapurin apache   4096  4月 7日 19:37 components/
-rw-r--r--  1 sasapurin apache   4372  4月 7日 19:37 configuration.php-dist
drwxr-xr-x  2 sasapurin apache   4096  4月 7日 19:37 editor/
-rw-r--r--  1 sasapurin apache   3890  4月 7日 19:37 globals.php
-rw-r--r--  1 sasapurin apache   1041  4月 7日 19:37 globals.php-off
drwxr-xr-x  3 sasapurin apache  12288  4月 7日 19:38 help/
-rw-r--r--  1 sasapurin apache   5867  4月 7日 19:37 htaccess.txt
drwxr-xr-x  6 sasapurin apache   4096  4月 7日 19:38 images/
drwxr-xr-x 12 sasapurin apache   4096  4月 7日 19:38 includes/
-rw-r--r--  1 sasapurin apache   8481  4月 7日 19:37 index.php
-rw-r--r--  1 sasapurin apache   5216  4月 7日 19:37 index2.php
drwxr-xr-x  4 sasapurin apache   4096  4月 7日 19:49 installation/
drwxr-xr-x  2 sasapurin apache   4096  4月 7日 19:38 language/
-rw-r--r--  1 sasapurin apache    710  4月 7日 19:37 mainbody.php
drwxr-xr-x  7 sasapurin apache   4096  4月 7日 19:39 mambots/
drwxr-xr-x  2 sasapurin apache   4096  4月 7日 19:39 media/
drwxr-xr-x  2 sasapurin apache   4096  4月 7日 19:39 modules/
-rw-r--r--  1 sasapurin apache   4929  4月 7日 19:37 offline.php
-rw-r--r--  1 sasapurin apache   2474  4月 7日 19:37 offlinebar.php
-rw-r--r--  1 sasapurin apache    709  4月 7日 19:37 pathway.php
-rw-r--r--  1 sasapurin apache    301  4月 7日 19:37 robots.txt
drwxr-xr-x  5 sasapurin apache   4096  4月 7日 19:39 templates/

しかし一見しただけでオーナー(sasapurin)は書込み権限を持っているが、グループ(apache)に書込み権限が無い事が分かった。  

せっかくのSSHでコマンド操作なので、なるだけシンプルに行きたいのだが、全部のファイルに適用する訳にもいかないから、こういう感じでやってみることにした。

[root@ html]# chmod g+w administrator/backups/
[root@ html]# chmod g+w administrator/components/
[root@ html]# chmod g+w administrator/modules/
[root@ html]# chmod g+w administrator/templates/
[root@ html]# chmod g+w cache/
[root@ html]# chmod g+w components/
[root@ html]# chmod g+w images/
[root@ html]# chmod g+w images/banners/
[root@ html]# chmod g+w images/stories/
[root@ html]# chmod g+w images/stories/
[root@ html]# chmod g+w language/
[root@ html]# chmod g+w mambots/
[root@ html]# chmod g+w mambots/content/
[root@ html]# chmod g+w mambots/editors/
[root@ html]# chmod g+w mambots/editors-xtd/
[root@ html]# chmod g+w mambots/search/
[root@ html]# chmod g+w mambots/system/
[root@ html]# chmod g+w media/
[root@ html]# chmod g+w modules/
[root@ html]# chmod g+w templates/

chmodでグループ(g)だけに書込み権限(w)を加える（+）という意味だ。
手間はかかったが、無事に赤い文字が緑に変わって書込み可能となった。

administrator/backups/ Writeable
administrator/components/ Writeable
administrator/modules/ Writeable
administrator/templates/ Writeable
cache/ Writeable
components/ Writeable
images/ Writeable
images/banners/ Writeable
images/stories/ Writeable
language/ Writeable
mambots/ Writeable
mambots/content/ Writeable
mambots/editors/ Writeable
mambots/editors-xtd/ Writeable
mambots/search/ Writeable
mambots/system/ Writeable
media/ Writeable
modules/ Writeable
templates/ Writeable

いちいちパーミッション修正を手作業でやってられるか！という人はこれが役立つかも。意味が分かる人だけ自分の環境に変更して使ってね。

#!/bin/sh
cd /var/www/html
chmod g+w administrator/backups/
chmod g+w administrator/components/
chmod g+w administrator/modules/
chmod g+w administrator/templates/
chmod g+w cache/chmod g+w components/
chmod g+w images/chmod g+w images/banners/
chmod g+w images/stories/
chmod g+w images/stories/
chmod g+w language/
chmod g+w mambots/
chmod g+w mambots/content/
chmod g+w mambots/editors/
chmod g+w mambots/editors-xtd/
chmod g+w mambots/search/
chmod g+w mambots/system/
chmod g+w media/
chmod g+w modules/
chmod g+w templates/

投稿者 sasapurin : 13:30 |Joomla! | コメント (0) | トラックバック

Joomla!：1.0系その2-お勧め設定

次はお勧め設定の項目について

ディレクティブ お勧め 現在
Safe Mode: OFF: OFF
Display Errors: ON: ON
File Uploads: ON: ON
Magic Quotes GPC: ON: ON
Magic Quotes Runtime: OFF: OFF
Register Globals: OFF: OFF
Output Buffering: OFF: OFF
Session auto start: OFF: OFF
Register Globals Emulation: OFF: OFF
mbstring.language: neutral: neutral
mbstring.internal_encoding: UTF-8: UTF-8
mbstring.encoding_translation: OFF: Off
mbstring.http_input: auto: auto
mbstring.http_output: pass: pass

見ての通り何もしなくてもOKになった。というのはちょっと端折り過ぎなので簡単に記しておく。

Joomla!のファイル群の中にhtaccess.txtというファイルがある。こいつはエディタで開くと分かるが記述がコメントアウトされている上に、拡張子がtxtになっているから、もちろんそのままでは.htaccessとして機能していない。ファイル名を.htaccessにリネームし、コメントアウトを外しながら、項目を有効にして、Joomla!インストーラの「もう一度チェック」をクリックすれば、気持ちが良い程に赤い文字が解消されて行くはずだ。.htaccessが使えない環境だとか、もともと記述しても機能しないサーバの場合は例外だが。（うちは自宅サーバなので、制限なくあっさりこのステップは乗り越えられた）

と言うか、今回.htaccessでphpの設定が変更できるということをこれで初めて知ったくらいだ。phpとか全然知らんもんね～この点（htaccess.txt）に関しては非常に親切だと思う。勉強になった。

投稿者 sasapurin : 12:55 |Joomla! | コメント (0) | トラックバック

Joomla!：1.0系その1-設置前チェック

Joomla!は使いやすいという記事を目にするが、まだ正直いってこれが使いやすいCMSだとは思えない。

まずはインストールが第一関門だ。1.0.15をインストールしてみた。しょもないところで躓くから、備忘録＆普及へのささやかな貢献のために私のこけた場所を記しておく。

PHP version >= 4.1.0 Yes
  - zlib compression support 利用可能
  - XML support 利用可能
  - MySQL support 利用可能
configuration.php 書込み不可
インストール終了後に表示される設定ファイルをコピーしてアップロードするならインストールを継続できます。
  - マルチバイト サポート 書込み可
Session save path 書込み不可
./tmp  

まずは、configuration.phpが赤文字になるところだ。こいつの意図する意味は、おそらく公開フォルダ（普通に言うドキュメントルート）に書込みが出来ないということである。例えばApacheのDocumantRootが下記の場合、

/var/www/html

# chmod 775 /var/www/html
# chown -R sasapurin:apache /var/www/html

こんな感じになると思う。私は利便性を考えてsasapurinをapacheグループに追加している。そうすればFTPなりSCPなりでコンテンツをアップしながら、Apacheがphpで実行した結果を好きに書き換えられるからだ。他に正しい方法があるなら教えていただきたいな。

その次がまた分かりづらい表記である。Session save pathを./tmpにしなさいとデフォルトでなっている。もちろん頭に./がついているから、相対パスという意味である。問題はその基点となるPATHはどこ？ということで迷うのではないだろうか？

これについてはもう一つ情報があるので、ここで整理しておく。Joomla!のファイル群の中に、htaccess.txtというファイルがあるのに気づいてる人は話が早い。テキストエディタで開いてみると最後の方にこう書かれている。

## session.save_path は DocumentRoot 以下に作成して下さい
php_value session.save_path './tmp'

正しくは下記の通りだ。

# cd /var/www/html/installation
# mkdir tmp
# chmod 777 tmp

きっとこれで二つ目の赤文字も解消されると思う。 DocumentRootという言葉に騙されて、/var/www/html/tmpとしてしまったら思うつぼで騙されたことになる。つまり下記の例は間違いである。普通の頭ならこうしちゃうと思うんだな。でもそれはJoomla!に関しては間違いらしい。

# cd /var/www/html
# mkdir tmp
# chmod 777 tmp

蛇足ながら付け加えておくと、session.save_pathは、PHPがセッション情報を保存するテンポラリフォルダの事らしく、PHPグローバルな設定はphp.iniで定義されている。グローバルな設定のままでもよさそうな気がするが、.htaccessに上記の追記をする事で、Joomla!専用のPHPテンポラリディレクトリを設けようという事らしい。php.iniを確認するとうちのFreeBSDサーバでは/tmpになっていたし、Vine Linuxでは/var配下にphp専用のフォルダを作って定義してあった。 

という訳でPHPなんて知らない人は、つまらん事で躓くポイントがある（ドキュメントが弱い）から、とてもJoomla!が簡単に導入できるとは、現段階では口が裂けてもいえないだろう。言っている人は自己満足に浸っているか素人の気持ちが分からない上級者だと思う。おそらくこれらのメッセージは開発者寄りのメッセージだと思う。実際に使うのは開発の知識の無い人だということを理解した上で、もう少し正確で万人に分かりやすいエラーを表示させた方が普及には役立つと思う。

投稿者 sasapurin : 10:17 |Joomla! | コメント (0) | トラックバック

2008年04月14日

お問い合わせメールフォーム

MovableType等のCMSの多くは、文字コードにUTF-8を使っている。それくらいは知っているのだが、それがいかに不自由なことなのか知らなかった。今まで必要性を全く感じていなかったので、「お問い合わせ」とか言う「メールフォーム」を機能させるためのCGIの多くが、SJIS対応で作られているという事実を知らなかった。

何の気なしにKENT CGIからPostMailを拝借してきて、MTのページに問い合わせフォームのタグを埋め込みテストをしてみたところ、文字化けを起こすではないか。ん？ああ文字コードの問題ねと、構成htmlファイルの文字コードを変更してみたらますます文字化けが悪化。案の定受け取ったメールのソースを見てみたらことごとく、ISO-2022-JPの文字が。これじゃぁだめだよねと、CGIを少しいじってみたのだが、メールはUTF-8と認識させることに成功したと思いきややっぱり駄目。根本的に文字コードを変換する仕組みがUTF-8に対応してないんだと分かった。これ以上はプログラマの仕事だよね。

じゃあ、UTF-8対応のメールフォームCGIを探してくれば良いんだなと思いきや、あんまり数が無いみたいで、見つけた殆どが有料で販売されている。有料だけあって色々な機能が実装されていてそれで付加価値をつけて商売しているんだなと分かった。そんな機能は要らないんだけどな。UTF-8は標準化される（普及する）までは当分お金のかかる規格だなと痛感したわけだ。

もちろんフリーで公開して下さっている数少ないCGIもあるのだが、利用規約をよく読むと少しでも利益が見込めるサイトの場合は商用扱いになると書かれていて、完全に個人用という用途でしか無償で利用させていただくことは出来ないと分かった。小さなお店のHPを知人から頼まれて再構成しているのだが、今の状況よりもお金がかかるとなると難しいなと思えてきた。

一番てっとり早いのは、新規ウィンドウをポップアップしてSJISで気兼ねなくCGIを動作させれば良いのである。そうすればブラウザの「戻る」を操作してしまい入力していた問い合わせメッセージが消えてしまうなんてアクシデントも未然に防げるだろう。だけどそういうのは見栄えが悪いというか、埋め込みたいというのがサイトの所有者としては本音なんだろうなと思ったりもする。

もっとも、MovableTypeの場合はメールフォームを生成するプラグインがあるらしいので、それでやってみても良いかも知れない。問題はPerlなりPHPなりがメール送信時に使用するモジュールがレンタルサーバにあるかどうかだろう。その点ホームサーバなら無ければ追加と言う最短の方法が取れるので楽なのだが。

今まで必要性を感じなかったところに色々な課題があるんだなと勉強になっている今日この頃。商売でHP作成の依頼を受けている人の大変さや気持ちが少し分かった気がする。さてどうしようかな。

投稿者 sasapurin : 20:45 |CMS , Movable Type | コメント (0) | トラックバック

2008年04月13日

カテゴリアーカイブを2