Enhancement（機能追加・改善） #23
完了
Kousuke Ebihara さんが約15年前に追加.
ほぼ15年前に更新.
説明
OpenPNE2にある画像・書き込み管理機能をOpenPNE3に追加する。
- アップロード画像リスト
- 画像アップロード・削除
- アップロードファイルリスト
- 日記管理 (対応せず)
- 日記コメント管理 (対応せず)
- コミュニティ管理 (対応せず)
- トピック・イベント管理 (対応せず)
- トピック・イベントのコメント管理 (対応せず)
- レビュー管理 (対応せず)
- アルバム管理 (対応せず)
- アルバム写真管理 (対応せず)
- 書き込みデータダウンロード (対応せず)
監視機能の拡張について¶
今後、core や plugin で画像書き込み管理ローカルナビ内に、監視系の機能を追加する場合、 config/monitoring.yml という設定ファイルを記述してください。このファイルのフォーマットは以下の通りです。
例)
imageList: # 識別名（任意の文字列）
caption: "Uploaded image list" # ナビメニューとして表示される文字列（翻訳の対象になります）
url: "monitoring/imageList" # 飛び先の内部URL
監視の記述を行うテンプレートファイルについて¶
テンプレートファイルの先頭には以下のスロットを設定ください。
<?php slot('submenu') ?>
<?php include_component('monitoring', 'submenu') ?>
<?php end_slot() ?>
- ステータス を Pending Review（レビュー待ち） から Rejected（差し戻し） に変更
- モジュール名についてですが、なぜ monitoringFunction という名前なのでしょうか。どうして monitoring ではいけなかったのでしょうか
- 監視機能のナビメニューが Navigation を用いる形で実装されていますが、 navigation に挿入された値をプラグインの仕様変更などにより変更し直すのはかなり困難です（変更対象のナビゲーションが厳格に特定しにくいため）。他のナビメニューに関してはユーザの変更を許しているので、最悪の場合でもユーザに変更を促せばなんとかなりますが、今回の変更ではそれもおこなえません。この機能のナビメニューはプラグイン側で意図したとおりの表示になるよう固定されているべきで、 DB で管理するメリットはおそらくほとんどないです。独自の設定ファイルからメニューを構築するようにするか、ルーティングを活用するなどして、今回の DB で管理するというアプローチを改めてください。
- apps/pc_backend/modules/monitoringFunction/templates/_subMenu.php で Exception クラスインスタンスの例外を捕獲していますが、意図が不明瞭です。特定の例外だけでなく、すべての例外を本当に捕獲する必要があるのですか？ そもそもどうしてここで例外を捕獲しているのですか？
- apps/pc_backend/modules/monitoringFunction/actions/actions.class.php の 54 行目、 75 行目、 108 行目がコーディング規約違反です
- 対象バージョン を削除 (
OpenPNE 3.1.3)
9ec82b1d でコードの変更を取り消しました。今回の対応項目とはしません。
ブランチで対処の上、マージをおこなってください。
- 対象バージョン を OpenPNE 3.1.5 にセット
- ステータス を Rejected（差し戻し） から Accepted（着手） に変更
- 担当者 を Shinichi Urabe から Kousuke Ebihara に変更
- ステータス を Accepted（着手） から Pending Review（レビュー待ち） に変更
更新履歴commit:"8f18a6c51818e9fead3a05da63f26ee891893892"で適用されました。
- 担当者 を Kousuke Ebihara から Shinichi Urabe に変更
- ステータス を Pending Review（レビュー待ち） から Fixed（完了） に変更
- 進捗率 を 0 から 100 に変更
他の形式にエクスポート: Atom
PDF
