WordPressとcss

　とはいえ、少しは具体的なWordPress感想も残しておかないと。
　
　と、今更WordPressって特に新しくもなく、もう7〜8年くらい前に卒業した学生が「これからはWordPressですよ〜」って久々に会った時に言ってたくらいです。
　個人のblogはこの@niftyを使ってるし、仕事では使うこともなく、たまに雑誌や書籍見ながら、へぇ、基本はphpなのか、程度でした。　ならいざとなってもなんとかなるか、と捉えていたのは事実です。
　
　で、今回初めて本格的に触って見たところ、いや〜、phpというよりこりゃcssカスタマイズの塊だな、と感じました。
　制作目的は個人的なものなので、クライアントから素朴かつ難解な要望も無く、DB周りのカスタマイズはゼロ。　故に現時点でphpを編集したのは一箇所のみ。
　それ以外は全部cssで、なんか今時のweb仕事でただ一つだけ技術を選べ、と言われたらhtmlすらさしおいてcssと言っても過言じゃないような気がしてきます。
　
　ところがご存知のようにcssは上書き自由、なんかそこからかしこに思いつきで加筆とかしても、とりあえずは意図通りになる（なったように見える）ので、あとから矛盾が出た時にそのデバッグが大変だったりしますね。
　それから、いつのまにか次から次へと新しい命令やらプロパティが生まれてて（いや、少なくとも私にはそう見える）、え、今はこれだけでこんなことができるの？、と戸惑うことも一度や二度ではありません。

　ただ、当たり前と言えば当たり前ながら、基本タグだけはcssで置き換えることはできず（それすらよく探せば可能なのかもしれないけど）、上記、一箇所のみのphp編集は、「なんでここがpタグなんよ？」という部分をh3とかへの書き換えでした。
　レシポンシブについては、最初から対応済みのテーマを選んでいるので、若干の不満はありつつ、これも手間要らず。

　Museと一緒で、うるさくないクライアントというか、詳細お任せものなら仕事でも楽勝かな、と。　いや、その道のプロなら難しい要求すら解決するでしょうから、かなり以前から人気なのも今更ながら頷けました。
　
　さて、コンテンツの設計をしないとな...

EC-CUBE3のあとはWordPressかい

　EC-CUBE3の構築が一段落し、本当はこうして落ち着いたところでtwig/Symfony2についてじっくり学ばないといけないのですが、仮にも一旦完成を見てしまうとすでに次の新しいことを探してしまうというこの性、思えば子供の頃から変わっていません。
　
　小学生時代、プラモデル作りに狂っていた私は、お年玉やら誕生日のプレゼントなど一瞬で使い果たし、一生のお願いもすでに年間で数生涯消費、それでも新しいプラモデルが欲しかった、今から考えるとちょっとネジの外れた子供でした。
　お店から買ったばかりのプラモデルのパッケージを腕に抱えて家まで帰る時の幸福感...
　そして家に帰って箱を開けてからの完成までの至福の時...
　
　だがしかし、完成してしまうとそれまでの愛情は何処へやら。　いや、少々誇張してしまいました。　実際には数日間は完成したプラモで遊んだり、鑑賞したり。　が、同時に、「次」を探し出している自分に気づきます。
　まぁ、親やそれでもこれだけ狂ったように創作意欲を次から次に沸騰させる子供に夢を投影したんでしょう。　こいつはひょっとしてすごい偉人になるのではないか、と。　全てとは言わないまでも、かなりワガママを聞いてもらいました。
　その結果、その子供はどんな偉人になったのか。

　大したこと、おまへん...　いやほんま全然。　天国の父や母、ほんっと！　すんません。　あの世に行ったら土下座して謝ります。
　
　閑話休題、Twig/Symfony2もそこそこに、昔の@niftyのフォーラムみたいなものを作りたくなって、突然WordPressに手を染めることに。
　正確にはWPのプラグインであるbbPressの作り込みが主なのですが、とりあえず半月ほどで機能面が完成。　あとは本来のコンテンツを盛り込んで...という段階になってまた悪い癖。　なぜかそこから制作が進まない。
　
　いや、これはこれで絶対に完成させます。　なんだけど、老後の生活設計のために取得しておきたい資格を見つけたりして、それは二年前に合格した危険物乙4よりも一段難しいということで、この夏は真剣にこれに賭けたいな、と新たな決意。
　と言えば聞こえがいいけど、結局中二病どころか、小学生の頃のあのプラモデル狂いの日々と同じじゃないかと密かに困惑。

信頼のテキストエディター、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じゃなくマシンそのものを再起動してみました。
　問題解決。　なんじゃ、そんなことやったんかい！
　
　サーバーは基本的にハードの再起動をさせたくないのと、サーバーアプリ類自体も自身のソフト的再起動だけでリフレッシュできるようになっているので、なかなか盲点でございました。