EC-CUBE3の値引き（某大手ペイメント対応）もする
前の記事
rider-dice.hatenablog.com
でも触れた値引き、でもこれってEC-CUBE単体の値引きにしかなってなくって某大手のペイメント会社さんを通すと
購入金額のまま送られてしまっている。つまり自分の書いたコードだとコード足らずだったので調査。
今回調査したのは、EC-CUBE純正のクーポンプラグイン。
これを使った場合、ペイメントに登録されるデータも値引きされた金額になっている。
と言う訳でソースコードを確認。
#346行目
$this->setCouponOrder($Order, $Coupon, $formCouponCd, $Customer, $discount, $app);
ここでオーダーの再受注をしている。
んで、setCouponOrderのロジックを見ると
$total = $Order->getTotal() - $discount;
$Order->setDiscount($Order->getDiscount() + $discount);
$Order->setTotal($total);
$Order->setPaymentTotal($total);
$app['orm.em']->persist($Order);
$app['orm.em']->flush($Order);
受注を更新する為にflushしているのと、setPaymentTotalに合計金額を入れている。
ここが抜けていた為に、DB上と表示上は金額が変更出来ているがペイメント会社さんには割引額が伝わっていなかった。
このままコピっとけば汎用性があるのでメモ。
Lavavel5.4にした際にインストールにハマる
元々EC-CUBE用に構築したCentOS6.9で、phpは5.6.3が入っていた事もあるがLaravel5.4にアップデートすると
PHPのバージョンを7にしてください。ってな事でcomposer updateすると怒られる。
とりあえず、remiが入っている状態で以下のインストールを実行
$ yum -y install --enablerepo=remi,remi-php70 php php-fpm php-devel php-pecl-xdebug php-mbstring php-mcrypt php-openssl php-mysqlnd php-xml sendmail php-gd php-pear php-xml php-mysql
基本よくばりセットをインストール。
これでcomposer updateをすると問題無くアップデート自体は出来た。
って事で、インストールしてみる
$ laravel new hogehoge
ここでエラー。どうやらzipがインストールされていない。とのエラー文言が出る。
pecl install zip をしてもエラーでインストールが出来ない。
php7に変更した際に消えてしまったと見える。
yum --enablerepo=remi,remi-php70 install php-pecl-zip
と言う訳で、pecl-zipを入れて再度インストール実行
$ laravel new hogehoge
無事hogehogeが出来た。
インストールする際には
$ yum -y install --enablerepo=remi,remi-php70 php php-fpm php-devel php-pecl-xdebug php-mbstring php-mcrypt php-openssl php-mysqlnd php-xml sendmail php-gd php-pear php-xml php-mysql php-pecl-zip
よくばりセット２としてコピペ出来るようにしておく。
CentOS6でlaravelのインストールパスを通す
laravelのリファレンスを観ていて
laravel new hoge
とコマンドを通すも、コマンドが通ってない。と言われて怒られる。
.bash_profileにパスを通さなければならない。
$echo 'export PATH="$HOME/.composer/vendor/bin:$PATH"' >> ~/.bash_profile
$source ~/.bash_profile
かならずパスを通して反映しておく。毎回リファレンス観てあれ？なんでだろ。と思うのでコピペ出来るようにしておく。
報（告しない）連（絡しない）相（なんてない）とコラコラ問答
営業とエンジニアの言った言わない。
システム開発の世界に身をおいていると1年に2,3回はリリース日の言った言わないに振り回される。
結局の所、エンジニアと営業の対立の溝が埋まる事はない。
営業はお客様に良い顔をしたいのは分かる。
しかし現実を見ていない。
・要件が出切っていない
→見てみないと分からないから～～～と言う現物を見てからインスピレーションを湧かせる。
営業には要望ベースでオーダーしているものの、それを現場に相談しないまま暖める。
孵化して立派に成長すれば良いが孵化しないまま暖め続けられる。
・仕様が決まっていない
→そんなのお前ら決めろと言われて作るも、確認すると「そんな使い方は考えていない」
まだ確認してくれるだけ幸いである。
「お客さんが今確認しているから～」とその場限りの取り繕い方をしたが故にタスクを忘れている。
どこで止まっていたか紐解くと大半はここにたどり着く。連絡は電話口頭が当たり前である。
・多分○○日くらいに
→結局最初から日付を切ってエンジニアは要望を出す。○○日迄に仕様を決定してください。
○○日までに最終要望のフィックスは必ずしてください。
とは言う物の結局お願いした日までに出てくる物は無い。
なぜ遅れたのか？
なぜ要望が出ていないのか？
「お客さんだって忙しいんだよ！」と言う返答一つしかない。
この状況でお得意様となった先方へ御用聞きに行く営業。
意気揚々と先方から帰ってきた営業に、突然エンジニアに突きつけられたメールの怒りはコラコラ問答へと昇華する。
突然の無茶なリリース日。日付管理票に書かれたシステム構築途中にひかれる大きな黃色の一本線
「お客様のリリース希望日！なるべくここでリリースしてください！！」
エンジニアは呆れそのコメントに一言「無理です。」とだけ記述してブラウザをそっ閉じする。
営業「オマエこれ何だ。何がやりたいんだコラ！紙面を飾ってコラ！
何がやりたいのか。ハッキリ言ってやれコラ。
リリースしたいのか、リリースしたくないか、どっちなんだ。
どっちなんだコラ！」エンジニア「何がコラじゃコラバカヤロー！」
営業「（食い気味に）何コラタココラ！」
エンジニア「何やコラ」
営業「（食い気味に）リリーススケジュールを飾るなって言ってんだコラ！」
エンジニア「お前が（最初に）言ったんだろコノヤロー」
営業「（食い気味に）言ったのはテメエだろがコラ！」
エンジニア「何この、オイ…」
営業「（食い気味に）何コラ！」
エンジニア「（ちゃんとリリース予定日を）言ったらやるぞコラ！」
営業「オマエ、オ…」
エンジニア「（食い気味に）（無茶なリリース日だけ今頃設定して）オマエ死にてえんだろ、コノヤロー」
営業「（食い気味に）オマエ今言ったなコラ！」
エンジニア「おう言ったぞ」
営業「吐いた言葉飲み込むなよオマエ！」
エンジニア「そのままじゃコラ！オイ、ナメてんなよコノヤロー！」
営業「ヨシ分かった。それだけだ（帰るそぶりを見せながら背中を向ける）
（やっぱり振り向いて）オマエ今言った言葉オマエ、
飲み込むなよ。なあ吐いて。分かったな。（帰るそぶりで一歩引く）
（やっぱり元の位置に戻ってから）本当だぞ？本当だぞ？なあ？
リリースするならしっかり噛み付いて来いよコラ。なあ。
中途半端な言った言わないじゃねえぞオマエ。分かったなコラ（一歩引く）
（やっぱり元の位置に戻ってから）分かったな。噛み付くんだなコラ」エンジニア「（食い気味に）オマエに分かったな言われる筋合いは無いんじゃコラ！」
営業「噛み付くんだなコラ！」
エンジニア「オッサンナメンなよコノヤロー！」
営業「（無言で振り向き、会場を後にする）」
～外に出て、車に乗り込もうとする長州に向かって～
発注先「営業さん！（リリースを）やるならプレスリリースした日という気持ちですか？」
営業「（エンジニアを頭ごなしに否定するのに）時間かかんね」
多分この業界でシステム上がりの営業さんと言う類稀な人は引く手数多であろうとつねづね思う。
なぜお客様の要望を聴くのか？
なぜ日付を切ってお客様の要望の打ち切りを行うのか？
なぜ順調に行きスケジュールよりも早く進行しているスケジュールの一度設定した日付を動かす事が悪なのか？
全てはお客様の為なのであろう。それは正しい。
ただし、同時にお客様の要望を具現化させる方は決まった事に対して動かないと、空振りばかりおきてしまい「無駄」な時間と思考をした事にしかならない。
「売上」と言う数字を意識する事は正しいが、それ以上に「内部リソースの稼働と使用率」についての意識が無い人が多い。
エンジニアは目に見えてお金を稼いではいない。だがこういうお客様が全ての営業さんはおうおうにしてエンジニアは社内の人間だから無原資で働く物と勘違いしている人間を多々見掛ける。
無茶振りをしても良いがエンジニアは機械ではない。
感情も体調もある。機械であって欲しいのであれば、その機械を動かす為の詳細な指示を忘れて欲しくない。
「自発的に考えて動くエンジニア以外は不要な人間だ」と言う記事をたまに目にする。
ただその大半は「考えても後でちゃぶ台返し食らって動いても無駄だから」と言う職場の環境を鑑みていない事が多いのではないだろうか。
と思う。
EC-CUBE3のサイト移転時のプラグインの注意
先に本番を作って後からステージングを作った関係で起きてしまった問題
アレコレとプラグインを突っ込んでいたが、このプラグインが起因で例えばページに紐付いているプラグインが無い。と言うエラーが出る。
まず出たエラーは
Compile Error: Symfony\Component\Debug\DebugClassLoader::loadClass(): Failed opening required
結局の所、Symfonyのコンパイルディレクトリが何らかの原因で生成もしくはコンパイル自体出来ていない。
ディレクトリの問題かと思い、EC-CUBEのフォルダ自体のパーミッションを
$ chmod -R 777 eccube/
と言う感じのパワープレイをしたが、このエラーは解決されない。
多分インストールした際に何らかの設定が入っていてサーバー固有に紐付いたコンパイルとかが有るのか。
その為、一旦EC-CUBEの素のバージョンをアップロードしなおしinstall.phpを叩く。
その後に手で差分を入れていくと言う地道な作業に。フロントページが正しく表示されたので、詳細ページに行くと
No mapping file found named
どうやらプラグインに紐付いたymlが無いと言うことで怒られる。
一旦管理画面からプラグインの全削除をしようとするも、ディレクトリ削除が出来ない。
また、オーナーズストアからファイルをダウンロードして再アップロードしようとしても「ファイルのアップロードに失敗しました」の文言が。
で、根本を探ると今回のサーバーへのアップロードはFTPサーバーの無いSCPでのアップロードでユーザーはSSH用ユーザーであった事がひとつ。
元々ファイルの生成はapache権限でやるのにSSHのユーザーが違うユーザーだった事も問題に。
$ chmod -R 777 /html/Plugin/ $ chown -R apache:apache /html/Plugin/ $ chmod -R 777 /app/Plugin/ $ chown -R apache:apache /app/Plugin/
これでアップロードも更新も問題なく動いた。
手でファイルを差し替えた場合、一番の問題はパーミッションよりもアップしたユーザー側になるな。と数時間ハマった忘備録。
EC-CUBE3で自作のSQLクエリを発行する
基礎的な部分ではあるが、EC-CUBE3はフレームワークで作らられている為、どうしてもちょっとした変更が難しい。
特にSQLクエリ部分は色々な部分に根をはってしまっている為、どうしてもSQLは単発で動かしたいと言う事が多い。
SQLの知識さえあれば、ある程度自由に情報を取得出来るのでこの辺を知っているとカスタマイズの幅が広がる。
例）/src/Eccube/Controller/ProductController.php
$sql ="SELECT * FROM dtb_products"; $stmt = $app['db']->query($sql); //1行1行フェッチする場合 while ($row = $stmt->fetch()) { //更新日時の日付をスラッシュにして時間を抜く $get_date = $row['update_date']; $arr_date = preg_split("/ /",$get_date); $ins_date = str_replace("-", "/", $arr_date['0']); $row['update_date'] = $ins_date; $arrProducts[] = $row; } //特にデータを弄る事なくそのまま全行fetchする $arrProducts = $stmt->fetchAll();
あとは変数をrenderする部分に今回であれば$arrProductsをマージすればよい。
