------------------------------------------------------------------------------------------
[EC-CUBE] 3.0.17　新規インストール
[レンタルサーバ] 自社サーバー
[OS] centos6
[PHP] 7.1.26
[データベース] MySQL 5.7.25
[WEBサーバ] apache 2.2
[導入プラグインの有無] Pointプラグイン
[カスタマイズの有無] 無し
------------------------------------------------------------------------------------------

当方、PHPは10年、ECサイトの開発（独自PKG）は8年以上のSEです。

今回ユーザーの要望により初めてEC-CUBEをベースとしてカスタマイズする事になりましたが、カスタマイズの方法が合っているのか？の判断が付かず、質問させて頂きました。

【改修内容】
　新着情報をblockではなく、新着情報一覧、新着情報詳細と独立した画面にする。

【修正内容（商品一覧の機能をコピーして作成）】
　①「/PROJECT_ROOT/src/Eccube/Resource/template/default」配下に「News」ディレクトリを作成し「list.twig」を作成。
　②「/PROJECT_ROOT/src/Eccube/Controller」配下に「NewsController.php」を作成。
　③「/PROJECT_ROOT/src/Eccube/Event/EccubeEvents.php」に下記を追加。
　　　const FRONT_NEWS_INDEX_INITIALIZE = 'front.news.index.initialize';
　④「/PROJECT_ROOT/src/Eccube/ControllerProvider/FrontControllerProvider.php」に下記を追加。
　　　$c->match('/news/list', '\Eccube\Controller\NewsController::index')->bind('news_list');
　　　$c->match('/news/detail/{id}', '\Eccube\Controller\NewsController::detail')->bind('news_detail')->assert('id', '\d+');
　⑤下記のSQLを実行
　　　INSERT INTO `dtb_page_layout` (`page_id`, `device_type_id`, `page_name`, `url`, `file_name`, `edit_flg`, `author`, `description`, `keyword`, `update_url`, `create_date`, `update_date`, `meta_robots`, `meta_tags`) VALUES
　　　(47, 10, '新着一覧ページ', 'news_list', 'News/list', 2, NULL, NULL, NULL, NULL, '2019-02-15 17:00:00', '2019-02-15 17:00:00', NULL, NULL);
　⑥「/PROJECT_ROOT/Repository/NewsRepository.php」
　　　こちらにもメソッドを追加。

【質問事項】
①上記修正にてそれぞれ独立した画面はでき、動作確認しても問題ないのでこのまま作業を進めていこうかと思っておりましたが
　色々なサイトを検索していくうちに、このような修正はEccubeのソースを直接さわるのではなく、独自プラグイン(?)として作成し、そのプラグインを追加する方法がEC-CUBEとしては正しい方法なのではないか？という疑問に直面しております。
　この機能をプラグインとして公開する予定はありませんが、この機能以外にも色々とカスタマイズ要件はあり、公開されている他のプラグインはインストールする予定です。
　EC-CUBEのカスタマイズや保守をされている方から色々なご意見をお聞きしたく、宜しくお願い致します。

②新着情報にカテゴライズ情報も持つ必要があるのでDBのカラムの追加も必要なのですが、「dtb_news」に新規カラムを追加してもいいものなのでしょうか？（EC-CUBEとして）

以上
宜しくお願い致します。

①
EC-CUBE3のカスタマイズ方法としてはご指摘のように
- プラグインとして開発する方法
- 本体のソースコードを変更する方法
の２種類あります。

どちらの方法が良いかは一概には言えないのですが、
今回のようなケースですと、
プラグインとして展開する予定はないと言うことですので、
EC-CUBE本体のソースコード管理をする前提となりますが、
本体のソースコードを直接変更される方がカスタマイズがしやすいのではないかと思います。

## 本体のソースコードを変更する利点
- プラグイン開発と比べて比較的工数が低くなりやすい
- ソースコード管理で本体のバージョンアップに追随しやすい

②
本体のソースコードを変更する場合にはdtb_newsに新規カラムを追加する方法が適切かと思います。
Entity/News.phpとEccube.Entity.News.dcm.ymlも合わせて修正が必要になるかとおもいます。


p.s.
修正内容の③はフックポイント用の設定のため、カスタマイズでは不要かと思いました。（あっても問題ありません）

okazy様

ご返答ありがとうございます。

> EC-CUBE本体のソースコード管理をする前提となりますが、
> 本体のソースコードを直接変更される方がカスタマイズがしやすいのではないかと思います。
本体のソースコードを変更すること自体が悪いというわけでは無いとの事、安心致しました。
また利点まで教えて頂きありがとうございます。

> 本体のソースコードを変更する場合にはdtb_newsに新規カラムを追加する方法が適切かと思います。
> Entity/News.phpとEccube.Entity.News.dcm.ymlも合わせて修正が必要になるかとおもいます。
このままソースコードを直接変更する方法で実装する場合は、テーブルも直接変更致します。
Entityの改修は頭にあったのですが、ymlのほうは完全に抜けておりました。
ご指摘頂きありがとうございます。

> 修正内容の③はフックポイント用の設定のため、カスタマイズでは不要かと思いました。（あっても問題ありません）
おっしゃる通りですね。削除致します。
こちらもご指摘ありがとうございます。