ローカル環境で作成したWordPressをサーバー(本番環境)にアップする

2018.11.15

WordPress

 

ども、六崎です。

 

今時期は、アプリゲームでハロウィンキャラが実装されてメッチャガチャを回している方も多いのではないでしょうか。
(書いている今は10月末です)
私ももれなく回してます(笑)
リリースからずっとプレイしているファイアーエムブレム ヒーローズ(feh)では、「大地の恵みに」と題してハロウィンガチャが行われていますが…ミルラちゃん、可愛くないですか?
今までマクムートはほぼもれなく当ててきたのですが、なかなか当たらず今回はダメかもしれないと若干諦めかけてます。
なにせ基本的に無課金勢だから、オーブ集めもカナリ地道!
あ、偶然ですがカゲロウさんはゲットしました(週末に一気にレベル上げ予定。

 

そんな感じでミルラちゃんで頭いっぱいな六崎ですが、数日前まではWordPressで頭がいっぱいでした!
WordPressって慣れてないとfunctionsやDB、htaccessとかいじりたくないじゃないですか。
私はいじりたくなかったです!
だっていじったら真っ白になったり、404とか500とか…そのたびにバックアップの大切さを身を以て感じてました(笑)

 

そんな恐怖のWordPressですが、開発時から本番環境に都度あげて作成って…あまり無いかなーと思うんです。
そうすると発生するのが、ローカル環境で作成したWordPressをサーバー(本番環境)にアップするという作業。
難しそうに感じるんですが、バックアップさえ取ってれば「どうとでもなれ~」でちょいちょい!とできます。

 

そんなかんじで、ここ数日私がやりまくったローカル環境から本番環境にWordPressをアップする方法をご紹介します。

 

まず、私の環境です。
[ローカル環境]
Vagrant(CentOS6)
PHP 5.6.38
MySQL 5.1.73

 

[サーバー]
さくらのVPS
PHP 5.6.38
MySQL 多分同じくらいだと思われます…

 

※基本的にターミナルを使用しての方法ですが、やり方はphpMyAdminとCyberduck等のFTP系ソフトを使ったやり方と同じです。(ターミナル分かんないよ!この記事意味分からないよ!という方は記事下にある参照サイトを御覧ください…もっと分かりやすいかも?)
※壊れた!!などの状態になっても責任は取れないので、ちゃんとバックアップを取って自己責任で行ってください。

 

1.サーバーにアクセスします

1
$ ssh [サーバーのuser名]@[IPアドレス]

 

2.サーバーにログインできたらDBを新規作成します

1
$ mysql -u [mysqlのuser名] -p [パスワード]

 

–DBに接続–

1
> CREATE DATABASE [DB名] CHARACTER SET [文字コード];

 

※文字コードは入れなくても大丈夫ですが、私の場合文字コードを指定しないで作成した場合に初期設定したはずのものになっていなくて文字化けマジックにかかったことがあるので…念のため。
※CREATEする前に、同じデータベースが無いか確認してください(恐らく、作れないよ!って言われるだけだと思いますが)

 

3.wp-config.phpを本番環境に合わせて修正します
ローカル環境と本番環境のDB情報が同じであれば修正する必要はありません。

1
2
3
4
define('DB_NAME', '2で作った[DB名]');
define('DB_USER', 'mysqlのuser名');
define('DB_PASSWORD', 'mysqlのパスワード');
define('DB_HOST', 'localhost');

 

※DB_HOSTは基本的にlocalhostで大丈夫だと思いますが、環境によりけりなのでご確認ください。

 

4.htaccessを本番環境に合わせて修正します
…必要はないかもと思い始めました(笑)
なぜなら、本番環境の階層やディレクトリ名に合わせて作ってます…よね?
もし、ローカルと本番で階層等が異なる場合は忘れずに修正してください。
トップページ以外で404が出ると思います(なぜなら、何回もやらかしたから覚えた

 

5.ローカル環境のwpフォルダを本番環境へアップします
変更したwp-config.phpや.htaccess等も忘れずにアップしてください。

 

6.ローカル環境のDBをエクスポートします

1
$ mysqldump -u [user名] -p [DB名] > [dumpfile.sql]

 

7.本番環境のDBへインポートします

1
$ mysql -u [user名] -p [DB名] < [dumpfile.sql]

 

8.DB内のURLを置換します
※DB内にシリアライズされたデータがあって、整合性がなくなるから一括置換は危険らしいです。(動かなくなるプラグインがあるとか…?)
[参照] WordPress Codex – ドメイン名またはURLを変更するとき
なので、公式で紹介されているSearch and Replace for WordPress Databases Scriptを使用します。
必要な情報を入力してSUBMITすると、メールが送られてくるのでそこからDLしてください(昔はその場でDLだったんだけどなー…

 

ちなみにですが、PHPのバージョンが5.3以下だと「Ajaxが~」とか言われて動かないのでご注意ください(これは1度やらかした

 

9.Search-Replace-DB-masterをwpサイトの直下にアップします
wp-adminやwp-content等のディレクトリやファイルがある階層にダウンロードしたSearch-Replace-DB-masterのディレクトリをごっそりCyber duck等を使用してアップしてください。
ex.http://hogehoge.comの場合のディレクトリ構造
[hogehoge]
– index.php
– .htaccess
– [wp]
 - [Search-Replace-DB-master] //ここにディレクトリごとアップ
 - [wp-admin]
 - [wp-content]
 - [wp-include]
 - wp-config.php
  などなど

 

10.Search Replace DBでDB情報を置換します
先ほどアップしたSearch Replace DBにアクセスします。
上記のhogehoge.comみたいな感じのディレクトリ構造の場合は以下のURLです。
http://hogehoge.com/wp/Search-Replace-DB-master/

 

すると以下の画像のようなページが開かれます。

 

searchreplace

 

それぞれどうなっているかと言うと…
① 置換前のURLを入力(ローカル環境)
ex. http://localhost/wp
※wpの後ろにスラッシュ(/)はつけない

 

②置換後のURLを入力(本番環境)
ex. http://hogehoge.com/wp
※こちらもwpの後ろにスラッシュ(/)はつけない

 

③本番環境のdatabase名が入っていると思いますので、確認してください。
wp-config.phpを読み込んで表示しているので本番環境のDB名を表示していないということは、wp-config.phpの情報が間違っているということになります。(④〜⑦も同様)

 

④本番環境のdatabaseのuser名が入ってるはずです。

 

⑤本番環境のdatabaseのパスワードが入っているはずです。

 

⑥本番環境のdatabaseのhostが入っているはずです。

 

⑦本番環境のdatabaseのport番号が入っているはずです。

 

⑧dry runを選択すると置換した場合、どうなるか確認できます。
ここで置換に間違いがないかよーく確認してください。
いや、間違っても修正がきけばまた①から入力していけばOKなんですが…たまにドジって「あ、これ修正するよりDB入れ直した方が早いやん…」ってことをたまにするので、お気をつけください!

 

⑨live runを選択すると置換開始です。置換終了後、本当に置換できているか念のため確認してみてください。

 

⑩delete meでプログラムの削除をします。これ、消さないと外部から書き換えとか余裕でできてしまうので、ご注意ください!

 

11.サーバーに上がっているSearch-Replace-DB-masterディレクトリも削除する。
これも忘れずに!!

 

12.本番環境の管理画面にアクセスしてみます
問題なく入れれば、ひとまずOKです。
もし、入れないorローカル環境の管理画面にリダイレクトされてしまう…等々あったら、
置換の内容が間違っているかもしれません。
もう一度よく確認してください。

 

また、念のためパーマリンク設定でなにも変更しなくてOKなので「変更を保存」をポチッとしてあげとくといいです。
問題がなければ、記述も変更されないしパーミッションが大丈夫かも確認できるので。

 

13.本番環境のサイトにアクセスしてみます
トップと下層ページ(投稿ページ、固定ページ、カスタム投稿ページなど)に無事アクセスできれば、OKです!お疲れ様でした。
もし…もし、トップページ、下層ページにアクセスして404と言われたら以下の可能性が考えられます。
・置換内容が間違っている

 

500だと以下かな…。
・.htaccessの内容が間違っている
・httpd.confで.htaccessが有効になっているか?

 

Authorization Requiredと表示されたら…。
Basic認証で認証エラーが起きてます。
・ユーザー、パスワードを正しく入れてるか?
・.htpasswdのある位置(パス)を正しく指定できているか?
(たまに意地悪されたのですが…)上記2つOKなのに、エラーを表示されることがありました。
私の場合、更新をすると問題なくサイトが表示され、次回以降問題なく認証されることがありましたので、参考までに。

 

ちなみに私はこの数週間の間に全部のエラーを発生させました(ドヤァ
…その都度泣きそうになったし、そのうちの一回は大野さんに「元気?」と聞かれるくらいガチで意気消沈してたから
ドヤれないです。

 

はい、そんな感じでローカル環境から開発環境へWordPressを移行できたと思います!
慣れちゃえば5分もかからずポチポチッとできるようになります。

 

では、また!

 

[参照] まごのて – ローカル環境で作成したWordPressのサイトをレンタルサーバーへ移行する方法


Top