CPIの暗号方式はMD5 SHAなのでよくある生成サービスサイトから作成することができません。

コントロールパネルでも生成できるみたいですが面倒なのでコマンドで作ります。

こんな感じで生成

$ htpasswd -nbm username password

とある理由でwordpressを丸ごと別のサーバに移管したり乗り換えたり、つまりお引越をさせないといけない場面は多々あります。既に稼働しているwordpressをスムーズに移行させるには下記の手順がベストです。カテゴリやプラグイン等々の再設定も行う必要ないので楽に移行できます。

wordpress移行前の準備、旧サーバから必要なファイルを揃える

1：旧サーバデータベースを丸ごとエクスポートする

phpMyAdmin等からwordpressが入ってるDBを丸ごとダンプしておく。
（※右図はphpMyAdminのエクスポート画面）

2：旧サーバからファイル一式をダウンロードする

FTP等でwordpress関連のファイル全てをダウンロードしておく。

新サーバにwordpress移行する手順

3：新サーバにファイルを丸ごとアップロードする

旧サーバからダウンロードしたwordpress関連のファイル一式を新サーバの任意のディレクトリにアップロードし、必要に応じて /wp-contents/uploads/ や /wp-contents/cache/ などパーミッションの変更が必要なディレクトリは777等に変更する。
（サーバによって数値は変わります）。

4：MySQLデータベースを作成する

新サーバで新規にMySQLデータベースを作成する。

6：wordpressの設定ファイルの必要な情報を変更する

/wp-config.php をDB作成時に設定したDBネームやパスワード、ホスト等に変更します。（下記の箇所）

/** WordPress のデータベース名 */
define('DB_NAME', '○○○○');
/** MySQL のユーザー名 */
define('DB_USER', '○○○○');
/** MySQL のパスワード */
define('DB_PASSWORD', '○○○○');
/** MySQL のホスト名 (ほとんどの場合変更する必要はありません。) */
define('DB_HOST', '○○○○');

7：wordpress管理画面に接続出来ているかを確認する

ブラウザからwordpressのトップページを参照し、インストール画面が出てくれば接続は出来ています。

8：旧サーバのDBからエクスポート（ダンプ）したデータを丸ごとインポートする

インポートにはphpMyAdminやNavicat等のツールを使うと便利。
（右図はphpMyAdminのインポート画面）

9：wordpress管理画面のログインID/パスワードを変更する

インポート出来たら『wp_user』テーブルのadmin権限のパスワードを変更します。（右図参照）

変更するカラムはadmin権限のユーザで下記の2カラムです。
『user_pass』カラム を $P$B9f/Y7GWy4FzX5uuccAbvJxWDGVdHl0に変更。
（パスワード adminadminでログイン出来る様になります）
『user_email』カラムを 任意のメールアドレスに変更。

詳しくは割愛しますが $P$B9f/Y7GWy4FzX5uuccAbvJxWDGVdHl0 という謎の文字列でパスワード adminadmin でログイン出来る様になっています。

この変更は前任者と管理が変わる場合は特にに重要になります。

10：wordpressのURLを変更する

『wp_options』テーブルの『option_name』→『siteurl」に記載されているURLを新サーバのURLに変更します。
テスト段階ですのでテスト専用のURLがあると思います。それを入れておきますが、新サーバにDNSを切り替えた際にはここを再度変更します。

11：wordpressトップページを参照して無事に旧サーバと同じ状態で表示されているか確認する

ブラウザからwordpressのトップページを参照して確認します。
この段階ではインストール画面が表示されたり、エラーが出ていたりする場合はDBの見直しが必要です。

12：wordpress管理画面にログイン出来るか確認する

ログインID『admin』、パスワード『adminadmin』でログイン出来るか確認する。

13：投稿出来るか確認する

管理画面にログインできたら、特に画像のアップロードなど確認しましょう。

ついでにadmin権限のパスワードが『adminadmin』になっているので変更しておきましょう。

基本的には以上ですが下記に補足を。。

記事内のリンクURLを直す

記事内の画像リンクが絶対パスで指定されてい場合が多くあるので右図のプラグイン「Search Regex」を使って一括置換してあげましょう。

プラグイン：Search Regex

※「Regex」にチェックを入れる事で正規表現が使えます。

実作業ではwordpress全データをDBにインポートする前に全置換してしまう方が早いですが、こういったメンテナンス系のプラグインを使うというのも一つの手もはあります。

またはSQL文を使って置換する事も出来ます。

SQL文

UPDATE `テーブル名` SET フィールド名A=REPLACE (フィールド名A,"置換前の文字列","置換後の文字列");

記述例

・テーブル名：dtb_customer
・フィールド名：uname
・置換前の文字列：山田
・置換後の文字列：鈴木

UPDATE `dtb_customer` SET uname=REPLACE (uname,"山田","鈴木");

短時間の集中的なアクセスによりDBに制限がかかる

EC-CUBEに登録する際に、半角カナや記号も順に変換していくようなのですが、あまりに多量でタイムアウトになったり、途中で処理に失敗してエラーが出る事があるのですが、これがWebARENA SuiteXだと余計に厄介な事態を招くことになります。（SuiteXだけかも知れないですが）

なんと、郵便番号の更新中にDBがシャットアウトされるのです。

正確には制限がかけられている状態。エラーになるだけならまだしも、制限がかかって“暫く使えなくなる”というのは如何なモノか。数時間程度で復旧しますが、結局INSERT構文等で流し込む事になります。

慣れれば大した事ではないんですが、この他にもSSLの設定やら面倒な事が多いので、どうでも良いことに時間を割きたくない方は避けた方がよろしいかと。

同じ様な規模感のサーバなら、CPIの方がいいですね。それよりさくらが一番いいですが。（あくまで個人の主観です）

参考：[フォーラム] 郵便番号DB更新中にエラー→管理画面にも入れません
参考：CPIにEC-CUBE 2系をインストール

WebARENA SuiteXでの .htaccess の設定

ついでなのでWebアリーナでEC-CUBEをインストールする際に設定する.htaccessの設定をメモしておきます。

※SSLを利用する際には/ssl/home/ 直下にも同じ.htaccessをコピーしましょう。

php_value memory_limit 50M
php_flag  display_errors On
php_flag magic_quotes_gpc Off
php_value magic_quotes_gpc Off

だからこういうサービスに従うは嫌いなんです。

サイトサーブ2(siteserve2)というEC構築のサービスがあるみたいです。
ひょんな事からこのサービスを使う羽目になった訳ですが、WordPressを使う為にはphpファイルのパーミッションを全て755にする必要があるらしい。（サーバサイドで処理するスクリプトファイルを755にする）

それに対する説明は一切ない。

MySQLはショップサーブ2側の管理画面から作成できるがホスト名が何処にも書かれておらず、ならばと思いlocalhostにしてみてもダメ。結局phpMyAdminからログインして確認しないといけないという、なんとも飽きれた確認方法を迫られる。

それに対する説明も一切ない。

さらにショップサーブ2側で画像をアップする際には日本語ファイル名はおろか、ドットが混じっていたり、既にアップしているファイル名と同じファイル名だとアップ出来ないというふざけた仕様（ファイル名はユニークなものにリネームするのが普通です）。

それに対する説明も一切ない。

極めつけは管理画面自体が常に重い。

ネットサービス群雄割拠の時代にこの仕様が“有料サービス”として罷り通る事自体我慢ならないし、いろいろ分かった所で今後何の役にも立たない。それでも「最初で最後、もう二度と使うことは無い」と割り切ってみても憤りは収まりません。

なぜ、EC-CUBEやLiveCommerceにしないのか。もうやってられません…。
だからこういうサービスに従うは嫌いなんです。

追記：後日更なるトラブルに見舞われる

なんと、MySQLデータベースが丸ごと壊れた。

いや、壊されたのだ。

どうやらサーバメンテでしくじったらしい。

一体どういう会社なんだここは。

勝手に壊されては堪ったものではない 。

はらわたが煮えくり返りそうになったが、
幸いにして前日のバックアップがあったので
DBを新たに作り直しインポートした事で辛苦な事態は免れた。

もうなんだか、ふざけすぎてて話になりません。このサービス。この会社。

qmailのstatusはstoppedとなりxinetも同時に停止していたので、xinet起動させからqmailを稼働させる。

原因

inodeが100%になっている為にダウンした模様。

-bash-2.05b# df -i
　　　　　　Filesystem Inodes IUsed IFree IUse% Mounted on /○○○○/vzfs 800000 799554 446 100% /

対策

主にサイズの小さなファイルやログが大量に生成されるプログラムが実行されている場合などにこの現象が発生する。
この場合、必要の無いファイル群を消去することで問題が解決。見つけ方は以下のコマンドなどで。

-bash-2.05b#
　　　　　　find /home/httpd/○○○○/○○○○/ -type f | wc -l

解決コマンド

-bash-2.05b# service xinetd status
　　　　　　xinetd dead but pid file exists

-bash-2.05b# service xinetd start
　　　　　　Starting xinetd: [ OK ]

-bash-2.05b# service qmail status
　　　　　　qmail is running