DrupalDrupal

keyword自動生成モジュール

投稿したコンテンツ本文の内容に応じて自動的にページ・キーワードを生成投稿したコンテンツ本文の内容に応じて自動的にページ・キーワードを生成

keyword自動生成モジュールとはkeyword自動生成モジュールとは

投稿したコンテンツ本文の内容に応じて自動的にページ・キーワードを生成し、ページ表示時にmeta keywordsに自動的に割り当てます。

無理やり作ったキーワードではなくコンテンツの内容に応じたキーワードなので自然なキーワードが作成され、ページ・キーワードとして反映します。

コンテンツを自分で更新できるといっても、コンテンツを変更する度にキーワードを同時に変更するのは面倒くさい。毎回本文内容に同期してキーワードを変更している方は稀ではないでしょうか。

コンテンツ投稿の面倒を解消コンテンツ投稿の面倒を解消

それに本文変更に基づいてキーワードを変更したつもりでも体感的な変更になってしまうため、本文で使用していない言葉がキーワードとして残ってしまったり、本文で協調しているキーワードを漏らしたり、人為的なミスが起こりがちです。

更に良質なコンテンツ投稿のアドバイザーとして更に良質なコンテンツ投稿のアドバイザーとして

キーワード自動生成機能は、そのような人為的ミスを防止し、快適なコンテンツ投稿環境を提供するばかりではなく、本文入力の結果、どのようなキーワードが自動生成されるか意識する事により検索エンジンに最適なコンテンツ(本文)記述のノウハウを自然に構築します。

狙ったキーワードで検索上位に表示するためには狙ったキーワードで検索上位に表示するためには

狙ったキーワードを本文中の有効な位置に有効な使い方で、使う必要があります。

キーワード自動生成機能を利用する事で自然に良質なコンテンツを登録するスキルが身につきます。

アクセス解析モジュール

GoogleAnalyticsによる高度なアクセス分析+アクト・ブレイン アクセス解析ツールGoogleAnalyticsによる高度なアクセス分析+アクト・ブレイン アクセス解析ツール

アクト・ブレイン製アクセス解析ツールとの連携機能をDrupalモジュール化しました。

同時にGoogleAnalyticsタグを組み込みます。

GoogleAnalyticsによる高度なアクセス分析に加て、アクト・ブレイン製アクセス解析ツールを利用することでアクセス解析の制度が大幅に向上します。

解析用タグはDrupalブロックとして生成されるので、管理ページやカウントしたくないページの指定が自由に設定できます。 

無料アクセス解析ツールの特徴無料アクセス解析ツールの特徴

ページ閲覧の流れを解析

「時間別遷移表示時=一日分の解析時」の「ページ分析」、「ページ入口」表示機能中に該当ページ以降のページ閲覧履歴を表示する機能を追加しました。[次に見たページ]

ページ単位での複数訪問者のページ閲覧の流れを表示するようにしました。これにより訪問者のページ閲覧のおおまかな流れが人目でわかるようになります。

下の「個人閲覧解析機能」は個人にフォーカスして追いかけるもので、他のアクセス解析ツールにも機能を持つものもありますが、ページにフォーカスして閲覧の流れを追うのは弊社オリジナルです。

"ほとんど"の訪問者や、"だいたい"の訪問者がどういう流れでページを閲覧しているのかをつかむ事により、導線を考慮したコンテンツの増やし方、キーワードの決め方が見えてきます。

個人のページ閲覧の流れを解析

ページ閲覧はページにフォーカスしてページ閲覧の流れをページ単位で追うものですが、個人閲覧解析機能は訪問者個人がどのページをどんな流れで閲覧したか解析する機能です。

これにより、個人々がどういった流れでページを閲覧したかが一目瞭然となります。

検索されたワード+入口ページ、さらにその先の閲覧の流れを解析

従来の「検索ワード分析」は検索エンジンで検索したワードをランキング表示するのみでした。

今回の拡張では、「検索ワード分析」画面のキーワードの横に「このキーワードで検索されたページ」ボタンを追加しました。

このボタンをクリックすると、「ページ入口」画面に変わり、当該キーワードで検索されたページのみの一覧が表示されます。

検索エンジンからの訪問が「キーワード」+「入口ページ」のペアで表示されます。

さらに[次に見たページ]を解析表示できます。

検索エンジン名の一覧表示

「入口ページ」画面ではそれぞれのページに飛び込んできたときの、検索ワード+検索エンジン名が一覧表示されます。

更に、[検索結果ページ]ボタンをクリックする事により、検索結果画面を別WindowにOpenします。検索されたときの様子、ライバルとの順位関係がわかります。

検索順位ばかりでなく、ライバルとの前後関係、内容の違いなど、ワンタッチで確認する事ができます。

リンク元ページの解析

訪問者は検索エンジンからのみではありません。様々なリンク元があり、そこからの訪問もあります。

「入口ページ」画面で表示される[リンク元ページ]をクリックするとリンク元ページが別Windowに開きます。

見慣れないページ経由の訪問を見つけたときなど、ワンクリックで確認できます。

無料アクセス解析ツールの仮登録ページ 無料アクセス解析ツールの設置方法はこちらです。

Drupalモジュール製作事例

アクト・ブレインのDrupal設置・運用サポートは Drupalオリジナル・モジュールの製作を基盤として行っています。

もともと、組み込み制御ソフトウェアの開発を行っていたアクト・ブレインだからこそです。

管理アイコン

管理ページにダイレクトにジャンプするアイコン管理ページにダイレクトにジャンプするアイコン

管理アイコン(adminicons)はアクト・ブレインのオリジナルモジュールです。

管理アカウントでログイン中に管理ページにダイレクトにジャンプするアイコンを追加表示します。

なぜ管理アイコン(adminicons)?なぜ管理アイコン(adminicons)?

Drupal標準のナビゲーションメニューやAdministrator Menu等の拡張モジュールによるナビゲーションは それなりに便利ですが、汎用的なメニューなので 機能性がいまいちです。

公開ページと管理ページのデザインが変わらない割には、ダイレクトに管理できるようなイメージがありません。(ありきたり?)

管理アイコン(adminicons)を追加すると管理アイコン(adminicons)を追加すると

アクト・ブレインのオリジナルモジュール(adminicons)を追加すると、管理ユーザでログインした時に、メニューやブロックの端に小さなアイコンが現れ、管理ページに直接ジャンプできるようになります。

Drupal標準ではコンテンツ表示時、[編集]ボタンが表示され、表示中コンテンツそのものの[編集]画面へはダイレクトに行けます。(上図 青○部分)

ところが、その他の内容を管理しようとすると、ページ最上部の黒地に白字のメニュー(Administration Menu拡張モジュール)や標準のナビゲーションメニューから行かなければなりません。(1クリックでは行けません)

アクト・ブレイン製adminiconsをインストールすると、上図赤○部分のように各ブロックの右上部に管理ページにダイレクトにジャンプするためのアイコンが表示されるようになります。

ワンクリックで相応する管理ページにジャンプできるため、操作性が向上します。

特に、ブックページやページ追加時の表示順の変更などは非常に簡単にできるようになります。

Inviteモジュール「申し訳ありませんが、招待状を送信可能な上限に達しています。」エラー

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」という名称に変更。という方法でした。

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

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

View_ownモジュールとFaqモジュール

Faqコンテンツがアクセス権にひっかかって表示できなくなったFaqコンテンツがアクセス権にひっかかって表示できなくなった

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

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

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

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

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

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

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

31: function view_own_perm() {
32:   foreach (node_get_types() as $type) {
33:     if ($type->module == 'node' ) {
34:      $perms[] = 'view own '. $type->type .' content';

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

31: function view_own_perm() {
32:   foreach (node_get_types() as $type) {
33:     if ($type->module == 'node' || $type->module == 'faq') {
34:      $perms[] = 'view own '. $type->type .' content';

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

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

View_ownモジュールとWebformモジュール

View_ownモジュールインストール後、Webform投稿ページが表示できなくなったView_ownモジュールインストール後、Webform投稿ページが表示できなくなった

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

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

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

Drupal標準の権限設定では

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

がown/anyそれぞれで定義可能です。

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

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

標準の権限設定に加えてノードタイプごとの own/anyそれぞれの閲覧権限が設定できるようになります。

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

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

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

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

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

31: function view_own_perm() {
32:   foreach (node_get_types() as $type) {
33:     if ($type->module == 'node' ) {
34:      $perms[] = 'view own '. $type->type .' content';

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

31: function view_own_perm() {
32:   foreach (node_get_types() as $type) {
33:     if ($type->module == 'node' || $type->module == 'webform') {
34:      $perms[] = 'view own '. $type->type .' content';

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

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

コンテンツにビューを挿入する

コンテンツの表現力やユーザビリティを向上コンテンツの表現力やユーザビリティを向上

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

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

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

insert_viewモジュールの利用方法insert_viewモジュールの利用方法

モジュールを有効にする

  1. 管理セクション≫サイトの構築≫モジュールでinsert_viewを有効にし、[設定の保存」をクリックします。
  2. 管理セクション≫サイトの環境設定≫入力書式ページを表示します。
  3. ビューをインサートしたい書式行の[設定]をクリックし、設定ページを表示します。
  4. insert view filterをチェックし、[設定の保存]をクリックします。
     

コンテンツに挿入する

例えば、ここにトップページのサイドブロックに表示されているフォトギャラリブロックを挿入してみます。

 

 

 

 

  1. 管理セクション≫サイトの構築≫ビュー≫リストを表示します。
  2. [編集]をクリックし、設定ページを表示します。
     
  3. 設定ページでは表示したいブロックをクリックし、選択したブロック上にマウスを置くと、ステータスバーに当該ブロックのIDが表示されます。

    上記、http://~中の、
    ・photo_gellery部分がview-ID。
    ・block_1部分がdisplay-IDです。
  4. コンテンツ中に[view:view-ID=display-ID]の型式で記述します。
    ↓がその結果です。
  5. パラメータやページ等は以下のような記述を行います。
    [view:name of view] is replaced by the content listing.
    [view:name of view=name of display] invokes the view using the specified display (see README.TXT for more info).
    [view:name of view=name of display=arg1,arg2,arg3] invokes the view using the specified display and passes arg1, arg2 and arg3 to the view.
    [view:name of view==arg1]
    詳細→insert_view

ユーザ・プロフィール情報への画像の仕込み方

ユーザ・プロファイルの中に仕込む画像のことで はまるユーザ・プロファイルの中に仕込む画像のことで はまる

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

アバターの問題アバターの問題

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

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

通常、

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

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

Content_profile拡張モジュールContent_profile拡張モジュール

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

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

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

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

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

しかし、

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

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

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

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

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

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

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

会員制サイト用:ログイン直後のページをユーザ・グループ別に指定

ユーザ・グループ(ロール)毎に異なるページを表示する拡張モジュールユーザ・グループ(ロール)毎に異なるページを表示する拡張モジュール

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

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

残念。

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

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

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