2014年9月30日火曜日

テキスト読み上げ用の音声データ ダウンロードが終わらない場合の対処法

SYSTEM_KDです。

お昼にMy Androidスマホ(Xperia VL)をみると、通知部分にダウンロードのマークが出ていたので、アプリの更新かと思いつつ、通知表示部分を開くと、「テキスト読み上げ用の音声データ」がダウンロードされておりました。

down_err01

ダウンロードされるの自体は良いのですが、どうみてもダウンロードが上手くいってない。。

ということで、ダウンロードをやり直そうと思い、手っ取り早く端末を再起動してみたのですが、結果は

down_err01

・・・・・

・・・・・

・・・・・

変わらず、この通知表示が出続ける。
どうやら、真面目に止めないと止まってくれないようです。
(いや、通信してる形跡もなく、完全にとまってはいるのですが。。)

結構はレアケースだとは思いますが、同様の症状が起きた場合の止め方についてまとめておきます。
(まとめはXperia VLの場合ですが、他の機種でも同様の項目から可能なはず)

1.設定画面から、「言語と入力」を選択

setting01

2.言事入力から、「テキスト読み上げ」を選択

setting02

3.テキスト読み上げより、「Googleテキスト読み上げの設定」を選択

setting03

4.Googleテキスト読み上げの設定より、「音声データをインストール」を選択

setting04

5.言語から「日本語(日本)」を選択

setting05

6.対象のダウンロードを発見できたと思いますので、あとは✕ボタンで、停止します。

setting06

これで、ダウンロードを停止でき、ダウンロード中の通知が消えると思います。

ちなみに、もう一度、ダウンロードボタンを押してダウンロードすると、今度は正常にダウンロードできました。(んー最初は、なぜダウンロードできなかったんだろう)

2014年9月29日月曜日

EC-CUBEプラグインの基本的な機能について その2

SYSTEM_KDです。
今回も、前回に引き続き、EC-CUBEプラグインの基本的な機能についてです。

前回かなりざっくりEC-CUBEプラグインの基本的な機能について書かせて頂いたのですが、表面的な部分だけでしたので、もう少し掘り下げてみたいと思います。

どの部分を掘り下げるかといいますと、フックポイントの登録部分「register」の部分です。

フックポイント=処理へ介入できるポイントですが、実際どうやって実装するかと言うと、こんな感じです。

// フックポイントの設定
function register(SC_Helper_Plugin $objHelperPlugin) {
$objHelperPlugin->addAction('LC_Page_Abouts_action_after', array($this, 'abouts_after'));
}

これで、フックポイントとコールバック用の関数を設定しております。
と言ってもよくわからないかもしれませんので、細かく見ていきます。


まず、


$objHelperPlugin->addAction(


は、フックポイントを活かすよーという設定を行います。
どのフックポイントを活かすかと言いますと、引数の「LC_Page_Abouts_action_after」の部分になります。


実は、これは、「クラス名」 + “_action_” + 「タイミング」という形式で設定しており、上記ですと、「LC_Page_Abouts」(当サイトについてページ)の処理の「after(後)」をフックして処理を追加するといった具合になっております。


about


要するに、フックしたい処理(ページ)のクラス処理したいタイミングをくっつけた名前を指定します。


そして、フックした時に行う処理が、最後の「array($this, 'abouts_after')」の部分になります。
重要なのは、「abouts_after」の部分で、この名前がコールバック処理(実際にフックさせた時の処理)関数の名前になります。

function abouts_after($objPage) {
// フックした時の処理を記述
}

試しに、変更してみます。
function register(SC_Helper_Plugin $objHelperPlugin) {
$objHelperPlugin->addAction('LC_Page_Abouts_action_after', array($this, 'abouts_after'));
}

// aboutsページの処理終わりをフック
function abouts_after($objPage) {
$objPage->tpl_title = "タイトルの表示内容をフックした処理で変更!!";
}

主要部分をこんな感じで、記述してやると処理終わりをフックして、タイトルを変更できます。
about2


まとめ


処理をフックするには、「regster」へフックポイントを記述してやる。
フックポイントを設定するには
$objHelperPlugin->addActionを呼んでやる
どのページをフックするかは、「引数1」、フックした際の処理については「引数2」で指定する。

引数1の形式
フックするページのクラス + “_action_” + 処理タイミング


※処理タイミング
ページの処理を行う前に、フックする ・・・ begin
ページの処理を行った後、フックする ・・・ after


引数2の形式
好きな名前をつける!!


ってな感じです。


次回は、テンプレート(Smarty)の表示をフックして変更する方法について説明したいと思います。

2014年9月28日日曜日

EC-CUBEプラグインの基本的な機能について

SYSTEM_KDです。
最近は、プラグインから横道にそれていたのですが、本日はプラグインについてのお話。

前回までで、クローズサイト化プラグインを作成しましたが、グローバル(スーバー)フックしか説明していませんでしたので、今回は他の部分についてもざっくり説明できればと思います。

具体的には、EC-CUBEプラグイン特有の下記functionについて説明できればと思います。

// インストール
function install($arrPlugin) {
}

// アンインストール
function uninstall($arrPlugin) {
}

// 稼働
function enable($arrPlugin) {
}

// 停止
function disable($arrPlugin) {
}

// フックポイントの設定
function register(SC_Helper_Plugin $objHelperPlugin) {
}

まずは、「install」と「uninstall

function install($arrPlugin) {
}
function uninstall($arrPlugin) {
}

こちらは、言うまでもないかもしれませんが、EC-CUBEへプラグインをインストールした際に動作するものと、EC-CUBEからプラグインをアンインストールした際に動作するものになります。


installの用途としましては、プラグインに必要なファイル(画像、CSS、ソース)等を必要な場所へコピーする際や、テーブルの拡張が必要な際にSQLを実行するタイミングとして利用します。


uninstallの用途としましては、インストール時にコピーしたファイルの削除拡張したテーブルを元に戻す際に利用します。


続きまして「enable」と「disable

function enable($arrPlugin) {
}
function disable($arrPlugin) {
}

こちらも、説明するほどではないかもしれませんが、EC-CUBEへインストールしたプラグインを有効にした際に動作するものと、無効にした場合に動作する部分になります。


用途としましては、有効・無効にする際にチェック処理が必要な場合等に利用できます。
例えば、外部と連携するプラグインなどの場合に、有効時に外部へ接続できるかの確認を行う。
無効時には、プラグインが停止することを外部に伝えるといった感じです。


次は「register

function register(SC_Helper_Plugin $objHelperPlugin) {
}

ここは、フックポイントを設定する部分になります。
フックポイントというのは、処理へ介入する部分となります。


グローバルフックの場合は、常に動作する(介入する)処理でしたが、こちらでは個別での介入ポイントを指定する形になります。


だいたい全てのページの開始終了時に介入して処理を追加することができるようになっている他、テンプレート(Smarty)についてもフックして、表示を変更したりすることができるようになっております。
(詳しくは随時説明できればと思っております。)


また、フックポイントは、この「register」で設定するだけでなく、「plugin_info.php」でも設定が可能です。

static HOOK_POINTS = array( フックポイントの設定 );

上のように、array でフックポイント設定してやることで「register」で設定しなくてもフックポイントを設定できます。


通常の処理については、こんなところです。
他に、プラグインを更新(アップデート)した際に実行される処理なんかもあるのですが、そんなに利用することはないと思いますので、利用する際に書ければと思います。

2014年9月27日土曜日

EC-CUBEにスマホでアクセスしてもPCサイトを表示するには(完全版)

SYSTEM_KDです。

少し前に、EC-CUBEにスマホでアクセスしてもPCサイトを表示するにはという記事を書かせて頂いたのですが、その際の下記の問題の対処方を書きたいと思います。

その問題というのは、デバイスタイプを強制的にPCへ書き換えているので、受注データ作成時に設定されるデバイスがPCになってしまうというものです。

問題をおさらいすると、スマホでアクセスした際にPCサイト(ページ)を表示するのは、SC_Display.phpをちょこっと書き換えれば良いけど、それだけでは、実際にスマホから購入されても、管理画面の受注管理で表示される端末種別が「PC」になってしまうということでした。

さっそく対処法です。

今回も、data/class/SC_Display.php を書き換えます。

スマホでもPCページを返すため「detactDevice」を変更しましたが、まずこのメソッドをコピーして、名前を「detectDevice」から「detectDeviceReal」へ変更します。
(detectDeviceとは別に、detectDeviceRealを追加する感じです)

そして、中身をこんな感じで書き換えます。

// 本来のデバイスタイプを返却
public static function detectDeviceReal($reset = FALSE) {
$nu = new Net_UserAgent_Mobile();
$su = new SC_SmartphoneUserAgent_Ex();
if ($nu->isMobile()) {
$device_type = DEVICE_TYPE_MOBILE;
} elseif ($su->isSmartphone()) {
$device_type = DEVICE_TYPE_SMARTPHONE;
} else {
$device_type = DEVICE_TYPE_PC;
}
return $device_type;
}

何をしているかと言いますと、コメントの通り「本来のデバイスタイプ」を返却しているだけです。

あとは、前回の記事でも少し書いたとおり、「SC_Helper_Purchase.php」の「saveOrderTemp」でデバイス情報をDBへ設定する際に、このメソッドから正しいデバイスを取得して、設定すればOKです。

[変更ソース]
data/class/helper/SC_Helper_Purchase.php

function saveOrderTemp($uniqId, $params, &$objCustomer = NULL) {
if (SC_Utils_Ex::isBlank($uniqId)) {
return;
}
$params['device_type_id'] = SC_Display_Ex::detectDeviceReal();
$objQuery =& SC_Query_Ex::getSingletonInstance();
// 存在するカラムのみを対象とする
$cols = $objQuery->listTableFields('dtb_order_temp');
$sqlval = array();
foreach ($params as $key => $val) {
if (in_array($key, $cols)) {
$sqlval[$key] = $val;
}
}
// 以下 省略 //

5ステップ目の部分を、

$params['device_type_id'] = SC_Display_Ex::detectDevice();

から

$params['device_type_id'] = SC_Display_Ex::detectDeviceReal();

へ変更します。

これで、スマホからアクセスして購入した場合に、端末種別が「PC」ではなく「スマートフォン」として表示されます。

Android SDK Manager で Broken

たまには、Androidネタをはさんでみる。

最近ようやくWiMAX2+の電波がやってきたので、うれしげに色々とダウンロードして、やっぱ早いなーと楽しんでいたのですが、その流れでAndroid SDK Managerをアップデートしたら、何かエラーが発生してしまいましたという話。

エラー内容としては

Android_SDK_Manager_error

Extras の中身が色々とBroken

Broken ARM EABI v7a
Broken Intel x86 Atom
・・・

ちょっと焦りましたが、「Google Play service for Fit Preview」をインストールしてないことが原因の様でした。

さすが、stackoverflow。ありがたやありがたやm(__)m

というわけで、、「Google Play service for Fit Preview」にチェックを入れ、インストールで解決!!

Android_SDK_Manager_error2

めでたしめでたし。

2014年9月25日木曜日

EC-CUBEにスマホでアクセスしてもPCサイトを表示するには

SYSTEM_KDです。

今日は、EC-CUBEの小ネタを投稿。

EC-CUBE(バージョン2.11以降)で、スマホの対応が行われ、PCスマホモバイル(ガラケー)の表示が行えるようになりました。

スマホが全面に出てきたイコール、モバイルの収束ということで、モバイルについてはパラメータでモバイルサイトを利用するかどうか、設定できるようになっております。

管理画面だと
parameter_cap

パラメータファイル上だと

/** モバイルサイトを利用するか(true:利用する、false:利用しない) (false は一部対応) */
define('USE_MOBILE', true);

部分になります。

では、スマホサイトを利用したくない場合はどうすれば良いでしょう?

そもそもそんな用途あるのか、という気もしますが、「PC側カスタマイズしてみたけど、スマホまで手が回らないから一時的に、PCページに飛ばしたい」とかあるかもしれません。

どうすれば良いかですが、わりきってしまえば意外と簡単です。

data/class/SC_Display.php の下記の場所をちょこっと変更します。

public static function detectDevice($reset = FALSE) {
if (is_null(SC_Display_Ex::$device) || $reset) {
$nu = new Net_UserAgent_Mobile();
$su = new SC_SmartphoneUserAgent_Ex();
if ($nu->isMobile()) {
SC_Display_Ex::$device = DEVICE_TYPE_MOBILE;
} elseif ($su->isSmartphone()) {
SC_Display_Ex::$device = DEVICE_TYPE_SMARTPHONE;
} else {
SC_Display_Ex::$device = DEVICE_TYPE_PC;
}
}
return SC_Display_Ex::$device;
}

変更する場所は、スマホのデバイスタイプを設定している箇所

SC_Display_Ex::$device = DEVICE_TYPE_SMARTPHONE;

を変更して、下記の様にします。

public static function detectDevice($reset = FALSE) {
if (is_null(SC_Display_Ex::$device) || $reset) {
$nu = new Net_UserAgent_Mobile();
$su = new SC_SmartphoneUserAgent_Ex();
if ($nu->isMobile()) {
SC_Display_Ex::$device = DEVICE_TYPE_MOBILE;
} elseif ($su->isSmartphone()) {
// 変更前 SC_Display_Ex::$device = DEVICE_TYPE_SMARTPHONE;
SC_Display_Ex::$device = DEVICE_TYPE_PC;
} else {
SC_Display_Ex::$device = DEVICE_TYPE_PC;
}
}
return SC_Display_Ex::$device;
}

これで、スマホでアクセスしてもPCのレイアウトへ遷移します。

簡単にできるだけに、弊害もあります。
最初に、わりきってしまえばと書いたのはそのためです。

その問題というのは、デバイスタイプを強制的にPCへ書き換えているので、受注データ作成時に設定されるデバイスがPCになってしまうというものです。

要するに、スマホで購入されても、管理画面の「受注管理」内にある「アクセス端末」が「PC」になってしまいます。

とはいえ、あんまり重要な情報でないような気もしますし、見る人はGoogle Analyticsとかでみるだろうから問題ないはず。

どうしても、ちゃんとした内容にしたいという人は、「SC_Helper_Purchase」の「saveOrderTemp」でデバイス情報をDBへ設定する際に、正しいデバイスを設定してやれば良いはず。
(未確認です。気が向いたら確認します!!)


1ステップの変更で対応できるなら、ちゃちゃっとプラグイン化したい所ですが、プラグインにしようとすると実は結構難しかったり。という話を近々やろうと思ってます。

2014年9月24日水曜日

EC-CUBE クローズ化サイトプラグインを作成(後編)

前編(リンク)で、クローズ化サイトプラグインを作成するための準備を整えましたので、後編では一気に完成させたいと思います。

[全ステップ]
1.プラグイン作成の準備 > 前編で対応
2.常に動作する処理の実装 > 前編で対応
3.クーロズ化に必要なパターンへの対応

では、最後のステップ
3.クーロズ化に必要なパターンへの対応
を行って、完了させましょう!!

とは言え、クローズ化に必要なパターンって一体なんだろうとなりますね。

・会員はアクセスできる必要があるけど、非会員はアクセスできてはダメ。

は必要そうですが、
非会員でも、ログイン画面にはアクセスできる必要がある。
メールとかで、ログイン情報が通知されるのなら良いですが、会員登録ができないとクローズ過ぎるサイトですし。。

管理画面は、普通にアクセスしたいってのもありますね。

考えだすと色々なパターンがありそうなのですが、今回はシンプルに、次のパターンで進めたいと思います。

  • TOPページは誰でもアクセス可能
  • 非会員は、会員登録画面・ログイン画面にアクセス可能。それ以外のページはTOPページへリダイレクト
  • 会員はアクセス可能
  • 管理画面はアクセス可能

どれからやっても良いですが、「管理画面はアクセス可能」から対応したいと思います。
問題になってくるのは、今表示されようとしている画面が管理画面かどうかを、どうやって判断するかになってくると思います。

[Q.現在のページが管理画面かどうかを判断するには?]

その疑問を解くヒントは引数部分にあります!!

LC_Page $objPage

ですね。
これにページの情報が詰まってますので、これを使って、ページを判断したいと思います。

function preProcess(LC_Page $objPage) {
if (strstr(get_class($objPage), "Admin") != "") {
// 管理画面のためアクセスOK
return;
}
}

幸い、管理画面のページ(のクラス)には全て「Admin」がはいっておりますので、それを利用してAdminかどうか判断をしています。
と、言ってもこのままでは本当に上手くいているか確認できませんので、もう1文追加します。

function preProcess(LC_Page $objPage) {
if (strstr(get_class($objPage), "Admin") != "") {
// 管理画面のためアクセスOK
return;
}

header('Location: ' . TOP_URLPATH);
exit;
}

これで実行すると、管理画面以外はTOPページへリダイレクトされます。
いや、され続けて永久ループします。(ダメじゃん)


ですので、TOPページはTOPページへリダイレクトさせないようにします。

function preProcess(LC_Page $objPage) {
if (strstr(get_class($objPage), "Admin") != "") {
// 管理画面のためアクセスOK
return;
}

if (TOP_URLPATH == $_SERVER["REQUEST_URI"]) {
// TOPページはリダイレクトしない
return ;
}

header('Location: ' . TOP_URLPATH);
exit;
}

これで、管理画面側は普通に見れて、フロント側はTOPページへ遷移します。
と言いたいとこですが、管理側ページで上手く表示されないページがあります。
どこでしょうか?


正解は、


 


オーナーズストア>モジュール管理>モジュール一覧
です。


このページのクラスには「Admin」がついていないためです。
改善してみます。

function preProcess(LC_Page $objPage) {
if (strstr(get_class($objPage), "Admin") != ""
|| strstr(get_class($objPage), "Upgrade")) {
// 管理画面のためアクセスOK
return;
}

if (TOP_URLPATH == $_SERVER["REQUEST_URI"]) {
// TOPページはリダイレクトしない
return ;
}

header('Location: ' . TOP_URLPATH);
exit;
}

Upgrade」も許可してやれば、「モジュール一覧」へアクセスできるようになります。


同じ要領で、ログインと会員登録・パスワードリマインダーあたりをリダイレクトさせないようにすれば、良さそうですが、その前に「会員はアクセス可能」を追加しておきたいと思います。


この処理を追加すればOKです。

$objCustomer = new SC_Customer_Ex();
if($objCustomer->isLoginSuccess(true)) {
// 会員はアクセス可能
return ;
}

上記のコードを追加すると全体は

function preProcess(LC_Page $objPage) {
if (strstr(get_class($objPage), "Admin") != ""
|| strstr(get_class($objPage), "Upgrade")) {
// 管理画面のためアクセスOK
return;
}

if (TOP_URLPATH == $_SERVER["REQUEST_URI"]) {
// TOPページはリダイレクトしない
return ;
}

$objCustomer = new SC_Customer_Ex();
if($objCustomer->isLoginSuccess(true)) {
// 会員はアクセス可能
return ;
}

header('Location: ' . TOP_URLPATH);
exit;
}
こんな感じですね。

では、今度こそフロントの必要なページを許可してやります。

function preProcess(LC_Page $objPage) {
if (strstr(get_class($objPage), "Admin") != ""
|| strstr(get_class($objPage), "Upgrade")) {
// 管理画面のためアクセスOK
return;
}

if (TOP_URLPATH == $_SERVER["REQUEST_URI"]) {
// TOPページはリダイレクトしない
return ;
}

$objCustomer = new SC_Customer_Ex();
if($objCustomer->isLoginSuccess(true)) {
// 会員はアクセス可能
return ;
}

$filename = $objPage->arrPageLayout['filename'];

// 許可するページを指定
$arrAccessPage = array(
'mypage/',
'entry/',
'login',
''
);

foreach($arrAccessPage as $pagename) {
if (strstr($filename, $pagename) != "" || $filename == $pagename) {
return;
}
}

header('Location: ' . TOP_URLPATH);
exit;
}

完成です!!


これで、マイページ・会員登録・ログイン以外へは非会員はアクセスできないクローズ化の完成です。


ちなみに、許可するページのarrayを設定する際に、'' があるのは、ログイン時の処理「LC_Page_FrontParts_LoginCheck」では、arrPageLayoutが設定されないのを回避するための指定になります。


上記のクローズ化では非会員が見れるものをかなり限定しておりますが、「当サイトについて」「お問い合わせ」は見せたいという場合は、「$arrAccessPage」に「abouts」「contact/」を追加するだけで、簡単に対応が可能です。


また、今回は許可するページをソースコードに直書きしてますが、定数(パラメータ)に移動させたり、DBに保持したりすれば、アイデア次第で結構汎用性のあるクローズ化サイトプラグインができるのではないでしょうか?


今回、プラグインを作っている間に色々とプラグインのネタを思いつきましたので、このブログで作っていけたらと思います。


今日のプラグインの完成版はこちらです。

EC-CUBE クローズ化サイトプラグインを作成(前編)

新しいノートを使うとき最初のページは綺麗に使おうと頑張りますよね。
ということで、始めのうちは頑張って更新します!!(謎

気を取り直して、前回の宣言通り、機能するプラグインを作りたいと思います。

何のプラグインを作るかといいますと、クローズサイト化プラグインを作りたいと思います。
(タイトルに出てますが)


クローズドサイト化は、会員のみしかアクセスできないようにするということです。
会員限定サイトや、企業間取引サイト(BtoBサイト)を作る際に必要な機能になります。

こったものを作ろうと思うと、大変ですが会員でないとアクセス出来ないようにするだけであれば、それほど難しくないと思いますので、今回も3ステップで作りたいと思います。

1.プラグイン作成の準備
2.常に動作する処理の実装
3.クーロズ化に必要なパターンへの対応

では、早速
1.プラグイン作成の準備

前回作成(リンク)したプラグインのベースをプラグイン用に整備したいと思います。

まず、プラグインのベースをコピーして、ファイル名を変更します。

変更するファイルはもちろん「PluginBase.php」になります。
今回作成するプラグインはクローズサイト化のプラグインですので、名前はそれっぽくMyCloseSiteにしてみます。

[ファイル名の変更]
PluginBase.php」→「MyCloseSite.php

ファイル名の変更が終わったら、TopicPathを変更した際と同様に、「MyCloseSite.php」をエディタで開き「PluginBase」を「MyCloseSite」へ置換します。

また、「plugin_info.php」をエディタで開き、クローズサイト化プラグイン用に書き換えます。

こんな感じになるかと思います。

class plugin_info{
/** プラグインコード(必須):プラグインを識別する為キーで、他のプラグインと重複しない一意な値である必要がありま. */
static $PLUGIN_CODE = "MyCloseSite";
/** プラグイン名(必須):EC-CUBE上で表示されるプラグイン名. */
static $PLUGIN_NAME = "クローズサイト化プラグイン";
/** クラス名(必須):プラグインのクラス(拡張子は含まない) */
static $CLASS_NAME = "MyCloseSite";
/** プラグインバージョン(必須):プラグインのバージョン. */
static $PLUGIN_VERSION = "1.0";
/** 対応バージョン(必須):対応するEC-CUBEバージョン. */
static $COMPLIANT_VERSION = "2.13.2";
/** 作者(必須):プラグイン作者. */
static $AUTHOR = "[作成者の名前]";
/** 説明(必須):プラグインの説明. */
static $DESCRIPTION = "会員限定サイト化プラグインです";
/** プラグインURL:プラグイン毎に設定出来るURL(説明ページなど) */
static $PLUGIN_SITE_URL = "";
/** ライセンス */
static $LICENSE = "LGPL";
}

せっかくなので、plugin_info について少し解説したいと思います。
(そんなに詳しくはないですが。。)

$PLUGIN_CODE [必須]
 ・・・ コメントの通りですがプラグインを識別する為のキーになります。一意になる値を指定すればOKです。

$PLUGIN_NAME [必須]
 ・・・ これまたコメントの通りですが、EC-CUBE上に表示される名称になります。作成したプラグインの名前になるかと思います。

$CLASS_NAME [必須]
 ・・・ プラグインのクラス名を設定します。今回ですと、「MyCloseSite.php」のクラス名を指定してやります。ここで指定したクラスが、プラグインのメインとして動作します。

$PLUGIN_VERSION [必須]
 ・・・ プラグインのバージョンです。対応しているEC-CUBEのバージョンを指定します。記述方法のチェックはないですが、2.13.0~2.13.2など分かりやすくした方が良いかと思います。

$AUTHOR [必須]
 ・・・ プラグインの作成者を設定します。好きなように指定して大丈夫です。

$DESCRIPTION [必須]
 ・・・ プラグインの説明を設定します。好きなように指定して大丈夫です。

$PLUGIN_SITE_URL [必須]
 ・・・ URLを設定できます。EC-CUBEの管理画面にてプラグインを確認した際、リンクとして設定されます。

$LICENSE [必須]
 ・・・ ライセンスを指定します。

※必須となっている項目を設定していない状態で、EC-CUBEへインストールを行ってもエラーは発生しませんが、正しく動作しなくなりますので、ご注意ください。

ソースの準備はこれで完了ですが、このままでは動作の確認を行いながら作成することが難しいので、EC-CUBEへインストールしたいと思います。

現在あるファイルを「tar.gz」で圧縮しプラグインにします。
(※推奨はtar.gz ですが、tarでもインストール可能です)

[圧縮対象]
MyCloseSite.php
logo.png
plugin_info.php
plugin_update.php

圧縮後のファイル名は、分かりやすく「MyCloseSite.tar.gz」にします。圧縮できたら、EC-CUBEの管理画面へ作成したプラグインをインストールします。
圧縮できたら、EC-CUBEの管理画面へ作成したプラグインをインストールします。

エラーなくインストールができれば、ステップ1は完了です。

おそらくこんな感じで登録されるかと思います。

pc0007

エラーが出た場合は、エラーログを確認したり、plugin_info.php、MyCloseSite.phpを確認したりして対処します。


では、続いてステップ2
2.常に動作する処理の実装
へ進みます。

具体的に何をするかと言いますと、ソースコードを「MyCloseSite.php」へ追加します。

インストールしたファイルへ追加する必要がありますので、プラグインのインストールを行ったEC-CUBEの下記のパスのファイルを開きます。

[変更対象ファイル]
data/downloads/plugin/MyCloseSite/MyCloseSite.php

ファイルを開いたら、以下のコードを追記します。

// グローバルフックポイント
function preProcess(LC_Page $objPage) {
// 常に動作させたい処理を記述
}

この処理は、グローバル(スーパー)フックポイントとなっており、サイトへアクセスがある度に毎回呼ばれる処理となっております。

EC-CUBEのプラグインの中で、自動実行する機能が付いているけど、cronの設定が必要ないものは、この処理をトリガーにして動作しています。
ですので、自動実行と言いつつ全くアクセスがない場合は、動作しなかったりします。

アクセスがある度に呼ばれるので、便利なフックポイントとなっておりますが、重い処理を記述してしまうとサイトの動作が一気に重くなりますので、注意が必要です。

とりあえず、どうなるか試しに何か表示してみましょう。

// グローバルフックポイント
function preProcess(LC_Page $objPage) {
// 常に動作させたい処理を記述
print_r("preProcess");
}

こんな感じで記述して、トップページを表示させてみます。

pc0008

左上に、"preProcess"の文字が表示されました。

どの画面へ遷移しても表示されていると思います。

管理画面へ遷移しても同じです。

pc0009

すばらしいですね。


プラグイン機能を利用せず、同じことをやろうとすると、LC_Page.phpに書くのかな?処理の内容次第では他に良いとこがあるようなと、悩みそうですが、自信を持ってかける分楽ですね
(って私が小心者だからかな?)

ということで、ぼちぼちな分量になってきたので、前編は終了です。

(後編に続く)

2014年9月23日火曜日

EC-CUBEのプラグイン(ベース)の作成

初回の投稿記念ということで、続けてもう1つ

さっそくEC-CUBEのプラグインを自分で作ってみよう、あわよくば売ってみようなノリで進めていきます!!

(まぁ、実際のところ企業で有料プラグインを作成して販売した場合、人気の有料プラグインに入るぐらいのダウンロード数がないと旨味がないと思いますが、個人なら少しのダウンロードでも良いお小遣いになる気がします)

pc0002
(今日現在の人気プラグイン)

 

前置きはこのくらいにしておいて、本題です。

まず、何から始めるかといいますと、プラグインをダウンロードするところから始めましょう。
完全によくあるパターンのやつなのですが、最近上場された、株式会社ロックオン様が作成された「パンクズプラグイン」をダウンロードし、それを変更します。

[ダウンロード]
プラグインのページはこちらになります。

初期に公開された+ベースにするという用途でダウンロードされているので、すごいダウンロード数になってますね。

ダウンロードするには、会員になる必要がありますが、無料ですので登録しちゃってください。


ダウンロード後、どういう手順で進めるかと言いますと

1.パンクズプラグインを解凍

2.名前を変えて、不要なファイルを削除

3.不要な記述をカットして、プラグインのベース完成

という(無理やり)3ステップだけです!!

 

では、さっそく

1.パンクズプラグインを解凍

にとりかかりたいと思います。

まず、ダウンロードしたプラグインを見てみましょう。
tar.gzの形式で圧縮されているかと思います。

プラグインといっても、ルールに則って作成したphpのコードを圧縮しただけのものになりますので、適当な解凍ツールで解凍してください。
解凍すると、結構な数のファイルが入っているかと思いますが、解凍できればステップ1は完了です。

 

続いてステップ2の
2.名前を変えて、不要なファイルを削除

に進みたいと思います。

ベースを作るために不要な部分をカットしようと思いますが、どの部分が不要かといいますと、大半です。
(まぁベース用なので、そりゃそうですね)

ディレクトリを名前の昇順に設定して、不要なのは上から

pc0004
bloc > ディレクトリまるごと
media > ディレクトリまるごと
templates > ディレクトリまるごと
config.php
LC_Page_FrontParts_Bloc_TopicPath.php
LC_Page_Plugin_TopicPath_Config.php

になります。
このファイルフォルダ削除します。

削除したら、残ったファイルは次の4つになるかと思います。

pc0005
logo.png
plugin_info.php
plugin_update.php
TopicPath.php

続いて、ファイル名を変更と言いつつ変更していないので、変更します。

変更対象のファイルは「TopicPath.php」になります。

こちらは、好きな名前で良いですが、ベースなので「PluginBase.php」に変えようと思います。

pc0006
(こんな感じです)

これで、ステップ2も終了です。

 

いよいよ最後のステップ
3.不要な記述をカットして、プラグインのベース完成
に進みます。

最後のステップというだけあって、今までの作業に比べると多少手間がかかります。

名前を変更したファイル「PluginBase.php」をエディタで開き、
ベースにするため、表示されたソースコードの不要な部分をカットしていきます。

まずカットする前に、「TopicPath」の記述を全て、先ほど変更したファイル名「PluginBase」に置換します。

次にソースコード内の以下の場所を削除していきます。

function install($arrPlugin) {     
// [削除] PluginBase::insertBloc($arrPlugin);
// [削除] PluginBase::insertFreeField();

// 必要なファイルをコピーします.
// [削除] copy(PLUGIN_UPLOAD_REALDIR . "PluginBase/templates/plg_PluginBase_PluginBase.tpl", TEMPLATE_REALDIR . "frontparts/bloc/plg_PluginBase_PluginBase.tpl");
// [削除] copy(PLUGIN_UPLOAD_REALDIR . "PluginBase/bloc/plg_PluginBase_PluginBase.php", HTML_REALDIR . "frontparts/bloc/plg_PluginBase_PluginBase.php");
// [削除] copy(PLUGIN_UPLOAD_REALDIR . "PluginBase/config.php", PLUGIN_HTML_REALDIR . "PluginBase/config.php");
copy(PLUGIN_UPLOAD_REALDIR . "PluginBase/logo.png", PLUGIN_HTML_REALDIR . "PluginBase/logo.png");
// [削除] mkdir(PLUGIN_HTML_REALDIR . "PluginBase/media");
// [削除] SC_Utils_Ex::sfCopyDir(PLUGIN_UPLOAD_REALDIR . "PluginBase/media/", PLUGIN_HTML_REALDIR . "PluginBase/media/");
}

ロゴ画像をコピーしている部分以外は全て削除になります。
※ステップ2で書き忘れたのですが、このlog.png がプラグインのロゴ画像になります。

ちなみに、この「install」部分がEC-CUBEの管理画面よりプラグインをインストールした際に動作する部分になります。

次は、uninstall部分に移ります。

(説明するまでもないかもしれませんが、この部分がEC-CUBEの管理画面よりプラグインをアンインストールした際に動作する部分になります)

function uninstall($arrPlugin) {
// [削除] $objQuery = SC_Query_Ex::getSingletonInstance();
// [削除] $arrBlocId = $objQuery->getCol('bloc_id', "dtb_bloc", "device_type_id = ? AND filename = ?", array(DEVICE_TYPE_PC , "plg_PluginBase_PluginBase"));
// [削除] $bloc_id = (int) $arrBlocId[0];
// [削除] // ブロックを削除する.
// [削除] $where = "bloc_id = ?";
// [削除] $objQuery->delete("dtb_bloc", $where, array($bloc_id));
// [削除] $objQuery->delete("dtb_blocposition", $where, array($bloc_id));

// [削除] // メディアディレクトリ削除.
// [削除] SC_Helper_FileManager_Ex::deleteFile(PLUGIN_HTML_REALDIR . "PluginBase/media");
// [削除] SC_Helper_FileManager_Ex::deleteFile(TEMPLATE_REALDIR . "frontparts/bloc/plg_PluginBase_PluginBase.tpl");
// [削除] SC_Helper_FileManager_Ex::deleteFile(HTML_REALDIR . "frontparts/bloc/plg_PluginBase_PluginBase.php");
// [削除] SC_Helper_FileManager_Ex::deleteFile(PLUGIN_HTML_REALDIR . "PluginBase");
}

処理部分は、全て削除となります。

じゃんじゃん進みます。

function register(SC_Helper_Plugin $objHelperPlugin) {
// [削除] // ヘッダへの追加
// [削除] $template_dir = PLUGIN_UPLOAD_REALDIR . 'PluginBase/templates/';
// [削除] $objHelperPlugin->setHeadNavi($template_dir . 'plg_PluginBase_header.tpl');
}

同じく、処理部分は全て削除

この2つについては、呼ぶだし部分を削除したので、functionまるごと削除します。

// [削除] // プラグイン独自の設定データを追加
// [削除] function insertFreeField() {
// [削除] $objQuery = SC_Query_Ex::getSingletonInstance();
// [削除] $sqlval = array();
// [削除] $sqlval['free_field1'] = "1";
// [削除] $sqlval['free_field2'] = "1";
// [削除] $sqlval['update_date'] = 'CURRENT_TIMESTAMP';
// [削除] $where = "plugin_code = ?";
// [削除] // UPDATEの実行
// [削除] $objQuery->update('dtb_plugin', $sqlval, $where, array('PluginBase'));
// [削除] }

// [削除] function insertBloc($arrPlugin) {
// [削除] $objQuery = SC_Query_Ex::getSingletonInstance();
// [削除] // dtb_blocにブロックを追加する.
// [削除] $sqlval_bloc = array();
// [削除] $sqlval_bloc['device_type_id'] = DEVICE_TYPE_PC;
// [削除] $sqlval_bloc['bloc_id'] = $objQuery->max('bloc_id', "dtb_bloc", "device_type_id = " . DEVICE_TYPE_PC) + 1;
// [削除] $sqlval_bloc['bloc_name'] = $arrPlugin['plugin_name'];
// [削除] $sqlval_bloc['tpl_path'] = "plg_PluginBase_PluginBase.tpl";
// [削除] $sqlval_bloc['filename'] = "plg_PluginBase_PluginBase";
// [削除] $sqlval_bloc['create_date'] = "CURRENT_TIMESTAMP";
// [削除] $sqlval_bloc['update_date'] = "CURRENT_TIMESTAMP";
// [削除] $sqlval_bloc['php_path'] = "frontparts/bloc/plg_PluginBase_PluginBase.php";
// [削除] $sqlval_bloc['deletable_flg'] = 0;
// [削除] $sqlval_bloc['plugin_id'] = $arrPlugin['plugin_id'];
// [削除] $objQuery->insert("dtb_bloc", $sqlval_bloc);
// [削除] }

これで、大物は終了しました。

あと一息、「plugin_info.php」を変更したいと思います。

こちらは、プラグインの設定ファイルの様なものですので、削除というか作成するプラグインに合わせて設定する様な形になります。

では、先ほどと同じように「plugin_info.php」をエディタで開きます。

まぁ、書いてある通りですし、ベース様なのであんまり変更する意味はないのですが、次の用に変更します。

class plugin_info{
/** プラグインコード(必須):プラグインを識別する為キーで、他のプラグインと重複しない一意な値である必要がありま. */
static $PLUGIN_CODE = "PluginBase";
/** プラグイン名(必須):EC-CUBE上で表示されるプラグイン名. */
static $PLUGIN_NAME = "プラグイン作成のベース";
/** クラス名(必須):プラグインのクラス(拡張子は含まない) */
static $CLASS_NAME = "PluginBase";
/** プラグインバージョン(必須):プラグインのバージョン. */
static $PLUGIN_VERSION = "0.1";
/** 対応バージョン(必須):対応するEC-CUBEバージョン. */
static $COMPLIANT_VERSION = "2.12.0";
/** 作者(必須):プラグイン作者. */
static $AUTHOR = "[作成者の名前を記入]";
/** 説明(必須):プラグインの説明. */
static $DESCRIPTION = "プラグインのベースに利用";
/** プラグインURL:プラグイン毎に設定出来るURL(説明ページなど) */
static $PLUGIN_SITE_URL = "";
/** ライセンス */
static $LICENSE = "LGPL";
}

これでステップ3も終了です!!


ということで、プラグインのベースができました。
一応、こちらに完成版をアップしております。

いま、変更したファイルをtar.gzで圧縮してEC-CUBEの管理画面よりインストールすれば、ロゴだけセットされたプラグインがインストールされます。

今回は、ほとんどプラグインのソースコードについて説明しませんでしたが、実際にプラグインを作成していく際に説明したいと思います。


EC関連のブログを書きながら、【EC-CUBE管理サポートアプリ】ACCubeにも興味をもってもらえたら良いなとか思っていましたが、どう考えてもブログの内容が、ACCubeのターゲット向けでない気がしております。。
(よろしければ周りのEC-CUBEショップオーナー様にACCubeを勧めてくださいということで。。m(_ _)m)


次回からは、このプラグインのベースを使って実際に機能するプラグインを作成したいと思います。

EC-CUBE関連のBlogでもはじめてみようかと・・・

初めまして、SYSTEM_KDです。

EC-CUBEに携わっているので、EC-CUBE関連のネタを中心にブログでも書こうかと思います。
(あとAndroidとか)
とは言え、EC-CUBE関連のサイト、ブログは山ほどありますし、発信できる程の情報を持っている自信はないので、まぁ細々とやっていこうかなと思ってます。

書き始めて早々ネタが無くなるのもさみしいので、しばらくはEC-CUBEのプラグインの作り方について書きたいと思います。

だいぶ浸透してきたと思いますが、プラグイン機能は、EC-CUBEのバージョン2.12で導入された目玉機能(?おそらく)になります。

プラグイン自体はEC-CUBEのオナーズストアで公開されており、結構な数が公開されております。

pc0001

また、プラグインは有料・無料、月額制と用意されております。

有料プラグインの価格は幅広く、500円・1000円のものから4~5万円するものまであります。

個人的なイメージとしましては、初期のころに登録されたプラグインは安め(1万円未満)で、
最近のものは高くなってきた(3万円前後)様な印象があります。

これは、始めのころは、無料プラグインのみで、有料販売はなかったため価格設定が難しかったとか、
単純に作り込んだプラグインが出てきたため、価格が上がったとかあるのではないかと勝手に思ってます。

とは言え、普通にシステム会社へカスタマイズを依頼するよりは、費用を抑えることができると思いますので、利用してみると良いのではないかと思います。

と言うことで突如始めた「SYSTEM_KDのブログ」、今後どうなっていくか不明ですが右往左往しながら進んで行こうと思います。

(ブログって1記事でどのくらいの量を書くんだろう。。)