Drupal

Drupal6で普通にInviteモジュールを使おうとすると、http://homepage.ok-jp.com/blog/20081212156でも問題になっているように、「申し訳ありませんが、招待状を送信可能な上限に達しています。」というエラーが表示され招待メールを送信することができないことがあります。

私がローカルテスト環境「Drupal6.15　＋　Invite6.x-2.0-alpha1」では、スーパーユーザを含めてすべてのユーザが同じ症状でした。

http://homepage.ok-jp.com/blog/20081212156で述べられているように、ロールを新設し、管理画面からInviteの初期設定ロールに割り当てれば問題は解決すると思います。

「思います。」というのは私自身は試していませんので、よくわからないという事で。

私のほうの対策としては、管理セクション≫ユーザの管理≫ロールの設定で「認証済みユーザ」というロール名称を「authenticated user」という名称に変更。という方法でした。

Drupal６日本語ディストリビューションをインストールすると自動的に「authenticated user」が「認証済みユーザ」という名称になり、普通に利用していますが、Inviteモジュールの場合、管理セクション≫ユーザの管理≫ロールの設定で「認証済みユーザ」という選択ができるにも関わらず、実際の招待状送信前チェックでは「authenticated user」に対するチェックを行っていました。

というわけで、とりあえず、「認証済みユーザ」→「authenticated user」で、手を打ったというわけです。

会員制サイトの構築にあたり、今まではユーザ・プロフィールやユーザ固有コンテンツの表示・非表示をViewsモジュールの閲覧権限の設定や、独自拡張モジュールで対応していましたが、View_ownモジュールを知り、使ってみることにしました。

→ 詳細はView_ownモジュールとWebformモジュール

Faq拡張モジュールへの景況

ところが、View_own拡張モジュールをインストールすると、従来から利用していたFaq拡張モジュールによるFaqコンテンツがスーパーユーザ以外でアクセスするとアクセス権にひっかかって表示できなくなってしまいました。

View_own拡張モジュールとFaq拡張モジュールを同居させるには

View_own拡張モジュールの改造が必要になります。

View_own拡張モジュールの下記部分(Ver 6.x-1.1の場合)

を以下のように変更します。

 上記変更後、以下の要領でWebformコンテンツの一般閲覧を有効にします。

1. 管理セクション≫ユーザの管理≫権限ページの「view_own モジュール」以下に「view any faq contentとview own faq content」の権限設定行が増えていますので各ロールに対して有効にします。
2. 管理セクション≫コンテンツの管理≫投稿の設定ページの
   ノードアクセスの状態：［アクセス権の再構築］をクリックして、変更を反映させます。

会員制サイトの構築にあたり、今まではユーザ・プロフィールやユーザ固有コンテンツの表示・非表示をViewsモジュールの閲覧権限の設定や、独自拡張モジュールで対応していましたが、View_ownモジュールを知り、使ってみることにしました。

View_ownモジュールなしの状態は

自分が投稿したコンテンツのみ参照可能"などの権限設定をコンテンツタイプごとに設定出来るようにします。

Drupal標準の権限設定では

• ノード全般の閲覧権限
• 各ノートタイプごとの生成権限
• 各ノートタイプごとの編集権限
• 各ノートタイプごとの削除権限

がｏｗｎ／ａｎｙそれぞれで定義可能です。

閲覧に関する権限設定は、ノードタイプごとではなく”全てのノード”に対してです。

View_own拡張モジュールをインストールすると

標準の権限設定に加えてノードタイプごとの ｏｗｎ／ａｎｙそれぞれの閲覧権限が設定できるようになります。

Webform拡張モジュールへの景況

ところが、View_own拡張モジュールをインストールすると、従来から利用していたWebform拡張モジュールによる投稿ページがスーパーユーザ以外でアクセスするとアクセス権にひっかかって表示できなくなってしまいました。

View_own拡張モジュールとWebform拡張モジュールを同居させるには

View_own拡張モジュールの改造が必要になります。

View_own拡張モジュールの下記部分(Ver 6.x-1.1の場合)

を以下のように変更します。

 上記変更後、以下の要領でWebformコンテンツの一般閲覧を有効にします。

1. 管理セクション≫ユーザの管理≫権限ページの「view_own モジュール」以下に「view any webform contentとview own webform content」の権限設定行が増えていますので各ロールに対して有効にします。
2. 管理セクション≫コンテンツの管理≫投稿の設定ページの
   ノードアクセスの状態：［アクセス権の再構築］をクリックして、変更を反映させます。

ホームページの更新をスムーズに、しかも快適に行うには 入力に気持ちの良い環境が必要です。

ただ単に文字を入力しているだけでは表現力も劣り入力作業が覇気がないものになってしまいます。

insert_viewモジュールを利用することでコンテンツの表現力やユーザビリティを向上させることができます。

ここのところ、ユーザ・プロファイルの中に仕込む画像のことで はまりまくってました。

ことの発端は、Drupal標準のユーザ・プロフィール情報が、通常のノードのような応用性が薄く、フォーム入力なり、アバターなり、Drupal標準機能にも関わらず拡張性が低い事でした。

アバターの問題

ユーザ要望による、投稿画像→サムネイル、中間サイズ画像、現画像というような使い方が標準のユーザ・プロフィール情報ではできないようです。

一覧ブロック、一覧ページではサムネイルを表示し、詳細ページでは中間サイズ画像、中間サイズ画像をクリックするとThickboxによるズームアップ表示。というごくありきたりな要望なのですが、事、ユーザ・プロフィール情報においては そんなありきたりなことが すんなりゆかない。ということがわかりました。

通常、

• 上記機能はフィールドを拡張するCCK、Image_field
• 臨機応変に画像サイズを変換キャッシュするImage_cache拡張モジュール
• DBから表示するフィールドを自由に選択できるViews

などを組み合わせる事で、投稿から一覧ブロック、一覧ページ、詳細ページ表示まで すんなり完了するのですが、ユーザ・プロフィール情報の場合、上記 拡張モジュールの力が及びません。

Content_profile拡張モジュール

そこで登場するのが、Content_profile拡張モジュールです。

Content_profile拡張モジュールは拡張性のない標準のユーザ・プロファイルに変わって、通常のコンテンツとして扱えるプロファイル情報、といった扱いです。（？わかりにくい）

つまり、標準のプロフィール情報にはない

• 通常のコンテンツの利点（＝様々な拡張モジュールの恩恵を受ける）
• プロフィール情報としての扱い（＝ユーザに紐付く）

の両方の利点を結びつけるモジュールがContent_profileです。

しかし、

実際はContent_profileでも不自由な点が存在した

Content_profileをインストールし、快適に投稿フォーム、表示ブロック、ページを作成。

といきたかったのですが、やはり問題がありました。

Image_cache拡張モジュールが機能しない

Content_profile情報の中の画像フィールドにはImage_cache拡張モジュールが機能しないということが わかりました。

確かに、Content_profile情報をコンテンツとして表示する場合はImage_cache拡張モジュールは機能するのですが、ユーザ・プロファイル情報として表示する場合は、機能しませんでした。

これは問題なので、早々 調べ始めたものの、Content_profileモジュールはまだβ版。使う方がいけないような気もしますが、もっと深く調べるか、次バージョンに期待するか、考え中です。

ユーザ・グループ(ロール)毎に異なるページを表示するuserregisterredirect拡張モジュールを見つけました。
→ http://drupal.org/project/userregisterredirect

ところが、バージョンが5.x-0.1で止まっています。

残念。

この程度は自分で作成。という事でしょうか。

会員制サイトというと、どうしても利用する拡張モジュールが多くなってしまい、重くなっていまいがちなので 固有の仕様部分は、サイト専用の拡張モジュールに まとめますが、そこに入れる提携パターンになりますね。

認証グループ（Drupalではロールと呼びます）

複数の認証グループ、例えば、単純に有料・無料で考えても、

1. 有料会員グループ
2. 無料会員グループ

など、さらにサイト管理者グループなどがあり、会員管理、認証管理には常に複数の認証グループが必要とされます。

Drupalのユーザ（グループ）管理機能は多岐にわたり、柔軟に権限管理できます

しかし、応用範囲が大きいためか、拡張モジュールが多すぎて見つけられないためか、新規ユーザ登録時、どの認証グループ（ロール）に所属させるかをコントロールする拡張モジュールが見つかりませんでした。

Drupalのデフォルト状態（認証ユーザ,スーパーバイザー）なら認証しているか否かで権限設定が済んでしまい、特に不自由はありません。

しかし、上記のように複数の認証ユーザを管理する場合、

ユーザ登録時に どちらのユーザとして登録するかを自動的に振り分ける方法

がありません。

デフォルトのユーザ登録画面で、ユーザにグループを（チェックボックスで）選んでもらう事で代用することはできますが、ユーザに選択させることのリスクが大きい、各々の新規登録ボタンをクリックした画面で、また もう一度 認証グループを選択しなければならないようなユーザビリティでは使い物になりません。

いま制作中のパートナーズナビでも相談する側、受ける側が明確に分かれ、おのおの権限が全く異なってきますので、2種類の[新規ユーザ登録ボタン]クリックで自動的に振り分ける必要があります。

既存の拡張モジュールに Auto Asign roleという

のがあり、これだと、一種類のロール（認証グループ）だけは指定できますが、デメリットとして、複数の認証グループを定義する事はできません。

今回は、

条件を指定して複数の認証グループが定義できる拡張モジュール

を自前で作成することにしました。

弊社の場合、DrupalでPayPalを利用する際はlm_paypal拡張モジュールを利用します。

Drupalに限らず、PayPal関連の動作チェック時に正規のPayPalアカウントを使用して実際にお金を動かしていたのでは大変です。

そんな時、PayPalが提供しているテスト用のアカウント（sandbox）があります。

sandboxを利用することで、実際にお金を動かすことなくPayPalを利用したような流れを実現することができます。

PayPal sandboxの利用手順

1. https://developer.paypal.com/ にアクセス。
   → PayPal sandboxページが表示されます。
2. [Sign Up Now]をクリック。
   → Sign Up for Access to the Sandbox Test Environmentが表示されます。
3. 必要事項を記入し、[Agree and submit]をクリックしアカウントを作成します。
   → 登録メールアドレスに確認用のメールが届きます。
4. メール中の確認用リンクをクリックします。
   → メールアドレスの確認ページが表示され、アカウントが作成されます。
5. https://developer.paypal.com/ にアクセス。
   → PayPal sandboxページが表示されます。
6. ログインフォームからログインします。
7. [Sandbox]タブをクリックします。
8. [Create Account]で買い手、売り手それぞれのアカウントを作成します。
9. 売り手用アカウント作成時に登録したメールアドレスをPayPal依頼時のメールアドレスとして設定します。
10. PayPalの正規URL「http://www.paypal.com/」をsandbox用URL「http://www.sandbox.paypal.com/」に変更します。
11. https://developer.paypal.com/ にアクセス。
    → PayPal sandboxページが表示されます。
12. ログインフォームから売り手用アカウントでログインします。
13. [Sandbox]タブの[プロファイル]サブタブをクリックします。
14. ウェブサイト支払いの自動復帰：をオンにし、「復帰URL」を設定します。
15. 支払いデータ転送：をオンにします。
16. [保存]をクリックし、表示されるIDトークンを控えておきます。

Drupalに限らず、会員制サイトなどでは善意に満ちたユーザばかりではありません。

あまり考えたくはありませんが、時には、登録を許可してしまったユーザを すぐにでも締め出したいような事態が発生してしまうこともあります。

しかし、管理者権限でIDやパスワードを変更しても既にログインしてしまったユーザにはログアウトまでアクセスを許してしまいます。

Drupalではユーザ管理ページで

• ブロック：アカウントが無効になり、次のアクセス（クリック等）で直ちにアクセス禁止に。
• アクティブ：アカウントが有効な状態。

のブロック：をワンタッチで選択することで安心できます。

その後、対象ユーザが別ページに移動しようとした瞬間に強制的にアクセス権を剥奪されてしまいます。

些細なことですが、サイトを運用する立場になると、不良登録者に対して即座に対応できるという事は重要なファクターではないでしょうか。