MT形式からWordPressへ移行した際に画像をインポートするプラグイン

WordPressから他のWordPressに移行するツールでは、画像ファイルも同時に移動できます。でも多くの無料ブログで使っているMovable Type(MT)から引っ越す場合は画像ファイルまでは移動してくれません。

そこで、MT形式からWordPressへ移行した際に画像をインポートするプラグインを作ってみました。

Images importer from URL

英語がわからないのでネイティブに通じる名前なのかわかりませんが「Images importer from URL」という名前のプラグインです。

ダウンロード:Images importer from URL

Images importer from URLがやること

このプラグインがインポートするのは画像だけです。ページの内容そのものは無料ブログからWordPressへデータを移動する手順を参考に移行してください。

移動したページの中ではインポート元となるブログの画像に、imgタグでリンクが張られています。そこで、Images importer from URLは次の動作をします。ユーザーが操作するのは赤い行の2点です。

  1. インポート元となる旧ブログのURLを入力
  2. imgタグのsrc属性で移行前のブログのURLから始まっているものと、/ から始まっているものをすべて抽出
  3. / から始まっている場合は、WordPress内にファイルがあるかを調べる。
  4. WordPressにファイルがない場合と、移行前のブログのURLで始まっている全ての画像ファイルにリンク切れがないか調べる
  5. リンク切れのない、移行前のブログにある画像一覧を表示
  6. スタートボタンで画像一覧をWordPressにインポート
  7. 各ページの画像URLをインポートした画像URLに自動で置換

使い方

Images importer from URLを使う前にページは全てインポートしておいてください。

関連記事:無料ブログからWordPressへデータを移動する手順

次にImages importer from URLをダウンロードします。

ダウンロード:Images importer from URL

ダウンロードしたファイルは .zip形式で圧縮されています。それをWordPressにアップロードする前に解凍してください。

フォルダの中身は次のとおりです。

  • css.php
  • form.php
  • import.php
  • properties.php
  • images_importer_from_url.php
  • js.php
  • xml_http_request_server.php
  • img/
    • pleasewait.gif
  • languages/
    • images_importer_from_url-ja.mo
    • images_importer_from_url-ja.po

アップロードと有効化

解凍したファイルをフォルダごと全部、インポート先のWordPressの “wp-content/plugins/” に、FTPでアップロードしてください。

2014年12月8日追記)上記はすでに訂正しましたが、先ほどまでアップロード先を間違えて “wp-content/uploads/” と書いていました。正しくは “wp-content/plugins/” です。書き間違いすみませんでした。

ファイルをフォルダから出して、wp-content/plugins/ に直接入れるのはやめましょう。他のプラグインも含め、すべてのファイルをフォルダに入れず wp-content/plugins/ に全部直接入れた場合、どれかのプラグインに全く同じ名前のファイルがあったらファイルのアップロードで上書きされてしまい確実に壊れます。

アップロード後の場所は “wp-content/plugins/images_importer_from_url” となります。

正しく配置されていれば、「インストール済みプラグイン」の一覧に「Images importer from URL」があります。

インストール済みプラグインへ

説明が「インポートしたページの画像ファイルを抽出して、”wp-content/uploads/” に保存し、画像リンクを差し替えます。MT2形式の旧ブログからWordPressに移行した際にお使いください。」となっているのがImages importer from URLです。

インストール済みプラグイン一覧

Images importer from URLを見つけたら「有効化」という文字をクリックします。クリックして表示が「停止」に変わったら、有効化に成功しています。

プラグインを有効に

有効化出来るとダッシュボードのサイドバーの設定に「URLから画像をインポート」という項目が増えています。その「URLから画像をインポート」をクリックすると画像をインポートするページヘ移動します。

URLから画像をインポート

画像のインポートとURLの置換

画像のインポート画面に移動すると次のようになっているので送信ボタンの左に、エクスポートした移転前のブログのトップページのURLを正確に入力してください。


http://hoge.example.com/
http://hoge.example.com  (最後のスラッシュはあってもなくてもどちらでも構いません)

インポートする画面

何度試しても次の画面が表示される場合は、このプラグインがお使いのサーバーでは使えない可能性があります。その場合は、あきらめてください。

エラーの場合は

旧ブログのトップページのURLを入力したら「送信」ボタンを押してください。すると次のように旧ブログに現存する画像の一覧が表示されます。

2014年12月8日追記

Seesaaブログの場合は、画像ファイルのURLが違うようです。そのため正しいURLを入力しても「旧ドメインの画像URLは見つかりませんでした。」と表示されてしまうという事が判明しました。

もし正しいURLを入力しても「旧ドメインの画像URLは見つかりませんでした。」と表示されてしまう場合は、ブログのURLではなく、画像ファイルの置かれているURLを入力してください。

Seesaaブログの場合
ブログのURLが http://xxxxx.seesaa.net/ ですと
画像のURLは http://xxxxx.up.seesaa.net/ という風に seesaa.net の前に up. というのが追加されるようです。

もしかしたら、これはSeesaaブログに限らず、ご使用されているブログによっては起こることかもしれませんので、その場合は、画像の置かれている基準となるURLを調べて入力してください。

追記)コメント欄で情報をいただきました。「はてなブログ」の場合の画像URLは
http://cdn-ak.f.st-hatena.com/images/fotolife/m/※はてなID
となるそうです。情報有難うございます。

追記)アメブロからも移行できたというコメントをいただきました。

アメブロにはエクスポート機能はありませんが、本文の移行はつぎの記事の要領で出来るみたいです。「アメブロからWordPressへの移転方法(記事エクスポート編)

それでも、画像の移転はできないのですが、当ページのプラグインで次のようにURLを打ち込んで画像をインポートされたようです。以下、頂いたコメントです。

アメブロは画像フォルダを右クリックし、プロパティを出します。
そこに表示されてるアドレス(URL)のコピペで移行できました。
全部選択すると移行できないので、ユーザー名までとか、日付までとか、色々ためしてみてください。

iifu6

問題がなければ「スタート」ボタンを押してください。画像がたくさん表示されるのを想定して「スタート」ボタンはページの上と下についていますが、どちらを押しても同じです。

「スタート」ボタンを押すと、次のようにインポートが終わったものから背景がクリーム色に変わっていきます。その際、画像の横に表示されているURLが旧URLから移行後の新URLに変更されます。おそらく100個ほどの画像なら1分かからずにインポートが終わると思います。

インポートの途中

この時、インポートに失敗した画像はクリーム色の背景ではなく、ピンク色の背景になります。

クリーム色になったものはインポートが成功しているので、新しいWordPressのブログの中に画像があります。それらはクリーム色になった時点でページの中の画像URLも新しい画像のものへ書き替えられています。

ですから、URLを入れるところからもう一度やり直すと失敗した画像だけを再取得する事になります。ピンク色の背景になった画像があった時は、URLの入力からもう一度試してください。

すべての画像のインポートが終わると画面のいちばん下に次のように終了した旨が青い文字で表示されます。

インポート完了

インポートが成功していれば、各ページの画像URLはインポートした画像のURLに書き替えられています。

インポートした画像は メディア » ライブラリ で確認できます。ただし(タイトルなし)となっているので、必要なら編集してください。

メディアライブラリ

インポートが終われば、このプラグインは必要ありません。プラグインを停止してから、削除してください。

無料ブログからWordPressへデータを移動する手順

無料ブログの多くは、Movable Typeを使っているのでWordPressへの引越しは簡単に出来ます。今回はSeesaa Blogを例に方法を説明しますが、他のブログでも同じように出来ると思います。

この方法はWordPressにすでにコンテンツのある場合でも使えます。元からあるページはそのままで、そこに引っ越したページが追加される形です。ですから、以下の手順でMT形式からWordPressに移行すれば、複数のブログをひとつにまとめる事も出来ます。

関連記事:MT形式からWordPressへ移行した際に画像をインポートするプラグイン

無料ブログからWordPressへの引越し方法

データの出力をエクスポート、入力をインポートといいます。Movable Type形式の無料ブログからWordPressへ移行するためには、次の2つの手順が必要です。

  1. 無料ブログをMovable Type形式でエクスポートして、ファイルに保存
  2. 保存したファイルをWordPressにインポート

Seesaa BlogやFC2ブログなど多くの無料ブログでは、標準でエクスポート機能が使えます。ただし、ライブドアブログの無料版ではエクスポート機能は使えません。ライブドアからWordPressへ移行する場合は1ヵ月だけ有料契約する必要があります。

Seesaa BlogからWordPressへの移行手順

Seesaa Blogでの作業(エクスポート)

まず、管理画面の「設定」ページで「その他」にあるエクスポートをクリックします。(その右横に「お引越し機能」というボタンがありますが、これはよそのブログからSeesaaへ引っ越す時のボタンです)

管理画面でエクスポートをクリック

開いた画面では次のようになっています。WordPressへ引っ越す場合、ここで「文字コード」はUTF-8を選びます。「取得範囲」と「コメント/トラックバック/タグ」はお好みで選択してください。

Seesaa Blogの設定画面

「エクスポート」ボタンをクリックするとファイルが自動でダウンロードされます。ページの量によりますが、ダウンロードにかかる時間はおそらく一瞬だと思います。

ダウンロードされたファイルはmtarchive-xxxx-20yy-mm-20yy-mm.logというようにmtarchive(MTアーカイブ)で始まる名前です。

Seesaa Blog側での作業はこれで完了です。あとはダウンロードしたファイルをWordPressへインポートします。

WordPressでの作業(インポート)

Movable Type(MT)形式のデータをWordPressにインポートするツールは無料で用意されています。

WordPressのダッシュボードで ツール » インポートと進みます。

WordPress管理画面

「インポート」ページの項目に「Movable Type と TypePad」というリンクがあるのでクリックします。

Movable Type and TypePadをクリック

次のようなウインドウが開いたら右下の「いますぐインストール」ボタンを押します。上の方に「注意: このプラグインは現在使用している WordPress のバージョンではテストされていません。」と書いてありますが、2014年8月時点のWordPress(バージョン3.9)では問題なく動きました。

いますぐインストールをクリック

画面が変わったら「プラグインを有効化してインポートツールを実行」というリンクをクリックします。インストールしようとしているのはプラグインです。インポート後に削除したいなら、プラグインページで「Movable Type and TypePad Importer」という名前を探して削除します。

プラグインを有効化してインポートツールを実行

「Import Movable Type or TypePad」という画面に変わったら「ファイルを選択」ボタンを押します。この時「ファイルをアップロードしてインポート」というボタンは薄くなっていて、押すことが出来ません。

ファイルを選択ボタンを押す

使っているOSによって画面は違いますが、ファイル選択画面になるので、先程エクスポートしたmtarchiveで始まるファイルを選択します。選択が済むと、色が薄くて押せなかった「ファイルをアップロードしてインポート」というボタンが押せるようになるのでクリックします。

ファイルをアップロードしてインポートをクリック

Assign Authors」というページに変わるので、インポートするページの作者の名前を選びます。初期値ではエクスポート元のブログでの名前が表示されています。もし新しいブログで別の名前を使っているのなら、その下の「or map to existing」の右のSelectでWordPressに登録されている名前が選べるので、それを選びます。

名前を選択

下の図の場合、ページ作者の名前は「Tom」でインポートされます。ここが「Tom」ではなく「Select」のままだと、その上に表示されている、昔の名前「えったん」でインポートされます。

ウソです。えったんがWordPressのユーザーにいない場合、えったんは無視され登録してあるユーザーの名前で登録されます。登録ユーザーが複数いる場合、おそらくauthor IDが1のユーザーになるのではないかと思います。

昔の名前えったん

名前を設定したら「Submit」ボタンを押します。

するとすぐに画面が変わり、インポートしたページタイトル一覧が表示されています。その一覧の一番最後に「All done. Have fun!」と表示されていたら、インポートは成功です。

All done. Have fun!

先ほど書いたように、インポートツールはプラグインです。インポートが終わって削除したいなら、プラグインページで「Movable Type and TypePad Importer」という名前を見つけて削除します。

注意!MTからWordPressへの移行ツールでは画像ファイルは移動されません

実際にやってみると、あっという間に移行は終わります。ただ、ひとつだけ問題があります。画像は移行してくれないようです。

移行後にインポートしたページを見ると普通に表示されていますが、画像ファイルは元のブログにあるままです。このままでも画像は表示されていますが、元のブログを削除すると画像もなくなってしまうので表示されなくなります。

そこで、MT形式からWordPressへ移行した際に画像をインポートするプラグインを作ってみましたのでご利用ください。

MT形式からWordPressへ移行した際に画像をインポートするプラグインのページヘ移動する。

WordPress 更新しても上書きされないテーマのカスタマイズ方法

先日、WordPressを使っているブログで「テーマがバージョンアップされる度にスタイルシートを書き直している」という方がいたのですが、それは非常にムダだと思うわけです。

次の手順でカスタマイズすれば、WordPressのテーマが更新されても、自分で変更した部分は上書きされずに維持できます。

WordPressのカスタマイズとは

WordPressのカスタマイズとは、拡張する事と思ってください。

その「拡張」とは、プラグインやテーマを使って行ないます。WordPress本体をアップデートしても、自分で追加したプラグインやテーマはWordPress本体とは別物なので、本体をアップデートした後も変わりません。

もし、プラグインなどを使わずにWordPress本体を直接書き換えた場合、WordPressを更新すると、変更した箇所も含めて上書きされてしまいます。

同じように「テーマ」も、テーマそのものを直接書き換えると更新時に上書きされてしまいます。

そうならないためには、独自に改変した部分だけを別ファイルに保存しておいて、後から読み込むようにすれば「テーマ」本体のアップデートに関係なく維持されます。

テーマのスタイルシートを拡張する

まず、スタイルシートだけを独自に書き替えてみましょう。

具体的には次のように行ないます。これはWordPress Codexの「子テーマ」というページで説明されています。

今回は、Twenty Fourteenを「親テーマ」にして、「子テーマ」を作ってみます。自分が拡張したいテーマに置き代えて読み進めてください。

親テーマの確認

子テーマを作る前に、自分のサーバーで「親テーマ」の保存場所を確認しておきます。

サーバー上の wp-content/themes の中に twentyfourteen というディレクトリ(フォルダ)があります。これが「Twenty Fourteen」のテーマファイル群です。

サーバー上のイメージ
wp1

そのディレクトリの名前「twentyfourteen」を確認したら、「子テーマ」の作成にかかります。

これは、あくまで Twenty Fourteen を親テーマに選んだ場合ですので、自分が拡張したいテーマのディレクトリ名を確認してください。

子テーマの作成

まず、自分のパソコンでディレクトリ(フォルダ)をひとつ作ります。

名前は好きに付けていいですが「私のTwenty Fourteen」などと、漢字やひらがな、カタカナを使ったり、スペースを空けたりしないで半角英数字だけでつけるようにします。今回は「watashi-no_Twenty14」という名前にしました。このように半角の – (ハイフン) や _ (アンダーバー) 大文字、小文字、数字は使えます。ただし、無理に使う必要はないので、基本的には半角アルファベットの小文字と数字だけでつけたほうが無難です。

wp2

次にメモ帳で新しいファイルを作り、次のように書きます。

/*
Theme Name: 私のTwenty Fourteen
Template:   twentyfourteen
*/

@import url('../twentyfourteen/style.css');

これを「style.css」という名前で、先ほど作ったディレクトリ(フォルダ)「watashi-no_Twenty14」の中に保存します。名前は必ず「style.css」です。

これで「watashi-no_Twenty14」というフォルダの中に「style.css」というファイルがひとつだけある状態になっています。

では「style.css」の中に書いた事を説明します。

1〜4行目

このファイルは、拡張子が .css である通り、スタイルシートです。1行目の /* と4行目の */ はスタイルシートのコメントアウトです。

コメントアウトとは反映されない注釈部分で、コンピュータには反映されませんが人間がわかるよう説明を書いておく時に使います。

なので、/* から */ まではスタイルシートのデータとしては反映されません。それを利用して、この中にWordPress専用の情報を書いています。スタイルシートには反映されず、WordPressにだけ反映されるデータ部分が2〜3行目です。

Theme Name: 私のTwenty Fourteen
Theme Name: の後が拡張されたテンプレートの名前です。自分の好きな名前を書きます。
日本語も使えることを示すために、あえて日本語を使っていますが、オススメはしません。半角英数字で書いた方が無難です。
名前にはスペースキーを押した時の空白文字も使えますが、改行しないで一行の名前にします。
Template: twentyfourteen
Template: の次に来るのは、先ほど調べた「親テーマ」のあるディレクトリ(フォルダ)の名前です。
今回はTwenty Fourteenを例にしているので「twentyfourteen」ですが、自分の継承したい親テーマのディレクトリ名を書き込みます。

Theme Name: と Template: の直後に半角スペースをつけていますが、これは見やすくしているだけで、何個つけても同じです。なくてもよく、次のように書いても構いません。

/*
Theme Name:私のTwenty Fourteen
Template:twentyfourteen
*/

ここまで説明した、Theme Name: と Template: の行が「子テーマ」の情報に絶対に必要なデータです。テーマを一般公開する場合は、他にも次のような情報を書きますが、自分で使うだけなら Theme Name: と Template: だけで大丈夫です。

子テーマ – WordPress Codex 日本語版」より

/*
Theme Name:     Kid
Theme URI:      http://example.com/
Description:    Child theme for the Twenty Ten theme for WordPress
Author:         Demetris
Author URI:     http://example.com/about/
Template:       twentyten
Version:        0.1.0
*/
  • Theme Name (必須) 子テーマ名
  • Theme URI (任意) 子テーマのウェブページ
  • Description (任意) テーマの説明。例: わたしの最初の子テーマ。ワーイ!
  • Author URI (任意) 作者のウェブページ
  • Author (任意) 作者の名前
  • Template (必須) 親テーマのディレクトリ名, 大文字小文字を区別します
  • Version (任意) 子テーマのバージョン。例: 0.1, 1.0, etc

@import url(‘../twentyfourteen/style.css’);

この行は、WordPressではなくスタイルシートの記述部分です。

@import url(‘../twentyfourteen/style.css’); で、親テーマのあるディレクトリから style.css を読み込んでいます。この行がないと親テーマのスタイルシートは読み込まれません。スタイルシートを完全に一から自作するなら別ですが、そうでない場合は必須です。

赤字の部分は、自分の継承したい親テーマのディレクトリ名を書きます。つまり、Template: の行に書いたのと同じディレクトリ名です。

サーバーへアップロード

ここまで出来たら、作ったディレクトリ「watashi-no_Twenty14」とスタイルシート「style.css」を、サーバーにアップロードします。

FTPでアップロードするのではなく、ファイルマネージャーでサーバー上に新規作成する方法は「ロリポップサーバーのFTPにWordPressのファイルを簡単にアップロード | Area5.net  Arisaya blog」に書かれています。

アップロード先は、親テーマ Twenty Fourteen と同じ wp-content/themes です。

wp-content/themesの中に、親テーマ「twentyfourteen」と、子テーマ「watashi-no_Twenty14」の両方があるようにアップロードします。そして「watashi-no_Twenty14」の中にstyle.cssが入っている状態です。

サーバー上のイメージ
wp3

自作した子テーマを適用させる

アップロードが終わったら、WordPressにログインしてダッシュボードの「外観」» 「テーマ」と移動して「テーマの管理」ページを開きます。

ここまでの作業にミスがなければ、テーマの一覧の中に「私のTwenty Fourteen」があるはずです。

wp4

「私のTwenty Fourteen」にはサンプル画像が表示されていませんが、サンプル画像を作っていないからです。そのままで問題はありません。

「私のTwenty Fourteen」が表示されている場所にマウスを乗せると「有効化」と表示されますので、その「有効化」をクリックします。

wp5

問題がなければページの上の方に「新しいテーマを有効化しました。サイトを表示する」と表示されるのでサイトを表示してみます。

wp6

サイトが有効化されないとしたら、ここまでの手順のどこかを間違えています。

サイトを表示して、素のままの何も変更されていない「Twenty Fourteen」が表示されていたら成功です。何故でしょうか。だってまだ何もカスタマイズしていないからです。では、スタイルシートを改変してみましょう。

wp7

自作スタイルシートの追加

ここまで出来たら「子テーマ」は完成されています。ただ、まだ何も独自部分がないので親テーマと全く同じ状態です。

今からやる手順でスタイルシートを書けば今後はテーマの更新に影響されずに、拡張部分を維持できます。

独自のスタイルシートは、先程自分で作った style.css の続きに書きます。

Twenty Fourteenの背景色を変更する

今回は試しに子テーマを、親テーマと違う背景色に変更してみます。

style.css にすでに書きこんである部分はそのまま変更せずに、その後に独自のスタイルシートを書き込みます。

/*
Theme Name:私のTwenty Fourteen
Template:twentyfourteen
*/

@import url('../twentyfourteen/style.css');

::selection,
.search-toggle:before,
*{
	color: #444!important;
}

.primary-navigation li:hover > a,
.primary-navigation li.focus > a,
::selection,
.search-toggle,
.search-toggle:hover,
.search-box,
.site-info a,
.site-footer,
.grid .featured-content .entry-header,
#featured-content,
#masthead,
.content-sidebar,
#secondary,
#page:before{
	background: #fff;
	border: none;
}

Twenty Fourteenの背景色の変更はWordPress › フォーラム » Twenty Fourteen サイドバーの背景変更を参考にしました。

サーバーの自作「子テーマ」のディレクトリ「watashi-no_Twenty14」にある style.css を上記のように変更したら、もう一度サイトを表示してみます。無事に色が変わっていれば成功です。

wp8

スタイルシートを変更したい場合、今後は「親テーマ」をいじらずに、「子テーマ」の style.css だけを変更するようにします。そうすれば「親テーマ」が更新されても影響される(上書きされる)心配はありません。

スタイルシート以外の変更

スタイルシート以外を変更する場合は、その変更したいファイルを「子テーマ」にコピーして、そのコピーしたファイルを変更します。

例えば、header.php を変更したい時は、header.php だけを親テーマから子テーマへコピーして、それを書き替えます。

子テーマと親テーマに同じ名前のファイルがある時は、子テーマのファイルが適用され、子テーマにないファイルは全て、親テーマのものが読み込まれます。

style.css と同じように親テーマが更新されても、子テーマのファイルは上書きされてしまうことなく残っていますので、カスタマイズした部分は常に適用されます。

WordPressで勝手にaddslashesされてバックスラッシュがついてしまう件

この記事を書いた際のWordPressのバージョンは3.9.1です。

バージョン5.4.0以前のPHPでは、magic_quotesがONに設定されていると、POSTやGETで送ったデータの中にある全ての ' (シングルクオート)、 " (ダブルクオート)、 \ (バックスラッシュ)、NULL文字の4つに自動的にバックスラッシュがついてエスケープされます。

バージョン5.4.0から削除されたんですが、まだそれ以前のPHPは多いです。

そこで、get_magic_quotes_gpc関数で、magic_quotesがONかOFFか判別して、ONの場合にはstripslashesを使ってバックスラッシュを削除します。

if(get_magic_quotes_gpc()){
    $hoge = stripslashes($_POST['hoge']);
}else{
    $hoge = $_POST['hoge'];
}

ところが、今作っているプラグインで、この作業をしてもPOSTで送ったtextareaのデータにバックスラッシュがついたまま消えません。しかも、テスト環境のmagic_quotesはOFFなのにです。

調べたところ、「POST送信時にバックスラッシュが付加される現象: wordpressメモ」というページを見つけました。

結論を書くと、WordPressを使っているとmagic_quotesの設定は関係なく、$_GET,$_POST,$_COOKIE,$_SERVERの4つは、必ずaddslashesされてバックスラッシュがつきます。

詳細は「POST送信時にバックスラッシュが付加される現象: wordpressメモ」に書いてあるとおりなんですが、wp-includes/load.phpに、wp_magic_quotesという関数があります。

ここで、上記のget_magic_quotes_gpc関数で、magic_quotesが有効になっているか調べ、ONの場合にはstripslashesを使ってバックスラッシュを削除しています。

そして、それで終わらずに、add_magic_quotesという関数を実行しています。

function wp_magic_quotes() {
	// If already slashed, strip.
	if ( get_magic_quotes_gpc() ) {
		$_GET    = stripslashes_deep( $_GET    );
		$_POST   = stripslashes_deep( $_POST   );
		$_COOKIE = stripslashes_deep( $_COOKIE );
	}

	// Escape with wpdb.
	$_GET    = add_magic_quotes( $_GET    );
	$_POST   = add_magic_quotes( $_POST   );
	$_COOKIE = add_magic_quotes( $_COOKIE );
	$_SERVER = add_magic_quotes( $_SERVER );

	// Force REQUEST to be GET + POST.
	$_REQUEST = array_merge( $_GET, $_POST );
}

この、add_magic_quotesは何かというとWordpressの独自関数で、実体はwp-includes/functions.phpにあります。

この中で、addslashes関数を使って、$_GET,$_POST,$_COOKIE,$_SERVERの全てのデータをエスケープしています。

function add_magic_quotes( $array ) {
	foreach ( (array) $array as $k => $v ) {
		if ( is_array( $v ) ) {
			$array[$k] = add_magic_quotes( $v );
		} else {
			$array[$k] = addslashes( $v );
		}
	}
	return $array;
}

wp_magic_quotes関数はどこで呼び出されているかというと、wp-settings.phpの242行目です。(バージョン3.9.1の場合)

なのでWordPressを使う場合は、magic_quotesの設定に関係なく、stripslashesが必要でした。

これがわかるまで随分ハマりました。「POST送信時にバックスラッシュが付加される現象: wordpressメモ」を書かれた方には感謝です。

.htaccess の Allow と Deny 〜アクセスの許可と制限〜

ロリポップのサーバーには不正なログインを試みるアクセスと判断された場合に、自動で制限をかける仕組みがあるそうです。

自分自身ではロリポップは借りていないんですが、不正アクセスのためにログインしようとしているとみなされたIPアドレスは自動でアクセス拒否にされる模様。

どうやってアクセス拒否にするかというと .htaccess を書き換えて行うようです。

それが自動で行われるのですが、なんらかの理由でその .htaccess が正しく書き換えられないとアクセスできなくなります。

ただし、一般公開ページを閲覧しようとして403エラー(アクセス拒否)となる場合は、必ずしも.htaccessが原因とは限らないようです。

ロリポップの場合 .htaccess でアクセス制限をかけるのはログインページであって不正アクセス防止のためなので、一般公開ページに制限をかける理由はありません。

先日、ロリポップを借りている方が、管理ページからスタイルシートを編集しようとしたところ、管理画面も一般公開ページもすべて403エラーでアクセスできなくなったそうですが、その時はパーミッションの設定で直ったそうです。

その方はロリポップに問い合わせをしたところ、次の返事が来て設定を修正しました。なぜパーミッションが変更されたのかはわかりませんが、そういうケースもあるようです。

WordPressをインストールされているフォルダのパーミッション(属性)が「770」で設定されており フォルダ内のデータを呼び出すことができない状態でございました。そのため、サイトが403エラーとなっております。

パーミッションの変更は次のページに説明があります。
サイト改ざんへの対策をお願いいたします – ロリポップ!レンタルサーバー

下の表は上記サイトより引用しました。

HTML・画像ファイル 604 rw—-r–
CGIの実行ファイル 700 rwx——
CGIのデータファイル 600 rw——-
.htaccessファイル 604 rw—-r–
ディレクトリ 705 rwx—r-x

.htaccess によるアクセス制限

.htaccess を見て次の通り書きこまれていたら、それがアクセス制限の記述部分です。

Order deny,allow
Deny  from all
Allow from IPADDRESS

赤字の IPADDRESS の部分は 123.456.789.100 のように 4組の数字を .(ドット)で区切って書いてあります。ここに指定されたIPアドレスからのみアクセスが許可され、それ以外は全て拒否されます。

場合によっては Allow from IPADDRESS の行は複数あるかもしれません。その場合、許可されたIPアドレスが複数あるという事です。

Order deny,allow
Deny  from all
Allow from IPADDRESS
Allow from IPADDRESS
Allow from IPADDRESS

そのIPアドレスに自分のアドレスがない場合、アクセスは出来ません。解決するためには、これを自分のIPアドレスに書き換えなければいけません。

でも、自分のIPアドレスがわからない!

自分のIPアドレスがわからなければ、それを指定して書き換えることができません。それでもログインしたい時は、一時的にすべてのIPアドレスからのアクセスを許可する設定をします。

具体的には、次のようにします。

  • Allow from IPADDRESS の次に Allow from all という行を追記する

Allow from all というのは、全てのIPアドレスを許可するという意味です。Allow from IPADDRESS の行が複数ある場合は、その後に追記します。

修正前
Order deny,allow
Deny  from all
Allow from IPADDRESS
修正後
Order deny,allow
Deny  from all
Allow from IPADDRESS
Allow from all

これで、全てのIPアドレスからのアクセスが許可されます。

ただし、ログインページは誰でもアクセスできると危険なので、どうしても緊急にログインしたい場合を除き、許可したIPアドレス以外はアクセスできないように、自分のアドレスを調べて訂正しておきましょう。

コメントアウト

上の書き方ですべてのアクセスを許可しますが、この書き方は無駄があります。それは、Allow from IPADDRESS の次に Allow from all としているため、最初の IPADDRESS は2回許可されているという事になります。言い方を変えると Allow from all には、上の行の IPADDRESS も含むので、上の行は冗長だという事です。

ですから、上の行 Allow from IPADDRESS は消してしまって構いません。

ただ、消してしまって後から困らないか不安!という場合には、消さずに無効にする方法があります。それには次のように、行の最初に半角で # (シャープ)を書き加えます。これをコメントアウトと言います。

Order deny,allow
Deny  from all
#Allow from IPADDRESS
Allow from all

こうすると # の後は行末まで説明書きという意味になり、設定から無視されます。例えば次の場合、赤字の部分は説明で、消しても設定には影響しません。見た時にわかりやすくなるようにつけているだけです。

# BEGIN Lolipop
<Files ~ "wp-login.php">
Order deny,allow
Deny  from all
Allow from 123.456.789.101
</Files>
# END Lolipop

<Files ~ “wp-login.php”> と </Files> の行は後で説明します。

Order deny,allow と Order allow,deny

先程の .htaccess の設定は次の意味です。

Order deny,allow

Order deny,allow
順序として、許可しないアドレスを先に指定して、次に許可するアドレスを指定するという断り(宣言)。
Deny from all
すべてのIPアドレスを許可しない。
Allow from 123.456.789.101
IPアドレスが123.456.789.101の場合だけ、アクセスを許可する。

不許可のアドレスを先に決め、その後に例外として許可するアドレスを1行ずつ列挙します。

例えば、この世にあるIPアドレスが次の10個だけだとします。

  • 123.456.789.101
  • 123.456.789.102
  • 123.456.789.103
  • 123.456.789.104
  • 123.456.789.105
  • 123.456.789.106
  • 123.456.789.107
  • 123.456.789.108
  • 123.456.789.109
  • 123.456.789.110

この中で、123.456.789.101だけを許可したい場合は、まず Order deny,allow で指定する順序を宣言します。これは、不許可が先、許可が後という意味です。

その後 Deny from all で全てのIPアドレスを不許可に指定します。この時点ですべてのIPアドレスからのアクセスが遮断されます。

そして Allow from 123.456.789.101 で、IPアドレスが123.456.789.101のものだけ、特別にアクセスを許可します。

では、この書き方でIPアドレスが123.456.789.110以外の9個のアドレスを許可するにはどう書けばいいでしょうか。次のようにすればOKです。

Order deny,allow
Deny  from all
Allow from 123.456.789.101
Allow from 123.456.789.102
Allow from 123.456.789.103
Allow from 123.456.789.104
Allow from 123.456.789.105
Allow from 123.456.789.106
Allow from 123.456.789.107
Allow from 123.456.789.108
Allow from 123.456.789.109

これで、指定していない123.456.789.110は許可されないので残りの9つのアドレスからはアクセスできます。

IPアドレスがこの世に10個しかない場合は簡単です。では1万個のIPアドレスから9999個を許可して1個だけ拒否するにはどうすればいいでしょう。Allow from IPADDRESS を9999行書けばいいだけなので簡単です。でも、ふざけるなです。

そんな場合は、指定する順序を逆にします。

Order allow,deny

Order allow,deny
順序として、許可するアドレスを先に指定して、次に許可しないアドレスを指定するという断り(宣言)。
Allow from all
すべてのIPアドレスを許可する。
Deny from 123.456.789.101
IPアドレスが123.456.789.110の場合だけ、アクセスを許可しない。

許可するアドレスを先に決め、その後に例外として許可しないアドレスを1行ずつ列挙します。

123.456.789.110以外のアドレスを許可するには次のように書けます。

Order allow,deny
Allow from all
Deny  from 123.456.789.110

この世に存在するIPアドレスが10個しかないのなら、次のどちらでも同じ意味になります。

Order deny,allow
Deny  from all
Allow from 123.456.789.101
Allow from 123.456.789.102
Allow from 123.456.789.103
Allow from 123.456.789.104
Allow from 123.456.789.105
Allow from 123.456.789.106
Allow from 123.456.789.107
Allow from 123.456.789.108
Allow from 123.456.789.109
Order allow,deny
Allow from all
Deny  from 123.456.789.110

指定のページだけアクセス制限をかける方法

ここまでで、IPアドレスを制限する設定は出来ました。ただ、このままだとサイトの全てのページが同じように制限されてしまいます。

一般公開しているページは、誰でも見て構わない。ただ、ログインページだけには制限をかけたい。そういう場合は、次のようにアクセス制限の設定を <Files ~ “FILENAME”></Files> で囲みます。

WordPressのログインページ wp-login.php だけ、制限したい場合は、wp-login.php のあるディレクトリで .htaccess に次のように記述します。

<Files ~ "wp-login.php">
Order deny,allow
Deny  from all
Allow from 123.456.789.100
</Files>

こうすると <Files ~ “wp-login.php“> から </Files> までは、wp-login.php のみに適用されます。

参考までに .htaccess に誰もアクセスできないようにするには下のように書きます。これは . (ドット)で始まるファイルには全てのアクセスを拒否するという意味です。

<Files ~ "^\.">
deny from all
</Files>

バリューサーバーで python の easy_install を使う

バリューサーバー で mysql-python を使いたかったので、easy_install を使ってインストールしました。

以下は、valueserver.jp に SSH でログインして実行しています。

使いたいパッケージが入っているか調べる

前に書いた記事「python版phpinfo」の pyinfo.py をインストールして見てみます。

pyinfo.pyの導入

$ wget http://www.twoevils.org/files/pyinfo.txt
--2014-06-04 09:42:53--  http://www.twoevils.org/files/pyinfo.txt
www.twoevils.org をDNSに問いあわせています... 204.246.122.18
www.twoevils.org|204.246.122.18|:80 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 11715 (11K) [text/plain]
`pyinfo.txt' に保存中

100%[===================================>] 11,715      --.-K/s 時間 0s      

2014-06-04 09:42:54 (78.6 MB/s) - `pyinfo.txt' へ保存完了 [11715/11715]

$ mv pyinfo.txt pyinfo.py
$ chmod 755 pyinfo.py

ブラウザで pyinfo.pyに アクセスして、表示してみると MySQL-Python は入っていませんでした。

pyinfo.pyの表示結果

そこで、独自にインストールします。

以下の作業は「さくらのレンタルサーバに Python モジュールをインストール」というページに書いてあることを、そのままバリューサーバーで実行しました。

easy_install の確認

バリューサーバーには既に easy_install は入っています。

$ which easy_install
/usr/bin/easy_install

ただ、そのまま easy_install コマンドを実行しても、システム標準の場所にインストールしようとして失敗します。

そこで「さくらのレンタルサーバに Python モジュールをインストール」に書いてある通り、あらかじめ設定しておきます。

*上記のサイトには、ローカルにインストールするオプションや、ローカルに入れたモジュールを使う方法も書いてあります。

site.USER_SITE の確認

Python を起動して、ユーザー・サイト用のディレクトリがどこに設定されているかを調べます。

$ python
Python 2.6.6 (r266:84292, Nov 22 2013, 12:16:22) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import site
>>> site.USER_SITE
'/virtual/xxxxx/.local/lib/python2.6/site-packages'
>>>

設定されているのは ‘/virtual/xxxxx/.local/lib/python2.6/site-packages’ ですが、そのディレクトリは用意されていませんので、自分で作る必要があります。ちなみに、/virtual/xxxxx が自分のホームディレクトリになります。

$ mkdir -p ~/.local/lib/python2.6

.pydistutils.cfg の作成

.pydistutils.cfg を作ることで easy_install に –prefix オプションをつける必要はなくなります。また、sys.path に PATH の追加もしないで済むので楽になります。

$ echo '[install]' > ~/.pydistutils.cfg
$ echo 'user=1' >> ~/.pydistutils.cfg
$ cat ~/.pydistutils.cfg 
[install]
user=1

easy_install を使ってみる

後は、普通に easy_install コマンドでモジュールをインストールできます。

MySQL-Python をインストールします。

$ easy_install mysql-python
Searching for mysql-python
Reading http://pypi.python.org/simple/mysql-python/
Best match: MySQL-python 1.2.5
Downloading https://pypi.python.org/packages/source/M/MySQL-python/MySQL-python-1.2.5.zip#md5=654f75b302db6ed8dc5a898c625e030c
Processing MySQL-python-1.2.5.zip
Running MySQL-python-1.2.5/setup.py -q bdist_egg --dist-dir /tmp/easy_install-UDQRse/MySQL-python-1.2.5/egg-dist-tmp-yYD_3Q
/usr/include/mysql/my_config.h:14 から include されたファイル中,
                 _mysql.c:44 から:
/usr/include/mysql/my_config_x86_64.h:422:1: 警告: "HAVE_WCSCOLL" が再定義されました
/usr/include/python2.6/pyconfig.h:6 から include されたファイル中,
                 /usr/include/python2.6/Python.h:8 から,
                 _mysql.c:29 から:
/usr/include/python2.6/pyconfig-64.h:808:1: 警告: ここが以前の宣言がある位置です
zip_safe flag not set; analyzing archive contents...
Adding MySQL-python 1.2.5 to easy-install.pth file

Installed /virtual/xxxxx/.local/lib/python2.6/site-packages/MySQL_python-1.2.5-py2.6-linux-x86_64.egg
Processing dependencies for mysql-python
Finished processing dependencies for mysql-python

先ほどの、pyinfo.py にブラウザでアクセスしてみると MySQL (MySQL-Python) が enabled に変わっています。

pyinfo.pyの表示結果

サーバーの細かな設定が誰でも読めてしまうのは、セキュリティの心配があるので、当サイトでは確認終了後に pyinfo.py は削除しました。

$ rm pyinfo.py

極悪?Windows XP はダメで危険なOSなのか?

Windows XP

これは、永江一石さんの書かれた記事「XP使い続けるような会社とは絶対に仕事しないし、客にもなりたくない」に触発されて書きました。

永江さんの記事の趣旨に異論はないんです。ないんですが、読んでて感じた違和感がありました。まるで Windows XP が極悪人みたいです。

「危険なXPを使い続けるのは、無知と言うより自分勝手きわまりないと思う」とか「XPからのメールはマジ、全拒否したい」とか。

Windows XP って長期間シェアのトップを君臨し続けたOSがそんなに危険で、悪いOSなんでしょうか。

新しい機能にこそ穴は出やすい

新しいOSがいいのかといえば、必ずしもそうとは言い切れないと思います。

何故かというと、新しい機能にこそ穴は出やすいから。

大勢に使われ、何年も稼動しているシステムならそれだけ、バグは発見されつくされていて、穴がなくなっている可能性があります。それに比べ、テスト回数が少なくて、稼働実績が少ないものほど、見つかっていない穴が潜在している可能性は高くなります。

例として、F1マシンで考えてみます。ストーブシーズンに、昨シーズンのマシンとシェイクダウン中の、来シーズンのマシンを比べたらどうなるでしょう。

速いのは新しいマシンかもしれません。でもトラブルが出やすいのも新しいマシンじゃないでしょうか。そのトラブルをなくすためのテストがシェイクダウンなんだから。

シェイクダウンの初期に2台を比べれば、昨シーズンの1年間、実戦というテストを重ね続けた、古いマシンの方が安定しているんじゃないでしょうか。

ただ、もしも「好きな方に乗っていいよ」と言われたら、新しいマシンに乗りたいですけどね。

枯れたOSは安定している

インターネットの黎明期、今ではサーバー用OSで主流になりつつある Linux が出てくるまで、サーバー用途にはBSD系のOS、中でも FreeBSD が主流でした。

Linux が人気を得はじめた頃、多くの FreeBSD ユーザーが主張していたのが、こういう内容です。

FreeBSD はもう何年も止まらずに稼動しているサーバーがいくつもあって、信頼できる。

つまり、新しい Linux よりも、古くて実績のある FreeBSD の方が信頼できる。という主張です。

確かに、せっかく安定稼働していたのに、バージョンアップしたらおかしくなったという例はあります。

だから、この主張自体は正しいと思うんです。新人よりもベテランの方が信頼できる。

今のシステムに困っていないなら、いじるなという意見もあります。

発展するためには育てること

でも、その理屈を企業に当てはめた場合、疑問が出てきます。定年間近の社員しかいない企業に発展性はあるでしょうか。

発展するためには、信頼のおけない新人を、信頼できるようになるまで育てるしかないです。

現在では Linux は充分に発展し、安定しているし信頼されています。

考えてみれば、FreeBSD が何年も止まらずに稼動していたのは、世に出て何年も経っていたからであって、出てきたばかりの Linux が長期間稼動していなかったのは当たり前の話だったんじゃないのかな。

Windows XP はダメなのか

Windows XP のサポートがまもなく終了するけど、新しい Windows の方が安定しているのでしょうか。

さっき書いたように、新しい機能がある新OSの方が見つかっていない穴は多いかもしれません。

10年以上にわたって大勢にテストされ続けた XP が、Windows8 よりも安定している可能性はあります。

もしも、新機能にバグがあった場合どうなるでしょう。Windows8 の新機能にバグがあった場合、攻撃の被害に遭うのは Windows8 であって、XP は被害を受けません。

そういう事態が発生する可能性もありますね。

むしろ、セキュリティ・アップデートをしないなら、Windows8 の方が、より危険かもしれません。

それなら XP を使い続けても大丈夫なのでしょうか。重要なのはここです。

問題なのは修正されないこと

OSが古いこと自体には、何も問題はありません。問題なのは修正されないことです。

修正されないという事は、発展しないという事ですから。

セキュリティホールが見つかった場合、パッチが配布されて、Windows8 の穴は塞がれます。穴がひとつ塞がって Windows8 の信頼性は上昇します。

では、もしも Windows XP にまだ発見されていないセキュリティホールが見つかった場合はどうなるでしょう。

セキュリティパッチは配布されないので、被害に遭い続けることになります。ここが、重要です。

OSが古いことが悪いのではなくて、修正されない事が悪いんです。

「XPくんは悪くないんだからね!」

信用を得るための投資

検切れの車を運転して事故を起こせば、ただの事故より問題があります。もしも、車検切れの車を運用してる企業があれば信用失墜でしょう。同じ事はパソコンにもいえます。企業にとっては、車もパソコンも同じ道具ですから。

重要なのは、4月になれば Windows XP は車検の切れた車と同じだということ。車検の切れた車は点検に出さないといけないし、点検できないのであれば買い替えるしかないです。予算かかって苦しくなりますが。

そして、新しい機能が必要ならバージョンを上げるしかないという事があります。古いバージョンの機能だけで足りるならバージョンを上げる必要はないのかもしれません。機能が少ない方が安定稼働出来るかもしれません。

でも、顧客が望むサービスに対応できるだろうかという疑問があります。日に日に進歩する技術の中で、顧客満足度を考えた場合、古い機能だけで対応できるでしょうか。お客は、古いF1と新しいF1のどちらに乗りたいでしょうか。

ということで、定年間近の社員しかいない企業に発展性はないように、新しいパソコンにも投資をしないと発展しないし、信用されないのかもしれないな。なんて思ったのでした。

そういえば、Windows XP が出たばかりの頃、生まれて初めてパソコンを買うから、一緒に行って教えてと頼んだYさんは、アキバでノートのVAIOを抱きしめながら「絶対大事にする!一生このVAIOを使い続ける!」と感激しながら言っていたけど、まだ使っているのかな?