テーマテンプレート ： 403/404 エラーのページでもサイドブロックを表示する
Drupal 5.x から、パフォーマンス向上のため 403 や 404 のエラー時に表示されるエラーページにはサイドブロックが表示されない仕様に変更された。
これを、エラーページでもサイドブロックが表示されるように変更するための方法。
themes/MYTHEME/template.php に、以下の内容を記述する。
修正箇所の MYTHEME 部分はテーマディレクトリ名、および、以下コード中の MYTHEME 部分は設定を変更したいテーマ名。
function MYTHEME_page($content, $show_blocks = TRUE) {
$show_blocks = $show_blocks ? $show_blocks : TRUE;
return phptemplate_page($content, $show_blocks);
}他にも common.inc に修正を加える方法などが、以下の参考サイトなどで紹介されている。
[参考]
Blocks are hidden in 404 pages | drupal.org
Menus Disappear on Page Not Found | drupal.org
403/404 errors should allow blocks | drupal.org
トラックバック
トラックバックは承認後に表示されます。
URLから "-nospam" を削除してトラックバックを送信してください。
コメント
有用な情報をありがとうございます。
2007-11-08(木) 15:58 － amayadori@drupa...いつも、有用な情報を、ありがとうございます。
今度、試しに使ってみます。
余談ですが、ご無沙汰している間に何か心境の変化でもあったのでしょうか?
どうも文体が硬い見下すような印象を受けてしまう感じに変わってしまっていますが・・・。
お気に障ったらお許しください。
ご無沙汰しております。
2007-11-08(木) 16:52 － 0829久しぶりだったのに、一昔の話題で申し訳ないような…
エラー時にブロックが非表示になる件に関しては、どこかで話題になりましたよね。確か。
それを思い出して書いてみたのですが、実際にパフォーマンスにどのくらい影響を与えるかは定かではない（というか、そんなに稼働率の高いサイトを運営していないので計測不可能というのが事実です）ので、そういう方面のことを気にされる場合には、効果的ではないかもしれませんね。本家サイトでもどっちがいいみたいなことが議論されているみたいですから。
Blog コンテンツと Tips コンテンツに関しては、他のユーザには役立たないかも…というのを前提に、自分用のメモとして書き残そうという気持ちで書いているので、たぶんこれまでも 「だ。である。」 口調で書いてたつもりだったのですが、パフォーマンスがどうこうとか、他の方法もあったりとか、その辺りを書き残すにあたって、自分用だけではなくなってしまうような書き方をしていたことが原因かもしれませんね。 ということで、その辺りをちょこっと修正しておきました。
ご心配をおかけして申し訳ありませんでした。が、私自身は残念ながら全く変わっておりません。（成長なしですorz）
一月ぶりで・・・
2007-11-08(木) 18:21 － amayadori@drupa...なんか、気を遣わせてしまって、スミマセン。
ひとつ、謝罪。
ワタシのコメントで
>どうも文体が硬い見下すような印象を受けてしまう
の見下すというのは正しくないですね。"冷たく突き放す"です。
普段から崩した口語調でものを書いているワタシだから余計に気になっただけなのかもしれません。
一応、手近のコンテンツと見比べてみたんだけど、なんか、堅いなーって、思ってしまったのでついつい・・・。
このネット上では自分本位の人が大勢いるので、どこかでいじめられたのかな・・・とか心配してしまいました。
スミマセン、余計なことから派生しちゃって<(_ _)>
コンテンツがないよエラーとか閲覧権限がないよーエラー時にメニューが表示されなくなるって言うのはずいぶん前にこちらで話を聞いていただいた事があります。
想像でしかないですが、現状でもコンテンツブロックが先に送信されてくるテーマの場合はメニューブロックがなかなか表示されないし、メニューがあるブロックが先に送信されてくるテーマではなかなか何も表示されないという感じで、メニューブロックの有り無しでずいぶん違うという印象は持っています。
メニューそのものの処理の問題なのか、ブロックの処理の問題なのかは判りませんけどね。
以上から考えると、メニューを表示した場合はかなり負荷がかかっているとは言えるのではないかと思います。
エラートラップ時に、メニューのあるブロックを表示させるように細工するとおそらく、コンテンツを見ているのと同じくらいの間隔にはなるのではないかと思います。
しかし、ユーザービリティと同じレベルで考えるべきものではないので、この辺の振る舞いがせめて選択制になっていたら良かったのではないとか思ったりもします。
それ以前に、メニューロジックの見直しがされて根本的な効率化が図れればもっと言うことはありませんけどね。
ま、少しずつ、あちらこちら手を入れているようですからその辺は様子を見ましょう。
って、その前に6.x以降に上げられない可能性もあったりしますが(^_^;)
そう言えば、セキュリティアップデートがいっぱい有ったので諸々アップデートするついでにCAPTCHAの最新版を触ってみました。
画像認証が別モジュールのままですけど、同梱されるようになってますね。
簡単な足し算のテストはそのままですけど、単語群から指定した位置の単語を入力させるためのテストも追加になっていました。
画像認証も後者のテストもマルチバイトに対応していますね。
日本語でも画像認証が出来ます。
ただし、ライセンスの問題でフォントは同梱してないので自前で用意しないといけませんけど(笑)
いじっていて思ったのは、なんかワタシがやった手法にどことなく似ているような似ていないような・・・。そんな錯覚をちょっと感じましたが、それだけみんな考えていたことは同じだったんだなーと、ちょっと安心しましたけど(笑)
同じ考えと言えば、ワタシが作ったランダムづくしのテストを作るモジュールと、同じ趣向のモジュールが本家に登録されてましたよ(笑)これまた、考えることは万国共通なんだなと(笑)
あー、CAPTCHAモジュールですが、認証の継続性が設定出来るようになっていましたよ。もう、すごい進化してます。
間違ったら、ログにまで吐き出してますよ。何が入力されてっていうところまで。
ワタシの作った奴の元のモジュールが新しいバージョンに対応しているのが出てましたけど、ふたたびカスタマイズするかどうかは正直に言って悩んでます。
ダウンロードもさほどされていないし、使っている声もないし。
xoopsと違って、Drupalはコミュニティが寂れてますね。
折角素晴らしいアプリケーションなのに、すごく残念という思いがします。
まあ、いいんですけど。
二週間ぶりで、ご無事健在なのが確認できましたので。
って、人のことは言えない(^_^;)
一月くらい放置してましたからね。そんな感じで・・・(何がだ)
わたしからも。
2007-11-09(金) 12:35 － 0829私からもひとつ謝罪を。
お礼を書くのを忘れていました。 いけませんね、ダメな人間になってしまうところでした。
ほんとにいつも、ご指摘やご心配をいただけることには感謝しているんです。 「ありがとうございます。」なんです。
今回も「～していただきたい。」という表現が、ニュース情報を提供するサイトなどにありがちな、ちょっと上からっぽい言い回しだったなということに関して、確かにそうだなと気付かせていただきましたし、基本的には情報提供ではなく自分用のメモのはずなので、えーい修正しちゃえ！と。 そんな感じですから、逆に気を使わせてしまっていたらスミマセン。
……と、メニューブロックについての話題、ここで、でしたか。
Drupal に関する話題はいろいろなところに散らばっているので、どこでの話題なのか、記憶できなくなってきています。
海馬も前頭葉もお疲れなのかもしれません。^^;
単純に想像してみるだけでも、サイドブロックが表示されるよりは非表示な方が断然パフォーマンスがよさそうだとか、メニューモジュールを含め、他のモジュールが絡んだブロックなんかだと、更にパフォーマンスに影響を与えそうだとか、そういうのはなんとなく感じますよね。
ナビゲーションはもちろんでしょうが、考え方によっては、パフォーマンスもユーザビリティの一部になりそうですから、エラーページにサイドブロックを表示するかどうかが設定で選択できたらいいな…というのは、私も思っていました。
で、今回 「template.php にちょっと書き込むくらいでどうにかできるなら、まいっか。」 と思えた方法を見つけたので、一応メモしてみたというわけです。
エラー時にもナビゲーションが必要だという場合には、他にも、ブロック表示のレスポンスを解消するために Block Cache モジュールなどを利用するとか、エラーページをナビゲーションなどを含めた別コンテンツとして作成し、エラー時にはそのノードを表示するとか、やり方はいろいろありそうです。
エラーページについても、CustomError モジュールを利用すれば、1つの実在するコンテンツとして作成するのではなく、その都度モジュールにページを生成させるような感じでエラーページを表示することもできるみたいですしね。
Captcha はどんどん進化していますね。 もう改造したりする必要はないくらいというか、それ以上になっているなと感じました。
前身の Captcha があったからこそ、PHP や Drupal API について学ぶことができたわけですし、そのおかげで Drupal について理解が深まったわけですし、ホント、Captcha モジュールにはいろんな意味で感謝してるんですよね。
なので、本当であれば、何か思うことがあったら CAPTCHA Drupal Group なんかで発言をすればいいんだろうなとは思うのですが、まだまだ、やっと読めるようになってきたぐらいの英語レベルですから、ハードル高すぎです。
とりあえず、今後も更新のペースはボチボチという状況が続きそうですが、どうぞよろしくお願いします。
なんだかんだいいながら・・・
2007-11-09(金) 18:12 － amayadori@drupa...謝罪だなんて、よしてくださいよぉ。
そんなことないですってば。
ワタシはコミュニケーションが好きな質なのでコメント付けるのが好きなんですよ。
で、そのうち"情"が湧いてしまうと言う煩わしいタイプなので(^_^;)その割には初めての人は苦手という人見知りな性格。どっちかにならんかなー(笑)
昨日、手前のrandquestは対応させないかもーみたいなこと言っておきながら、対応してしまいました(笑)
元になっているcaptcha riddlerがバージョン5.x-3.0になっていたので、てっきり対応しているものかと思ったら、使えなかったんですよ。
なので、原因追及もあり、CAPTCHAモジュールの進化も使わない手はないなーと言うことで、対応させてしまいました(笑)我ながら見事な風見鶏ですね(^_^;)
一応、テストはしましたけど万全じゃないですからね。
どこかに落とし穴があるやも(笑)
本家に書き込みが出来るようになったら、どんどん書き込んでください(笑)
既に、いくつか問題点もあるので(^_^;)
・CAPTCHAのAdd CAPTCHA adminstration links to formsというオプションが有効になっているときに、プロフィールモジュールのフィールドで非表示項目の属性のフィールドが編集時に表示されません。
・キャプチャ認証時のキャプチャについての説明が記述できる項目が新設されたんですよ。で、インストールされているロケールコード毎に設定出来るようになっているのは気が利いていいんだけど、翻訳のための文字列が1つしか用意されていないので、自動インポートモジュールを使っているとどちらも翻訳されてしまい、手動でインポートするとどちらも翻訳されないんですよね。翻訳のための文字列をデフォルト用と、それ以外で用意とか出来ればロケールコードが2つの場合はそれで済んでしまうんでしまうんですよね。3つ有った場合は、どうしたらいいのか判りませんけど。私は日本語でしか使わないからいいんですけど(笑)
ま、書き込めるようになったらお願いします(笑)
その時には解決しているような気はしますけど(^_^;)
エラー発生時のブロック表示はthemesettingapiモジュールを併用することで、テーマ設定の画面で切り替えが出来るようには出来るんじゃないかと。
試しにやってみようかと持ったんですけど、切り替えるような自体があまりあるとは思えないし、そもそも、ワタシのようにテーマを頻繁に変えるような輩にはある意味めんどくさい行為になりそうなので放棄しました(^_^;)
うちの場合、過去のコンテンツを削除したりとかはほとんどしていないので、検索エンジンから飛んできてもエラーには遭遇しないと思っているので、エラーに出くわすのはスパマー?とか思ったりしてます。
アクセスデニーはしょうがないですが、これも悪さを企んでいる輩?とか思っていたりするので、ま、これもいいかな？みたいな安易な気分になりつつあります(笑)
別に苦情が出ている訳じゃないし、コメントがついたりメールもらったりしている訳じゃないので、それこそ投げやりです(いいのかそれで?)
ま、楽しく行きましょー(笑)
どうせ、誰も真剣に見てませんって。
あっ、0829さんのトコロはすごく参考にしている一階結構多いみたいですね。うちとは大違い(笑)
と言うことで、駄文はこの辺で(^_^;)
Theme Settings API、アリですね。
2007-11-12(月) 13:40 － 0829モジュール同士の互換性って、同じ開発者の方が作成しているものでないとなかなか難しいのでしょうね。
特に、元になっているモジュールに大きな仕様変更があったりした時には、対応すること自体考えちゃいますよね。たぶん。
結局は自分で何とかしないと…というのも、オープンソースかつ自由度の高さ故、と言えるのかもしれませんね。
っと、これはお互いに…ということで。
本当はできた方が貢献度高いんだろうな…と "たまに" 思うことがあるだけで、道のりは果てしないですからね。
そうですね。 実際には試していないのですが、きっといけると思います。
私の場合は、テーマ自体をほとんど一から自作しているので、template.php に書き込んだ方が手っ取り早いのですが、配布テーマを作成されているような場合には、ぜひ Theme Settings API モジュールと絡めて作成していただきたいですよね。
ああ、そういえば、配布できるようなテーマを作成したいなとも思っていたんですよね、私も。 ボチボチと頑張ります。
簡単にできますよ、思った以上に・・・たぶんですけど(笑)
2007-11-12(月) 15:26 － amayadori@drupa...ごめんなさい<(_ _)>
ワタシが作った(改造した?)randquestは中身は見ない方がいい代物です(笑)自分でも判りません(^_^;)
ワタシのように興味本位だけでやった人間のものは最悪ですよ。ソースが汚いし一貫性がない(笑)
計画性を持って拡張していないからですけどね。
って、ワタシの場合は読むことすらしていません。
いや、本当に英文、アレルギーなんです。
だから、本音ではPHPなんて（PHPに限らないですけど)触りたくないんです。
非難されようが、馬鹿にされようが「日本語で記述できるスクリプト」でやりたいです(T.T)
とは思っていますが、そんなものはローカルでしか使えないのであまり現実的ではないのでPHPと仲良くやっています(仲がよいかと言うよりこき使われているという感じデスけど)(笑)
とりあえず、0829さんの方が、情報見てるし、発見するのも早いしこの方面に関しては0829さんの方が断然上ですよ(笑)ワタシは、技術系の知識もないですしね。その分理解力に断然、不利です(^_^;)
と言うことで、0829さんに期待したというわけです(ヲイ)
themesettingapiモジュールはsettings.phpというものの中に、変数を発生させる部分を記述して、それをモジュールがテーマ管理画面に割り込ませているわけですが、今回のこの例だと、テーマ自体には影響しないので割と簡単にいけちゃうと思います。
template.phpに0829さんが探してきた部分を記述して、あとは変数を参照してon/offするようにすればいいのではないかと思います。当然、settings.phpにその変数を設定させるようなものを作らなければいけませんけどね。
そう考えるとそんなに難しくないですよね?ね?(^_^;)
出来ないですかね?とか言っておきながら、頻繁にテーマを入れ替えるのでtemplate.phpに記述するだけでも面倒なワタシは、settings.phpに書き込む方法ですら試してません(ヲイ)自分で言っておいてアレですが(^_^;)
ま、暇だし、難しくないので(たぶん、おそらく)ちょっと、やってみます。結果は後ほど(笑)
他の方法でも上がっていたコアの一部をいじるのは、それこそリスクが高いので、せめて、テーマ周辺か、モジュールでon/offが出来るようになった方がメリット大きいんですけどね。
空いた時間に…
2007-11-12(月) 16:25 － 0829私も、エキサイト翻訳と Google 翻訳と Yahoo!翻訳の 3つのサイトをフル稼働させながら、やっと…ですから、最近英語アレルギーが少しは軽減されてきたといっても、期待はできないですね。（って、できないことを自慢しても仕方ないんですけど…^^;）
たぶんサンプルファイルだと思うんですけど template.php と theme_setting.php が同梱されているみたいなのと、Custom Theme Settings | drupal.org をざっと見た感じから察するに、theme_setting.php で定義した内容を template.php とか .tpl.php とかから theme_get_setting() 関数を使って読み込むという感じですかね？（コードのあるページは翻訳サイト通すと余計に意味不明になりがちなんですよね…）
まあ、自分でやってみるのが一番ですよね。 空いた時間にちょっと弄ってみようかな。
スミマセン(^_^;)
2007-11-12(月) 16:56 － amayadori@drupa...既にやってしまいました(笑)
ソースは手前のサイトに貼り付けておきましたので一読いただければ判りやすいかと(判りやすいかな?書いている人間が問題ですがね)。
仕組み的には、お察しの通り、theme_get_setting() 関数で設定内容を引き出して条件分岐をさせる感じです。
今回は、元々template.php内に直書きするタイプなので、変数を見て条件分岐させただけの簡単なものですが、実験的には成功した模様です。
プライベートで使うには、テーマデザインを変える度に手をかけなきゃいけないので、あまりメリットはないような気がしますが、テーマデザインを配布しようという人にはメリットはあるでしょうね。
通常は、themesettingsapiモジュールが存在しなかったときのトラップを備えないといけないのですが、ま、無くても変数自体が無視されるだけで、仕組み的には該当部分は実行されないので影響はないでしょう(笑)
とりあえず、簡単にできましたね(^_^;)
テーマデザインや、themesettingsapi絡みの翻訳poについて日本語プロジェクトでも話題に出てましたね。
ま、今回はスルーしておきましたけど(笑)実験だし(笑)
いえいえ、ありがとうございます。
2007-11-12(月) 17:38 － 0829403や404でブロック領域を表示させるのをUIでon/offさせてみました | Drupal-J.com でのソース、読ませて？いただきました。 ありがとうございます。
どちらにしても、今後、Thema Settings API については必要になることもあるかもしれないので、自分でも何かしらやってみようと思います。
は、サンプルコードに記載されていた、以下のような方法になるのかな？と… （まだ手を付けてないので何とも…ですが。）
あ、これは amayadori さんのところにコメントした方が良かったのかも…
良ければ修正してください・・・スミマセン
2007-11-13(火) 18:50 － amayadori@drupa...先のコメントで、手前のサイトの記事を参照いただいておりますが、pathautoモジュールのアップデートを行った際に仕様が変わっていてtokenモジュールを使うようになったのはいいのですが、記述の仕方が変更になってしまっていました。
しかし、バージョンアップに伴い旧来のpoファイルには含まれていない箇所が多数出現したためにエラーメッセージ等が不明な状態のまま、ひとまずブログにしたためたのですが、仕様が変更なった部分にちょうどはまってしまったようで、参照していただいている先のURLが意図していないものになっておりました。
本日、やっとpathautoの日本語化に手を付けて、何がいけないのかが判ったのでpathautoの設定をし直したのですが、その際、謝ってオプションを変更していまい、古い別名URLを削除する動作になっていました。
その影響で、リンク先を開いてもエラーにこそなりませんが、意図したページは開かれなくなってしまいました。
万が一リンクを辿ってこられる方にご迷惑をおかけするのも申し訳ないので、0829さんの手を煩わせるようで申し訳ないのですが、コメント中のリンクURLを修正していただけないでしょうか?
現在のURLは http://drupal-j.com/blog/amayadori/242 になっています。
本当に申し訳なく思います。ごめんなさい。
ご連絡ありがとうございます。
2007-11-14(水) 12:09 － 0829すみません、遅くなりましたが修正させていただきました。
モジュールのアップグレードはいいのですが、記述の変更というのはうれしくない仕様変更でしたね。
ご連絡ありがとうございました。
ありがとうございます。
2007-11-14(水) 18:02 － amayadori@drupa...色々と、お骨折りいただきまして、ありがとうございます。
お手間取らせました<(_ _)>
おそらく、tokenモジュールを必須にして、依存度を高めたために、takenモジュールに合わせる必要が出てきたのではないかと推測してます。
もしかすると、オプションなどの状態によっては以前のバージョンのままでも問題が出ないのかもしれませんが、日本語化の過程ではそこまでうかがい知ることが出来ませんでしたので現状、断言は出来ません。
トラブル時の過程で、一度すっぱりデフォルト値に戻しているので、少なくとも、デフォルトの状態では互換性がない仕様なのだとは思います。
同梱のinstall.txtには
> For content patterns:
> [user] is now [author-name]
> [cat] is now [term]
という記述がありますので、ブログで使うであろうユーザー名に置き換える書式は変更になっていると明言されていますから、ブログメインの運営のサイトは注意が必要です。
takenモジュールから取得する値の処理方法によってなのかもしれませんが、上記の新しい書式ですらエラーを返します。この辺がさらに混乱の元になっています(うちの場合[author-name-raw]を使わないとエラーが返ってきました)。
pathautoを導入しているサイトで2.0系にアップデートする場合にはアップデート直後にはコンテンツの作成・編集は一切行わず、エラーメッセージを駆逐し終わるまでpathautoの設定を優先的にすることをおすすめします。
そうしないと、闇雲にいじり回してしまい、既存のエイリアスを新しいので置き換えてしまうと言う間抜けなことをやってしまいます(^_^;)
一応、過去の訳をそのまま引き継いだ上での日本語化なので、過去の訳と表現が違う部分が目立つかもしれませんが、とりあえず設定する分には問題ないと思うので、0829さんのところでお使いでアップデートする予定があったら使ってください。projectにおいてあります。
pathautoのモジュール情報を書いてからリンクを貼ってオープンにしますが、非公開にはしていないのでproject/ja-pathautoで見れますので(^_^;)
そんなわけで、お騒がせいたしました<(_ _)>
なるほど。
2007-11-19(月) 10:53 － 0829ユーザ名やカテゴリ名などは使用頻度が高い部分だと思いますから、気をつけないといけませんね。
セキュリティアップグレード以外のアップグレードというのは、行うべきか、そのまま現状を維持すべきか、なかなか悩ましいですね。
面倒なので Install.txt を読まないこともあったのですが、やっぱり読まなきゃいけないな…と実感しました。
詳しく見ていないので単なる予想ではありますが、ユーザ情報へのリンクなどを含んだものが [author-name] で、ユーザ名のテキスト部分のみを抜き出したものが [author-name-raw] となっているのかもしれませんね。
Pathaouto モジュールだけを考えるとわかりにくい仕様に感じますが、他のモジュールでも活用するということを考えると、そんなものなのでしょう。
何はともあれ、いろいろありがとうございました。
いろいろと・・・
2007-11-12(月) 18:35 － amayadori@drupa...色々と、ありがとうございます。
調べもしないで書きました。ごめんなさい。
エラートラップについては装備されているのが前提で、しかも実験という程度の感覚でしたので意図的にスルーしました。
参考にしたテーマデザインにはちゃんとトラップが埋め込んでありましたので横着しなければ良かったんですけどね(^_^;)
ま、templatesettingsapiモジュールに手を出そうという人は(全く)phpを知らずには出来ないはずだと思ったので、その辺高をくくりました。ごめんなさい。
ま、方法としては変数がnullならデフォルトを埋め込むというのもありかもとは思います。
変数が多いと効率悪いですけどね(笑)
themesettingsapiモジュールが当たり前になってくる可能性もありますし、マージされる可能性も否定は出来ないでしょうから触っておいて損はないかもしれませんね。