2013年11月6日水曜日

WordPress: フッターCopyrights表示を自動更新する方法

WordPressのテーマによくある、フッターに著作権表記については、通常こんな感じで記載されていますよね。

「Copyright © 2003 - 2013 サイト名称 All Rights Reserved.」

この2003年の部分は、著作権の発生した年、すなわち、当該サイトを設置した年を意味します。
また、その横の2013年は、今年であり現存するサイトの著作権は今も有効であることを意味するそうです。

当該サイトを運営していく上で、毎年毎年この後ろの年数を手動で変更するのは面倒ですね。

そこで、

自動的にこの2013年の部分を更新してくれるように変更するコーディングを書いてみました。

修正前は、以下のようにコーディングされていました。

print '
Copyright © サイト名 All Rights Reserved.'
;

今回は、基準年を2003年、現在もサイト運営中という設定で、上に書いた著作権表示をしてみたいと思います。

$thisYear = date(Y);
print '
Copyright © 2003-'.$thisYear.' サイト名 All Rights Reserved.
';

このようにコーディングすることで毎年の面倒が軽減されます。

※このコーディングは、設定上の設置年2003年現在の場合、表示が、「2003-2003」
となってしまい、少々かっこ悪いです。

2013年11月4日月曜日

Windows7 ワークグループ名称の変更方法

うちのホームネットワーク上に何台かPCがつながっているのですが、

それらをまとめて、ワークグループ名を設定して管理しています。

この前、自分の失敗でThinkCentre M90pのレジストリを壊してしまい

システムの再インストール作業を実行しました。

このとき、ワークグループの設定をしなかったため、このPCだけが、

違うワークグループ名下で稼動しているという、いわゆる、村八分

状態であることが判明しました。

そこで、

この村八分解除、いや、ワークグループ名の変更手順を記録します。

まず、

1.コントロールパネル>システムを開きます。
 スタートボタンを押し、「コントロールパネル」押下し、すべてのコントロールパネル項目から
 「システム」を見つけ、これをクリック。

あるいは、
 スタートボタンを押し、「コンピューター」押下し、メニューバー上の「システムのプロパティー」
 をクリックする

すると、以下の画面が表示されます。


この画面の「コンピューター名、ドメインおよびワークグループの設定」欄にある「設定の変更」を
クリックします。(上記画像の赤丸部分参照)


2、システムのプロパティーから変更ダイアログを呼び出す
設定変更をクリックすると、「システムのプロパティー」が表示されます。
その中に「コンピューター名」タブを押します。
そのダイアログ内に
現在設定されている「コンピューター名」および「ワークグループ名」が表示されています。
今回、
ワークグループ名が、本来設定すべき名称と「異なっている」ことを確認してください。
その上で、
このタブ内にある
「このコンピューターの名称を変更するには[変更]をクリックしてください。」
と記述されている右横に「変更(C)」と表記されているボタンがあります。
これを押します。
(下記画像を参照)



3、コンピュータ名・ドメイン名の変更ダイアログ画面でワークグループ名を変更する

「コンピュータ名/ドメイン名の変更」ダイアログが表示されます。

このダイアログの一番下に「ワークグループ(W)」欄があります。

このラジオボタンをクリックすると、好きなワークグループ名を設定できます。

ここに、設定すべきワークグループ名を記入し、「OK」をクリックします。


その後、「OK」ボタンを押し、「システムのプロパティー」も閉じます。
すると設定変更は、再起動後に反映する旨のインフォがでるので

システム再起動してください。

4、結果の確認

再起動が完了したら、ワークグループの名称が変更されたか確認します。
「1.」で最初に出した画面「すべてのコントロールパネル項目>>システム」画面
にワークグループ名がありますので、そこを見て確認完了となります。


2013年10月18日金曜日

EC-CUBEをXAMPPに導入しローカルで使う

EC-CUBE、日本発のOpen Sourceだそうです。
今回は、このEC-CUBEの使い勝手を見極めるべく、自宅のローカル環境に導入することに
しました。

この記事は、ローカル環境のXAMPPにEC-CUBEを導入する手順をまとめました。

結論からいうと、XAMPPが導入されていさえいれば、「CMSの追加作業は簡単」という
感想を得ました。

1、XAMPPにEC-CUBE用のデータベースを作成する。


※XAMPPは設定済みとしてお話を進めさせていただきます。

「http://localhost/」にアクセスし、「ツール」→「phpMyAdmin」をクリックします。



XAMPP導入時に設定したphpMyAdminのユーザ名、パスワードを入力し、実行をクリックします。



phpMyAdminにログインしたら、「データベース」タブをクリックし、「新規データベースを作成する」の
したのダイアログにEC-CUBE用のデータベース名を指定して「作成」をクリックしてください。



tsteccubというデータベース名のDBが作成できました。

以上でphpMyAdminの設定は終わりです。

2、EC-CUBEをインストールする。


本体は、日本発ECオープンプラットフォームEC-CUBEサイトよりダウンロード(無料)から
入手します。

が、EC-CUBEメンバー(登録無料)となってから出ないとダウンロードできませんでした。


EC-CUBEメンバー(登録無料)の手続きの詳細は省略しますが、表示された画面の指示に
したがって進めれば、なんなく登録は終了するはずです。

登録が完了すると以下の画面が表示されます。



「EC-CUBEメンバートップページへ」のバナーをクリックして、メンバーページへ入り、「無料ダウンロード」のバナーをクリックし「EC-CUBE本体」を任意の場所へダウンロードしてください。


2013年10月17日現在、ダウンロードされたファイル名は「eccube-2.13.0」でファイル形式は
zip形式で落ちてきます。

このファイルを解凍しその中身をデスクトップ等の適当な場所にコピーして中身を出します。
そして、中身のフォルダ名をXAMPPで使用する際にわかりやすい名前にリネームします。

(例)
私の場合、「eccube-2.13.0」を「eccube」にしました。

このリネームした「eccube」フォルダを「C:\xampp\htdocs」(XAMPPフォルダの位置)にコピーします。



ここまでで、ローカル環境にEC-CUBEがインストールされたことになります。
次にEC-CUBEをセットアップします。
ブラウザから。
「http://localhost/eccube/html/install」
と入力しEC-CUBEのセットアップ画面を開きます。


これが出たら、「次に進む」をクリックします。


「チェック結果」画面で、「アクセス権限は正常です」を確認して「次へ進む」をクリックします。


必要なファイルコピーがされます。「コピー成功」を確認し「次に進む」をクリックします。

次に、「ECサイトの設定」[管理機能の設定」「WEBサーバの設定」画面が出てきます。
ここでは「ECサイトの設定」のみ設定します。


「店名」「メールアドレス」「ログインID」「パスワード」を指定します。

その後、「次へ進む」をクリックします。


「データベースの設定」を行います。
「DBユーザ」、「DBパスワード」にXAMPP導入時に設定したユーザ名、パスワードを指定してください。

※「次へ進む」クリックしたら、エラーが出ました。次のようなものです。


「DB NOT FOUND」でした。原因は、「DBの種類」を「MySQL」と指定し忘れたからです。

皆様は、引っかからないようにしましょう。

次に、



「データベースの初期化」画面に進みますが、何もせず「次へ進む」をクリックします。


「データベースの初期化」結果画面が出ます。
ここでは「○○○成功しました」というメッセージを確認して「次へ進む」をクリックします。



「サイト情報について」という画面が出ます。さっと流し目くれて「次へ進む」をクリック。


インストール完了画面が出ます。「管理画面へログインする」をクリックしてください。


EC-CUBEの管理画面へ入るログイン画面が出ますので、必要事項を入力してください。

ちなみに、このアドレスがブラウザに表示されていますので、このアドレスを「お気に入り」

に入れとく楽チンです。具体的には「http://localhost/eccube/html/admin/」。

あと、表示のとおり、「index.php」を消せといわれていますので、気が向いたときに消してお

いてください。ただ、この表示は誤っていて、「index.php」の所在は、「/eccube/html/install/index.php」

にあります。


管理画面に入ると、上のような画面が表示されます。適宜設定していくこととなると思いますが、

ここでは、「ふーん、こんなんなんだ」程度でおkです。

なお、当画面の右上に「SITE CHECK」ボタンを押すと(今の時点では)初期のEC-CUBEサイトが

表示されます。


初期のEC-CUBEサイトです。

長々書いてきましたが、以上の作業でローカルXAMPP環境にEC-CUBEを導入することができました。

なお、
EC-CUBEとWordPressとの連携をしたくなったりする欲求があると思います。

この点については、

1、EC-CUBEをベースにWordPressと連携をとる
2、WordPressをベースにEC-CUBEと連携をとる

のふたつを考えると思います。

1については、無料のプラグインがありますので、実現可能性は高いと思います。

2は、WordPressの固定ページからEC-CUBEに飛ばすことを想定して実現可能性を
模索しますが、ものが「SSL」環境下で使用することが必須と考えられることから、
「セッション管理が切れる」のではないかという懸念があります。

今のところ、アドレスを分けて単体運用が、余計なトラブル抱えずに済むかなと

考えています。



2013年9月28日土曜日

東京大神宮+出雲大社東京分祀参拝

本年、平成二十五年は、遷宮の年回りであることは、周知の事実です。

伊勢神宮は、二十年毎に、出雲大社は、なんと、六十年に一度のご遷宮だそうです。

私、出雲大社の次回遷宮の年には生存していないことは確実です。

そこで、実際に三重県、島根県に出向いて参拝旅行へと行きたいところですが、

時間も、暇もそこまで裂けない。

またそこで、

東京はいいところです。それは、東京のお伊勢さんと呼ばれる「東京大神宮」があり、出雲大社

については、「出雲大社東京分祀」があります。

この二社へ参拝することを以って、ご本家に参拝したことにするという技を使うことにしました。

時間、費用的に厳しいが東京に近い方にはいい案ですね。

まづは、東京大神宮から参拝です。


木製の鳥居が出迎えてくれます。


由緒書を拝見し、元は、日比谷に鎮座されていたこと、関東大震災で現在の飯田橋に遷座され、
飯田橋大神宮と呼ばれていたことなどが書き記されています。

一番目を引いたのは、日本で最初の神前式結婚式を執り行ったことという記述でした。



境内内は、コンパクトで、参拝の方がいっぱいでした。特に、ご利益が縁結びで有名ということから
でしょうか、女性の参拝者が非常に多かったです。

社殿の中では、ちょうど結婚式が執り行われておりました。

参拝の後、御朱印帳を買い求め、そこに、当社の御朱印を頂戴しました。


三種類用意されていますが、こちらは、「ちょう」です。白地に蝶が映えます。

御朱印帳のみで、¥800円


買い求めた御朱印帳に、当社の御朱印を頂戴しました。

初穂料¥300円


次に、六本木に鎮座する「出雲大社東京分祀」へ参拝。こちらは、六本木ヒルズのそばで大変
都会的なお社で、東京らしさを感じました。

このお社、本家の出雲大社が昔、ものすごい高層建築だったことを想起してか、お宮がビル三階部分に相当する部分に鎮座されています。


こちらの参拝作法は、行ってみてびっくりしたのですが、通常は「二礼、二拍手、一礼」の作法ですが、こちらでは、「二礼、四拍手、一礼」の作法となっております。



こちらで御朱印を頂戴するには、拝殿向かって右側に社務所があり、そこのインターフォンを使って宮司さんに御朱印をお願いすることになります。


初穂料¥300円

こちらのお社でも、東京大神宮と同様、縁結びのご神徳からか、女性の参拝者が多かったです。

今年は、伊勢、出雲ともに遷宮するという珍しい年回りで東京ではありますが、両社に参拝できたことがうれしかったです。


2013年9月2日月曜日

レジストリ壊してシステムリカバリを食らう―ThinkCrntre M90p system recovery because of registry broken

急いで出かけるため、pcをシャットダウンして、電源切って出て行きました。

帰ってきて、PCでの作業を再開するため、PCを立ち上げました。

画面を見ると、以下のようにいつもと違う風景が出ています。


出力されたダイアログ、メッセージは以下のとおり。
----------------------------------------------------------------------------
スタートアップ修復
「コンピュータを開始できませんでした スタートアップ修復はシステムの問題を確認しています。」

「問題が見つかった場合、スタートアップ修復はそれらを自動的に修正します。この処理の最中にコンピュータは何回か再起動することがあります。」

「個人用ファイルまたは、情報は変更されません。これは数分かかることがあります。」
----------------------------------------------------------------------------

この後、システムを復元するかどうか尋ねられ、システム復元を選択したところ、スタートアップ修復は、復元を試みていました。


この後、復元が完了したので再起動をするよう促すメッセージがでたので、指示に従い再起動。

すると、また、上記のコンピュータを開始できない旨のメッセージが出力されました。同様に、復元、再起動を行ったところ、正常に起動し、デスクトップも出現しました。

一瞬、直った?と思いましたが、事態はそう甘くはありませんでした。

再起動を指示したところ、起動フェーズでまた、「スタートアップ修復」が発動され最初と同じように問題を見つけ、修復処理を二回行ったところで、正常起動されるという症状が発生しました。

この「スタートアップ修復」の詳細メッセージを貪ったところ、「レジストリーが壊れています」というメッセージが記録されている箇所を発見しました。

レジストリ壊れたら、ほぼ、システムを再インストールが必要となり、これまで蓄積してきた、ユーザーデータは消されてしまうことになります。

このようなときのために、「バックアップ」が必要になります。

残念ながら、バックアップの直近が、結構古いものだったため、データリカバリーには、向かないことが判明。

ただ、

二回、システム復元処理を行えば、データは読み書きできる状態でしたので、デスクトップ出現後、
必要データの疎開作業をいそいそと始めました。

吟味、振り分け、疎開と一連の作業に2時間程度割くことになりました。

大丈夫だろうと一応の見切りをつけたところで、

ThinkVantage Rescue and Recovery の機能を使い、当システムを工場出荷状態に戻す作業を実施することになりました。

システムを復旧させるには、

1、このシステムを工場出荷状態に戻す(Rescue and recovery system restore)
2、リカバリ後、自分でインストールしたアプリケーションを再インストール(Windows Updateによる
  パッチ修復も含む)
3、疎開させたデータを戻す

このような三ステップの段取りで戻すことになります。

ここでは、1のシステムを工場出荷状態に戻す作業をやるところまでを記録しておきます。

システムを工場出荷状態に戻すためには、電源を落とすところから始める必要があります。

このため、疎開データを疎開させる作業が完了したら、通常、PCを落とすようにシャットダウンさせます。

<作業>
1、電源オン
2、1と同時に「PF12」連打!
3、PCから、ビープ音がするまで連打したら、「PF12」連打をやめ、しばらく様子見
4、下写真のような画面が登場するので、「続行する」クリック。

5、画面上に三つのメニューがでるので、「完全に復元」をクリック


6、「システムを復元すると、最後のバックアップ以降に作成したすべてのデータが上書きされます。保存したいファイルを、すべて外部デバイスにコピーしてから、復元作業を続行することをお勧めします。」というメッセージがでるので、「続行する」をクリックする。
(もうすでに、案内の作業は終わっているため)


7、「完全復元」を選択すると、システム全体のバックアップがロードされます。すべてのファイル、アプリケーション、個人設定、およびオペレーティング・システムが復元されます。最後のバックアップ以降に作成されたすべてのデータは失われます。

このメッセージの下に、「出荷状態の復元」がありますので、そのラジオボタンをチェックし、先に進めます。


8、警告として、「工場出荷時コンテンツの復元は、システムが回復不能になった場合を想定しています。システムが工場出荷状態に復元されます。すべての個人データや設定、インストールしたアプリケーションが削除されます。」というダイアログがでますので、「続行する」をクリックします。


9、「システムが再起動してWindows回復環境に入ります。または、システム起動時にF8を押してWindows回復環境に入ることもできます。今すぐ起動しますか?」のダイアログに対し、「OK」をクリックします。



10、Rescue and Recoveryから言語選択の要求がきますので、「Japanese」を選択して、「次へ」をクリックします。


11、Product Recoveryから、「『はい』をクリックすると、データは失われ、システムは選択された状態に復旧されます。続行しますか?」のメッセージがでますので、「はい」をクリックします。


12、システムは、工場出荷状態に復元されます。作業中は、写真のように、進行状況が出力されます。


13、リカバリーが終わると、「リカバリー・プロセスが完了しました。システムを今すぐ再起動しますか?」というメッセージが出ますので、「はい」をクリックします。


14、システムに再起動がかかります。その後、このシステムを購入したときと同じように、初めてシステムを起動したときと同じように、システムの設定を行います。




15、Windwsの設定が終了したら、

   ・Windows Updateを利用して、パッチをいわれるがままに充てまくる。
   ・自分で入れたアプリケーションを再インストールする。
   ・疎開したデータを元の場所に戻す。

これらw実施してリカバリー終了となります。

今回のレジストリの破壊は、シャットダウン中に電源が喪失した場合に起こりやすいという記録がありました。

そういえば、急いでいたので、シャットダウン完了を確認しないまま、電源落としたのかもしれません。

身から出たさびでした。

電源確認は、入念に行いたいと思います。

2013年8月27日火曜日

php fputcsvを使わないでCSVファイルをダウンロードする

自サーバでDBのでーたをCSVファイルにしてダウンロードするロジックを検証していました。

(WordPressのプラグインを利用しています。)

(トラブル現象)
1、3件出なければいけないところ、2件しかCSVファイルに出てこない。
2、CSVファイルの見出しのひとます目に「・ソ」「x'EFBBBF'」が入り、文字化けした。

(原因)
1、については、レコードは三件きちんとデータとして吐き出されている。しかし、一番最後のレコードの一番最後のアイテムのデータが壊れていることが分かりました。

2、については、ファイルの先頭三バイトに「x'EFBBBF'」が挿入されていてこれがもとで最初のアイテムが文字化けしてしまっていることが分かりました。この三バイトがどこでセットされているかは、推測ですが、アウトプット・バッファーにデータをfputcsvしたときでは?と思います。

※この三バイト「x'EFBBBF'」は後にBOM付きUTF-8ファイルと呼ばれる品物であることが判明。


(対応)

1、CSVの項目の区切りを「”」、各項目ごとの区切りを「,」にして変換しているロジックを
mb_str_replace()を使ってコンバートする。
※mb_str_replace()は、予め、ダウンロードして、稼動DIRに設置しておく。

2、アウトプットバッファーのクリーニングを、ob_end_clean()を使ってお掃除した上で
fwrite()を使ってファイルプットする。

3、CSVデータ1レコードの終わりに改行コード\r\nをつける。

4、fputcsvとmb_str_replaceを参考に問題プログラムを修正する。

修正コードCSVレコードGenerate部分

function prv_fputcsv($fp, $data, $encoding="") {
 require_once 'mb_str_replace.php';

 $csva = '';
 foreach ($data as $col) {
  $col = mb_str_replace('"', '""', $col, $encoding);
  $csva .= "\"$col\",";
 }
 fwrite($fp, "$csva\r\n");
} 

ファイルダウンロード部分

     
$file_size = @filesize($full_file_name);
     ob_end_clean();
     ini_set("zlib.output_compression","0");
     header("Pragma: public");
     header("Expires: 0");
     header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
     header("Cache-Control: public");
     header("Content-Type: text/csv");
     header("Content-Disposition: attachment; filename=".$file_name);
     header("Content-Length: ".$file_size);
     @readfile($full_file_name);
     @unlink($full_file_name);

このように、二箇所の修正を行いました。

(結果)

前出のトラブル現象はずべて解消しました。

めでたし、めでたし。

※ソースの部分に、SyntaxHhgilighterを当ブロガーに導入しました。
 導入方法は追ってアップできればと思っています。

2013年8月18日日曜日

XAMPP 1.7.7 MySql 文字コードセットをUTF-8に変更する方法

文字コードの設定は重要です。

クライアントサーバ間の文字のやり取りをする場合、文字化けの虞のある場所です。

そこで、私の使っているXAMPP1.7.7のMySql設定を確認することにした。

コマンドプロンプトからMySqlにログインし、

mysql> show variables like 'char%';

を入力すると



このように、

character-set-client = cp932
character-set-conection = cp932
character-set-database = latin1
character-set-server = latin1
character-set-system = utf-8

ばらばらな文字コード設定になっていました。

そこで、この文字コードをUTF-8に統一することになりました。

変更方法は、MySqlの設定ファイル、My.iniに下記を設定することにより行います。

[mysqld]
skip-character-set-client-handshake
character-set-server = utf8
collation-server = utf8_general_ci
init-connect = SET NAMES utf8

MySql,Apacheの再起動を行い、先ほどのコマンドを入力すると変更結果が得られます。


character-set-client = utf-8
character-set-conection = utf-8
character-set-database = utf-8
character-set-server = utf-8
character-set-system = utf-8

このように、すべて、UTF-8に設定されました。

多くのブログに掲載されている、「default-character-set=utf8」を、My.iniの[mysqld][mysql][client][mysqldump]に設定する記述に応えてそのまま設定すると、MySqlが動きませんでした。

この、パラメータはxampp MySqlには使えません。


2013年8月9日金曜日

WordPress 固定ページ編集で、HTTP304発生

昨日まで編集できていたWordPressの固定ページの編集が、今日、いきなり、できなくなっています。


編集窓に変更を加えた後、更新ボタンを押すと、サーバーからアクセス拒否を表す、HTTP403

が返されてきます。

昨日、何やったかな?

1、変更をいっぱいくわえたので、WordPressのDBバックアップ、ファイルバックアップを実施。
2、レンタルサーバにある機能で、「WAFセキュリティー」設定を全部セット
  (XSS対策、SQL対策、ファイル、メール、コマンド、PHPの各対策)

この二つくらいでした。

具体的にどのような症状かというと・・・・

A.管理画面の固定ページを編集画面で特定のページは、更新ボタンを押すと、編集していても、い なくても、HTTP403が返される。

B.他のページは、編集していても、いなくても、更新ボタンを押すと更新できる。

A.について編集窓には、<iframe>タグを用いた記述をいている。
B.については、普通の文字列のみの記述をしている。

こんな感じでした。

まず、昨日行った「バックアップ」にエラーがないかログをチェックしたところ、DB,
FILE共にNORMAL ENDしていて特に問題となるようなことはありませんでした。

次にやったWAFセキュリティー設定。

これは、サーバー管理ツールのWAF設定の画面に行って、説明書きをよーく読んでみました。

-----------------------------------------------------------------
■ 検出時に動作について

検出された場合には、アクセスが拒否されエラーページが表示されます。
----------------------------------------------------------------

と書かれていました。

これって

HTTP403

のことだよね。

うんうん。

さっさとWAF設定を全部解除設定にしました。

暫くして、Aの編集は、滞りなく編集できるようになりました。(汗)

今回の場合、XSSの設定だけはずせばいいと思いましたが、念のため全解としました。

開発中は、こんなもの設定しないほうが良いですね。




2013年8月7日水曜日

WordpressにIE安全じゃないよ!と怒られる-IE10なのに・・・

Wordpressで開発していますが、突然、管理画面のダッシュボード画面に赤い警告が出ました。

------------------------------------------------------
お使いのブラウザは安全ではありません!


Internet Explorer の安全ではないバージョンをお使いのようです。
古いブラウザを使っていると、コンピューターを危険に曝してしまいます。
WordPress のすばらしさを実感するには、ブラウザーを更新してください。


Internet Explorer をアップグレードするか ブラウザの選択肢を知る
Browse Happyサイト を訪れてみてください。


非表示にする
-------------------------------------------------------

こんな文言が入っていました。

おかしいな?

IE10なのに・・・

それと、テンプレートとか崩れていることも発覚。

パンくずリストも、「○○>■■>△△」というように横並びに表示されるはずが、

「○○>
■■>
△△」

このように、縦になっている。

そこで、

Google先生にお尋ねしてみました。

「wordpress ie10 安全ではない」

すると、

シロップ さんのパソコン修理日誌パソコン修理日誌にたどり着きました。

中身を拝読すると

むむむ!

おんなじ現象あるね。

解決方法は、なんと、IEのアドレス窓に虫眼鏡、南京錠、紙がち切れたイメージとリロードマーク
が並んでいるうちの

「紙がちぎれたイメージ」

これが原因でした。

現状、「青くなっている」

これをクリックすると

あら不思議

私意図したもとの状態に戻っているではありませんか。

これを押すと互換表示されるようです。

あまり深い意味は探りませんでしたが、不具合解消ということで

先に進むことにしました。

シロップ さん、感謝です。(^^)

2013年8月1日木曜日

SSL環境下でWordPressの管理画面、ログイン画面を使う

SSL環境でWordPressを運用するには、公開ページに対してSSL運用が可能となって

ホットするのもつかの間で、ログイン画面、管理画面に入れなくなります。

私、あせりました。

そもそもの間違いは、SSL申請中にWordPressを導入し、チョコチョコイジッテイタこと

でした。

WordPressの導入時は、http://example.comで運用中で、何の問題もありませんでした。

しかし、SSLの申請上、WWW.あり、なしを決定したり、.htaccessの設定を変えたりで

サーバーの環境が刻々と変わり、挙句、SSL用にIPが変わった。

(1)www.wxample.com IP:nnn.nnn.nn.nn

(2)example.com       IP:mmm.mmm.mm.mm

となっていました。

まづこれを上の(2)のIPを(1)のIPに合わせるようにDNS設定を変更する。

次に、WordPressのインストール先をexample.comだったのでwww.example.comにするため、

一度

WordPress本体をサーバーからUninstallする。また、MySql DB を削除する。

こうして、サーバーからWordPressとMySqlを削除した上で、再度WordPressをインストールする。

(DBも新規作成したうえで)

こうして、作成しなおした環境下で本題の「WPのログイン・管理画面をSSL環境下で稼動するよう設定変更を行う」

これを実現するには、WordPressの環境設定ファイル「wp-config.php」を修正する。

サーバのドキュメントルートし下にWordPressを導入した場合

www.example.com/

以下に当該ファイルは存在するはずです。

このファイルの適当な箇所に以下のパラメータを設定することで、うまくいきました。

--------------------------------------------
/** SSL ログイン・管理画面アクセスを強制する */
define('FORCE_SSL_ADMIN', true);
--------------------------------------------

この環境変数設定は、管理画面、ログイン画面に対し、強制的にSSLアクセスする
パラメータです。

このほかにログイン画面だけ強制的にSSLアクセスするパラメータがあります。
-------------------------------------------
define('FORCE_SSL_LOGIN', true);
-------------------------------------------

参照

http://wpdocs.sourceforge.jp/Administration_Over_SSL

やっと、SSL環境下での開発が始められます。


2013年7月30日火曜日

SSL環境下で301リダイレクトを使って「WWWあり」と「WWWなし」を統一する

レンタルサーバを借りて、ドメイン登録をしました。

私の入ったレンタルサーバは、www.example.comと「www.あり」

example.comの「www.なし」いずれの指定でもアクセス可能な設定でした。

今回、SSLを設置するにあたり、コモンネームというのをSSLに指定する

必要に迫られました。

????

SSL通信を行うには、サーバー証明書というのが必要で、この証明書に

コモンネームという設定があり、ここにURLを指定する必要があります。

すなわち、

コモンネームに指定されたURLによるアクセスでなければ、SSL通信

ができないということだそうです。

ということは、ドメインの指定で上記のように「www.あり」「www.なし」の

いづれでもアクセス可能な設定であっても、SSL通信をするには、いづれか

一方に決めないとコモンネームに登録されていないURLでアクセスすると

SSL通信が確立されないのです。

たとえば、

コモンネームが、www.example.comと指定されている環境で、

example.com

と指定してアクセスすると、SSL通信できません。

ということらしいのです。

そこで、

SSL導入にあたり、ドメイン「example.com」に「www.あり」「www.なし」

いづれか一方に統一する設定、http://でアクセスしても、https://にリダイレクトする設定
をすることになりました。

方法を以下に示します。

ドメインのルート直下にある「.htacsess」ファイルに以下の設定を追加記入します。

★「www.あり」に統一かつ、コモンネームのアドレスにリダイレクトさせる場合

▼設定例(example.com)
-----------------------------------------------------
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^example.com
RewriteRule (.*) https://www.example.com/$1 [R=301,L]
-----------------------------------------------------

★「www.なし」に統一かつ、コモンネームのアドレスにリダイレクトさせるする場合

▼設定例(example.com)
-----------------------------------------------------
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^example.com
RewriteRule (.*) https://example.com/$1 [R=301,L]
-----------------------------------------------------

じゃあ、どちらに統一すべきか?

という議論がありますが、私見では、どっちでも、お好きなほうを

選べば良いと思います。

※この手法は、サイト移転したときに、アドレス転送をする場合にも使うそうです。

引越し前サイトに新サイトのアドレスを埋めればOK。

2013年7月28日日曜日

第36回 隅田川花火大会、中止のお知らせ 高橋真麻の根性中継あり



突然の豪雨で大変でした。

大会史上、中止は初めてだそうですね。

私見ですが、
震災復興途上のなか、何浮かれてんだよ!と天に叱られているような
心持になりました。

なお、この日は、浦安でも花火大会が行われましたが、隅田川と同様に
中止に追い込まれました。

なにか、震災のことが風化しているようで気になります。
今日も、福島第一からは、放射性物質の海洋拡散が起こっている
のに・・・・。

2013年7月21日日曜日

Anton Bruckner - Symphony No.9 - Wiener Philharmoniker - Leonard Bernstein


懐かしい映像を見つけましたのでうpします。

1990年の春、オーストリア、ウイーンの楽友協会大ホールで行われたコンサート。

そのときの映像が最近公開されたようなのです。

私、このコンサート一番後ろの立ち見エリアで聞いていたのです。非常に懐かしく
そして、うれしい思いでいっぱいです。

Scherzo. Bewegt, lebhaft - Trio. Schnell のところで、バーンスタインが、跳ねています。当時もこの跳ねるシーンを
生で見てびっくりしたのを鮮明に覚えています。

もう、23年も前のことですが、いい思い出と再開してうれしいです。
ムジーク・フライン グロッサー・ザール・・・綺麗なホールです、また、行ってみたい。

Anton Bruckner
Symphony No.9 in D minor, WAB 109
Sinfonie Nr.9 d-Moll, WAB 109
("dem lieben Gott")

I. Feierlich, misterioso . . . . . . . . . . . . . . . . . . . (0:01:16)
II. Scherzo. Bewegt, lebhaft - Trio. Schnell . . . . .(0:28:38)
III. Adagio. Langsam, feierlich . . . . . . . . . . . . . . (0:41:14)

Wiener Philharmoniker
(Vienna Philharmonic Orchestra)
Leonard Bernstein

Recorded live at the Große Musikvereinssaal, Vienna, 1990


2013年6月22日土曜日

富士山が世界遺産に登録された

富士山が世界遺産に登録されたというニュースがありました。

かっこいい富士山、日本人の心。

いいですね。めでたい。




少し心配なのは、観光増による、ごみの問題です。これがために、自然遺産に登録できなかった経緯をもつので心配です。

日本人の心の問題として、ごみは手に持って下山すればいいのです。一人一人の心がけで美しい富士山を後世に繋ぎましょう。

あくまでも、富士山はご神体です。

2013.05.31の富士山

2013年6月14日金曜日

lenovo ThinkCentre M90p 付属マウス交換 CRU 利用

先日壊れたlenovo ThinkCentre M90p付属のマウスが、lenovoの保守サービスから送られてきました。

CRU(Customer Replaceable Unit )送付サービスというそうです。

私の利用マシンには、三年間、オンサイト保守サービスというワラントが付いていまして、今回、このワラントの権利行使という形でマウスの交換が実現しました。

実際の交換は、pcを買ったときのように、ただ、旧マウスをUSBから抜いて、新マウスをUSBに差込、PCのPowerを入れて、動作確認を行い、正常稼動なら対応終了となり、実際にそうなりました。

左:新マウス、右:旧マウス

ワラントってこういうときに効果が出ます。

通常の保守サービスは、1年程度しか付いていませんね。しかも、郵送で引き取りが主流です。
オンサイト保守は、高いけど、マザーボード壊れたときとかは絶大な威力発揮します。
(一回、経験あり)


こんな感じで壊れたマウスの引き取り等の手順が書かれた紙も同封されてくるので非常に分かりやすいです。

これでマウスの交換も終わり、一軒落着。