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

会員制サイトの構築にあたり、今まではユーザ・プロフィールやユーザ固有コンテンツの表示・非表示を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. 管理セクション≫コンテンツの管理≫投稿の設定ページの
   ノードアクセスの状態：［アクセス権の再構築］をクリックして、変更を反映させます。

メニューやタイトルを動的に作成

ブログやCMSは、動的にコンテンツを生成します。

その関係で、表示されるメニューやタイトルは動的に作成されます。その関係で、文字においても画像によるインパクトが出せず、なんとも煮え切らないページになっているということはないでしょうか。

Signwiterモジュールを利用することで、装飾の自由度が格段にあがります。

例えば、本サイトのタイトル(このページでは「メニューやタイトルを画像にする-Signwriter」)もSignwriterモジュールを利用して表示しています。

いかがでしょうか？ブラウザに依存する文字には得られないデザイン感が出ていませんか？

Signwriterは以下の手順で有効にします。

1. 管理セクション≫モジュールで「Singnwriter」を有効にします。
2. ユーザの管理≫権限でsignwriter モジュール以下、
   ・administer signwrite
   ・ruse PHP for signwriter pages
   を有効にします。
3. 管理セクション≫サイトの環境設定≫Signwriterで、最低限の設定を行います。
   
   薄赤の部分は上記と同様に設定してください。
4. 次にAdd a profileをクリックして画像変換用のプロファイルを作成します。
   
   薄赤の部分にプロファイル名を入力します。いくつかプロファイルを作成する場合は違いの分かる名前にします。
5. 全般の設定は以下のようにします。
   
6. テキスト部分の設定を 通常時、Hover時、アクティブ時各々行います。
   
7. Drop Shadow、Background、Borderに関しても同様に設定します。
8. Image Layout、Image Typeを設定します。
   
   上記はこのサイトのページタイトル用の設定例です。慣れてきたら変えてみると違いが分かってきます。
9. [保存]すると、Signwriterのメイン設定ページに戻ります。
10. 上記で設定したプロファイルが Profile一覧に表示されます。
    
11. Template Hooksで作成したプロファイルをPage titles:で使用するように選択します。
    
    必要に応じて、プロファイルを作成し、各々割り当てます。
12. メニューに対してSignwriterを適用する場合は、上記同様にプロファイルを作成し、各々のメニューに割り当てます。
    
13. 最後に[設定の保存]を行います。

いかがでしょうか。あまり使いすぎると、うるさいですが、Signwriterはリアルタイムの画像処理はサーバ側で行うためクライアントに負担をかけません。

生成されるタグにもキャラクタ文字列は残っており、SEO的にも問題がありません。

自動登録ロボット対策としてCAPTHAモジュール

Webサイトを設置し、しばらくたつとお問い合わせフォームから全文英語（ほとんどハイパーリンクのみの本文）の投稿が目立つようになってきます。

宣伝目的による自動登録ロボットによる投稿です。

対策として、Drupal CAPTHAモジュールが利用できます。

あまり目立たないうちはスパム対策といえど、善意の訪問者に対してのユーザビリティを下げるので あまり使いたくないですが、増えてくると、善意の投稿まで見落としてしまう事になってしまうので、ころあいをみて CAPTCHAモジュールを活用します。

以下の手順で利用します。

1. 管理セクション≫サイトの構築≫モジュール：Spam control：CAPTCHAを有効にし、[設定の保存]をクリックします。
   
2. 管理セクション≫ユーザの管理≫CAPTCHA で以下の設定を行います。
   
   最下行の webform_client_form_29 は本サイトのお問い合わせフォームのフォームIDです。
   ID名はお問い合わせフォームの数や設置順で変わってきますので最後の数字の部分は自分のサイト上の数値にあわせます。
   上記入力後[設定の保存]をクリックします。
3. 管理セクション≫ユーザの管理≫CAPTCHA≫Image CAPTCHAページで、Exampleの様子を見ながら各種 見栄えの設定を行います。
   機能的にはデフォルトの状態で機能しますが、デフォルトのままだと、多少見にくいので調整します。
   
4. [設定の保存]をクリックします。

以上で設定は完了です。

お問い合わせフォームを表示すると、送信ボタンの上に以下のように表示されるようになります。

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

ことの発端は、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モジュールはまだβ版。使う方がいけないような気もしますが、もっと深く調べるか、次バージョンに期待するか、考え中です。