‘WordPress’ カテゴリーのアーカイブ

いつの間にかWordPressのPing制御プラグインcbnet Ping Optimizerが動かなくなっていた件

WordPress | by 管理者
3月 03日 2013 年

Linuxで構築したウェブサーバーのアパッチのエラーログを見ていたら、何やらおかしなログが記録されていました。

このログをみるとPingに関するエラーのようです。

[Mon Feb 25 13:47:33 2013] [error] [client 127.0.0.1] File does not exist: /var/www/html/pinger
[Mon Feb 25 13:47:33 2013] [error] [client 127.0.0.1] File does not exist: /var/www/html/pinger
[Mon Feb 25 13:49:13 2013] [error] [client 127.0.0.1] File does not exist: /var/www/html/pinger
[Mon Feb 25 13:49:13 2013] [error] [client 127.0.0.1] File does not exist: /var/www/html/pinger

 

Pingとは、ブログ記事を更新すると、すぐに検索エンジンにインデックスして欲しいので、「新しい記事を書いたから、見に来てね。」って検索エンジンにお知らせする機能のことですが、一度書いた記事が完璧で2度と更新しないのら問題ないですが、私みたいに誤字脱字・間違った内容が有るとすぐに修正します。

そしてその都度、「記事を更新したから見に来てね。」ってPingを打つと、検索エンジンから「何度も何度もPingを打つんじゃねー\(*`∧´)/ ムッキー!!」ってスパム扱いされる可能性があり、同じ記事に対する2回目以降の更新では通常Pingを打ちません。

そこで私のサイトではPingを自動制御するプラグインとしてcbnet Ping Optimizerを入れていたのですが、それの設定画面を見ると設定画面のはずなのに、何やらこのプラグインが必要なくなったってことを説明する文章が表示されてしまいました。

 

作者のサイトを見ると、cbnet Ping OptimizerのVersion: 3.0でCompatible to WP: 3.5.1って出ているので、Wordpressの3.51で使えそうな感じがしますが、cbnet Ping Optimizerをググってみると、Wordpress3.5以上では使えなくなったみたいです。

ってことは、昨年の12月にWordpressのバージョンアップがあってから、まともにPingを制御できていなかったことになります。

さらにネットで調べると、cbnet Ping Optimizerを以前のバージョンに戻して使っている人もいましたが、私はこのプラグインを無効にして、別のPingを制御するプラグインWordpress ping Optimizerを入れてみました。

すると、cbnet Ping Optimizerの設定情報とログを引き継いでくれるみたいです。・・・楽ちん楽ちん!

そこで、このログを見ると昨年12月19日を最後に、3月3日までPingが制御されていなかったことが分かります。

つまりこの2ヶ月間、記事更新のたびにガンガンPingを打っていたことになる訳です。

恐ろしい。

 

Wordpress ping Optimizer

WordPressのBackWpUpによる肥大化するバックアップファイルの対処方法(ついに300MB超えてしまった。)

WordPress | by 管理者
1月 30日 2013 年

WordPressのバックアップファイルの大きさをご存じですか?

私はブログをWordPressで書いています。

そのWordPressの環境をBackWpUpで丸ごとバックアップしていますが、バックアップファイルの大きさが、ついに300MBを超えてしまいました。

写真を沢山使ってブログを更新すると、どんどんとWordPressの環境が肥大化していきます。・・・ある意味仕方ないですね。

バックアップファイルの大きさ

 

 

BackWpUpはWordpressのバックアップファイルを1つのZIP形式のファイルに圧縮したあと、クラウドのSugarSyncにファイル転送して万一サーバー環境に支障があってもバックアップファイルからリストア(復元)することで安全性を確保しています。

ところで、BackWpUpのログを見ると、300MBのファイルに対して、バックアップ全体で23分かかり、中でもSugarSyncへのファイル転送で17分かかっていることが分かりました。

  • 2013/01/29 03:08.21: Archive size is 297.34 MB
  • 2013/01/29 03:08.26: Upload to SugarSync now started...
  • 2013/01/29 03:25.42: Job done in 1426 sec.

 

仮に2012年の1年間だけ限定してバックアップすると、バックアップファイルの大きさが168MBもあり、このままバックアップ方法を変えなければ来年の今頃は470MB、3年後には800MBに膨れ上がり、ある閾値を超えたところでバックアップできなくなったり、リストアできなくなったりします(するはずです)。

それが、明日かもしれないし、1年後かもしれません。

そのため、バックアップファイルの大きさを知っていた方が良いと思います。

 

バックアップやリストアが出来なくなる理由はいろいろ考えられますが、SugarSyncが大きくなり過ぎたファイルのアップロードを拒否する場合、転送時間が長くなり過ぎてネットワークがタイムアウトする場合、サーバを管理しているレンタルサーバ会社がネットワーク負荷を警戒して遮断する場合などがあります。

そこで、バックアップやリストアで身動きが取れなくなる前に、その対策を行うことにしました。

 

 

対策の概要

大きくなりすぎるバックアップファイルを①2010年~2012年までの過去の全データのバックアップ と ②2013年以降のバックアップに分割してバックアップすることにします。

 

①の過去のバックアップファイルは300MB程度の大きさになりますが、現在この大きさのファイルをバックアップ出来ているので今後も大丈夫だと思われます。

また過去のデータなので今後ファイルの大きさが増えることはありません。

バックアップは週1回実行する。・・・過去のデータなので修正しないと思うけど、絶対修正しないとは言い切れないので、このくらいの低頻度でバックアップします。

 

②のバックアップファイルは現状で35MB程度あり、ブログを更新するとこのバックアップファイルが大きくなっていきます。

バックアップは毎日実行する。・・・更新頻度が高いので、毎日バックアップを実行します。

 

 

バックアップ方法

下の画面が、バックアップジョブの一覧です。

1番上のジョブは今まで実施していた全データのバックアップジョブです。今後これを使う予定はありません。

2番目のジョブは①2010年~2012年までの過去の全データのバックアップジョブです。(データの容量が増えることはありません。)

3番目のジョブは②2013年以降のデータのバックアップジョブです。(データの容量が増えます。)

バックアップジョブ

 

 

①のバックアップジョブの詳細画面です。

どうもピンとこないのですが、Blog Uploadsでは、Exclude(除外)を指定します。

そのため、2010年・2011年・2012年のデータのバックアップを取得したいときは、除外する2013年をチェックします。

バックアップは毎週(Weekly)月曜日の2時から開始します。

※ ①で取得したバックアップファイルを「2010-2012_blog_2013-01-30_00-00-15.zip」として説明します。

2010-2012年のバックアップ

 

 

②のバックアップジョブの詳細画面です。

同様にBlog Uploadsで、Exclude(除外)を指定します。

そのため、2013年以降のデータのバックアップを取得したいときは、除外する2010年・2011年・2012年をチェックします。

バックアップは毎日(Daily)月曜日の3時から開始しします。

※ ②で取得したバックアップファイルを「2013_blog_2013-01-29-23-55-14.zip」として説明します。

2013年以降のバックアップ

 

これで火曜日~日曜日まで午前3時に毎日バックアップジョブが開始され、たった3分程度で終了します。そして月曜日だけ全データのバックアップが開始されますが、これも午前2時と午前3時の2回に分けて行われるので、サーバやネットワークにかかる負荷が分散されます。

 

 

 

実際にリストアしてみると・・・

いきなり本番環境でリストアのテストをしてはいけません。

必ず、予備のテスト環境を用意して、リストアが出来ることを確認をしてから本番環境にリストアしてください。

 

リストア方法

ここでリストア方法を2つに分けます。

① バックアップファイルの中身をftpやWinSCPソフトを使って公開サーバのWordpressのファイルに上書きできる場合(ほとんどの人がこちらだと思います。)

Windowsパソコンで「2010-2012_blog_2013-01-30_00-00-15.zip」と「2013_blog_2013-01-29-23-55-14.zip」を解凍して、古いデータ「2010-2012_blog_2013-01-30_00-00-15」に新しいデータ「2013_blog_2013-01-29-23-55-14」を上書きして1つに纏めます。

纏めたファイルは公開サーバのWordpressの階層構造と同じものなので、公開サーバに上記ソフトでファイル転送して上書きします。

※ 古いデータを公開サーバに転送してから新しいデータを転送して上書きしても一緒ですが、トラフィックが無駄なので、パソコンで1つに纏めてから転送する方法をお勧めします。

この時点で、BackWpUpのToolsを選択するとRestoreボタンが表示されるので、このボタンを押してデータベースを復元します。

Restoreボタンを押す

これでリストア作業はお終いです。

問題なくリストア出来ていることを確認します。

 

 

② バックアップファイルの中身をftpやWinSCPソフトを使って公開サーバのWordpressのファイルに上書きできない場合。(私の場合はこちらです。)

Windowsパソコンでバックアップしたデータの「2010-2012_blog_2013-01-30_00-00-15.zip」と「2013_blog_2013-01-29-23-55-14.zip」からWordpress.sqlを取り出します。

この時点で、ファイルが4つあります。

  • 2010-2012_blog_2013-01-30_00-00-15.zip と これから取り出したwordpress.sql
  • 2013_blog_2013-01-29-23-55-14.zip  と これから取り出したwordpress.sql
  • 上記wordpress.sqlは同じものなので、どちらか一方あれば大丈夫です。

 

これらの3つのファイルを公開サーバのwordpressの一番上の階層(ルート)にftpやWinSCPソフトを使ってファイル転送します。

この時点で、BackWpUpのToolsを選択するとRestoreボタンが表示されるので、このボタンを押してデータベースを復元します。

Restoreボタンを押す

 

 

次にサーバにリモートログインし、「2010-2012_blog_2013-01-30_00-00-15.zip」 と 「2013_blog_2013-01-29-23-55-14.zip」を解凍して元の環境に上書きして画像データをリストアします。

下の画面は、管理者(root)でログインし、unzipコマンドで2010-2012_blog_2013-01-30_00-00-15.zip(古いデータ)を解凍して上書きするところです。

続いて、同様に 2013_blog_2013-01-29-23-55-14.zip(新しいデータ)も解凍して上書きします。

基本的に古いデータを解凍して上書きしてから、新しいデータを解凍して上書きします。

# unzip -o 2010-2012_blog_2013-01-30_00-00-15.zip

# unzip -o 2013_blog_2013-01-29-23-55-14.zip

サーバで解凍して上書き

 

 

リストアしたファイルやフォルダの所有者が管理者(root)のままなので、apacheに変更します。

これは、自分のいる位置(カレント)を1つ上の階層に上げて、chown コマンドを実行します。

# cd ..

# chown -R apache:apache wordpress

所有者の変更

 

 

これでリストア作業はお終いです。

問題なくリストア出来ていることを確認します。

 

*** 2013年2月5日 追加 ***

スケジュールどおりsugarsyncへの自動バックアップ、バックアップしたファイルのPCとの同期も問題なしです。

バックアップしたファイル

 

バージョンアップに注意、WordPress3.5のバグ?ウェブマスターツールでクロール未完了のエラー発生!

WordPress | by 管理者
12月 16日 2012 年

2012年12月13日にWordPress3.5にバージョンアップしたところ、Googleウェブマスターツールでクロールエラーが発生しました。

今回のアップデートで、画像の扱いが大きく変わったようですが、どうもそれに伴うエラーのようです。

Googleウェブマスターツールを使っている方は、ダッシュボードからクロールエラーの項目を見てください。

私の場合は、「8クロールを完了できませんでした」と出ています。

そしてエラーページのURLとレスポンスコードは以下のようになっていました。

http://it.trend-ai.com/?feed=rss2&p=○○○○   レスポンスコード301

 

そしてこのURLをクリックすると以下のエラーが出ます。

エラー画面

 

さらにこのURLの○○○○を調査すると、このIDは本来ページのIDなのに画像のURL/wordpress/?attachment_id=○○○○のIDになっており、転送設定が上手く出来ない原因になっているようです。

12月11日のバックアップがあるので、そこからWordPressのバージョンを戻すのが良いか、それともデータをこのまましてWordPressのバージョンだけを戻す方が良いか?

ちょっと考え中です。

 

*** 2012年12月17日 修正 ***

解決偏

いろいろと試したところ、画像を取り込むときにに、画面右下のリンク先が「添付ファイルのページ」になっていると、画像ファイルをドラッグアンドロップした時点でこのエラーが発生するみたいです。

メディアファイルを選択

 

一度でもメディアライブラリに取り込むと、画像を削除するまでこのエラーは無くならないので、このエラーが出たら取り込んである画像を削除してから、リンク先を「メディアファイル」に選択しなおして画像を取り込みます。

この作業をしてからGoogleウェブマスターツールで該当URLをクリックしても、「ページの自動転送設定が正しくありません。」エラーが出なくなったので、解決したみたいです。

エラーゼロ件

 

ブログのエラーチェックしてますか?

WordPress | by 管理者
10月 22日 2012 年

10月の頭にサイトの目に見えるところのリニューアルを行いましたが、それ以降過去に公開したブログの記事の見直しをしています。

過去の記事の内容を修整しているの?って思いがちですが、違います。

文法的にHTMLが違っているところや意図しないタグが使われているところの修正をしています。

 

理由は、ホームページを作り直したとき、W3Cのチェックツール[Markup Validation Service]を使ってHTMLの公正を行いましたが、このツールを使って既に公開済みのブログをチェックしたら惨憺たる結果になったからです。

 

エラーがあるときの画面

w3cエラー画面

 

エラーが無いときの画面

w3c正常画面

 

 

特にひどかっったのは、WordPressのテーマを独自に編集した部分やプラグインの設定でタグと日本語を組み合わせて使った部分です。

もともとXHTML1.0で記述されているところにHTML4.01の記述で追加したものだから記述形式がぐちゃぐちゃ、そして文法エラー。

文法エラーにならないけど、記述がおかしいところも幾つかありました。

普段、WordPressで記事を書く時はビジュアルエディタを使っていますが、これだと使っているタグが見えません。

 

ビジュアルエディタ

ビジュアルエディタ

 

HTMLエディタ

HTMLエディタ

※ 同じブログの記事をビジュアルエディタとHTMLエディタで開いたときの表示例

 

HTMLエディタに切り替えると、何も文字を挟まないで<strong></strong>の記述があったり、<strong><strong>文字</strong></strong>のように二重に文字を囲んでいたり、<h1>の記述が2こあったり、プラグインを使って画像を貼り付けた時に、貼り付けを失敗した画像の残骸(コードが残っているが画面に表示されない怪しい状態)が残っている等のおかしな記述がボロボロと見つかりました。

 

ブラウザはIEとFirefoxとchromeで動作確認しており、問題なく表示されるので今まで問題ないと思っていましたが、IEとFirefoxとchrome等のブラウザは、使い勝手が悪いとユーザーに敬遠されてしまうため、多少文法的におかしなところがあっても問題なく表示してしまうようです。

しかし、このような誤りのある記述をgoogleはどのように解釈するのでしょうか?

文字を二重にstrongでかこったり、hタグとstrongの組み合わせは解釈しないならまだ良いですが、変な方向に解釈される可能性があるので、かなり地味な作業ですが全てのブログの記事を見直しています。

ブラウザに問題なく表示できれば良い」という意見もありますが、検索エンジンに上位表示されて初めてユーザーに見てもらえるので、googleに誤解なく解釈してもらえるように記述することは大切だと思います。

 

***   2012/10/24  追加  ***

全てのブログ記事のHTML文法エラー及び怪しい記述の修正を終わりました。

一部、珈琲焙煎機の動画の記述のみ対処方法が分からなくてエラーが残ってしまいましたが、それ以外はW3Cのエラーチェックをクリアしました。

・・・もしかしたら、どこか忘れている記事があるかも!?

全てのソースに目を通して、一番酷かったのは、原発事故のときのニュースの引用部分でした。

HTMLソースを確認しないで元記事からそのまま貼り付けているものだから、<h1>タグがそのままコピーされていたり、、原発事故以来良くテレビでみかけるようになった中○大学の某教授のブログからの転載では<strong><strong>文字</strong></strong>が二重どころか三重に囲まれている文章が何行もあり、凄い状態でした。

ついでにブログのテーマを編集して各記事の日付に日(にち)が表示されないバグとカレンダーの投稿日の文字を赤色のボールド表示の下線付きに変更しました。

ブログの記事のHTMLが正しく記述できていない時点で、自分の意図したことが検索エンジンに伝わっていないので、パンダアップデートやペンギンアップデートで検索順位が「下がった」・「上がった」と騒ぐ以前の話です。

このようなところもきちんとやらないといけないですね。

 

 

日本語版パンダアップデート実施!?

さて、googleは、2012年10月23日に検索エンジンのアルゴリズム変更を行った模様です。

今回の対策は、コピーコンテンツの排除が目的のようですが、今までに実施したパンダアップデートも同じ目的だったはず!?。

にもかかわらず、いまだニュース関係を検索すると、2chのまとめサイトばかりヒットして探し物がなかなか見つからない状態なので、日本だけ現状のパンダアップデートの検索アルゴリズムでは排除しきれない特殊な事情があるのかも知れないですね。

 

以下、Googleウェブマスター向け公式ブログより転載

独自コンテンツをより高く評価するために

Google は日々、ユーザーのみなさまから数多くのフィードバックを頂いています。中でも日本のユーザーの方から寄せられるご意見の中には、独自のコンテンツを持つ サイトが、ほかのサイトからのコピーで構成されるサイトに埋もれてしまい、見つけづらいというご意見が多数ありました。この問題に対処するために、今回の アルゴリズムのアップデートでは、独自コンテンツを持つサイトをより積極的に表示するよう変更を実施しました。この変更は、日本語検索結果の約 5% に影響する見込みです。

http://googlewebmastercentral-ja.blogspot.jp/2012/10/google-search-algorithm-change.html

ブログのタイトルで何度も同じキーワードを左側に配置するとペナルティ!

WordPress, SEO | by 管理者
10月 21日 2012 年

先月末から特定のキーワードで検索しても検索結果に表示されなくなりました。

原因は、特定のキーワードをブログタイトルの先頭に配置したことが原因だと思われます。

記事タイトルへの特定キーワードの配置は1年半前からやっており、SEO目的では無く分かり易くする配慮だったのですが、google様から怒りを買ってしまったみたいです。

1年も前から検索順位を不等に下げられていると感じながらも原因がつかめないまま、つい最近になって検索結果の圏外へと消えてしまいました。

 

圏外に吹っ飛ぶのに1年半にも及ぶ長い時間がかかった理由ですが、特定のキーワードを入れた記事は全体400件の中の80件程度あり、時間をかけて記事を書いて積み重ねた結果80件程度書いたところで爆発したって訳です。

まさにgoogleが仕込んだサイレントボム。

 

例えば、以下のようなタイトルの記事を沢山書くと次第に検索順位が落ちていき、いずれ「オートキャンプ」や「家族」で検索されなくなります。

(家族でオートキャンプ)今度はどこに行こうかな。
(家族でオートキャンプ)夕食はカレーにしました。

 

そこで記事のタイトルから特定のキーワード(上の例のカッコ部分)を抜いたところ、3日位前から検索結果に表示されるようになりました。

再び検索結果に現れたときは6ページ目でしたが、今日は4ページ目に検索順位が上がったため、対策が当たったことを確信しました。

ブログやホームページを持っている方は、毎回特定のキーワードをタイトルの左側に配置するのは止めた方が良いでしょう。

 

*** 2012/10/24 追加 ***

特定のキーワードをタイトルの左側に配置しても上位表示されるホームページがありました。

他にも何か要因が絡んでいるのかもしれないですね。

必ずしもこのようになる訳では無いようです。

WordPressのBackWPupとSugarSyncの連携でファイルが大きすぎてバックアップに失敗する場合の対処方法

WordPress | by 管理者
8月 04日 2012 年

WORDPRESSでブログを書いていますが、サーバに障害が発生しても元に戻せるように外部のクラウド(SugarSync)にデータのバックアップを取っています。

そのためにバックアップ用のプラグインBackWPupを使用していますが、今年の7月当初から失敗することが多くなって、それでも何度かリトライして成功していたのですが、中旬くらいから全く成功しなくなってしまいました。

 

はじめは放置していましたが、さすがにそうもいかなくなり、重い腰を上げて失敗する原因を調査したところ、BackWPupのファイル転送時間が10分を超えるとタイムアウトすることが判明しました。

 

転送時間を決定しているところは、 backwpup-functions.phpのこの部分「$revtime=time()-数字」の数字部分です。

この数字を大きくすると、タイムアウトする時間を延ばすことが出来ます。

BackWPupは良いプラグインですが、この数字をパラメータ化して設定画面から簡単に変更できると、さらに使い勝手が向上すると思います。

 

この対策を見つけてくれた人に感謝!!

 

****  変更後  ***

//cron work
function backwpup_cron() {
if (is_file(backwpup_get_temp().'.running')) {
$cfg=get_option('backwpup');
$revtime=time()-600; //10 min no progress.
$infile=backwpup_get_working_file();
$httpauthheader='';

 

****  変更後  ***

$revtime=time()-1200; //20 min no progress.

$revtime=time()-1800; //30 min no progress.

$revtime=time()-2400; //40 min no progress.

$revtime=time()-3000; //50 min no progress.

 

 

*** 2012/08/07 追加 ***

下の画面は、この対策をして数日経過してからの画面ハードコピーですが、まったくWordPressの環境が問題なくバックアップできています。

欲を言えば、Linux Clientをリリースして欲しいな~と。

WordPressだけでなく、サイト全体のバックアップを取りたいですね。

WordPressの新手のコメントスパム

WordPress | by 管理者
6月 23日 2012 年

WordPressでブログを運用すると、1日に20~30通のコメントスパムが書き込まれます。

こんなのいちいち相手にしてられないので、その対策としてAkismetを使って機械的にコメントスパムを除去していますが、Akismetでもまれに正規のコメントを見逃してスパム判定するので、スパム判定されたコメントのチェックが必要になります。

 

 

私のブログは日本語のブログなので、日本語以外で書かれたコメントであれば、ほぼ100%スパムです。

そのため、スパム判定されたコメントのチェックは簡単に出来ますが、今日スパム判定されたコメントを見ていたら、なにやら日本語で書かれたコメントが混ざっており、またAkismetが見逃したかなと思ったら、コメントの内容が意味不明な日本語でした。

 

これがそのコメントですが、どこかから拾ってきた日本語の文章に私のドメイン名を入れて適当に作っているので意味はメチャクチャです。

これを機械的にスパム判定するんだからAkismetは賢いです。

 

 

ちなみにこのコメントスパムの発信元のIPアドレスを調べるとロシアのものでした。

そして、このIPアドレスで検索すると他の掲示板に同様の投稿が有りました。

これも同様に酷い日本語です。

BackWPupを使ってWordPressからDropBoxへ転送できるファイルの大きさの上限は150MB?

WordPress | by 管理者
5月 01日 2012 年

WordPressのバックアップをBackWPupで行ってバックアップデータをDropBoxに保存する方法が公開されているのでやってみましたが、できませんでした。

DropBoxに転送できるファイルの大きさの上限は300MBのはずだと思っていたのですが、実際に容量の大きなファイルを転送すると以下のようなエラーがでます。

2012/04/30 23:08.13: [ERROR] DropBox API: Error: File "/var/www/wkbk/backwpup_1_2012-04-30_23-07-29.zip" is too big max. 150 MB.

 

このエラーを見ると、WordPressから転送できるファイルの大きさの上限は150MBみたいです。

WindowsXP上でDropBoxのフォルダに同期させる方法なら150MBを超えても大丈夫だったので、使用しているAPIの仕様が違うのかな?

 

*** 追加 2012/05/01 ***

この件についてWordPressのForumで調べたら、同じように悩んでいる人がいて、分割してアップロードするとかSugarSyncを使うとか対策方法が書き込んでありましたが、wordpressからバックアップデータを分割してDropBoxにアップロードすることは出来なさそうなのでSugarSyncを使ってみました。

http://wordpress.org/support/topic/plugin-backwpup-dropbox-file-limit-150mb

http://wordpress.org/support/topic/latest-changes-to-dropbox-broke-backwpup

 

ちなみに DropBox APIのを調べると、アップロードするときのファイルサイズは150MBがリミットだから、それ以上のファイル転送はデスクトップアプリケーションを使うように書いてあります。

Notes

There's a 150MB limit to all uploads through the API. Users looking to upload files larger than 150MB will have to do so through the Dropbox desktop application.

https://www.dropbox.com/developers/reference/api#files-POST

 

以下はBackWpUpでSugarSyncを使っときのログですが、166MBのファイルのアップロードに約3分くらいかかりました。

思ったより早かったです。

WordPressのバックアップだけなら、150MBの転送制限のあるDropBoxよりSugarSyncの方が使いやすいし、無料で使える容量も2GBのDropBoxに対して5GBとSugarSyncの方が大きいので、LinuxにAPIを入れて使うことをしない限りDropBoxを使う理由は無いかもしれないですね。

 

2012/05/01 09:42.31: Backup zip archive create done
2012/05/01 09:42.31: Archive size is 166.38 MB
2012/05/01 09:42.31: One backup file deleted
2012/05/01 09:42.31: 1. try sending backup to SugarSync...
2012/05/01 09:42.33: Authed to SugarSync with Nick trendai
2012/05/01 09:42.33: 4.97 GB free on SugarSync
2012/05/01 09:42.35: Upload to SugarSync now started...
2012/05/01 09:44.10: Backup transferred to https://trendai.sugarsync.com/wordpressbkup/wordpressbkup/backwpup_1_2012-05-01_09-41-48.zip
2012/05/01 09:44.10: 1. try for database check...
~ 略 ~
2012/05/01 09:44.12: Job done in 144 sec.

新規環境へのWordPressのリストア方法

WordPress | by 管理者
4月 22日 2012 年

珈琲焙煎機の発売を開始してから少し落ち着いてきたので、台風シーズンを迎える前に自宅にあるWEBサーバをレンタルサーバに移行する計画を開始しました。

今回借りたサーバはさくらインターネットのVPSサーバ、100GBのハードディスクと1GBのメモリと1つのIPアドレスが割り振られるプランで月980円です。

ところで移行するにあたり、ブログのデータをそのまま新サーバに持っていく事ができるのか、かなり不安でした。

データのバックアップはBackWPupというプラグインで行っており、BackWPupのToolsメニューからリストアできると聞いていましたが、実際にやったことは無く。

当たり前ですね。

リストアに失敗したらブログが読めなくなって今までの努力が水の泡になってしまいますから、ブログをやり始めて間もない頃であればともかく、2年分もデータがあると、テストしてみようなんて気はさらさら起きません。

 

そして新サーバでリストアしたところ、無残にも失敗しました。

失敗といっても、Toolsからリストアしただけでは失敗します。

おそらくデータが大きすぎて(160MB)リストアの途中で終わってしまったみたいです。

しかし、力技でリストアできることがわかりました。

 

方法は以下の通りです。

前提として、WordPressを新サーバにセットアップし、BackWPupプラグインをインストールします。

① BackWPupで取得したバックアップデータからwordpress.sqlだけを抽出してバックアップデータとwordpress.sqlの両方をWordPressフォルダの直下に置きます。

② BackWPupのToolsからRestoreボタンを押して記事の文字部分のテキストデータ(wordpress.sqlに入っているみたい)のみリストアします。

③ サーバ上でバックアップファイルを上書きで解凍します。・・・画像データや各種設定情報、プラグイン等の上書きを行う。

# unzip -o バックアップファイル  ※カレントをwordpressフォルダに移してこのコマンドを実行、バックアップ形式はzipを想定

④ 1つ上の階層にカレントを移して所有者をrootからapacheに変更します。

# cd ..

# chown -R apache:apache wordpress  ※wordpressのフォルダをwordpressと想定

この方法で画像もプラグインもリストアできました。

WordPressが 3.3にバージョンアップされて仮名漢字変換の不具合解消、WindowsXP + IE8でもようやく使えるようになりました。

WordPress | by 管理者
12月 15日 2011 年

WordPressが3.3にバージョンアップされて、WindowsXP + IE8 または IE7で仮名漢字変換を間違えたときに1文字消すと1行分まるまる消えてしまうバグが解消されました。

このバグは、IE9やFirefoxなら問題ないみたいなんですが、どうしてもIE8しか入っていないパソコンでブログを書かないといけない時は、ついついクセでバックスペースキーを押した瞬間「バサッ」と1行丸まると消えてしまい、その都度あせりました。

ctrl + zでundo出来ると良いのですが、漢字変換で確定する前なので、undo出来ませんでした。

仮名漢字変換が絡んだバグなので、1バイト圏である英・米・欧では発生しないバグなんですよね。

だから、内在してしまったのだろうと思います。

今までは、メモ帳などのエディタ類に編集してそれをWordPressの画面にコピーしていましたが、その手間がなくなりました。

これでようやくIE8でWordPressが使えます。

まだ、Windows7にバーションアップしていない人には朗報です。

※ Windows7でもIE9を削除するとIE8になるので、Windows7だから問題ないって訳ではないようです。実際、某証券会社でサポートしているブラウザは未だにIE8ですから、Winodws7で動作させるときはIE9を削除することが前提になります。