Laravel leerer weißer Bildschirm

Meine Laravel-Site hat bereits funktioniert. Ich habe kürzlich ein Upgrade auf Apache 2.4 und PHP 5.5.7 durchgeführt.

Jetzt wird ein weißer leerer Bildschirm angezeigt, wenn ich zu laravel.mydomain.com gehe. Nichts in Apache-Fehlerprotokollen, Routen usw. sollte in Ordnung sein, wie es zuvor funktioniert hat.

.htaccess wird geladen, wenn ich eine 500 erhalte, wenn ich eine ungültige Zeile in /var/sites/laravel/public/.htaccess einfüge.

Hier ist mein .htaccess:

$ cat /var/sites/laravel/public/.htaccess
<IfModule mod_rewrite.c>
    <IfModule mod_negotiation.c>
    Options -MultiViews
</IfModule>

RewriteEngine On

# Redirect Trailing Slashes...
RewriteRule ^(.*)/$ /$1 [L,R=301]

# Handle Front Controller...
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L]

Hier ist meine virtuelle Host-Direktive:

DocumentRoot "/var/sites/laravel/public"
ServerName laravel.mydomain.com
<Directory "/var/sites/laravel/public">
    AllowOverride All
    allow from all
    Options +Indexes
    Require all granted
</Directory>

Und apachectl -S

$ /usr/local/apache2/bin/apachectl -S
VirtualHost configuration:
*:*                    is a NameVirtualHost
     default server mydomain.com (/usr/local/apache2/conf/extra/httpd-vhosts.conf:25)
     port * namevhost mydomain.com (/usr/local/apache2/conf/extra/httpd-vhosts.conf:25)
     port * namevhost laravel.mydomain.com (/usr/local/apache2/conf/extra/httpd-     vhosts.conf:34)
ServerRoot: "/usr/local/apache2"
Main DocumentRoot: "/var/www"
Main ErrorLog: "/usr/local/apache2/logs/error_log"
Mutex rewrite-map: using_defaults
Mutex default: dir="/usr/local/apache2/logs/" mechanism=default
PidFile: "/usr/local/apache2/logs/httpd.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="daemon" id=1 not_used
Group: name="daemon" id=1 not_used

Apache

Ist diese Antwort beschreiben oder Ihre Situation helfen? Das Upgrade auf Apache 2.4 bringt einige Änderungen in der Apache-Konfiguration mit sich.

Laravel

Überprüfen Sie die Protokolle von Laravel oder Apache?

Seit dem Upgrade auf Laravel 4.1 hatte ich "Fehler" (WSOD) auf dem weißen Bildschirm, als die Anwendung nicht in den Protokollspeicherort schreiben konnte. Ich habe dies immer gelöst, indem ich das App- / Speicherverzeichnis von Apache beschreibbar gemacht habe (entweder Gruppe beschreibbar in "www-data", "apache" oder weltschreibbar - das hängt von Ihrem Server-Setup ab.

Webserver-Benutzer

Auf Ubuntu / Debian-Servern wird Ihr PHP möglicherweise als Benutzer "www-data" ausgeführt. Auf CentOS / RedHat / Fedora-Servern wird Ihr PHP möglicherweise als Benutzer "Apache" ausgeführt.

Stellen Sie sicher, dass Ihre Dateien dem Benutzer gehören, auf dem PHP ausgeführt wird:

# Debian/Ubuntu
$ sudo chown -R www-data /path/to/laravel/files

# CentOS/RedHat/Fedora
$ sudo chown -R apache /path/to/laravel/files

Beachten Sie, dass Sie möglicherweise nicht als Benutzer www-data oder apache ausgeführt werden. Es hängt von Ihrem Hosting und Setup ab!

Laravel 4

# Group Writable (Group, User Writable)
$ sudo chmod -R gu+w app/storage

# World-writable (Group, User, Other Writable)
$ sudo chmod -R guo+w app/storage

Laravel 5+ (einschließlich 6)

# Group Writable (Group, User Writable)
$ sudo chmod -R gu+w storage

# World-writable (Group, User, Other Writable)
$ sudo chmod -R guo+w storage

#####
# The bootstrap/cache directory may need writing to also
##

# Group Writable (Group, User Writable)
$ sudo chmod -R gu+w bootstrap/cache

# World-writable (Group, User, Other Writable)
$ sudo chmod -R guo+w bootstrap/cache

Ein Update zu Fidelopers Antwort für Laravel 5 und seiner neuen Dateistruktur lautet:

$ sudo chmod -R o+w storage/

Versuchen Sie dies auf der Seite public / index.php

error_reporting(E_ALL);
ini_set('error_reporting', E_ALL);
ini_set("display_errors", 1);

Die folgenden Schritte lösten das Problem mit dem leeren weißen Bildschirm auf meinem Laravel 5.

• Wechseln Sie zu Ihrem Laravel-Stammordner
• Geben Sie Schreibberechtigung bootstrap/cacheund storageVerzeichnisse

sudo chmod -R 777 Bootstrap / Cache-Speicher

• Umbenennen .env.examplein.env
• Generieren Sie den Anwendungsschlüssel mit dem folgenden Befehl in Terminal / Eingabeaufforderung von Laravel root:

PHP Artisan Key: generieren

Dadurch wird der Verschlüsselungsschlüssel generiert und der Wert von APP_KEYin aktualisiert.env Datei

Dies sollte das Problem lösen.

Wenn das Problem weiterhin besteht, aktualisieren Sie es config/app.phpmit dem neuen Schlüssel, der mit dem obigen Befehl zum Generieren des handwerklichen Schlüssels generiert wurde:

'key' => env('APP_KEY', 'SomeRandomString'),

zu

'key' => env('APP_KEY', 'KEY_GENERATED_FROM_ABOVE_COMMAND'),

Für alle, die eine leere Seite erhalten, auch nachdem der Speicher für die Anzeige von Fehlern zugänglich gemacht wurde, setzen Sie diese beiden Zeilen in die ersten Zeilen von public / index.php, um zu sehen, was zumindest passiert. Für mich war dieser Fehler da: Klasse 'PDO' nicht in /var/www/***/config/database.php in Zeile 16 gefunden

error_reporting(E_ALL);
ini_set('display_errors', 1);

Als ich neu in Linux war. Normalerweise fand ich diesen Fehler bei meinem Laravel-Projekt. Weiße Fehler bedeuten Fehler. Möglicherweise liegt ein Berechtigungsproblem oder ein Fehler vor.

Sie müssen nur zwei Schritte befolgen und arbeiten wie ein Champion :)

(1) Geben Sie die Erlaubnis. Führen Sie diesen Befehl im Stammverzeichnis Ihres Projekts aus

(a) sudo chmod 777 -R storage
(b) sudo chmod bootstrap/cache

(2) Wenn Sie das Projekt geklont oder aus Github gezogen haben, führen Sie es aus

composer install

(3) Konfigurieren Sie Ihre .env-Datei ordnungsgemäß, und Ihr Projekt funktioniert.

Ich hatte mit einem ähnlichen Problem auf einem CentOS-Server zu kämpfen. Die Verwendung von PHP Artisan Serv und der Zugriff über Port 8000 auf dem lokalen Computer funktionierte einwandfrei, konnte jedoch meine Remote-Computer nicht dazu bringen, eine bestimmte Ansicht zu laden. Ich konnte Zeichenfolgen gut zurückgeben, und einige Ansichten wurden geladen. Ich habe eine Weile nach Berechtigungen gesucht, bevor mir endlich klar wurde, dass es sich um ein SELinux-Problem handelt. Ich habe es einfach von erzwungen auf freizügig gesetzt und es hat funktioniert. Ich hoffe, das hilft jemand anderem da draußen, der möglicherweise auf dasselbe Problem stößt.

setenforce permissive

In meinem Fall habe ich installiert laravel viele Male und bin sicher, dass die Berechtigung zum Schreiben von Ordnern korrekt erteilt wurde.

Wie die meisten der obigen Antworten:

sudo chmod 777 -R storage bootstrap

Der Fehler ist, dass meine Nginx-Konfiguration aus der offiziellen Dokumentation stammt .

Ich habe den Domainnamen erst nach dem Kopieren geändert ， dann habe ich eine leere Seite bekommen. Ich habe versucht neu zu starten nginxund php-fpm, aber nicht für mich zu arbeiten.

Schließlich habe ich diese Leitungskonfiguration hinzugefügt, um das Problem zu lösen.

location ~ \.php$ {

    # same as documentation ...

    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

Ich hoffe ich kann anderen helfen.

Ich habe auch eine weitere Option, warum ein Problem mit leeren Seiten auftreten kann. Wenn Sie sich im Produktionsmodus befinden und Ihre Konfigurationsdateien von PHP Artisan (config: cache) zwischengespeichert haben, versuchen Sie, die folgende Cache-Datei zu löschen:

php artisan config:clear

oder löschen Sie es manuell (bootstrap / cache / config.php)

Das Ausführen dieses Befehls hat es für mich gelöst:

php artisan view:clear

Ich denke, eine leere Fehlerseite war etwas wie zwischengespeichert. Musste die Caches leeren.

Mit Blick auf den leeren Bildschirm in Laravel 5.8. Alles scheint in Ordnung zu sein, sowohl im Speicher als auch im Bootstrap-Ordner mit 777-Rechten. Auf

php artisan cache:clear

Es zeigt das Problem, dass es sich um Leerzeichen im App-Namen der ENV- Datei handelte

Ich habe einige Probleme beim Einrichten in einem Vagrant-Computer. Was für mich wirklich funktioniert, war:

chmod -R o+w app/storage/

aus dem Inneren der Vagrant-Maschine.

_{Referenz: https://laracasts.com/lessons/vagrant-and-laravel}

Eine andere Sache, die das WSOD verursachen kann, ist das Fehlen des Schlüsselworts 'return', wie in:

return View::make('yourview');

im Gegensatz zu

View::make('yourview');

Manchmal liegt es daran, dass für Laravel 5.1 PHP> = 5.5.9 erforderlich ist. Update PHP wird das Problem lösen.

Seltsam für mich, aber in meinem Fall musste ich den Cache der Laravel leeren, um das Problem zu lösen.

Ich hatte auch das gleiche Problem, nachdem ich es getan hatte composer update

Ich habe auch versucht zu installieren, composer required monolog/monologaber es hat nicht funktioniert.

Dann entfernte ich das Verzeichnis / vendor und lief composer installund arbeitete wie gewohnt.

Im Grunde muss es meine Monolog- und andere stabile Paketversion auf die vorherige zurückgesetzt haben. also besser nichtcomposer update

Was mir beim Vergleich der beiden Ordner / vendor aufgefallen ist und festgestellt hat, dass diese classesDateien /vendor/monolog/monolog/src/Handlernach der Aktualisierung des Komponisten fehlten.

Es kann viele Gründe für den fehlerfreien leeren Bildschirm geben. Ich habe dieses Problem oft gesehen, wenn ich ein Laravel-Projekt in Shared Hosting hochladen möchte.

Grund: Falsche PHP-Version

In meinem Fall lag das Problem an einer falschen PHP-Version. Ich hatte PHP 7.1 Version in lokalen Computer, wo wie in Shared Hosting Cpanel gab es PHP 5.6 Version. Das Hochschalten der Version von 5.6 auf 7.1 hat bei mir funktioniert.

Sie können die PHP-Version in cpanel über den auf der cpanel-Homepage verfügbaren Multiphp-Manager ändern.

Manchmal in route.php können Sie haben

Route::get('/{id}', 'Controller@show'..

vorher geschrieben

Route::get('/add', 'Controller@add'..

Es kann eine leere Methode sein, Controller::show()wenn Sie beginnen, Ihren Controller von Grund auf neu zu entwickeln. In diesem Fall erhalten Sie eine leere leere Seite, wenn Sie eine /addURL anfordern . Dies geschieht, weil die Anforderung von bearbeitet wurde/{id} Route verarbeitet wurde und ihre Methode nichts zurückgibt.

Versuchen Sie einfach, die /addRoute vorher zu platzieren/{id}

Ein weiteres Problem mit demselben Verhalten ist die Verwendung von Laravel 3 mit PHP 5.5.x. Sie müssen den Namen einer Laravel-Funktion "yield ()" ändern, da dies ein reserviertes Wort in PHP 5.5 ist

Grund kann sein, Middlewarewenn Sie vergessen, den folgenden Code am Ende der handleFunktion einzufügen

return $next($request);

Ich habe auch den gleichen Fehler erhalten, als ich zum ersten Mal mit laravel + Ubuntu 14.04 gestartet habe. Ich klicke einfach mit der rechten Maustaste auf Bootstrap und Speicherordner >>> Eigenschaften >>> Berechtigung >> Andere Zugriff >>> ändere ihn in "Dateien erstellen und löschen" Berechtigung für beigefügte Dateien

Danke dir

Ich habe dies aus den Laravel-Foren erhalten. Wenn Sie jedoch kürzlich Laravel-Versionen UND PHP-Versionen aktualisiert haben und Nginx ausführen, stellen Sie sicher, dass Sie Ihre Nginx-Konfigurationsdatei geändert haben, um die neue PHP-Version widerzuspiegeln. Zum Beispiel:

Ändern Sie in Ihrer Nginx-Site-Konfigurationsdatei (hier: / etc / nginx / sites-available)

fastcgi_pass unix:/var/run/php5-fpm.sock;

zu

fastcgi_pass unix:/var/run/php/php5.6-fpm.sock;

Ich habe das gleiche Problem. Ich ändere bereits den chmod-Ordner in den Speicherordner. Füllen Sie die Datenbankeinstellungen in .env aus, aber das Problem wurde nicht behoben. Ich habe Laravel 5.5 und PHP 5.6 verwendet, um das Problem zu beheben, bin ich zu (cpanel-> PHP Selector) gegangen und habe zu PHP 7.1 gewechselt. Und das Problem ist behoben.

Im Normalfall sollten Fehler protokolliert werden, es sei denn

Das Skript kann nicht in die Protokolldatei schreiben

• Überprüfen Sie den Pfad
• Berechtigungen

Oder es ist ein Fehler bei App-Server-Protokollen auf höherer Ebene wie Appache || aufgetreten Nginx

Oder es sind Ressourcenbeschränkungen wie PHP-INI-Einstellungen

memory_limit
max_input_time
max_execution_time

Oder Betriebssystemlimits und so weiter

Zusätzlich zu Berechtigungsproblemen bei Speicher- und Cacheordner- und PHP-Versionsproblemen kann es weitere Gründe geben, leere Seiten ohne Fehlermeldung anzuzeigen.

Zum Beispiel hatte ich eine Fehlermeldung beim erneuten Deklarieren ohne Protokoll und mit leerer weißer Seite. Es gab einen Konflikt zwischen meiner eigenen Hilfsfunktion und einer Herstellerfunktion.

Ich schlage vor , als Ausgangspunkt , führen artisanBefehle. beispielsweise:

php artisan cache:clear

Wenn es ein Problem gab, wird es im Terminal angezeigt und Sie haben einen Hinweis und können bei Google nach der Lösung suchen.

Ein leerer Bildschirm tritt auch auf, wenn Ihre Laravel-App versucht, zu viele Informationen anzuzeigen und PHP-Grenzwerte aktiviert werden (z. B. Zehntausende von Datenbankeinträgen auf einer einzelnen Seite). Das Schlimmste ist, dass in den Laravel-Protokollen keine Fehler angezeigt werden. Sie werden wahrscheinlich auch keine Fehler in den PHP-FPM-Protokollen sehen. Möglicherweise finden Sie Fehler in Ihren http-Serverprotokollen, z. B. löst nginx so etwas ausFastCGI sent in stderr: "PHP message: PHP Fatal error: Allowed memory size of XXX bytes exhausted .

Kurzer Tipp: Fügen Sie für Ihr Abfrageobjekt hinzu, ->limit(1000)wo 1000Ihr Limit liegt.

Ich bin auf dieses Problem gestoßen, als ich versucht habe, eine Laravel 5.8-App auf meinem Server auszuführen und sie mit Vagrant Homestead aus der lokalen Entwicklung hochzuladen. Nach einer Weile stellte ich fest, dass die Dev-Subdomain auf dem Live-Server, den ich ausführte, irgendwie auf PHP 5.6 eingestellt war.

cPanel> MultiPHP Manager> Auf PHP 7.2 einstellen

habe das für mich behoben. Hoffe das könnte jemandem helfen.

Verwenden Sie diesen .htaccess , um zu lösen

Options +ExecCGI
addhandler x-httpd-php5-cgi .php
Options -MultiViews
DirectoryIndex index.php
<IfModule mod_rewrite.c>
<IfModule mod_negotiation.c>
    Options -MultiViews -Indexes
</IfModule>
RewriteEngine On
RewriteBase /
# Handle Authorization Header
RewriteCond %{HTTP:Authorization} .
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
# Redirect Trailing Slashes If Not A Folder...
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} (.+)/$
RewriteRule ^ %1 [L,R=301]
# Handle Front Controller...
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
#RewriteRule ^ index.php [L]
RewriteRule ^(.*)$ index.php?/$1 [L]
</IfModule>

In meinem Fall war das Problem BLANK WHITE SCREEN so einfach wie ein Tippfehler oder ein falsches Zeichen in der env-Datei. Ich habe Socialite implementiert, als ich die .env-Anmeldeinformationen für Google+ wie folgt eingerichtet habe:

G+_CLIENT_ID = Your G+ Client ID
G+_CLIENT_SECRET = Your G+ Client secret
G+_REDIRECT = 'http://localhost:8000/callback/google'

Da die .env-Datei jedoch nicht das Pluszeichen '+' verwenden kann, muss ich diese Korrektur vornehmen:

GOOGLE_CLIENT_ID = Your G+ Client ID
GOOGLE_CLIENT_SECRET = Your G+ Client secret
GOOGLE_REDIRECT = 'http://localhost:8000/callback/google'

Ich hoffe das hilft dir einen dummen Fehler zu finden ...

In meinem Fall wurde das Problem durch einen Neustart von Apache behoben. für Ubuntu / Debian:

sudo service apache2 restart