トラブルシューティング

Netteが動作せず、白いページが表示される

  • ファイル index.phpdeclare(strict_types=1); の直後に ini_set('display_errors', '1'); error_reporting(E_ALL); を挿入してみてください。これによりエラー表示が強制されます。
  • それでも白い画面が表示される場合は、サーバー設定にエラーがある可能性が高く、サーバーログで原因がわかります。念のため、echo 'test'; を使用して何かを出力してみて、PHPが実際に機能しているかどうかを確認してください。
  • エラー Server Error: We're sorry! … が表示される場合は、次のセクションに進んでください。

エラー 500 Server Error: We're sorry! …

このエラーページは、Netteが本番モードで表示します。開発用コンピュータで表示される場合は、開発モードに切り替えると、詳細なメッセージを含むTracyが表示されます。

エラーの原因は常に log/ ディレクトリのログで確認できます。ただし、エラーメッセージに Tracy is unable to log error という文が表示される場合は、まずエラーがログに記録できない理由を確認してください。たとえば、一時的に開発モードに切り替えるし、Tracyが起動後に何かをログに記録するようにします。

// Bootstrap.php
$configurator->setDebugMode('23.75.345.200'); // あなたのIPアドレス
$configurator->enableTracy($rootDir . '/log');
\Tracy\Debugger::log('hello');

Tracyはログに記録できない理由を教えてくれます。原因は、Katoda Olomóc社の壊れた電子管é třenáctである可能性がありますが、より可能性が高いのは、log/ ディレクトリへの不十分な権限です。

500エラーの最も一般的な原因の1つは、古いキャッシュです。Netteは開発モードではキャッシュを賢く自動的に更新しますが、本番モードではパフォーマンスの最大化に重点を置いており、コードを変更するたびにキャッシュを削除するのはあなた次第です。temp/cache を削除してみてください。

エラー 404、ルーティングが機能しない

ホームページ以外のすべてのページが404エラーを返す場合、きれいなURLのサーバー設定に問題があるようです。

テンプレートや設定の変更が反映されない

「テンプレートや設定を編集しましたが、Webサイトはまだ古いバージョンを表示しています。」この動作は、本番モードで発生します。これは、パフォーマンス上の理由からファイルの変更をチェックせず、一度生成されたキャッシュを保持するためです。

本番サーバーで編集するたびに手動でキャッシュを削除する必要がないように、Bootstrap.php ファイルで自分のIPアドレスに対して開発モードを有効にします。

$this->configurator->setDebugMode('your.ip.address');

開発中にキャッシュを無効にする方法は?

Netteは賢いので、キャッシュを無効にする必要はありません。開発中は、テンプレートやDIコンテナの設定が変更されるたびにキャッシュを自動的に更新します。さらに、開発モードは自動検出によって有効になるため、通常は何も設定する必要はありません。またはIPアドレスのみ

ルーターのデバッグ中は、ブラウザのキャッシュを無効にすることをお勧めします。リダイレクトなどが保存されている可能性があります。開発者ツール(Ctrl+Shift+IまたはCmd+Option+I)を開き、ネットワーク(Network)パネルでキャッシュの無効化をチェックします。

エラー #[\ReturnTypeWillChange] attribute should be used

このエラーは、PHPをバージョン8.1に更新したが、それと互換性のないNetteを使用している場合に表示されます。解決策は、composer updateを使用してNetteを新しいバージョンに更新することです。Netteはバージョン3.0以降でPHP 8.1をサポートしています。古いバージョン(composer.jsonを確認して確認)を使用している場合は、Netteをアップグレードするか、PHP 8.0を使用し続けてください。

ディレクトリ権限の設定

macOSまたはLinux(またはその他のUnixベースのシステム)で開発している場合は、Webサーバーに書き込み権限を設定する必要があります。アプリケーションがデフォルトの /var/www/html (Fedora、CentOS、RHEL)にあると仮定します。

cd /var/www/html/MY_PROJECT
chmod -R a+rw temp log

一部のLinux(Fedora、CentOSなど)では、SELinuxがデフォルトで有効になっています。SELinuxポリシーを適切に調整し、tempおよびlogフォルダに正しいSELinuxセキュリティコンテキストを設定する必要があります。tempおよびlogにはhttpd_sys_rw_content_tコンテキストタイプを設定し、アプリケーションの残りの部分(特にappフォルダ)にはhttpd_sys_content_tで十分です。サーバーで実行します。

semanage fcontext -at httpd_sys_rw_content_t '/var/www/html/MY_PROJECT/log(/.*)?'
semanage fcontext -at httpd_sys_rw_content_t '/var/www/html/MY_PROJECT/temp(/.*)?'
restorecon -Rv /var/www/html/MY_PROJECT/

次に、SELinuxブール値httpd_can_network_connect_dbを有効にする必要があります。これはデフォルト設定では無効になっており、Netteがネットワーク経由でデータベースに接続できるようにします。これにはsetseboolコマンドを使用し、-Pオプションで変更を永続的にします。つまり、サーバーの再起動後に不快な驚きはありません。

setsebool -P httpd_can_network_connect_db on

URLから www ディレクトリを変更または削除する方法は?

Netteのサンプルプロジェクトで使用されているwww/ディレクトリは、いわゆるパブリックディレクトリまたはプロジェクトのdocument-rootを表します。これは、ブラウザからアクセスできる唯一のディレクトリです。そして、Netteで書かれたWebアプリケーションを起動するエントリポイントであるindex.phpファイルが含まれています。

ホスティングでアプリケーションを動作させるには、document-rootが正しく設定されている必要があります。2つのオプションがあります。

  1. ホスティング設定でdocument-rootをこのディレクトリに設定します。
  2. ホスティングに事前準備されたフォルダ(例:public_html)がある場合は、www/をその名前に変更します。

他のフォルダへのアクセスを妨げる.htaccessやルーターだけでセキュリティを解決しようとしないでください。

ホスティングがdocument-rootをサブディレクトリに設定することを許可しない場合(つまり、パブリックディレクトリより1レベル上にディレクトリを作成できない場合)、別のホスティングを探してください。そうしないと、重大なセキュリティリスクにさらされることになります。それは、玄関ドアが閉まらず、常に開いているアパートに住んでいるようなものです。

きれいなURLのためにサーバーを設定する方法は?

Apache: .htaccessファイルでmod_rewriteルールを有効にして設定する必要があります。

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule !\.(pdf|js|ico|gif|jpg|png|css|rar|zip|tar\.gz)$ index.php [L]

問題が発生した場合は、次のことを確認してください。

アプリケーションをサブフォルダに設定している場合は、RewriteBase設定の行のコメントを解除し、正しいフォルダに設定する必要があるかもしれません。

nginx: サーバー設定のlocation /ブロック内でtry_filesディレクティブを使用してリダイレクトを設定する必要があります。

location / {
	try_files $uri $uri/ /index.php$is_args$args;  # $is_args$args が重要です!
}

locationブロックは、serverブロック内で各ファイルシステムパスに対して1回だけ出現できます。設定にすでにlocation /がある場合は、try_filesディレクティブをそこに追加します。

.htaccessが機能していることの確認

Apacheが.htaccessファイルを使用しているか無視しているかをテストする最も簡単な方法は、意図的に破損させることです。ファイルの先頭に行Testを挿入し、ブラウザでページを更新すると、*Internal Server Error*が表示されるはずです。

このエラーが表示された場合、それは実際には良いことです!Apacheが.htaccessファイルを解析し、挿入したエラーに遭遇したことを意味します。行Testを削除してください。

*Internal Server Error*が表示されない場合、Apacheの設定は.htaccessファイルを無視しています。一般的に、Apacheは設定ディレクティブAllowOverride Allがないためにそれを無視します。

自分でホストしている場合は、簡単に修正できます。テキストエディタでhttpd.confまたはapache.confファイルを開き、関連する<Directory>セクションを見つけて、このディレクティブを追加/変更します。

<Directory "/var/www/htdocs"> # あなたのドキュメントルートへのパス
    AllowOverride All
    ...

Webサイトが他の場所でホストされている場合は、コントロールパネルで.htaccessファイルを有効にできるかどうかを確認してください。できない場合は、ホスティングプロバイダーに依頼してください。

mod_rewriteが有効になっていることの確認

.htaccessが機能していることを確認できたら、mod_rewrite拡張機能が有効になっているかどうかを確認できます。.htaccessファイルの先頭に行RewriteEngine Onを挿入し、ブラウザでページを更新します。*Internal Server Error*が表示された場合、mod_rewriteが有効になっていないことを意味します。有効にする方法はいくつかあります。さまざまな設定でこれを行うさまざまな方法については、Stack Overflowを参照してください。

リンクが https: なしで生成される

Netteは、ページ自体と同じプロトコルでリンクを生成します。つまり、https://fooページではhttps:で始まるリンクを生成し、その逆も同様です。 HTTPSを削除するリバースプロキシサーバー(たとえばDocker内)の背後にいる場合は、プロトコル検出が正しく機能するように、設定でプロキシを設定する必要があります。

プロキシとしてNginxを使用している場合は、リダイレクトを次のように設定する必要があります。

location / {
	proxy_set_header Host $host;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_set_header X-Forwarded-Proto $scheme;
	proxy_set_header X-Forwarded-Port  $server_port;
	proxy_pass http://IP-aplikace:80;  # アプリケーションが実行されているサーバー/コンテナのIPまたはホスト名
}

さらに、設定にプロキシのIPと、インフラストラクチャを運用しているローカルネットワークのIP範囲を指定する必要があります。

http:
	proxy: IP-proxy/IP-range

JavaScriptでの { } 文字の使用

文字 {} はLatteタグを記述するために使用されます。{ 文字に続くものは、スペースと引用符を除き、すべてタグと見なされます。したがって、直接 { 文字を出力する必要がある場合(JavaScriptでよくある)、{ 文字の後にスペース(または他の空白文字)を置くことができます。これにより、タグとしての解釈を回避できます。

テキストがタグとして解釈される状況でこれらの文字を出力する必要がある場合は、これらの文字を出力するための特別なタグ {l}{用)と {r}}用)を使用できます。

{これはタグです}
{ これはタグではありません }
{l}これはタグではありません{r}

メッセージ Presenter::getContext() is deprecated

Netteは、依存性注入に移行し、プログラマーにPresenter自体から始めて一貫して使用するように導いた最初のPHPフレームワークです。Presenterが依存関係を必要とする場合、それを要求します。 逆に、クラスにDIコンテナ全体を渡し、そこから直接依存関係を取得する方法は、アンチパターンと見なされます(サービスロケータと呼ばれます)。 この方法は、依存性注入が登場する前のNette 0.xで使用されており、その名残がメソッドPresenter::getContext()であり、 давно deprecatedとしてマークされています。

非常に古いNetteアプリケーションを移植している場合、このメソッドがまだ使用されている可能性があります。nette/applicationバージョン3.1以降では、警告Nette\Application\UI\Presenter::getContext() is deprecated, use dependency injectionが表示され、バージョン4.0以降ではメソッドが存在しないというエラーが表示されます。

クリーンな解決策はもちろん、依存性注入を使用して依存関係を渡すようにアプリケーションをリファクタリングすることです。回避策として、独自のメソッドgetContext()をベースPresenterに追加し、メッセージを回避できます。

abstract BasePresenter extends Nette\Application\UI\Presenter
{
	private Nette\DI\Container $context;

	public function injectContext(Nette\DI\Container $context)
	{
		$this->context = $context;
	}

	public function getContext(): Nette\DI\Container
	{
		return $this->context;
	}
}
バージョン: 4.0