私は過去6か月間 Organic Groups を使用しており、単純な使用例では複雑であることがわかりました。グループのユーザーまたはグループのコンテンツを表示するための基本的なビューを作成するだけでも、すぐに「ロケット」に変わります。
モジュールには、アクセス制御など、私が必要としなかった大量の追加機能が付属しています。
さらに、グループのコンテンツとグループメンバーシップを移行できず、テーブルに手動で挿入すると、確実に機能しませんでした。
以下は、フラグと参照モジュールを使用して基本的なOG機能を作成するための私のソリューションです。私の要件は:
コメントまたは代替ソリューションを投稿してください。
ところで、Cliveは meta でこのハウツーを投稿するように勧めました。ありがとう、クライヴ!
1。ユーザーはグループを作成できます:
グループを作成するには、新しいコンテンツタイプ「グループ」を作成し、ユーザーが新しいコンテンツを作成するための権限を付与します。また、グループのロゴをアップロードできるように画像フィールドを追加しました。
2。ユーザーは、承認または権限なしでグループに参加(およびグループから脱退)できます
フラグモジュール は、ユーザーがグループに参加(およびグループから脱退)できるようにする優れた方法であることがわかりました。 「グループ」という新しいフラグを作成し、「グローバルフラグ」がオフになっていることを確認してから、「グループ」を「フラグ設定可能なコンテンツ」として選択します。フラグリンクをカスタマイズして、「このグループに参加する」などと言うこともできます。ところで、デフォルトのリンクテキストを変更するだけで hard in OG になります。
3。ユーザーは他のノードを追加してグループコンテンツとして表示できます
他のノードを「グループ」コンテンツタイプに割り当てるために、 references モジュールからのノード参照を使用しました。 エンティティ参照 とDAメンバー エンティティ参照を優先するように見える も調べました(以前に使用しました).
ただし、ノード参照にはインストール数が多く、ノードの追加/編集ページで「利用可能なグループ」をユーザーがフラグを設定したグループのみにフィルターできる、気の利いた「参照」機能が付属しています。
写真ノードをグループタイプに割り当てられるようにするには、「group_content」フィールドを写真タイプに追加し、フィールドタイプとして「ノード参照」を選択します。 「値の数」として、ウィジェットのタイプ(オートコンプリート、チェックボックス、選択リスト)、チェックボックスと5を選択できます。 「参照可能なコンテンツ」については、「グループ」のコンテンツタイプを選択するだけです。
この設定を使用して、新しい写真ノードを作成し、それをこれまでに作成された任意のグループに割り当てることができます。これをユーザーのグループに限定するには、「type = groupのコンテンツ」のビューを作成し、「フラグ付きコンテンツのみを含める」チェックボックスをオンにして関係「フラグ:Nodeフラグ」を追加します。選択します。 「グループフラグ」を選択し、「現在のユーザー」を選択します。
これで、ビューには現在のユーザーによってフラグが付けられたグループのみが表示されます。 「ディスプレイ」の下の「追加」をクリックし、「参照」を選択して保存します。
次に、写真のコンテンツタイプを再度編集して、「group_content」フィールドを編集します。下部には、「参照できるノードのリストをビューで提供できる」というオプションがあり、新しいビューがオプションとして表示されます。それを選択して保存します。
コンテンツタイプの[フィールドの管理]で[既存のフィールドを追加]を使用して、他のノードから同様の参照を作成できます。
4。ビューを使用してグループコンテンツとグループメンバーシップを表示する
あとは、ビューを作成するだけです。たとえば、ユーザーのリストとグループコンテンツのリストをグループページに表示したいとします。
OGでは、これらのビューは複雑です。 グループコンテンツビュー および グループのユーザー の例を参照してください。
フラグとNode参照を使用すると、非常に簡単です:
各グループのユーザー数を含むグループのリスト ":
グループに属するメンバーのリスト:
グループに割り当てられているノードのリストを表示します。
それでおしまい。追加の利点として、いくつかの基本的なSQL INSERTステートメントを使用して、レガシーグループメンバーシップとグループコンテンツをインポートできました。
最近、町に新しい子供がいます(D7から)、Organic groupsモジュールの潜在的な代替案を提供します、つまりGroupモジュール(現在のメンテナンスは、Driesが開始した場所で発生しますDrupal ...)。プロジェクトページからの引用は次のとおりです。
このモジュールは Organic groups (OG)の代替として設計されています。
それについての詳細(プロジェクトページからも):
Organic Groupsを使用すると、コンテンツ自体をグループにすることができます。エンティティ参照フィールドを使用して、グループ(ノード、用語、...)とそのコンテンツ(ノード、用語、ユーザー、...)間の関係を追跡します。
Groupsは代わりにグループをエンティティとして作成し、完全にフィールド化、拡張、エクスポートできるようにします。すべてのグループには、ユーザー、ロール、およびアクセス許可をアタッチできます。グループは、あらゆるタイプのエンティティの親としても機能します。グループとして見ることもエンティティであり、サブグループの作成は非常に簡単です。
これまでのところD7のベータ版しかありませんが、その 使用統計 は、「新星」のようであることを示しているようです。そして、最近、「重い」- 有機グループ モジュールの有効な代替手段としてさまざまな場面で言及されていると聞きました。
これらのサブモジュールを介して追加機能を有効にすることができます:
グループ モジュールは 問題2603136のコメント#2 で説明されているように ルール モジュールともうまく統合されています。
...すでに次の目的でルールを使用できます。
- 新しいグループを追加
- 新しいGroupMembershipを作成して保存します($ group-> addMember()と同等)
- GroupTypeからGroupRoleを追加または削除します
- 新しいGroupMembershipまたはGroupエンティティに反応する
- …
まだ行われていないのは、カスタムルールのアクションまたは条件です。グループの90%以上が純粋なエンティティAPIのCRUD操作であるため、すでにすぐに達成できる量を考えると、カスタムルールコードはまだありません。
追加できる便利なルールは次のとおりです。
- グループのすべてのメンバーに電子メールを送信し、オプションでGroupRoleでフィルター処理する
- 上記のリストのわかりやすいラベル:「メンバーが参加したグループ」は、「GroupMembershipエンティティが作成される」よりも簡単に聞こえる
...
統合が既に存在するか、パイプラインにある他のモジュールについては、 他のモジュールとの統合 およびその「関連する問題」を参照してください。
このモジュールの使用方法の興味深い図については、 ユーザーがノード/コメントへのアクセスを同じロールを持つユーザーに制限するオプションを実装する方法を参照してください を参照してください。