EC-CUBE 2.11 顧客データのお引越し その2
顧客データをCSVにしてインポートしようとしたら、エラー。
key2に値がはいってませんよ…と。
key2といえば、dtb_customerのsecret_keyってカラムなんだけど、正直何のためにあるのやら。
いろいろ調べてみたところ、以下のようなことが分かった。
・ユーザの仮登録機能に必要な、同一ホスト内でのユニークIDである
なんだろ?
本登録を行う際にこれを使って本登録用のURLパラメータでも生成するのかな?
今回の案件は仮登録機能を使ってないのでよくわかりません。
ただ、どちらにせよNullが許されないユニークデータなので、アルゴリズムどおりに作っておきましょう。
「/data/class/helper/SC_Helper_Customer」の「sfGetUniqSecretKey()」で
「SC_Utils_Ex::sfGetUniqRandomId('r')」から
「/data/class/util/GC_Utils.php」の「gfMakePassword($pwLength)」が呼ばれてるってことを考えると、こんな感じの生成なはず。
さすがにこれはエクセルに埋め込めないか…ということで、関数(Make_key()とか)にして前回のコードに追加。
とりあえず、これで問題はなさそうですが…。
こういった顧客データのお引越しがめんどくさいので、各ASPからEC-CUBEへの移行がなかなか進まないんだと思います。
ロックオンも、そういったところを強化すればよりEC-CUBE利用のショップが増えると思うんだけどなぁ…。
ちなみに、2.4から2.11への顧客データ移行モジュールも…動きませんでした。
移行プログラム、全部自分で書いたんですけどね…しかも1日とかで。
さすがに、あの時は死ぬかと思いました。
バージョンアップに伴うデータ移行ですらこの状況なので、他社ASPからの移行なんてもっと大変なわけです。
このあたりの負担を減らしてくれたら、他のASP使ってる顧客にもEC-CUBEへの乗り換えを勧められるんですけど。
商品点数が多くなると、DBを上手く使って動的にページ生成しないとキツいので、まさに移行を勧めるチャンスなのですが、移行にこんなに手間がかかるようではクライアントも渋っちゃいますよね。
余計な経費は払いたくないクライアント。
(自由度の高い)EC-CUBEへの移行を進めたい営業。
その狭間で、いつも苦労しているのはエンジニアです。
もっとエンジニアを評価して( ゚д゚)ホスィ…。
エンジニアの作った、あるいはカスタマイズしたシステムが利益を産んでるということを忘れないでくださいな。
key2に値がはいってませんよ…と。
key2といえば、dtb_customerのsecret_keyってカラムなんだけど、正直何のためにあるのやら。
いろいろ調べてみたところ、以下のようなことが分かった。
・ユーザの仮登録機能に必要な、同一ホスト内でのユニークIDである
なんだろ?
本登録を行う際にこれを使って本登録用のURLパラメータでも生成するのかな?
今回の案件は仮登録機能を使ってないのでよくわかりません。
ただ、どちらにせよNullが許されないユニークデータなので、アルゴリズムどおりに作っておきましょう。
$head = $head = "r";//本会員登録の場合?仮会員登録機能がONなら"t"らしいけど…
//----------------(function gfMakePassword($pwLength))-----------
// 乱数表のシードを決定
srand((double)microtime() * 54234853);
// パスワード文字列の配列を作成
$character = "abcdefghkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ2345679";
$pw = preg_split("//", $character, 0, PREG_SPLIT_NO_EMPTY);
$password = "";
for($i = 0; $i<$pwLength; $i++ ) {
$password .= $pw[array_rand($pw, 1)];
}
//----------------(ここまで)-----------
//----------------(function sfGetUniqRandomId($head = "")より)-----------
// 予測されないようにランダム文字列を付与する。
//$random = GC_Utils_Ex::gfMakePassword(8);→つまり、上の部分で$passwordで取得なので省く
// 同一ホスト内で一意なIDを生成
$id = uniqid($head);
$secret_key = $id . $secret_key;//ほんとはreturn $id . $random;で返してるけど今回はこれでおk
//----------------(ここまで)-----------
「/data/class/helper/SC_Helper_Customer」の「sfGetUniqSecretKey()」で
「SC_Utils_Ex::sfGetUniqRandomId('r')」から
「/data/class/util/GC_Utils.php」の「gfMakePassword($pwLength)」が呼ばれてるってことを考えると、こんな感じの生成なはず。
さすがにこれはエクセルに埋め込めないか…ということで、関数(Make_key()とか)にして前回のコードに追加。
とりあえず、これで問題はなさそうですが…。
こういった顧客データのお引越しがめんどくさいので、各ASPからEC-CUBEへの移行がなかなか進まないんだと思います。
ロックオンも、そういったところを強化すればよりEC-CUBE利用のショップが増えると思うんだけどなぁ…。
ちなみに、2.4から2.11への顧客データ移行モジュールも…動きませんでした。
移行プログラム、全部自分で書いたんですけどね…しかも1日とかで。
さすがに、あの時は死ぬかと思いました。
バージョンアップに伴うデータ移行ですらこの状況なので、他社ASPからの移行なんてもっと大変なわけです。
このあたりの負担を減らしてくれたら、他のASP使ってる顧客にもEC-CUBEへの乗り換えを勧められるんですけど。
商品点数が多くなると、DBを上手く使って動的にページ生成しないとキツいので、まさに移行を勧めるチャンスなのですが、移行にこんなに手間がかかるようではクライアントも渋っちゃいますよね。
余計な経費は払いたくないクライアント。
(自由度の高い)EC-CUBEへの移行を進めたい営業。
その狭間で、いつも苦労しているのはエンジニアです。
もっとエンジニアを評価して( ゚д゚)ホスィ…。
エンジニアの作った、あるいはカスタマイズしたシステムが利益を産んでるということを忘れないでくださいな。