endoさん
モバイルのテーマ切り替えは標準機能で実装されていたのですね。
もしもデバイス毎にもっと詳細にテーマを切り替える場合には、教えて頂いた
「/concrete/src/Routing/DispatcherRouteCallback.php」のexecuteあたりを
オーバーライドすれば対応出来そうな感じですね。
また、ブロックの表示項目変更もデバイス毎にあるルール(sp_view.phpとか)を作って
「/concrete/src/Block/View/」の「BlockView.php」や「BlockViewTemplate.php」を
オーバーライドすれば対応可能そうな気がしてきました。
お忙しいところご回答頂きましてありがとうございました。
Concrete5の導入について
2015年4月17日 at 17:41
現在は独自のCMSを利用してサイト運営を行っているのですが、運用工数などをかなり削減出来そうなのでConcrete5.7に移行する事を検討させて頂いております。
少しだけいじってみて気になる点がいくつかありましたので質問させてください(長文で申し訳ございません)。
→試しているバージョンは「concrete5.7.3.1」となります。
一部のみでも構いませんので、もしもご存知でしたらご回答を頂けますと幸いです。
①コンテンツの履歴管理について
ブロックのCSSなどを変更した場合に、ページを公開する前に表示確認をしたいと考えております。
独自で作成してみたブロックのview.cssを修正したところ、承認をしていないのに公開されているページに即時反映されておりました。
これは各ブロックのCSS(jsも？)などはバージョン管理の対象となっていないのでしょうか？
→Concrete5の仕組み的にview.cssなどのバージョン管理は難しいものなのでしょうか？(拡張すれば実現は可能？)
②動的URLについて
別システムからRESTfulなAPIを利用して商品情報などを取って来て画面を表示しようと考えています。
→URLで指定されたIDを利用してブロックから外部APIの呼び出しをするような事をしたいです。
例)
「http://[ドメイン]/item/123456/」がユーザが訪問してくるURLだとすると、htaccessなどで「http://[ドメイン]/item/?item_id=123456」のような
形式にリライトし、itemページ内のブロックでパラメータ値「123456」を元に外部APIを呼び出してレスポンスをview.phpで整形して画面上に表示する。
上記のような外部APIから情報を動的に取得してページを構成している事例などはありますでしょうか？
また、上記のようなパターンでフルページキャッシュを作成した場合に、どのようにキャッシュが有効になるか教えて頂きたいです。
「http://[ドメイン]/item/?item_id=123456」のURLに対してフルページキャッシュが作成されるイメージで合っているでしょうか？
もしもURLで指定されたIDのパラメータ値が変われば別のキャッシュファイルが作成されますでしょうか。
③デバイスによる表示切替について
同じURLでもスマホやPC、アプリのWebViewなどデバイスによって表示内容を変更したいと思っております。
ガラッと表示項目やデザインが変わってしまうのでレスポンシブデザインで頑張るのではなく、デバイス判定してテーマやview.php？やカスタムテンプレート？
を動的に切り替えるような事が出来ないかと考えております。
上記のような事を実現するアドオンや、実際にこう対応したよなどの事例がありましたら教えて頂けないでしょうか？
※ すでに稼働しているサイト移行で検討しているなので、URLを別に分けたりする対応はNGなのです。。。
④外部会員システムについて
外部に会員システムがあり、特定ページアクセス時に外部システムに会員状態を問い合わせを行い、場合によってはログイン画面へ遷移させるような事を考えております。
Concrete5はブロックの構成でページが出来上がっているイメージがあり、もしページを表示する際に会員判定のような共通処理？が必要となった場合にはどのように実現するかイメージがあまり湧きませんでした。
もしもページとして共通処理のようなもの？が必要になった場合にはどこに実装するのがお作法なのでしょうか？
→対象ページに配置するブロックのControllerとかに実装してしまうもの？なのでしょうか。
⑤ページ表示時のDB更新について
ユーザが参照するページはreadonlyなレプリケーションDBを参照させるようにしたいと考えております。
→管理画面サーバからのみマスタDBの更新を許可するようなイメージです。
上記を試そうと思ったところ、ページアクセスの度にログをDBに書き込もうとしている？のかエラーになってしまいました。
何か起きた時にログは必要なので別ファイルに出力するように機能拡張してみようと思ったのですが、その他ユーザがアクセスするページ表示の際にDBを更新するようなものはあるでしょうか？
もしも公開されているページへのアクセスでその他Concrete5のテーブルがいろいろと更新されるようであれば方式を見直してみようかと思っております。
⑥パッケージ領域のオーバーライドについて
Concrete5の導入に合わせて、運用が便利になりそうなアドオンをいくつか作成しようと思っています。
もしも複数パッケージから同じコアクラスのエイリアス設定を変えるようなものがあった場合には、最後にエイリアス設定を変えたパッケージの内容のみが反映されるようなイメージなのでしょうか。
同じコアクラスを拡張したいけど、機能的には全然別物なのでパッケージを分けたい！ような場合が出てきたらどのように対応すれば良いものでしょうか。
※ マーケットから複数インストールしたアドオンが、たまたま同じコアクラスのエイリアス設定を変えるようなものだった場合なども同じかと思いますが
Re: Concrete5の導入について
2015年4月18日 at 1:31
endoさん
ご回答ありがとうございました。
独自CMSは何でも出来る自由度が高くメリットも大きいですが、リッチなものにしようと思うと工数がかかってしまう課題もありなかなか判断が難しいところですよね。
今回いろいろとOSSのCMSを探していて、concrete5は直感的で運用者に優しそうなのと、MVCで開発者にも取り組み易そうと思い現行の業務フローとマッチすればぜひ導入させて頂きたいと思っております。
もし自分が調査したことがあれば、なるべくこちらのコミュニティでも共有させて頂ければと思います。
ぜひ今後ともよろしくお願いいたします！
ご回答ありがとうございました。
独自CMSは何でも出来る自由度が高くメリットも大きいですが、リッチなものにしようと思うと工数がかかってしまう課題もありなかなか判断が難しいところですよね。
今回いろいろとOSSのCMSを探していて、concrete5は直感的で運用者に優しそうなのと、MVCで開発者にも取り組み易そうと思い現行の業務フローとマッチすればぜひ導入させて頂きたいと思っております。
もし自分が調査したことがあれば、なるべくこちらのコミュニティでも共有させて頂ければと思います。
ぜひ今後ともよろしくお願いいたします！
Re: Concrete5の導入について
2015年4月17日 at 22:56
> ①コンテンツの履歴管理について
ファイルの差分管理はありません。そちらはgit等をご活用ください。concrete5で管理するのはコンテンツまでです。
> ②動的URLについて
ページリストブロックのcontrollerをご参照ください。フルサイトでインストールした場合、トピックリストブロックで生成されるURLに動的に反応してコンテンツを表示する仕組みになっていますので、参考になるかと思います。また、そもそもページ送りは動的に生成されています。
フルページキャッシュに関しては、ブロックごとのコントローラーのプロパティにて、キャッシュへの対応方法が指定されています。例えばページリストは動的なブロックですので、フルページキャッシュを許可していないブロックですので、各ページでフルページキャッシュを常に有効にしない限りは、ページリストブロックが置かれているページではフルページキャッシュは生成されません。
> ④外部会員システムについて
こういう機能はシングルページで実装します。標準のログイン画面はcontrollers/single_pages/login.php と single_pages/login.php の組み合わせできています。
> ⑤ページ表示時のDB更新について
> ユーザが参照するページはreadonlyなレプリケーションDBを参照させるようにしたいと考えております。
基本的には可能ですし事例もありますが、5.7系ではまだ事例が少ないです。ただ仰る通りログを取る機能はありますので管理画面から無効にしていただければと思います。
> ⑥パッケージ領域のオーバーライドについて
マーケットプレイスのアドオンは、基本的にはルールとしてコアクラスのエイリアス設定を上書きはしないと思います。複数パッケージで上書きは試したことは無いですが基本的にはLaravelのFacadeクラスを使っていますのでそちらに依存すると思います。すいません、詳しくないです…。
ファイルの差分管理はありません。そちらはgit等をご活用ください。concrete5で管理するのはコンテンツまでです。
> ②動的URLについて
ページリストブロックのcontrollerをご参照ください。フルサイトでインストールした場合、トピックリストブロックで生成されるURLに動的に反応してコンテンツを表示する仕組みになっていますので、参考になるかと思います。また、そもそもページ送りは動的に生成されています。
フルページキャッシュに関しては、ブロックごとのコントローラーのプロパティにて、キャッシュへの対応方法が指定されています。例えばページリストは動的なブロックですので、フルページキャッシュを許可していないブロックですので、各ページでフルページキャッシュを常に有効にしない限りは、ページリストブロックが置かれているページではフルページキャッシュは生成されません。
> ④外部会員システムについて
こういう機能はシングルページで実装します。標準のログイン画面はcontrollers/single_pages/login.php と single_pages/login.php の組み合わせできています。
> ⑤ページ表示時のDB更新について
> ユーザが参照するページはreadonlyなレプリケーションDBを参照させるようにしたいと考えております。
基本的には可能ですし事例もありますが、5.7系ではまだ事例が少ないです。ただ仰る通りログを取る機能はありますので管理画面から無効にしていただければと思います。
> ⑥パッケージ領域のオーバーライドについて
マーケットプレイスのアドオンは、基本的にはルールとしてコアクラスのエイリアス設定を上書きはしないと思います。複数パッケージで上書きは試したことは無いですが基本的にはLaravelのFacadeクラスを使っていますのでそちらに依存すると思います。すいません、詳しくないです…。
Re: Re: Concrete5の導入について
2015年4月18日 at 1:36
hissyさん
詳細なご回答ありがとうございます！
> ①コンテンツの履歴管理について
> ファイルの差分管理はありません。そちらはgit等をご活用ください。concrete5で管理するのはコンテンツまでです。
ファイルの差分管理機能はなく、ブロックのファイルを修正して直接デプロイした場合にはキャッシュがなければ即時反映と言う事ですね。
現行CMSの業務フローでは、ステージ環境で確認後に本番反映と言うフローがどうしても必要となってしまうため、ステージ(管理画面での確認用)と本番のモジュールを別に管理しておき、管理画面からブロック編集( or ファイルアップロード)出来るように機能拡張(db.xmlなどは禁止？)→このタイミングではステージのみモジュールが変更されている状態(公開ステータスを承認待ち？に合わせて更新)→本番公開時にステージ環境から対象ブロックを本番環境へ同期(rsyncなど？)のような形が実現出来ないか検討してみたいと思います。
> ②動的URLについて
参考になるsrcを教えて頂きありがとうございます！
いま手元にsrcがないので、のちほどページリストブロックの確認させて頂きたいと思います。
> ページリストブロックが置かれているページではフルページキャッシュは生成されません。
フルページキャッシュが生成されないとなると、今回の例の場合には毎回の外部API呼び出しをしてしまう事になりそうですね。
キャッシュ処理のsrcはまだ見れていないのですが、外部APIへの負荷が少し心配なので、指定されたパラメータを含むURLに対してページキャッシュ出来るような仕組みを少し検討してみたいと思います。
> > ④外部会員システムについて
> こういう機能はシングルページで実装します。
シングルページのcontrollerとして処理を書くようなイメージになるのですね。
参考に標準ログイン画面を確認させて頂きます！
> > ⑤ページ表示時のDB更新について
> > ユーザが参照するページはreadonlyなレプリケーションDBを参照させるようにしたいと考えております。
> 基本的には可能ですし事例もありますが、5.7系ではまだ事例が少ないです。
上記の件、了解いたしました。
実現は可能との事で安心いたしました、一応アプリケーションログは監視しておきたいので、Loggerのあたりをファイル出力可能なように拡張出来ないか検討してみたいと思います。
> マーケットプレイスのアドオンは、基本的にはルールとしてコアクラスのエイリアス設定を上書きはしないと思います。
失礼いたしました、マーケットプレイスのアドオンはコアクラスのエイリアスを書き換えたりはしないのですね。
すっかり共通的な処理の機能拡張を行うアドオンのようなものは、コアクラスの置き換えを行っているのかと勘違いしてしまっておりました。
いくつかアドオンのsrcも確認してきちんと理解するようにいたします。
お忙しいところご回答頂きまして本当にありがとうございました！
同じような疑問を抱く方がもしかしたらいるかも知れないので、検討した結果ものちほど記載させて頂きます。
詳細なご回答ありがとうございます！
> ①コンテンツの履歴管理について
> ファイルの差分管理はありません。そちらはgit等をご活用ください。concrete5で管理するのはコンテンツまでです。
ファイルの差分管理機能はなく、ブロックのファイルを修正して直接デプロイした場合にはキャッシュがなければ即時反映と言う事ですね。
現行CMSの業務フローでは、ステージ環境で確認後に本番反映と言うフローがどうしても必要となってしまうため、ステージ(管理画面での確認用)と本番のモジュールを別に管理しておき、管理画面からブロック編集( or ファイルアップロード)出来るように機能拡張(db.xmlなどは禁止？)→このタイミングではステージのみモジュールが変更されている状態(公開ステータスを承認待ち？に合わせて更新)→本番公開時にステージ環境から対象ブロックを本番環境へ同期(rsyncなど？)のような形が実現出来ないか検討してみたいと思います。
> ②動的URLについて
参考になるsrcを教えて頂きありがとうございます！
いま手元にsrcがないので、のちほどページリストブロックの確認させて頂きたいと思います。
> ページリストブロックが置かれているページではフルページキャッシュは生成されません。
フルページキャッシュが生成されないとなると、今回の例の場合には毎回の外部API呼び出しをしてしまう事になりそうですね。
キャッシュ処理のsrcはまだ見れていないのですが、外部APIへの負荷が少し心配なので、指定されたパラメータを含むURLに対してページキャッシュ出来るような仕組みを少し検討してみたいと思います。
> > ④外部会員システムについて
> こういう機能はシングルページで実装します。
シングルページのcontrollerとして処理を書くようなイメージになるのですね。
参考に標準ログイン画面を確認させて頂きます！
> > ⑤ページ表示時のDB更新について
> > ユーザが参照するページはreadonlyなレプリケーションDBを参照させるようにしたいと考えております。
> 基本的には可能ですし事例もありますが、5.7系ではまだ事例が少ないです。
上記の件、了解いたしました。
実現は可能との事で安心いたしました、一応アプリケーションログは監視しておきたいので、Loggerのあたりをファイル出力可能なように拡張出来ないか検討してみたいと思います。
> マーケットプレイスのアドオンは、基本的にはルールとしてコアクラスのエイリアス設定を上書きはしないと思います。
失礼いたしました、マーケットプレイスのアドオンはコアクラスのエイリアスを書き換えたりはしないのですね。
すっかり共通的な処理の機能拡張を行うアドオンのようなものは、コアクラスの置き換えを行っているのかと勘違いしてしまっておりました。
いくつかアドオンのsrcも確認してきちんと理解するようにいたします。
お忙しいところご回答頂きまして本当にありがとうございました！
同じような疑問を抱く方がもしかしたらいるかも知れないので、検討した結果ものちほど記載させて頂きます。
Re: Concrete5の導入について
2015年4月18日 at 16:27
キャッシュについては、ブロックキャッシュを活用すれば、毎回APIを読みにいくことは無く、取得結果を一次保存することも可能です。いいサンプルがあればまた共有します
多摩勉強会/遠藤
Re: Concrete5の導入について
こちらだけの回答？になりますが、
標準で機能がついているようです。
/concrete/src/Routing/DispatcherRouteCallback.php
ここに、「Mobile_Detect」というクラスが用意されていますので、
といった利用方法があるようです。
テーマの切り替えも、オリジナルのソース内に記述があるようで、
（/concrete/src/Routing/DispatcherRouteCallback.php）
と、Configでモバイル用のテーマを宣言して、デバイスタイプで切り替えているロジックがあるようです。
自分で試した訳ではないので、実際に動作するかは、未確認ですが、ご参考になれば・・・