[gelöst - irgendwie] Drupal 8.5.1-Installation bei 1und1

dass die Installation nicht im document root steht?
Für Unterverzeichnisse, die sowieso nur Ärger verursachen und keinerlei Mehrwert bieten, sind zusätzlich Einstellungen erforderlich.

Die Basiseinstellung der max_exec von 30 Sekunden ist zumindest während der Installation und bei vielen Modulen, nicht ausreichend.

Für die Entwicklung sehe ich hier eher 600 als angemessen an, oder im laufenden Betrieb mindestens 120

Auch das Memory kann ein Engpass sein. 128 MB ist das Mindeste, was eine laufende Seite haben sollte, auch wenn in den Installationsvoraussetzungen 64MB angegeben werden.

Wenn viele Module im Einsatz sind, sind eher 256 MB sinnvoll.

Hi Ronald!
Vielen Dank für deine Antwort.
Dass Unterverzeichnisse nur Ärger verursachen kann ich nicht recht nachvollziehen. Das Routing der Subdomain funktioniert ja problemfrei. das RewriteBase / in der .htaccess-Datei "erdet" ja das Zielverzeichnis zum einem root-Verzeichnis.
Bilder kann ich direkt ansurfen, das Routing funktioniert also schon.

Die Installation lief gut durch, eine Erhöhung der Ausführungszeiten scheint mir nicht notwendig - habe ich trotzdem probiert, ändert nichts.
Die Seite besitzt nur die Standardmodule, der Speicher ist groß genug - aber auch hier habe ich große Werte ohne Erfolg ausprobiert:

...

EDIT:
Ich habe noch herausgefunden, dass bei 1und1 alle PHP-Direktiven über die .htaccess einstelllbar sind. Ich habe dann eine Weile lang damit rumrpobiert und habe dann über die info.php herausgefunden, dass die Werte dort gar nicht übernommen werden.
Daraufhin habe ich dann die php.ini erneut bearbeitet und unter anderem den Wert

error_reporting = E_ALL

gesetzt. Ich erhalte zwar immer noch keine Error-Logs, dafür ist jetzt die Seite plötzlich erreichbar. Ich habe keine Ahnung, woran das jetzt lag.

noch ein Tip, wie man OPcache zum laufen bringt:

in die php.ini muss

wobei der Pfad entsprechend angepasst werden muss - "/kunden/" ist hier wichtig! Und ein verstecktes Verzeichnis namens ".opcache" muss angelegt werden.

[Quelle]

Ich habe mich gerade mit genau dem gleichen Thema beschäftigt.
Bei mir war auch der Bringer die .user.ini mit dem Eintrag bezüglich date.timezone.

Der Eintrag in der php.ini hat nicht gereicht.
Würde mich mal interessieren, wie das zu verstehen ist.
Jemand meinte, während der Installation wird php cli ausgeführt, also eine andere PHP Version? Kann da jemand was zu sagen?
Deshalb funktioniert es nicht mit der php.ini, weil die gar nicht verwendet wird, aber mit der user.ini, weil der User der gleiche bleibt.

Das Error Logging muss auch in der php.ini passieren.
Bei mir steht da Folgendes:

Interessant wäre noch, welche PHP Version Du verwendest?
Vermutlich eine der 7.x, die als CGI laufen.
Das kann man nicht so in die .htaccess schreiben, wie bei php 5.6 als Apache Modul.
Deshalb als php.ini.

Dein Problem mit den Subdomains verstehe ich nicht.
Ich kann doch einfach im 1-und-1 Kundencenter einstellen, dass drupal8.meinedomain.de auf den ORdner /homepages/12/1234567/htdocs/drupal_8 gemappt sein soll?
Ist ja schräg, dass Du die Apache conf editieren kannst.
Welches Paket hast Du?

Das mit der Subdomain war ja nicht wirklich ein Problem, sondern nur eine weitere mögliche Fehlerquelle und eine Halbwissen-Unsicherheitsverunsicherungszusatzverkomplizierung, die zwar unwahrscheinlich verantwortlich war, aber irgendwie doch in erster Linie nicht auszuschließen.
Die Erreichbarkeit der Dateien hatte ich ja aber frühzeitig getestet und als Fehlerquelle ausgeschlossen.

Ich hab die Domain auf PHP 7.1 eingestellt.

Dass man die Apache conf speichern konnte hat mich auch sehr überrascht. Ich bin ja nicht vom Fach, aber ich habe das Gefühl, dass 1un1 da eine kleine Sicherheitslücke hat, die man als Einfallstor nutzen könnte - vor allem, da man mit ein paar Pfadwechseln sehr viele Kundennummern ermitteln konnte, aber auch, weil die Linux-Distribution nicht auf dem neuesten Stand war (Debian 8.10).

Mein Packet heisst "1&1 Dual Advanced".

" vor allem, da man mit ein paar Pfadwechseln sehr viele Kundennummern ermitteln konnte"
Stimmt, wenn man via SSH rein geht, dann sieht man die ganzen ordner mit Kundennummern.
Das habe ich vor ein paar Tagen dem Support erzählt. Die meinten aber, das sei unkritisch, weil man weiter nicht drauf zugreifen kann, sondern nur auf die eigene Installation.

Aber was Du schreibst, ist ja noch mal einen Zahn schärfer.
Das würde ich auf jeden Fall melden.
Ich meine, wenn Du das kannst, kann das ja jemand anders auch.
Oder ist das eine spezielle Apache conf, so wie es eben möglich ist, eine eigene php.ini zu schreiben?
Hast Du da nur Deine Virtuellen Verzeichnisse gesehen, oder auch andere?

Das 1&1 Dual Advanced ist dann von der Größe her noch etwas kleiner als das Unlimited Pro.
Kann es sein, dass das nicht mehr angeboten wird? Ich habe nur in einem alten Blog was gefunden mit einem Bild, woraus die Leistungen hervor gingen.
Unter Webhosting- Angeboten habe ich nichts gefunden.
Ich hatte die letzte Zeit auch einige Kunden mit veralteten Web-Projekten, die auf Wunsch einfach auf das Unlimited Pro mit viel mehr Memory ect. umgestellt wurden.
Das hat weder Kosten verursacht, noch Ausfallzeit.

Könnte ja sein, dass das ein Auslaufmodell ist und deshalb nicht mehr aktualisiert wird.
Würde ich auf jeden Fall nachhaken.
Die Webhoster sind halt auch nur so gut, wie wir abverlangen. ;-)
(und natürlich zahlen)

Hab ich auch grad gesehen. Ich würde mehr als die Hälfte einsparen...

Ich glaube Hacker kommen da eher über andere Sicherheitslücken rein, wie etwa über all die nicht geupdateten PHP Content Management Systeme...

Ja Hacker sehe ich da weniger als Problem.
Eher neugierige Leute wie uns, die überall rum fummeln müssen und versehentlich was ändern, was sie nicht ändern können sollten. ;-)