DrupalDrupal

複数の認証グループを管理するには

結局自前で作成結局自前で作成

認証グループ(Drupalではロールと呼びます)認証グループ(Drupalではロールと呼びます)

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

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

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

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

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

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

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

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

がありません。

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

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

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

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

今回は、

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

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

PayPal開発の時のテスト・アカウント(sandbox)

DrupalでPayPalを利用する際はlm_paypal拡張モジュールを利用DrupalでPayPalを利用する際はlm_paypal拡張モジュールを利用

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

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

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

PayPal sandboxの利用手順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ではユーザ管理ページで

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

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

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

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

Drupalという「CMS」で失敗?

最近のDrupalご関する特に多いご相談最近のDrupalご関する特に多いご相談

「Drupalは高機能」しかし「それを使いこなせない」「Drupalは高機能」しかし「それを使いこなせない」

という事です。

Drupalは確かに高性能で、始めはゼロでも拡張モジュールやPHPの知識と、検索力があればある程度使いこなせると思います。

しかし、結果的には時間がかかったり、挫折したり。

時間や費用は、オリジナル・システムを外注するよりは抑えられるかもしれません。しかし、出来た結果を評価したときに、必ずしも効果が得られているかは疑問です。

最近多い ご相談は最近多い ご相談は

  • 要求したのに伝わっていない、無視された
  • これ以上 続けても先が見えない
  • 何をやっているかわからない、不安だ
  • 無意味に時間だけ過ぎてゆく
  • 説明されていないのでわからない、不安だ

と、

コミュニケーション不足、プログラマーの技術不足コミュニケーション不足、プログラマーの技術不足

コミュニケーション不足、プログラマーの技術不足が見受けられます。

金額より先に、目標や要求を詰めたのか?

Drupalの自由度が高いせいで、力不足のプログラマーは目標に達する前に挫折する傾向があります。

作り直しや、修正、修正で、コストで言えば膨らんでいる作り直しや、修正、修正で、コストで言えば膨らんでいる

そうなる前に、もう少し前に 弊社に声をかけていただかれば、、、

という想い(重い?)が多い今日この頃です。

選んだテンプレートの良し悪し

高性能ゆえに逆にいまの時勢を反映していないテンプレートもある高性能ゆえに逆にいまの時勢を反映していないテンプレートもある

テンプレート(テーマ)は、サイト構築の効率を高めますテンプレート(テーマ)は、サイト構築の効率を高めます

しかし、中には高性能ゆえに逆にいまの時勢を反映していないテンプレートもあります。

たとえば、meta keywordやmeta descriptionを設定可能とし、設定内容を各ページ表示時に反映できるテンプレートがあります。

それはそれで、有用な考えなのですが、問題は全ページに同じkeyword、descreptionを反映するため逆に 今現在のSEOとは逆行している事です。

SEO関連のタグをいちいち考えることなく自動的に表示するという発想は良いのですが、いつも同じとなると問題外です。

いくらなんでもサイト内で全てのページのkeyword、descreptionが同一とか、今風には考えられません。

各ページは、各々、表示する内容が違うから存在価値があるのであって、それを表現できないとは、、、章タイトルが全て同じ、というような本を誰が喜ぶでしょうか。

今回の仕事で、こんなテンプレートの遭遇しました今回の仕事で、こんなテンプレートの遭遇しました

全てのページ、正確にはトップページとその他サブページという2種類ですが、びっくりしました。

弊社は通常、node word拡張モジュール+弊社オリジナル・モジュールを使用するので初体験だったのですが、ほとんど全ページ 同一keyword+descreptionという驚きのサイトです。

無名のサイトが順調にアクセスを増やすにはコンテンツ量に応じた読者を増やす事です。

その際に、どのページが何を語っているかが解らないのは致命的な問題です。

keywordとdescription

SEO対策としては keywordやdescreptionは、いまや あまり重要視されないようです。というより、keywordやdescreption偏重のhtmlでは通用しないと言ったほうが良いと思います。

というのは、keywordに何を いくつ入れるとか、descreptionにどんな言葉をいれたらクリックされやすいとか、そんな事は 不要な検索者を増やす一方で(増えたらそれなりに幸せではありますが、、、) 実は大切な訪問者に対しての対策にはなっていないからです。

大切な訪問者に対して何を行うかは、意見がわかれるところですが、ファーストページ以降のコンバージョンに結びつかなければ呼び込んでも成果が上がりません。

成果を上げるためには、逆に訪問者を絞り込む事。訪問者を誘導する術が必要です。

クリーンURLの応用範囲

SEOにも良く自分で解りやすい名前が付けられるので有効にSEOにも良く自分で解りやすい名前が付けられるので有効に

クリーンURLとは、各コンテンツのURLに ?q= を含まないスッキリとしたURLを指しますクリーンURLとは、各コンテンツのURLに ?q= を含まないスッキリとしたURLを指します

例えば about というページがあった場合、この機能が無効の際は「http://example.com/?q=about」というURLになりますが、有効の際には「http://example.com/about」というURLになります。

SEOにも良く、自分で解りやすい名前が付けられるので有効にしておきます。というか標準で有効です。

これで、話は終わりではなく、

  1. 日本語URL
  2. URLの自動生成

を考えてみたいと思います。

日本語URLとは文字通り日本語を使用したURLです日本語URLとは文字通り日本語を使用したURLです

URLエンコードされる事が多く、場合によっては冗長でみにくくなりそうですが、役一年間私的ブログサイトで試した結果、マイナス要因はなく、YahooでもGoogleでも検索結果として表示されるURLには正常に日本語で表示されます。

descriptionとならんで表示されるため、検索キーワードが入っている場合は強調されて表示されますので日本語URLは ぜひとも利用したい機構です。

では、URLの自動生成はどうでしょうかでは、URLの自動生成はどうでしょうか

Drupalというと真っ先に思い浮かぶのはAutomatic Nodetitlesですが、Automatic Nodetitlesを導入すると逆に意図したURLを付けたい時に注意が必要です。できないわけではないので致命的ではないですが。

ページタイトルがそのままURLになるので、ページタイトルを決める際の意識がより一層SEOを意識したものになる。それはそれで良いことではないかと思います。

ページタイトルを本文の内容から自動的に生成するモジュールもありますが、本文修正の度にタイトルが連動して変わってしまう事 自身は悪い事では無いかもしれませんが、それにより、同時にURLも変わってしまうのは問題です。それ以前の自動被リンクや、検索エンジンのインデックスも無効になってしまうことは大きなデメリットです。

Drupalによる多国語対応

多国語だけに対応も多様多国語だけに対応も多様

多国語化されたサイトは なにか難しげな印象を持つかもしれませんが多国語化されたサイトは なにか難しげな印象を持つかもしれませんが

Drupalは比較的 実現しやすいCMSではないでしょうか。

いま、多国語対応サイトを開発しています。主に講師が英語圏(アメリカ、イギリス、フィリピン)、生徒が日本人で、スカイプを利用してのオンライン英会話サイトなのです。

弊社としては、本格的な多国語対応サイトが初めてだったわけですが、始める前には見えなかった事が幾つかあったので記録しておきます。

  • Drupalの設定内容が解りにくい。
    → これはDrupalに限らず、完全に日本語化されていないモジュールを使う上では宿命ですね。
  • テンプレート(テーマ)に埋め込まれてしまった文章は多国語化には向かない。
    → テンプレートを対象とした翻訳という対応方法もありますが、翻訳対応の場合は、一文字でも変更になると翻訳されなくなってしまうため、あまり取り入れたくない方法です。
  • 選択肢が多い。
    → Drupalに関わっていると、いつも選択肢の多さに驚かされます。というか忙しいときは邪魔にかんじるほどです。
    自分なりの方向性を持って接しないと飲み込まれてなにも解決しないような感覚になります。

というわけで、今回、多国語対応といっても日本語と英語の2ヶ国語です。しかも翻訳やコンテンツの準備は お客さまがおこんっていますので、多国語対応の入口。といったところでしょうか。

今回のサイトは、講師の方のエントリーはすでに進んでいました。

集客対象は完全に生徒です集客対象は完全に生徒です

という前提での設定を行いました。

ポイント、

  • 会員制サイト & 多国語対応。
  • ユーザ: Admin、講師、生徒、ゲスト。
  • 集客対象は生徒(日本人)。
  • ゲストにはブラウザ設定値での言語切り替え、対象なし時は日本語表示。
  • 会員(講師)にはアカウント設定≫言語の設定≫言語での設定値による表示。

といことで、以下のような設定を行いました。

  1. 管理セクション≫サイトの環境設定≫言語≫リスト:
    Ja(日本語)のウェイトをen(英語)より上げる。デフォルトはen(英語)のまま。
    ※ デフォルトを変えると、インタフェースの翻訳など、様々なところで異常がでてきます。
  2. 管理セクション≫サイトの環境設定≫言語≫設定≫言語:
    パスプレフィックス(代替言語あり)を選択。
  3. 管理セクション≫サイトの環境設定≫言語≫MULTI LINGUAL SYSTEM≫言語≫Content selection:
    Current language and language neutralを選択。
  4. 管理セクション≫サイトの環境設定≫言語≫MULTI LINGUAL SYSTEM≫言語≫Current translation links:
    オフ。
  5. 管理セクション≫サイトの環境設定≫言語≫MULTI LINGUAL SYSTEM≫言語≫Switch interface for translating:
    オン。
  6. Multi languageモジュールでコンテンツ、メニュー、ブロックの多国語化対応を可能にし、メニューやタイトルなどの単語および熟語はMulti languageモジュールを活用。
  7. 長文またはコンテンツそのものの場合は、Content translationでコンテンツそのものを、各々用意する。
    ※ コンテンツ単位となると言語が違えば文章の長さ、使用する写真なども違ってくる。という考え方です。

ここまで行うにあたり、「1.のデフォルトはen(英語)のまま。」というのから外れここまで行うにあたり、「1.のデフォルトはen(英語)のまま。」というのから外れ

デフォルトを「ja」にしてしまい。少しはまってしまいました。

デフォルトを「ja」にしたのは上述の通り集客対象は日本人なので、デフォルトの言語がenでは日本人が逃げてしまうと思ったからです。日本人のファースト・ビューは絶対に日本語にしたかったからです。

しかし、それにより、「インタフェースの翻訳」で不具合を生じてしまいました。結局Drupalに限らず?デフォルトの言語はen(英語)であり、それを前提としての多国語対応だったようです。

もう一つ、困った事が起きました。

要求では、会員がログインした瞬間に、当該会員の

アカウント設定による言語でページ表示が行われるアカウント設定による言語でページ表示が行われる

というものでした。

私も、てっきりそうなると思っていたのですが、動きが違いました。

実際にアカウントの選択が活かされるのはブラウザ起動時。つまりログイン時ではなく、ログインしっぱなしでブラウザを閉じた後の、ブラウザ起動+自動ログイン時だったのです。

Drupalの言語切り替え機能は、いくつか選択肢がありますが、上記選択肢が一番のようです。

その中でも、何もわからないときの表示言語が日本語というのが必須でしたので、、、

というのは、ゲストユーザ(人間)なら言語切り替えリンクをクリックしてもらえる可能性がありますが、クローラはそんなことはしませんので、へたをすると、インデックスされたページがすべて英語だったなどどいうことが冗談ではなく起きそうです。

従って、何が何でもデフォルト表示は日本語。という事でした。

Drupalによるシステム開発日誌

ここのところ 何か急にDrupalが脚光を浴びてきたような、、、ここのところ 何か急にDrupalが脚光を浴びてきたような、、、

弊社にもDrupalの機能や、Drupalを使う事になった事による質問が増えてきています。

求められる情報から発信し、もっと求めていただくように持ってゆくのが正統派SEOですので、本日より わたし自身の備忘禄もかねて、日常の開発業務での いきさつをつづってゆこうと思います。

Drupalを利用してサイトを構築中でしたが、完成間近で制作を放り出されてしまいました。何とかなるでしょうか?

はい、大丈夫です。

弊社の場合、Drupalを利用したサイトなら、途中からでも修復する自身があります。

ただ、初期設計の問題で、現状のまま問題点をつぶしてゆくだけでは収集が付かない場合がありますので、お引き受けする前に現状の調査をさせていただいています。

調査の結果、現状を引き継ぐより、現状を反省点として再出発したほうが効率が良い場合もあります。

都度、ご相談しながら進めてゆきますので、ご安心ください。

このページ の ページTOPDrupalサイト構築 の サイトマップDrupalサイト構築 の TOPページ