EC-CUBE3のバグ自己修正 -- HTML特殊文字のアンエスケープ（デコード）

ECサイトの構築もほほ完成し、動作確認をしていたところ、問題が見つかりました。
当店の名前は「T&Aシステムズ」で、半角の「&」が含まれています。
この記号はHTMLの特殊文字の中のひとつで、ユーザー入力フォームなどでこれらの文字が入力された時のセキュリティ対策のために、別のコードに変換する「エスケープ処理」が行われます。
「&」は「＆amp；」というコードに変換されます。
そしてフォーム入力内容を確認表示させるときに、「アンエスケープ（デコード）処理」をして元の文字に戻します。

ところが、このデコード処理がされず、「&」がコードのまま表示されている箇所が2ヶ所（実際には他にもあると思われる）見つかりました。
1ヶ所目は、前の記事で書きましたが、カード決済プラグインの決済画面で、当店名の&が化けていました。
決済会社に連絡しましたが、最初はEC-CUBEのせいにされ、受け付けてくれませんでした。
なので、いろいろと状況証拠を提示し、決済会社のシステム部門に上げてもらえることになりましたが、2週間以上回答がなく、ネットであれやこれやかなりの時間調べ、再度別の証拠を提出して催促したら、やっとプラグインのバグを認めました。
しかし、バグを修正するのは時間がかかるので、とりあえずEC-CUBEの中のプラグインが管理している当店名の情報を書き換えるコマンドを知らせてきたので、これを実行しました。
そうしたら、&がちゃんと表示されるようになりました。

2ヶ所目は、ECサイト訪問者が「お問い合わせページ」に質問を入力したときに、自動でユーザーに送られるメールの本文内でした。
これは明らかにEC-CUBE3.0.17のバグです。
ググったところ、HTML特殊文字をデコードする「htmlspecialchars_decode」関数が見つかりました。
src\Eccube\Service\MailService.phpが自動メール送信プログラムなので、その中の$body変数に上記デコード関数を適用しました。
この結果、メール本文の中の&がそのまま表示されるようになりました。

IISでEC-CUBEを動かすのに（大きく）つまずいたこと

EC-CUBEにはバージョン2、3、4があり、バージョン2もまだサポートされています。
私は「新しモノ好き」ではなく、逆に新しいものを信用ていないので、多くの実績がある古いバージョンの2で構築しようとしました。
前のブログで書いたように、3つの”つまずき”がありましたが何とか克服し、商品を登録できる段階までは構築できたのですが、次に大きな壁に突き当たりました。

ECサイトでの決済はカード決済が主流なので、決済業者と契約しました。
当初はバージョン2の最終版である2.17で構築しようとしたのですが、決済業者のプラグインが2.13にしか対応していないとのことだったので、しかたなく2.13で構築しました。
そしてプラグインをダウンロードし、インストールまではできたのですが、設定段階で通信エラーが発生しました。
決済業者に報告したら、当方のサイトがTLS1.2に対応しているか確認されたので、IISサイトをHTTPS化する情報をいろいろ調べ、無料のSSL証明書を入手し、TLS1.2に対応させましたが、通信エラーは解決しませんでした。
ファイアウォール設定やPHPの設定なども確認しましたが、原因が分からず、決済業者からも新しい情報は得られず、先に進めなくなってしまいました。

仕方がないので、別の決済業者を試すことにしました。
ところが、別の業者は2.13に対応しておらず、2.17対応ということだったので、別のサーバーを用意し、2.17でサイトを再構築しました。
そしてその業者のプラグインをダウンロードしインストールしましたが、接続テストをしようとしたら、今度はEC-CUBEがクラッシュしてしまい、再インストールしないといけない状態になってしまいました。

どれもこれも、まともなプラグインは無いのか～～～！

「ただほど難しいものは無い」ですね。お金を使いたくないなら、手間暇を使うしかないです。
今度はバージョン2を捨て、最新版の4でやることにしました。
しかし、4はIISには対応していないらしいので、Apacheで構築する必要がありました。
Webサーバーの世界ではIISはごくマイナーで、Apacheがメジャーです。
だったら「何で最初からApacheを使わないのか？」と言われるかもしれませんが、それは、私個人の経験の問題で、Apacheは経験が無く、IISしか経験が無かったからです。
この際、何でも勉強なので、Apacheの情報を調べ、インストールしました。やはり主流だけあって、インストール自体はIISより簡単かもしれません。

しかし、次につまずいたのはSSL証明書の問題です。
IISの時は比較的簡単に証明書を取得できたのですが、Apacheではいろいろ方法を試しましたが、どうしても取得できません。
IISの証明書をエクスポートして、Apacheにインストールしようとしましたが、だめでした。
どうも同じサーバー（同じIPアドレス）では、証明書は1枚しか発行してもらえないらしいです。

ということで、またIISに戻ることにしました。
ただしバージョン4には対応していないので、バージョン3で構築することにしました。
しかし、バージョン3のダウンロードリンクが公式サイトから無くなっていました。2の最終版のダウンロードリンクはあるのに、なぜ3が無いのか理解できません。
しかたなく他のサイトを探し、3の最新版である3.0.18をダウンロードしましたが、何かが不足しているようなエラーでインストールできません。
先人たちのインストール手順を見ると、vendorというサブフォルダが存在しているのですが、私がダウンロードしたものにはありませんでした。
vendorを作成するコマンドがあるらしいので、やってみたら作成されましたが、それでも何やら不明なエラーでインストールできません。
なんでこんなに次から次に問題が出てくるのか、訳分からず、いい加減に腹立ってきました！

絶対に最初からvendorフォルダはあるはずだと思い、ひとつ前のバージョンの3.0.17を見つけダウンロードしたところ、やはりvendorフォルダが存在していました。（何で3.0.18には無かったのか？）
とりあえずインストールしようとしましたが、今度はweb.configファイルの構文に問題ありみたいなエラーが出てインストールできません。
もういい加減面倒くさくなってきたので、web.configファイルを削除してみたら、なんとインストールが始まりました。

インストールは無事完了しましたが、管理画面が出てきません。
ググったところ、管理画面のサブフォルダ名の前にindex.phpを入れると出るということだったので、やってみたら出ました。
基本情報を入力し、管理画面からサイトを確認したら、サイトもちゃんと表示されました。
バージョン2の標準サイトデザインはやはり古い感じでしたが、3ではかなり洗練されたものになっており、トップページには写真が自動スライド表示になっています。

次は肝心の決済プラグインです。
契約している業者のバージョン3用プラグインをダウンロードしました。
ところが、インストールしようとすると、「圧縮ファイルを確認してください」とエラーになります。
いったいこのEC-CUBEも決済プラグインも、どうなっているのか！無茶苦茶なシステムです。（ただやから文句も言えない・・・）

ダウンロードしたプラグインファイルは、拡張子.tar.gzの圧縮ファイルです。これを解凍したら.tarファイルができます。これも圧縮ファイルです。容量を小さくするために2段階圧縮をしているのです。
.tarファイルをEC-CUBEにアップロードしようとしたら、ファイルサイズがオーバーしていると断られました。
なので、PHPのupload最大容量設定を増やし、再度行ったらアップロードでき、インストールできました。（マニュアルにはこのことを書いておらず、非常に不親切です）
今度は通信エラーも発生せず、テスト決済も正常完了しました。

しかし、喜ぶのはまだ早かったのです。
「一難去ってまた一難」次の問題発生です。
管理画面からは全てのページが確認できるのですが、別のPCから確認すると、トップページは表示できるのですが、サブページのリンクをクリックすると、「存在しない」というエラーで表示されないのです。
管理画面から表示させた各ページのURLには、サブフォルダ名の前に必ずindex.phpが挿入されていますが、別PCから見る時のリンクにはindex.phpはありません。これが原因だと思われます。
どうもインストールする時に削除したweb.configが関係しているようで、このファイルの内容を確認したところ、URLの書き換えをしているようです。
とりあえずweb.configを元の場所に戻してみましたが、今度はトップページも表示されなくなりました。
やはりweb.configの構文エラーが出ます。

またググったところ、日本のサイトには答えが見つからなかったのですが、英語のサイトにヒントが見つかりました。
どうもIISの場合、URLリライト機能は標準搭載されていないらしいのです。
なので、「rewrite_amd64_ja-JP.msi」をダウンロードしてインストールすればよいらしいので、実行しました。
そうしたら、表示されるようになりました。

やれやれ、やっとECサイトを構築する目途がたちました・・・

結果的に考えてみると、殆どのつまずきの原因はIISにあるようです。
先述のように、IISのWebサーバーがごくマイナーなのがよく分かりました。
最初からApacheでやっていたら、こんなに苦労することは無かったかもしれません。

IISでEC-CUBEを動かすのにつまずいたこと

いろいろあって、当Webサイトでパソコンと関係の無い商品を売り出すことになりました。
当方自社Webサーバーを運用しており、IISで公開しています。なので、無料でECサイトを簡単に構築できる（らしい）EC-CUBEをIISで動かすことにしました。

◆つまずき-その1 「インストール画面が表示されない」

原因から言うと、dataフォルダのパス指定が間違っていたことでした。
IISで仮想ディレクトリを設定し、EC-CUBEのインストール・ディレクトリをリンクしました。
元々インストール・ディレクトリの中にあるdataフォルダは、セキュリティを考えると、外部からアクセスできない場所にに置いた方が良いらしいので、IISの公開ディレクトリであるwwwrootの親ディレクトリであるinetpubの中に移動しました。
そして、htmlフォルダの中にあるdefine.phpの3行目で、htmlフォルダから見たdataフォルダの位置を相対パスで指定しましたが、これが間違いでした。
実際には、仮想ディレクトリの元フォルダであるwwwrootの親をたどらず、実ディレクトリの親をたどるから、dataフォルダが見つからず、エラーになっていたのです。
基本的な勘違いでした。
ということで、dataフォルダをhtmlフォルダの親階層に移動させ、パスを「../../data」としたら、無事インストール画面が表示されるようになりました。

◆つまずき-その2 「インストールの最終段階でサーバー・エラー」

最終段階はデータベースの構築なので、データベースを作成し直せばよいという情報があり、やりましたが、だめでした。
IISでPHPを動かす場合、IISの[モジュールマップの追加]で、「FastCgiModule」として「php-cgi.exe」を登録する必要があるのですが、このモジュールのタイムアウト・エラーが原因でした。
php-cgi.exeの設定項目の[アクティビティ タイムアウト]の値を600に設定したら、無事インストールが完了しました。
しょぼいCPUを使っているからでしょうか？（一応デュアルコアですが）

◆つまずき-その3 「商品画像が登録できない」

これが一番苦労しました。
画像のサイズがphp.iniの設定サイズを超えているからという情報と、画像の保存フォルダのセキュリティ権限の問題という情報が殆どでしたが、画像のサイズは小さく、権限を設定してもだめでした。
何日も先人の情報を検索し、最後に見つけたものが、EC-CUBEとは関係なく、IIS+PHPでファイルのアップロードができないという情報でした。
PHPは、ファイルのアップロード時にphp.iniの「HTTPアップロードファイルの一時ディレクトリ」指定項目のupload_tmp_dirで指定されたディレクトリに一時的に保存する仕様になっており、そのディレクトリにIISの匿名認証ユーザーであるIUSRの書き込み権限を与える必要があります。これを設定していなかったために、エラーになっていた訳です。

どうもIIS+PHP環境はいろいろ難しいようです。
この環境でのWEBの情報が少ないのも、こういう理由があるからかもしれません。