Drupal-Installation nach PHP-Umstellung nicht mehr erreichbar

Außerdem soeben noch einen Hinweis vom Forum auf drupal.org ausprobiert;
Änderung in der .htaccess (Zeile 155 ff.), aber leider auch ohne Wirkung:

Es gibt auf dem Webserver einige Logfiles. Einmal für den Apache und dann für PHP. Welche Fehlermeldungen vom Apache gibt es denn in Deinem Fall? Nach einer PHP-Umstellung kann es sein, daß eine alte Drupal-Installation Fehler auswirft und deshalb Nichts mehr angezeigt wird. Also auch da nach Fehlern suchen. Ohne diese Fehlermeldungen kann man dir vermutlich nicht helfen.

ist jede Aktion ein Stochrn im Nebel, wenn man kein logfiles hat.

Diese Meldung besagt, dass ein Fehler mit dem Webserver aufgetreten ist.

Es kann sein, dass hier eine eingestellte Grenze überschritten wurde, oder ein Fehler gefunden wurde, der die Anzeige verhindert.

Da es mit der Umstellung der PHP-Version zusammenzuhängen scheint, kann dies heißen, dass die PHP.ini überschrieben wurde, oder dass Module, die bisher eingebunden waren, deaktiviert wurden.

Genaues erfährt man in den logfiles.

Erstmal danke für eure Beachtung meiner Anfrage.

Auf dem Webserver, der per FTP angesteuert werden kann, gibt es neben dem html-Verzeichnis (für Applikationen, dort auch das Drupal-Unterverzeichnis /cms) das Verzeichnis logs, in dem sich eine error_log-Datei befindet.

Ich zitiere, wie dort (m)ein Aufruf der Webseite erfasst wurde:

1. Drupal ist tatsächlich in einem Unterverzeichnis installiert
2. Es handelt sich um viele "Datei nicht gefunden" Fehler

Das heißt aber doch, dass sich in der Dateistruktur etwas verändert hat, oder die Einstellung des Webservers für die Document Root geändert wurde.

Entweder hat Document Root vorher auf html gezeigt, oder auf cms. Je nachdem musst du die .htaccess anpassen.
Wichtig ist auch, dass mod_rewrite aktiviert sein muss.
Das vergessen manche Provider auch.

Kläre das mit deinem Provider.

Soweit ich mich erinnere, ist Drupal 8 immer etwas "verwirrt" bei einem Wechsel der PHP-Version. Mit einem "Cache Rebuild" ist dann wieder alles gut. Ich weiß leider keinen anderen Weg als "drush cr", da ich grundsätzlich Drush benutze um Drupal zu administrieren. Alles andere kostet mir zu viel Zeit und damit meinen Kunden zu viel Geld.

Der Provider ist - auf Wunsch des Drupalseitenbetreibers - zu PHP 5.6 zurückgekehrt.
Die Seite ist wieder erreichbar.

Nur und leider: beim Versuch des Einloggens (../user/login) kommt nach Eingabe von Benutzername und Passwort die Meldung Auf der Website ist ein unvorhergesehener Fehler aufgetreten. Bitte versuchen Sie es später nochmal. (Adresse nun: ../user/1).

Das wurde dann gemacht, indem über phpMyAdmin alle Tabellen geleert wurden die mit 'cache_' beginnen (gemäß eines Tipps an anderer Stelle in diesem Forum), sowie natürlich auch der Cache des Browsers selbst. Doch auch das macht das Einloggen nicht möglich.

Die error_log-Datei des Webservers verzeichnet:

[Sat Mar 11 23:41:02 2017] [warn] [client 78.55.14.6] mod_fcgid: stderr: Uncaught PHP Exception Symfony\\Component\\Routing\\Exception\\RouteNotFoundException: "Route "simplenews.settings_subscriber" does not exist." at /var/www/web41/html/cms/core/lib/Drupal/Core/Routing/RouteProvider.php line 187

Verwirrend: Es gibt zwar ein Simplenews-Modul für Drupal, doch das ist hier nicht mehr in Verwendung.

Die Hauptfrage dieses Postings ist: wie kommt der User wieder in die Drupalinstallation rein, wie kann eine Anmeldung erzwungen werden?

Gruß, Tikita

In der Datenbank wude mit phpyAdmin in allen Tabellen nach Datensätzen gesucht, die simplenews enthalten - und sie wurden gelöscht.

Anschließend war ein Einloggen wieder möglich.

Bedenklich: das Modul Simplenews war nicht mehr im Gebrauch, nicht aktiviert und hat dennoch diese Probleme verursacht.

Das war es zum Thema "Versuch eines Umstiegs auf PHP 7" mit leidvoller Rückkehr zu PHP 5.6 ;-)

Somit war das Modul wohl nicht sauber deinstalliert worden. Das kann auf unsauberer Programmierung beruhen, ist aber häufiger darauf zurück zu führen, daß Module einfach nur deaktiviert werden und danach das jeweilige Modul aus der Datei-Struktur entfernt wurde.

Die direkte Manipulation der Datenbank ist der letzte Ausweg, wenn man genau weiß, was man macht. Schnell übersieht man diverse Abhängigkeiten in der in der Datenbank, die mit jeder Drupal Major Version zunehmend komplexer wird. Somit sollten solche Lösungswege nicht als erste Möglichkeit propagiert werden, um Probleme in Drupal zu lösen.
Auch die oben getätigte Aussage, daß das Leeren der Tabellen das gleiche ist wie ein Cache Rebuild stimmt nicht ganz. Je nach Caching Strategie des Systems werden bei einer "normalen" Cache-Entleerung auch nicht immer alle Caches erfasst und auch mehr als jene Tabellen, die mit "cache_" anfangen. Dies betrifft z.B. den Menu-Router sowohl bei D7 ("menu_router") noch bei D8 ("router"). Außerdem könnten auch Caching-Mechanismen im Betrieb sein, die andere Datenbank-Systeme benutzen oder das Datei-System zu benutzen wie z.B. die CSS-Aggregation ist auch nicht ungewöhnlich.