信頼のテキストエディター、Jedit

　パソコンで何かしら仕事をしていると、文字入力は避けられません。
　パソコン通信と共にグラフィックの世界に入ったので、いわゆるプレーンテキストしか必要ではなく、修飾された文字が必要な時はIllustratorを使う習慣が身についてしまいました。
　そして時代的にもまだパソコンの性能は低く、サクサクと入力するためにもワープロソフトよりもテキストエディターを常用するようになったのです。

　まだMacがマルチタスク非対応だった頃は、デスクトップアクセサリーという仕組みの中でminiWriter、System7の頃になると単体アプリのYooEditがお気に入りでした。
　それもコロコロ変わるMacのOSやCPUのせいで使えなくなり、やがてJeditというシェアウエアに出会い、以来ずっと愛用、今もこの文章をその最新版であるJeditΩで書いています。

　これもシェアウエアで、無償のエディターが数多ある中なぜ有償エディターかというと、もちろんその機能故。
　大昔、テキストエディターに行番号が表示されるのが、プログラミングのためだと知りました。　実際、今でも「何行目に文法ミスがある」みたいなエラーメッセージが出ると重宝します。

　が、プログラミング時に最も頼りにするのはマルチファイル検索という機能。
　これは指示したフォルダー中のTEXT書類全てから文字列を検索してくれるもので、このハンドラはどこに記載されているか？なんて時に非常に頼りになります。　最近のプログラムやコードはあちこちに分散して記述されていますから、これがないと解析できません。
　
　そしてコードの一斉書き換えにも便利なのが、正規表現による検索機能。
　ここで正規表現の説明はしませんが、一度ハマりだすと詰将棋みたいにのめり込んでしまいます。　プログラム以外にも動画編集時のタイムコード変換なんかにも愛用しています。　いや、こういう仕事こそコンピューターに任せなくちゃ。

　長年愛用してきたJedit Xは32bitアプリのため、MacOS 10.14になったら動かなくなります。　その後継として出たのがJeditΩ。
　さすがにこれは無償アップグレードとはゆかず、1,200円払い、正直使いにくくなった面もありつつ（これはMacOSのカーネルに完全準拠した結果かも）、プログラム時に重宝するのが、二つの書類を比較、相違部分をグラフィカルに示してくれる機能です。
　この機能自体はXcodeのようなプログラミングフレームワークでは採用されているものの、swift以外の言語でも使えるのが助かります。　「え〜、そもそもバックアップとどこが違うんだろう？」なんて時に。
　
　下は、前回に続いて新旧のアイコン比較。
　こうして拡大してみると、旧版にはなにか文字がびっしりと。　文字列を検索してみると、なんと竹取物語でした。
　

Transmitというftpアプリに金を払った

　チートな仕掛けのおかげでEC-CUBE3の仕事も先が見え、とはいえ簡単だけど細かい調整もあり、昨日寝たのが朝の6時。　起きたのが11時。　まぁ、これでもよく寝れた方。
　
　ところが起きたら頭がフラフラする。　いや、確かに寝酒（朝酒だ）したけど、そんなに呑んでない。　あ、これは脳がオーバーヒートした、と気づきました。
　ここ三週間ほどずっと目と頭の中をコードやらタグが渦巻いてて、幸か不幸か家で仕事をしていると、のべつまくなし問題解決を考えています。　これ、ただの多忙ではこうならないのですよ。
　いくら作業が山積みでも、手順がはっきりとわかっているときは、嫌にはなるけどここまで頭は沸騰しません。　今回は手順も仕組みもわからず、いわゆる手探りの繰り返しだったので、やがて脳の神経、というか脳の神経を行き交う化学物質が音を上げたのでしょう。

　幸いにしてその後、最後の課題も思いがけないラッキーな手段で解決できそうな見通しが立って、久々に頭の中にコードやらタグのない夕風呂につかることができました。
　ああ、なんて甘露な愉悦。

　こんなポンコツでもなんとかかんとか他人の書いたコードをカスタマイズできるのかというと、やはりアプリケーションの存在が大きい。

　まず一つ目はftpアプリ。　
　安全のためには、リモート（サーバー側）のファイルは一旦ローカル（こちら）にダウンロードしてから編集、再度アップロードするのが定石ながら、内容を見ながら試行錯誤するのにはまどろっこしい。
　php、twig、ymlという錚錚たるややこしい拡張子もダブルクリックで開き、そのまま編集、上書きも可能というのは今時のftpアプリでは可能なんですが、その速度に違いがあるの気づきました。

　Macのftpアプリでは実質無償（ドネーション）のCyberDuckが有名ながら、これはツーテンポくらい遅れる。　一方で有償のTransimitというのは瞬時に開いて瞬時に更新してくれます。
　このTransmit、実はもう十年くらい前から使っているんだけど、ダウンロード後、購入しないと一週間で5分くらいで接続が切れてしまうようになります。　逆に5分なら使えるので、ローカルできっちり煮込んで、アップロードだけささっとすませるせこい使い方でごまかしてきました。
　あと、自分のマーケットサイトの自前サーバーがなぜかTransmit以外では接続できない、つまり、Transmitは有償なりのメリットがあるとも気づいていました。
　
　しかし、この価格が5,400円と微妙に高い。
　開発側はもはやシェアウエアじゃないぞ、って感じなんでしょうが、私的には1,200円とかせいぜい2,400円ってところかと。
　てなわけでずるずると五分縛りの下で十年近くごまかして来たわけです。

　が、今度は仕事。　他人の書いたコードを改変してゆくという苦行を前に、そんな悠長なことはやってられません。　ということで先月、ちょっと目に涙を浮かべながらお買い上げ。　うん、でも期待通りですよ。
　気分は外付けドライブって感じで、リネームやら複製やらが、Finder感覚でさくさく使えます。　金（かね）は阿弥陀ほど光る、と亡祖母がよく口にしていましたが、まさしく。

　もう一つ、こういう仕事に欠かせないのがテキストエディターなんですが、それはまたの機会に。
　
　下のアイコンはTransmitのもの。　左の古いバージョンでは室内やらヘッドライト内部まで作り込まれていたのに、新バージョンで退化しているのであった。

php_file_get_contentsの誘惑

　とまぁ、motoGPネタで久々にここを更新できたのは、EC-CUBE3の仕事がやっと一段落したからですが、いや、はっきり言ってtwig/symfony2難しいです。
　あぁこれは暗礁だ、と半ば諦めつつ、ジュンク堂でたった一冊しか出ていないsymfony2の参考書を購入。　おかげで概論はそこそこ分かったものの、具体的に今抱えている問題の解決にまでは結びつきません。

　そんな中、ふと見つけたのが、twig中に直接phpを置くことができるphp_file_get_contentsというおまじない。　これでphpはもちろん、sqlクエリーもこれまで通り使える。
　ところが調子に乗っていると、phpではじき出した値がtwigに渡らないことに気づきました。　あれこれ変数を工夫してもダメ。
　どうやら、twigはphpの中身は完全無視でただ文字通り「得たファイルの内容」を中継するだけのようです。
　別途検索したページでの、twigはあくまでビューに徹しているので、その中でphpをごそごそしようとするのは発想が違う、という指摘が頭をかすめます。
　とはいえ、時間的に背に腹は変えられない。　ならばどんどんphpで作り込んでtwigに淡々と並べさせるだけ。　そりゃ慣れてるから早いわな。（とはいえここでもオブジェクト型ではなく手続き型を踏んでいるというポンコツぶり）
　
　ただ終わってみると、twigだけで書かれたものに比べると美しくないし、なにより進歩がない。　だが理想を追い続けて納期が間に合わないのも致命的。
　これを乗り越えないと明日がない予感もしつつ、今回はこれで許してくれ...

とりあえず今更にしてEC-CUBE3始まったかな、と

　まだ公開はされていないものの、とりあえず人生初のEC-CUBE3サイトがなんとかなりそうな見通しが見えてきました。
　デフォルトデザインをベースに、機能はプラグインを足してゆく方針でスタート。

　とはいえ、クライアント側としては率直な希望があるわけで、それは往々にしてEC-CUBE3本体やプラグインの設定一つで可能になるわけではありません。　ということでやっぱりカスタマイズ必須。

　最初のうちはPHPとSQL知ってりゃなんとかなるのか、と思っていたけど、まずはtwigという言語から。
　もちろん佳境に入るとPHP覗いてはみますが、それは意外と勇み足で、煮詰めてゆくと結局twigメインで、あとはhtmlのインラインタグ、スタイルシート、まさかのBootStrapと、まさしく雑貨屋的知識と経験が必要な世界でした。
　異分野としてphpMyAdminの使い方や、さらにレスポンシブ時代に拡大縮小フリーのsvgグラフィックを作るためにゃIllustrator知ってますか？って幅の広さ。

　「単純にPHP上からSQL文書かせてくれや、それを＄に入れたら上がりやんけ」とつぶやきつつ、それじゃ何のためのフレームワークかわからないので、独特の文法に（とは言っても実はそれほど難解ではない）がっつり四つ。　27インチの画面いっぱいにブラウザ、エディタを広げまくり、タイプミスや複数のコードを差を血眼になって探す。

　いや、もうかれこれ十年前にOsCommerceで苦闘していた経験が役に立ちました。　おっと、誤解なさらないように。　もう私はポンコツですから、速度は遅い遅い。
　多分現役バリバリより十倍くらい遅いかと。　だから絶対よそのオフィスなんかで一緒に仕事したくない。　無能がバレる。
　今はありがたいことに自宅で仕事ですから、「あ〜、あのクエリー文がなんでこっちに来ない？」とか呻きながら起きてすぐにiMacに向かい、とりあえず集中力だけで乗り切っています。

　その集中力は例えば、夜明けまでうんうん試行錯誤した末にばたりと睡眠。　10時頃から再びiMacに向かい、昼過ぎに焼き玉子飯やパスタ。　ここで一山超えていればビールの一本も開けられるんだけど、ここ数日はそれどころじゃなくて、そのまま気がつけば夕方。　あぁ、買い物行かなくっちゃ、あ、その前にそろそろプール行かないと体がまずい、ってな感じであっという間に一日が終わります。

　それも問題が解決した時の達成感があるからできるわけで、というかこのドーパミンが堪らない、いや、これがあるからわたしゃゲームに興味がないのだ、と改めて納得しました。

　てなことで、このECサイト公開に向けてまだがんばります。

webフォントやら字詰やら

　現在進めているEC-CUBE3サイトを稼働させているサーバーはエックスサーバーという会社（OSX serverを使っている身としてはややこしい名前）で、EC-CUBE3そのもののインストールから、必要なPHPやらDBなんかを一斉にやってくれる機能が気に入ってチョイスしました。　いやぁ、もう自分でPHPのモジュールをダウンロードしてコンパイルなんて時代じゃないでしょ。
　
　で、このサービスにはメール、WordPressなどに加え、ひっそりとですがモリサワのwebフォントも含まれています。
　
　明朝とかゴシックだけだなんて、まるで創成期のDTPみたい、なんて紙のデザイナーがwebページを蔑視していたも昔の話、結構以前からウェブ上で特定のフォントを指定できるwebフォントという技術が確立されています。
　にもかかわらず、うちでは学生もwebの先生もどうも乗り気ではありません。
　学生は二年間モリサワフォントを使える契約に入っているので、当然web作りにも使えるのに、なんで？と聞くと、速度が遅いとネットや雑誌で批判されているからとか、モリサワへの申請がややこしいとか。
　
　ならばこれは良い機会かと、使用してみました。
　モリサワへの申請云々はエックスサーバーが一括してやっているので体感できないとして、表示に関しては、Windows7のIEを除けば、Windows/MacのChrome、Mac/iOSのSafriでは全く問題ありませんでした。　指定したのはモリサワのフォーク。
　唯一アウトのIE on 7では、ブラウザが戸惑ったかのように文字表示が遅れた挙句にMSゴシックになりますので、このタイムラグが初期の時代に遅いと評された理由なのかもしれません。　windows10とかではもうIEは使われていないとかで、もうこれをwebフォント忌避の理由にするのはやめましょう。（下記の例は全て「絵」です。なぜならこのblogを提供している@niftyではモリサワのwebフォントが表示できないため）

　で、美しく表示されたは良いけれど、たまたまたサイト上で表示させた文字列（店の名前）がカタカナばかりだったので、そのトラッキング、いわゆる文字の送りに隙間が目立つのが気になりました。
　え〜？今時のcssって字詰できないの？と思って探したら、ほら、やっぱりあった。
　
.selector {
font-feature-settings : "palt";
}

　とcssに書き加えるだけでした。
　おっと、「selector」の部分には具体的なクラス名が入りますから、本文はノーマルのまま、見出しのみ詰め打ちって選択も簡単です。
　

　お〜、こりゃすげぇなぁ、webフォント、と思ってたら、別にこれはwebフォントに限った話ではなく、OTF(Open Type Font)が前提の命令だそうで、つまりはそれぞれの端末内のフォントがOTFであれば有効になる機能だとわかりました。
　実際に、MacOSで標準のヒラギノゴシックで試したら、ほんとだ、ちゃんと文字詰できている。
　

　ただ、欲を言えば、この文字詰めはフォントに含まれている詰め情報を基にしているので、例えばフォントによって詰め量に差が出るとか、デザイナーとしては最も詰めたい音引き（ー）が全く詰まらないとか、まだまだかな、という部分も残ってます。
　まぁでも元々スタイルシートの概念とか、この文字詰めの機能とか、グラフィックデザインの基礎がどんどん電子媒体に移植されてゆくのを見るのは興味深いです。

フレームワークフレームワーク！

　先日、かなり以前にosCommerceの仕事をもらったところからphp使えましたよね？という連絡がありました。　どうやら久しぶりに新たなECサイトを立ち上げたいということ。
　んで、時代はEC-CUBEみたいだよ、と答え、そのまま立ち上げに協力することに。
　
　とはいえ、こちらもEC-CUBEは未体験なので、参考書を購入するところから始めます。　この本、ネットではあまり評判は良くないけど、ver.3から入るには実際これがなければまずとっかかりすら掴めませんからありがたいものです。
　
　で、EC-CUBE3って、確かに最後の最後はphpなんだけど、そこはほとんど作り手は意識することはなく、言語としてはtwigというものに触れることになります。　というより、デフォルトのままで良いなら、twigすら触らずに、web上の管理画面から一応全ての設定が可能になっています。　まさしく今風フレームワーク思考。
　つまり、場合によっては、php, css, js, twigはおろか、DBとの接続もhtmlすら知らなくても最低限のことはできるということになります。　というか、フレームワークってのはそういうふうに構築の効率化を目指すもんなのですけどね。

　あれ？これってどこかで体験したような、と考えると、Adobeが「複雑なコードを一切書くことなく最新デザインのwebページが作れます」と謳っているMuseでした。　つまりこれもアプリケーションの形を取っていながら、html, css, jsを裏で操るフレームワークなのでした。
　いえいえ、それ以前に難解化が指摘されているDreamWeaverも立派なフレームワークですよね。　さらにjs(javaScript)を今に蘇らせたj-queryもjsに特化したフレームワークみたいなものと言えなくもなく、何重もの翻訳、書き換えがワンセットになり、運が良ければユーザーはそんなこと全く意識しなくてもプログラム的な完成品を得ることができるようにいつのまにかなってしまったようです。
　
　話をEC-CUBE3に戻すと、このフレームワークの全体構造というか仕組みを理解するのに少し時間を食います。
　この段階では、いっそphpを直接書き換えて、みたいな気もおきつつ、それはぐっと我慢。　それで以前osCommerceに苦労させられたのを思い出します。　その後、なんとか流れが読めて来て、とりあえず先方と最終形態の叩き台になり得るくらいまでカスタマイズすることができました。

　ここまでの段階ではphpもsqlの知識も要りません。　一方でhtmlとcssは必須ながら、htmlは皮肉なことに、5的な構造の知識ではなく、むしろ今では禁忌的なインラインタグの知識が重宝されます。
　twigについては恥ずかしながら、コメントアウトの方法だけ学び、あとは、あぁそういう文法なのかぁ、程度しか理解していません、（今の所）

　逆に伏兵だったのがbootStrap。
　EC-CUBEは3になってレスポンシブに標準対応しています。　もちろんデフォルトのデザインのままでは何も意識せずにぽこぽことコンテンツを入れてゆけば良いのですが、少し欲張ると、このレスポンシブ対応が立ちはだかります。
　吐き出されたhtmlを見ると、どうやらEC-CUBE3にはbootStrapが絡んでいることに気づきます。
　こちとら自分のマーケティングサイトでとっくにレスポンシブ対応しているけど、Muse任せなので何が何だかわからない。
　ということで、このbootStrapの「12」にこだわる基本文法を理解するのに数時間を要しました。
　
　さてレスポンシブといえば、svgの有り難み。
　なんかweb業界では多分ブラウザ互換のせいか、今ひとつsvgの評判は良くないんだけど、それも含めてサーバー側の対応も進み、しかもHDPIディスプレイ時代も合わさって、とても便利だと思うんですけどね。　Illustratorを何十年も使っている身としては余計に。
　Illustratorのweb対応化は普段DTPで使っている時には邪魔だと思っていますが、svg想定時にはCCになってからの書き出し機能の充実も含めて、いやいや、なかなかこれはこれで素晴らしいワークフローじゃないの？とパソコンでもスマホでも美しく表示されるオブジェクトに満足しています。

　てなことで、ここからは決済やら表示方法などのプラグイン実装にも移ってゆきますので、また別の問題にぶち当たることになるんだろうけど、とりあえずEC-CUBEに手も足も出ないという最悪の事態は避けられたのでありがたやありがたや。

嗚呼、再起動

　学校の授業が一段落し、整体以降体調も良いので週明けは昼前から事務所に行ってネットの工事やosCommerceのカスタマイズをしました。　いやぁ、陽の高いうちにスクリプティングの仕事をするなんて、なんて健康的なんでしょ。
　
　osCommerceのカスタマイズ＝PHPとHTMLなわけですが、この仕事、最初に打診を受けたときには時間に余裕がなかったり、頭の冴えがなかったりで「神が降りてきませんでした」と断った経緯があります。　しかし、他の業者に見積もりを依頼したら文字通り桁違いの金額が提示されたとかで、ハードルが低くなって再打診されたものです。
　ハードルが低くなったとは言え、先方の一番重要視するカスタマイズには四苦八苦。
　最近冴えが光っているので何とかなるはずなんだけど、とふとアイデアが閃きましたが、結果は失敗。　おっかしいなぁ、考え方はこれで良いはずなのに。
　
　要は一つのページに二つのフォームを埋め込むカスタマイズ。
　言葉で説明すると、フォーム1とフォーム2に分け、それぞれ＜form＞〜＜/form＞で区別してあります。　にもかかわらずフォーム1でsubmitしているにもかかわらずフォーム2の数値が送信されてしまっています。
　う〜ん、おかしい。おかしい。
　
　昼過ぎから始めたのにいつのまにか陰りゆく事務所。　ああ、神は何処へ...
　そうこうするうちに、全くいじっていない部分の画像が表示されなくなってきました。　あれ？と思ってブラウザを再起動するとその問題は解決。　もしやと思って先のフォームを試してみると、ちゃんと1と2で別々に動作しているではないですか。
　いえ、サーバーアプリ関連はブラウザの挙動を常に疑って、再起動がつきものというのは身をもって体験しているはずなのに、熱くなっていつの間にか忘れちゃうんですよね、これ。　果たして何時間無駄にしたのか。
　
　パソコン黎明期はともかく、特にMacの世界ではUNIXベースになってから非常に安定していて、再起動という儀式に罪悪感すら抱くようになった今日この頃、先のファックスモデムのトラブルといい、なんだ結局まだその程度なのかい＞おまえら、という感じです。

たまには再起動

　先日会社のwebサーバーのPHP4を再コンパイルしたらosCommerceの実験サイトが停止してしまいました。
　無様にも画面にはPHPのエラーコードが表示され、原因はmySqlと連携が取れなくなったということがすぐに判明。

　あれ？　これ以前にも見たエラーやな、と思って考えたらPHP5をコンパイルしたときのメッセージ。　テキストデータにしてあるコンフィギュアオプションを調べたら、今回の4の再コンパイル時の文字列に5の時のものが混じっていたことを突き止めて、またまたコンパイル。
　
　無事osCommerceは立ち上がったものの、お次はページ内のイメージタグが全てhttpsで配信されて表示されないエラーが。
　あれ？これも以前体験したエラーやな、と気付きつつ、既に自分の第二の記憶野であるこのblogを探すと、あった。
　
　これがいつまで経ってもnamahageさんのサイトに頼っており、文字列もコピー＆ペーストしているために、有効期限がnamahageさんが書かれた365日の例文のまま作成しています。
　だから毎年この季節になるといつも期限切れとなり、記憶が消えている私はいつもこの時期にこのトラブルに悩まされるのでした。
　
　これではいかん、と今度は日数延長を試みるも、ミスをしたりして結局また365日に。　程度低いわ＞自分
　ともかく注意深くセットして、あれ？　SSL通信は復活しているのに相変わらず画像のみhttps配信されたままです。
　
　あれれ？　これはどこにもメモってない。　あれ？こんな大きなエラーなのに？　このエラーも以前自分で解決しているのに...　
　久々にosCommerceのスクリプトをデジャヴデジャヴ...とつぶやきながら開いたり、都合一日ほど必死で考えるも、解決策が思い出せません。
　
　そこでふと「こんなわかりやすいエラーなのにどこにもメモを残していないというのは、よほどあほらしいか、初歩的な方法で直ったからじゃないか？」と思うように。
　初歩的？...　
　
　とApacheじゃなくマシンそのものを再起動してみました。
　問題解決。　なんじゃ、そんなことやったんかい！
　
　サーバーは基本的にハードの再起動をさせたくないのと、サーバーアプリ類自体も自身のソフト的再起動だけでリフレッシュできるようになっているので、なかなか盲点でございました。

塩漬け四年もの

　相変わらずのosCommerceのカスタマイズでなかなかblogの更新まで頭が回りません。（というか、学校に行く以外はずっとこればっかりなので発想が硬直化している、とも）
　
　さすがにこれだけやると随分手慣れて来たと言うか、不具合を見つけても大体の見当がつくようになり、顧客が見る部分はほぼ完成したという所まで来ました。
　後は管理部門ですが、これもEasyPolulateのカスタマイズも基本的な所は終わり、あとは細かいfixを残すのみとなりました。
　
　ということで、GPLライセンスの精神からどこかでこれを公開しなければならないのですが、以前にも書いたようにここではちょっと場違いでもあり、以前から持っていた個人のホームページ上で展開する事に。
　ただ、双方向はあっちでは無理ですので、適当に根っことなる発言をここで書いて、コメントがもしある場合はこのblogのその根っこ発言で扱うようにしました。
　
　では、とホームページを更新しようとしたら、何と四年間も放置、塩漬けしていたんですねぇ...
　これではいかんとずっと思いつつ、ついつい楽なこちらのblog更新にかまけていたせいとは言え。
　
　このデザインを見て私のデザイン能力と思われるのも嫌ですが、かと行って今更大掛かりな改造もする時間も無く、恐らくずっとこのレイアウトで行くと思います。　もろweb1.0の遺産。
　まぁ、本音として既にwebのグラフィックデザインは冗談抜きで若いもんにかなわないと思っています。　紙ものはまだ何とか太刀打ちできるんですけどねぇ。
　
　ということで、本論に入る前の前書きのようなものから始めました。
　偉そうに書いていますが、私が本格的にサーバーをいじる様になって二年、PHP+MySQLを本格的に勉強するようになってたったの数ヶ月で学んだ事を書いてありますので、これからPHP+MySQL+Apacheでwebアプリを作ろうとする人にはささやかにでも役に立てるかと思います。
　
　とは言っても軟弱ものの私はゼロからコードを書けるわけも無く、オープンソースのカスタマイズが主です。　でもosCommerceにせよ、OpenPNEにせよ今から自分が書き起こして勝るものを書くことは不可能ですから、カスタマイズというのもこれからは一つの大きなデザイン（設計と言う広義）の道になるのではないかと感じています。

この夏の個人的大人の宿題

　と、夏休みも事実上カウントダウンの状態ですね。
　私立の息子は既に金曜日から学校に。
　
　で、この夏休みは何をやっていたかというと、ずっとosCommerceのカスタマイズをやってました。
　例年、この時期になると「あぁ、あれをやるはずだったのに」と後悔するのが常ながら、今年は「まぁまぁ、よくやったほうじゃないの？」という感じです。
　
　osCommerceの何をしていたかというと、簡単に言うと商品のグループ表示化です。
　osCommerceは基本的に商品単位で表示し、オプション選択をそれにつける、という形態で、パソコンの部品やDVDなどを販売する時にはこれで全く問題はありません。

　ところが衣服類（靴なんかもそうかなぁ）だと、一つの商品にサイズと色のバリエーションがあって、それぞれ三種類あれば9つの商品を登録します。
　そうすると、デフォルトの画面上の「新着商品」に基本的に同じ商品群がずらっと9個並ぶ事になり、お客に取っては良い迷惑。　
　しかし、バリエーションごとの商品登録もしないと、今度は在庫をそれぞれ管理できなくなるので、例えばMはあるけど、Lの注文が来たら在庫切れ、というトラブルになります。
　
　ということで、いくらバリエーションがあっても表示されるのは一つのグループとして表示され、商品は在庫も含めてバリエーションごとにきちんと管理もできるようにしたわけです。
　
　な〜んて事を書いてもosCommerceを知らない人にとっては全く「？」な話でしょうが、一口に上のような仕様変更と言っても、ほぼ全ての部分に手を入れなくてはならないし、データベースには新たなテーブルは作らなくてはいけないし、と思ったより大変な作業でした。
　「できた」と思ってもあちこちクリックすると思わぬエラーに遭遇して、日々それを潰すという地味〜な作業の夏の日々。
　
　何よりPHPもMySQLも自己流で覚えたのと、オープンソース系のカスタマイズは、他人の書いたコードを読み解いていく事から始まるので最初のうちは「こりゃ無理かな」とすら思っていたので、それなりの達成感はあります。
　
　調子こいて詳細検索の部分もオリジナルには無い項目を入れたり、在庫のあるものから検索するなどを加えたりしましたので、ご興味がある方はこちらのサンプルをご覧になってみてください。
　以前ここでも紹介した携帯版の方のサンプルはこちらで、データベースはパソコン版の方と共用になっています。　ただ、テーブル表示はFOMAやWINで無いと無理なようで、今後の対応を決めなくては...
　
　GPLライセンスの考え方からすると、こんなカスタマイズでも公表しないといけないんでしょうね。　と、言ってもここじゃあまりに専門的すぎるので、落ち着いたらどこかのホームページででも紹介したいと思います（って、走り書きみたいなもんですけど、多分）
　
　さて、これで終わりかというと、次はお客様には見えない部分の裏方の方で、商品の一斉アップロード化としてEasyPopulateのカスタマイズに取りかかっています。
　ただ、これも当然というかなんと言うか、思う通りの仕様ではない訳で、またカスタマイズ地獄が待ち受けています。　とりあえずは2300行ほどあるPHPのコードを読む事から始めないと...
　
　成功したら、上記のサンプルページにずら〜っと多彩な商品が並んでいると思います。
　まぁ、ここまで来たんだから何とかなるでしょうけど...