@
Ja, genau deswegen auch der Verweis auf die Pro-Version von QCC
Danke, doch nach längerer Suche konnte ich nicht herausfinden, was der Preis für die Pro-Version ist.
@
Ja, genau deswegen auch der Verweis auf die Pro-Version von QCC
Danke, doch nach längerer Suche konnte ich nicht herausfinden, was der Preis für die Pro-Version ist.
Vielen lieben Dank für eure Lösungsvorschläge!!!
Wenn Du alle 10 Minuten den Cache leeren lassen willst, kannst Du den Cache doch gleich ganz deaktiviren, da er so gut wie nutzlos wird.
Nein, wenn du eine entsprechende Last hast, dann sind auch 2 Minuten super
Nutze besser Optimierungen wie "CSS- und JS-Dateien minimieren und zusammenfassen", sofern möglich. Auch Lazy Load und derartiges sind sinnvoll, um das Laden zu beschleunigen.
Ist gemacht (Yootheme)
Nutzung von http/2
Ist das bei SSL nicht Standard?
Aus Erfahrung: Nutze den Server-Cache (wenn verfügbar, z.B. OpCache (php) und den normalen Cache in der Joomla-Konfiguration
OpCache ist an, doch lahmt dieser meiner Meinung nach.
Teste ich die Seite mit OpCache, so hat diese eine
DOMContentLoaded: 919 ms
load: 1,33 s
Mit Joomla-Standard-Cache + OpCache:
DOMContentLoaded: 640 ms
load: 1,00 s
Mit PageCache + OpCache:
DOMContentLoaded: 328 ms
load: 791 ms
Zitatdas Skript garbagecron.php löscht nur den abgelaufenen Cache.
Kubik-Rubik Ja, dass dachte ich mir schon.
Und danke für den Verweis, aber ich möchte das - wenn überhaupt - mit nem Cron-Job lösen
Hallo,
ich habe Zeitweise das SeitenCache Plugin bei Joomla 3.10.8 aktiviert und den anderen Cache deaktiviert. Das bringt bei Last manches Mal Entspannung
Den SeitenCache aber muss man manuell löschen. Das passiert nicht automatisch und ist hinderlich, wenn die Bilder nach Veröffentlichung eines Artikels automatisch geändert werden.
Die Idee - CronJob alle 10 Minuten auf das Cache Verzeichnis laufen lassen.
Weiß jemand, wie der Cronjob aussehen müsste?
Bei meiner Recherche bin ich auf garbagecron.php gestoßen was alle (??) Cache Dateien bereinigen soll.
Leider findet sich in der Doku nichts genaues - ich vermute mal, dass es ein Konstrukt für den "normalen" Cache und nicht für das SeitenCache Plugin ist.
Wer weiß darüber was genaueres?
Grüße,
Mitcha
Nein, so war das nicht gemeint.
Meine Frage bezog sich darauf, ob die Sicherheitslücke so groß ist, dass man jetzt (sehr) zeitnah updaten sollte - aber egal
Wünsche euch ein schönes Wochenende
Nein, ich meinte, ob ich jetzt dringend von 3.10.6 auf 3.10.8 updaten soll (also noch dieses Wochenende)
Danke für den Update-Hinweis.
Wie kritisch ist die Lücke - eine "sofort-handeln-Lücke"?
Noch etwas - ich kann das nicht auf "erledigt" setzen:
Nachtrag - das mit dem roten Quadrat hat funktioniert
Hoppla,
wie von Zauberhand ist jetzt wieder alles korrekt - vielleicht doch der Provider...
Hallo,
ich bin gerade auf der Fehlersuche. Mit Update auf 3.10.6 hat sich bei mir das Datum im Content auf Englisch umgestellt. Statt 31. März 2022 steht 31. March 2022
Da ich sowohl Joomla, als auch Yootheme aktualisiert habe, kann das Problem auch bei Yootheme (oder vielleicht auch am Provider) liegen.
Weiß jemand von euch zufällig, wo ich da anpacken kann?
Vielen lieben Dank,
MItcha
Danke für den Hinweis,
das kenne ich schon, werde aber nicht so recht schlau daraus. Letztlich wird es wohl nur über Probieren und Studieren gehen
Hallo liebes Forum,
ich wollte einmal fragen, was die neue API (Webservice) von Joomla kann. Ist damit auch ein Import und Verarbeitung möglich bspw. von Daten, deren Struktur so aussieht:
https://openweathermap.org/api/one-call-api#hist_example
Oder ist die API lediglich als Export Schnittstelle gedacht?
Schöne grüße,
Mitcha
BTW:
Mach doch deine Migration mit PHP 7.4.
Und wenn alles sauber durchgelaufen ist, stellst du auf PHP 8 um.
Genau das habe ich mir auch schon überlegt. Der Ursprungsgedanke aber war, dass es sich hier um einen Bug handeln kann und der sollte gefixt werden, weil ich denke, dass im nächsten halben Jahr immer mehr die Migration durchführen werden und dann auf ein ähnliches Problem stoßen können.
Danke Elwood
Aber mich frustriert das.
Es ist eine ganz frische Webhostingumgebung, die durch keine Vorkonfigurationen irgendwie "versaut" sein könnte- zumindest die bei Strato. Beim V-Server habe ich über plesk eine neue Umgebung aufgebaut und bei webgo ist eigentlich vieles möglich und bei allen drei scheitert es nach einer frischen Installation mit Joomla....
joomla_update.php
Nein, das stimmt, werde es aber die Tage einmal nachholen
Nein, wie beschrieben bricht die Migration mitten im Prozess ab und quittiert alles mit einem 500 er. Sie läuft nicht durch. Logfiles sind am Start des Threads hinterlegt
Da bin ich jetzt aber auch mal gespannt!
Ich auch!
So ist es. Strato Webhosting hat MySQL 5.7.
Und somit ist es auch bei mir getestet.
Könnte es sein, dass unter "Optionen" der Update-Server nicht korrekt eingestellt ist? ("Joomla Next")
Wenn ich das nicht einstelle, kann ich nicht auf 4.0.3 migrieren.
MySQL 8 deshalb, da du bei den Hostern nichts anderes mehr bekommst.
An alle anderen - das ist nett, dass ihr das testet. Aber es bringt nichts, wenn man das lokal und mit andern Voraussetzungen macht. Es geht um die eindeutige Reproduktion des Fehlers/Bugs.
Wegbo oder Strato. Frische Installation J 3.10.2 mit PHP 8.0.11 auf J4.0.3 migrieren schlägt fehl.
Ich habe das auf unterschiedlichen Instanzen getestet und gestern noch extra auf einem V-Server - auch hier fehlgeschlagen.
Das Problem müssten dann ja alle haben, die mit PHP 8 und Joomla 4 arbeiten.
Nein, das Installieren von J4 funktioniert unter PHP8. Nur die Migration schlägt fehlt.
Einfach selber mal testen. Ich hab das bei zwei Hostern nachvollziehen können.
J 3.10.2 installieren (frische Installation), PHP 8 einstellen und dann auf 4.0.3 migrieren - funktioniert nicht - zumindest nicht bei Strato oder webgo
Ich bin jetzt der englischen Sprache nicht so mächtig - wie kann man denn einen Bugreport einreichen?
Migration mit PHP 8.0.11 und MySQL 7.x
Und das geht halt nicht so ohne weiteres