Zen Cart用モジュール「顧客情報CSV出力コンポーネント」販売開始

久しぶりのZen Cartモジュール。
顧客情報を抽出するモジュール(コンポーネント)です。※有料8,000円
顧客情報CSV出力コンポーネント
セールのお知らせを郵送で送りたいとか、年賀状や暑中見舞いを送りたいとか、そういった用途にお使いください。
出力するデータは下記のようになっています。
[01]顧客ID,[02]国,[03]郵便番号,[04]都道府県,[05]市町村,[06]住所1,[07]住所2,
[08]会社名,[09]顧客姓(漢字),[10]顧客姓(仮名),[11]顧客名(漢字),[12]顧客名(仮名),
[13]性別,[14]生年月日,[15]電話番号,[16]FAX番号,[17]メールアドレス,[18]DM
「[18]DM」はメルマガ購読の申し込みの有無でDM送信がOKなのかNGなのか表示します。
並び順は都道府県コード順です。
今年の年賀状送付にもまだ間に合うかも!?
※このモジュールは「CSV-コントローラー(無料)」が必要です。

ZenCart用モジュール

オフィスあんどぷらすで制作販売しているZenCart用モジュールのうち、ポイントモジュールアドバンスと、会員ランクモジュールアドバンスのセット販売を期間限定で行います。
期間限定ですので20%OFF 1万円引きにて提供しちゃいます!
セットでこそ力を発揮する機能もあるので、やはりセットで使ってもらいたいのですが、まずは予告です。
具体的なキャンペーン期間は決まり次第告知します。
ZenCartのコミュニティ掲示板に顔を出す時間もなかなか作れないほど、最近もZenCartカスタマイズいっぱいやってます。
オフィスあんどぷらすはCS-Cartに力を入れていきますが、ZenCartのモジュール開発もまだまだしていきます。
最近ではこんなものを作っていました。
・商品の発送を外部委託している企業様用の出荷依頼CSVファイルの出力モジュール開発
・上記に付随して各種フォームの入力チェック機能のカスタマイズ
・共同購入モジュール(非常に困難な局面に遭遇しています。。早急に完成させたいところです。)
・商品オプションの組み合わせ登録を商品登録画面内で完結させるロジック開発(これもちょっと手こずってます)
・オプションの必須項目設定を管理画面で一元的に管理するモジュール開発(ちょっと修正中です)
その他既存サイトの修正とか調整とかも受託してます。

Zen Cart 1.3.0 配達希望日指定モジュール(配送希望日)

Zen Cart 用の配送モジュールに依存しないで配達希望日(配送希望日)を指定するためのモジュールです。
元は当ブログでも過去に紹介しましたが、本家で公開されている海外モジュール「order_delivery_date_2-2」というモジュールです。
このモジュールを日本語化し、1.3.0用としました。
便利なモジュールなのですが、コアの改変が多いので導入には注意をしてください。
入手はこちらから
http://www.a-akinai.com/modules/zox/admin/categories.php?cPath=1_12&pID=15
無料です。

Zen Cartポイントモジュールアドバンスv120

ポイントモジュールアドバンスのアップデートを行いました。
内容は下記。
※※ 2009/10/20アップデート+バグフィックス(v120) ※※
機能追加によりマイナーバージョン番号をアップしました。
□新機能
・多通貨に対応しました。これに伴いポイント表示系の関数を刷新。
これまでも多言語には対応していましたが、複数の通貨を採用したショップにおいて
(例えばUSD)で100ドル未満の商品に対してポイント付与率が1%の場合、ポイントが付与されないという問題がありました。
今回の機能追加で、複数の通貨を採用していても円の場合とほぼ同じだけのポイントが付与されるようになりました。
「ほぼ」というのは、為替レートによって購入額に応じた比率での付与なので為替レート分差が生じます。
あくまでも購入額に対するポイント付与率での計算としています。
・ポイント利用時の最大ポイント利用数制限の拡張 thx Miss Yamane
最大利用ポイント数の設定値を「空欄」とすることで最大利用数を保有ポイント数と同一にします。
□バグ修正
・edit_ordersにおいて注文修正画面でのステータス変更時に意図しないポイント確定が発生するバグの修正。
・ポイント含むセール設定画面でセールの追加が出来なくなった問題の対処
最新のセキュリティパッチの導入によって上記問題が発生していました。
(フォーム生成をデフォルト関数で行う形に変更)
■ポイント有効期限チェックについて
□新たに管理者ログイン時に自動チェックする方式を加えました。全部で4種類です。
・管理者ログイン時
・ユーザーログイン時
・手動
・cron
ユーザーログインのみ負荷も考慮して該当するユーザーのみに関してチェックします。
その他は全ユーザーチェックです。
□cron利用について説明とファイル追加 合わせて既存のpoints_expiration_method.phpを手動時のみ利用するよう変更
・cron利用 及びコマンドラインでのphp利用が可能であることが前提
・cron用ファイルはZen Cartのインストールパスを利用環境に合わせて記述することが必要
・cron用ファイルはインストールパス以下であればどこに設置しても稼動します。念のためファイル名のリネームか.htaccessで制限をかけることをお勧めします。
※ただし、extra_function等の事前にロードするディレクトリには不可。adminログイン画面が表示されなくなります。
ご利用いただいている方は下記URLから入手後適用してください。
http://www.a-akinai.com/modules/zox/index.php?main_page=product_free_shipping_info&products_id=10

ZenCart日本語公式

http://zen-cart.jp/bbs/viewtopic.php?f=6&p=22836#p22836
注目度は高いけど、実のある議論は難しいかな。
・掲示板という場
・発言者の立場
利用者から見れば無料モジュールで標準搭載のほうがいいという意見が出るのは当然だよね。
その意味では、このトピの議論を掲示板という場に投げたのはいかがなものかと。
実はこの議論、以前よりdev-zenというZenCart開発用のMLや、skypeミーティングでされてきていることなんだよね。
そこでの意見は真っ二つで、「公式はモジュール開発をすべき」か否かでいつも紛糾する。
そしてコンセンサスは取れないままなし崩し的にモジュール開発がスタートした。(と俺は思っている。)
発言者の割合は半々から6:4くらいで「公式はモジュール開発している場合じゃない」という意見なんだよね。dev-zenでは。
なぜ掲示板にこの話題を投げたのか。
「みんなが望んでることはやっぱり公式のモジュールじゃん」
という主張のための議論ではないのか。
導きたい結論ありきの、論調の誘導が目的でこの場を選んだのならフェアじゃないなと。
(相変わらず俺は穿った見方するねw)
では改めて、なぜ今公式の運営に対するリソースが不足しているのか。
リソースが不足しているということは事実としての共通認識だ。
(誰と誰の共通認識かというと、公式モジュール賛成派と反対派)
それでも既に動いてしまっている複数のモジュール、テンプレート開発プロジェクトは進捗が見られる状態。
一部の人達がモジュール開発してる。
んじゃリソース不足してないんじゃないのかという意見も出そうだけど、ドキュメント、サイト、コアバージョン追随ということに関しては実働リソースがほとんどない。
何故かって?公式のプロジェクトは、アークウェブさんの社内リソースの投入と、一部の有志によって成立しているから。絶対数が足りないのでモジュールやテンプレート以外にリソースを割けないんだよ。
これ以上のリソースは有志頼みなんだけど、この有志が集まらない。
次。
ドキュメントの類にリソースが集まらないのは何故か。
ここのところの議論はいつもされてこなかった。
リソースが足りない。

誰かやってくれませんか?

誰もやらない。
この繰り返し。
リソースが足りない原因が掴めていない。
なんで誰もやらないのかということを考えたことはあるんだろうか。
どうも、面倒だからやりたがらないとしか捉えていない様子。
それは間違ってはいない。
大抵の人にとってドキュメントの整備は楽しくないからね。
楽しくない作業にも意義を見出す人達はいないのか?
モジュール作者とか、Web屋がその候補だと思うんだ。
こういう人は、ZenCartをビジネスライクに捉えている。
故に常にどうしたら売り上げが上がるかということを中長期的な視点から考えている。
楽しいか否かとか、やりがいとかは最優先項目ではない。
自分の利益の為にZenCartのユーザー拡大や、利便の提供が必要だと考えているので、楽しくない、陽の目をあびないドキュメント整備等の作業に「目的」を持って取り組める数少ない層なんだよ。
なのに、そういった層の人達がコミットしない。
何故か。
そこには原因があるはず。
公式の動きにコミットすると困ることがあるんだよきっと。
自分のビジネスが阻害されるからなんじゃないの?
自分が販売しているモジュールと重複するモジュール開発プロジェクトが立った。
自分が開発しようとしていたモジュールと重複する公式モジュール開発プロジェクトが立った。
自分がカスタマイズを請け負ったサイトと同様な機能を有するモジュール開発プロジェクトが立った。
こういった状況に陥ることは往々にしてあると思う。
そんな状況が発生することが目に見えてる以上、コミットすることはかなり難しい。
サイト構築とかカスタマイズする時守秘義務契約結ぶでしょ。
場合によっては競業避止も結ぶかもしれない。
法的にもコミットできなくなるね。
ではこういった人達が公式にコミットしたいと考えた時、回避策はないのか?
公式がモジュールをやらなかったらどうなる?
コアとかドキュメントだけだったら、上述のような状況は発生し得ないよね。
そうすればリソースが今よりも確保しやすくなる。
と思うんだけどどうだろうか。
自分のビジネスと競合するプロジェクトだけコミットしなければいいじゃんという意見はナンセンスだと思うよ。
公式は利用者の利便性を向上することも大事だけど、関わる制作者(モジュール作者に限らずWeb制作会社全般)の利益も守るべきだと思う。
掲示板にも書いたけど、関わる全ての人が利益を享受できないのはどこかが歪んでるんじゃないかな。