Enhancement（機能追加・改善） #23: 画像・書き込み管理機能の追加 - OpenPNE 3 - OpenPNE Issue Tracking System

Enhancement（機能追加・改善） #23

画像・書き込み管理機能の追加

Kousuke Ebihara が14年以上前に追加. 14年以上前に更新.

ステータス:

Fixed（完了）

優先度:

Normal（通常）

担当者:

Shinichi Urabe

対象バージョン:

OpenPNE 3.1.5

開始日:

2009-09-29

期日:

進捗率:

100%

説明

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() ?>

関係しているリビジョン

リビジョン d98bf90b (差分)
Kousuke Ebihara が14年以上前に追加

reverted 9ec82b1d144bac08a7276c6418a61ae1d5b46645 because I'll fix some weak points for #23 (refs #23)

リビジョン 403ff4d3 (差分)
Kousuke Ebihara が14年以上前に追加

renamed monitoringFunction to monitoring (refs #23)

リビジョン d28dc09a (差分)
Kousuke Ebihara が14年以上前に追加

changed way to display monitoring menu (refs #23)

リビジョン 95b69e50 (差分)
Kousuke Ebihara が14年以上前に追加

fixed some spacing (refs #23)

リビジョン d60e5a25 (差分)
Kousuke Ebihara が14年以上前に追加

added translation for menu (refs #23)

リビジョン 8f18a6c5 (差分)
Kousuke Ebihara が14年以上前に追加

added ability to load menu item for monitoring module on migrating (fixes #23)

リビジョン 72278658 (差分)
Kousuke Ebihara が14年以上前に追加

added missing migrations (refs #23)

履歴

#1 Kousuke Ebihara が14年以上前に更新

このチケットは http://trac.openpne.jp/ticket/3309 で進行していました。

#2 Kousuke Ebihara が14年以上前に更新

ステータス を 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 行目がコーディング規約違反です