THEMA:

Danke für die Angabe der Werte. 
Bei max_input_vars kann ich nur bis 5000 auswählen bei meinem Hoster (Hoststar.ch). 
Das verrückte ist, dass ich auf anderen Webseiten beim gleichen Hoster keine Probleme habe.

Der Fehler kommt, wenn ich einen Beitrag speichern möchte (editieren oder neu erfassen). 

Gruss Qsi

Ich habe ein paar Kunden bei Hoststar. Die haben tatsächlich eher bescheidene Limiten für die PHP.INI. Aber alle diese Webseiten funktionieren. Und Deine anderen bei Hoststar ja auch. Also kann es nicht daran liegen.

Wenn Du magst, könntest Du mir mal die Zugangsdaten zu Deinem Back-End per PN senden. Dann schaue ich mal rein.

Leute Leute, seid vorsichtig mit den Limits! Derartig hohe Werte (im GB-Bereich und mehr...) zu setzen ist meistens sinnfrei und gefährlich zugleich.
Die Limits gibt es aus Sicherheitsgründen und nicht zum Ärgern der Kunden. Je höher die Limits sind, desto mehr Angriffsmöglichkeiten gibt es.
Ein normales Joomla braucht nicht mehr als 60sec Laufzeitlimit, 128 MB RAM-Limit und 32 MB Post-Size. Max_vars reicht 8000 vollkommen.
Alles was darüber liegt sollte nur nach Bedarf eingestellt sein!

Sehr hohe Werte beschleunigen auch rein gar nichts, falls das jemand denkt.

Ah, jetzt wird's interessant! Wie berechnet man die benötigten Werte? Selbstverständlich kommt man auf die Idee, dass mehr RAM die Webseite schneller machen. Zuhause beim eigenen PC ist es ja auch so. Wenn man zum Beispiel Nextcloud installiert, wird schnell mal gemotzt, man habe zu wenig Memory.

Du schreibst, ein «normales Joomla» benötige nicht mehr als 128 MB RAM. Aber was ist mit den Erweiterungen? Da bin ich schon mehrmals auf die Nase gefallen. Es scheint naheliegend, die höchsten vom Hoster bereitgestellten Werte einzustellen. Ich kann doch nicht nach dem «Try and error» Prinzip diese Werte schrittweise herunterschrauben und jedes mal schauen, ob die Webseite noch funktioniert?! Darum die Frage: wie berechnet man die benötigten Werte?

Das Berechnen ist so ohne weiteres nicht möglich, aber im Fall von Joomla kannst Du die Laufzeit und den RAM-Bedarf ganz einfach mit dem Debug-Modus messen und anzeigen lassen.
Ein Beispiel: Ein Joomla mit dem Helix Ultimate Template ohne weitere Inhalte braucht gerade mal 9 MB RAM. Dies nur mal so als Beispiel. Natürlich brauchen andere Joomla mehr, aber dazu werde ich gleich noch einen ausführlicheren Beitrag schreiben.

HIer ein Screenshot wo der Debugmodus die Laufzeit und den RAM-Bedarf anzeigt.
 

Hier nun wie versprochen mehr Details. Betrachten wir folgende PHP-Einstellungen:

max_input_vars

In 99% aller Fälle reicht der Wert 8000 mehr als aus. Ausnahmen können bei Shop-Scripten auftreten, wenn es um bestimmte Funktionen in Zusammenhang mit komplexen und vielen Artikeln geht. Meist Artikel mit vielen Varianten (Größe, Farbe, Gewicht etc.pp.)
Wir bieten bei unseren Hostings die Varianten 4000, 8000 (Default) und 16000 an. Mir ist kein einziger Kunde bekannt, der damit nicht auskommt und wir hosten alle Arten von Scripten.


memory_limit

Jeder php-Prozess, also jeder einzelne Seitenaufruf darf diese Menge an RAM allokieren. RAM ist jedoch physikalisch begrenzt und wie viele Aufrufe, insbesondere parallele der eigenen Seite und von Nachbarwebs auf einem Server es geben wird, kann man nicht vorhersehen. Eine Vielzahl kritischer Systemzustände können sich ergeben, wenn hier serverseitig nicht sinnvoll abgesichert wird.
Leider ist es so, das viele Entwickler sich an Ihrer lokalen Entwicklungsumgebung orientieren, in der oft alles erlaubt ist. So kommt es vor das ein Slider-Plugin plötzch 512 MB haben will oder noch mehr, obwohl das sonstige gesamte Joomla mit z.B. 32 MB auskommt. Solche Erweiterungen meiden!

Wie findet man nun die richtige Einstellung für das Hosting?
Die Entwickler der Sctipe sollten immer Requirements nennen, an denen man sich orientieren kann oder bei der Installation eine Prüfung einen sinnvollen Wert anzeigt. Leider ist dieser Weg auch nicht perfekt, denn oft geben Entwickler viel zu hohe Werte an – nach dem Motto „mehr ist besser“.
Wenn ein Limit überschritten wird, reagiert der Server mit einem Error 500 und im Fall eines aktivierten Error-Reportings auch mit der passenden Meldung, so das man solche Probleme eigentlich seher schnell erkennt und reagieren kann.
Mit 128 MB RAM kommt man normalerweise bei den meisten Joomla-Webs zurecht. Bei Shop-Erweiterungen, teilweise Foren oder anderen Erweiterungen kann es sein das man höher stellen muss (sofern das der Hosting erlaubt) oder man einen anderen Tarif buchen muss. Ein kurzes „Try and error“ in solchen Fälle oder das Orientieren an der Herstellerangaben ist doch eigentlich keine große Sache.


max_input_time

Ein ebenso kritisches Limit, insbesondere in Verbindung mit memory_limit und upload_limits
Die reine serverseitige PHP-Laufzeit beträgt (oder solltes es wenigstens) nur wenige Millisekunden, optimal unter einer Sekunde.
Es gibt aber Ausnahmen: Bei Updates oder bei bestimmten Wartungsarbeiten (Backups, bei Shops Importe/Exporte) usw. wird viel mehr Zeit benötigt. Nur dafür braucht man genau genommen höhere Limits als wenige Sekunden. Leider wird auch hier nicht optimal programmiert. Backupsscripte laufen meistens schon mit Ajax-Funktionen, so das das Abarbeiten einer Aufgabe in kurze Blöcke abgearbeitet wird und somit das Laufzeitlimit keine Rolle spielt, aber viele andere Scripte brauchen eben doch mehr. Ich würde jedoch dazu raten nur im Einzelfall mehr als 60 sec einzustellen. Also nur wenn irgendeine Funktion das tatsächlich braucht. Das werden als nur interne Backend Funktionen sein, denn kein User wartet ja mehr als 60 sec auf die Website-Anzeige…


post_max_size

Sollte bei Joomla auf 32 MB stehen, weil ab der 4er-Version man mit 16 MB teils nicht weiterkommt – leider.
mehr als 32 MB sind nur notwendig, wenn die Website Funktionen nutzt, die hier tatsächlich den Upload solcher Datenmenge erforderlich machen. Scripte wie Nextcloud oder Galarien etc. brauchen hier z.B. höhere Limits (logischweise). Zu beachten gilt, das die einzelnen Limits aufeinandsere abgestimmt sind. Wenn als ein Script 512 MB Datenupload erlaubt, dann bitte berücksichtigen das auch das Laufzeitlimit dazu passt. Nicht jeder hat heute Glasfaser mit hoche Upload-Bandbreiten….


Damit das hier nicht ausufert, belasse ich es hiermit, obwohl man zu dieser Thematik noch viel mehr schreiben könnte.

 

Aus aktuellem Anlass komme ich nochmals zurück auf das ursprüngliche Problem von Qsi:

- Es können keine Beiträge gespeichert werden (weder neu noch vorhandene)
- Es können keine Kategorien gespeichert werden (weder neu noch vorhandene)
- Upload von Medien ist nicht möglich

Fehlermeldung

Speichern fehlgeschlagen. Fehler:

Wobei nach «Fehler:» nichts konkretes steht.

Qsi hat mir einen Back-End-Zugang gegeben, aber ich habe die Ursache auch noch nicht herausgefunden. Es gibt da Joomla 4.2.9 und PHP 8.1. Dazu den SP Page Builder Pro und das Astroid Framework und sonst noch ein paar Erweiterungen.

Am Editor liegt's nicht, der Fehler ist sogar reproduzierbar, wenn ganz ohne Editor gearbeitet wird.
Das Back-End-Template hat ein paar Overrides, aber diese zu deaktivieren hat auch nichts gebracht.Error reporting = Maximum, aber es werden keine Fehler angezeigt.

Die Konsole zeigt folgende FehlermeldungDiese sagt mir aber gar nichts.

Qsi und ich hoffen jetzt auf weitere Hilfe... Vielen Dank!

mal prüfen ob die beiden Pfadangaben in der configuration.php korrekt sind.

Die Pfade sahen tatsächlich etwas seltsam aus:
/home/ch99999/web/xyz.ch/public_html/./logs
/home/ch99999/web/xyz.ch/public_html/./tmp

Eine Änderung zu
/home/ch99999/web/xyz.ch/public_html/logs
/home/ch99999/web/xyz.ch/public_html/tmp
hat aber nichts gebracht.

Schau mal hier, vielleicht hilft es
forum.joomla.de/thread/17470-beitrag-l%C...sich-nicht-speichern