web-dev-qa-db-ja.com

管理ページのWSOD

事実は次のとおりです。

  • Drupal 6.20のクリーンインストールを行いました
  • インストールおよび有効化 管理メニュー モジュール

この時点から、admin/*ページにアクセスできなくなりますが、node/*user/*の両方にアクセスできます...

PHPログ:

No entries

Apacheエラーログ:

No entries

Apacheアクセスログ:

127.0.0.1 - - [10/Mar/2011:16:22:16 +0000] "GET /drupal_testes/ HTTP/1.0" 200 5771
127.0.0.1 - - [10/Mar/2011:16:22:14 +0000] "GET /drupal_testes/admin HTTP/1.1" 200 -

DBテーブルウォッチドッグ:

Nothing serious... 

/drupal_testes/admin...への1回のアクセスについては、これですべてです。
(システムテーブルで)admin_menuを無効にしても機能します。また、補足として、admin/build/modulesにアクセスして管理メニューを再度有効にすると、ページがロードされてWSODで終了するまでに時間がかかります。
その後drupal_testes/nodeにアクセスすると、admin/*ページを除いて、admin_menuがアクティブで機能しています。

WSODウォークスルー は知っていますが、このケースが当てはまる理由はありません。
なぜこれが起こっているのか、何か考えがありますか?


#4を編集

  • インストール時のまったく同じ動作 Token

#5を編集

  • 理論上はトークンや管理メニューよりも重いCCKをインストールしても問題はありません。
  • cache_*テーブルをフラッシュしても何も変わりません。
  • Php.ini memory_limitを増やしても違いはありません...

問題は問題のモジュールを無効にすることで解決されますが、目標はそれらをアクティブにして適切に機能させることです...

3
acm

新しいサイトを開始したばかりで、質問に示されているようにまだデータが含まれていない場合は、再インストールした方がWSODのソースを検索するよりも速くなる可能性がありますDrupal.


そうでなければ、データベースを直接見ることができます:

  • まず、ウォッチドッグテーブルを確認します。ApacheおよびPHPログに表示されないエラーメッセージが含まれている可能性があります

  • 次に、_cache_something_という名前のすべてのテーブルを切り捨てて、キャッシュを空にします

  • 次に、このモジュールが問題の原因であると確信している場合は、テーブルsystemで有効なモジュールのリストを編集できます。 :リストからモジュールを見つけて、その_status to "0"_を変更します

ただし、データベースに直接変更を加える場合は、念のため、まずバックアップを保存してください;-)

4
wildpeaks

PHPメモリ制限が32 MB以上に設定されている)こと、および出力バッファリングが有効になっていることを確認してください。

1
Codeblind

これがあなたのケースで起こっていることかどうかはわかりませんが、開始前にBOM署名が存在します<?php見えにくい。モジュールに問題があり、WSODは、使用しているエディターによって追加されたBOMシグネチャが原因であることが判明しました。その後、通常のエディターでファイルを編集すると、このシグネチャは表示されませんでした。次に、デフォルトでBOM署名を追加するようにエディターが設定されていることを発見しました。

スペースに似た目的を持ついくつかのUnicode文字もありますが、一部のエディターでは表示されません。これも私にも起こり、ファイルのコンテンツをフォーラムに投稿し、Firefoxを使用してそのフォーラムページを表示するまで、WSODの理由を理解できませんでした。

0
kiamlaluno