Die Fehlermeldung wird sich ohne das yt Plugin verändert haben - wie lautet die nun?
In der configuration.php sollte error_reporting auf maximum stehen und debug auf 1 - von der Fehlerausgabe / stack trace am besten einen Screenshot posten.
Die Fehlermeldung wird sich ohne das yt Plugin verändert haben - wie lautet die nun?
In der configuration.php sollte error_reporting auf maximum stehen und debug auf 1 - von der Fehlerausgabe / stack trace am besten einen Screenshot posten.
Der veraltete Joomla Core ist hier laut Fehlermeldung das Hauptproblem, siehe
https://fv-roehrsdorf.de/admin…anifests/files/joomla.xml
Das TK Gen Multi II Template (Warp 6) ist jedoch auch ein Problem.
https://www.fv-roehrsdorf.de/t…en_multi_ii/warp/warp.xml
Warp 7 lässt sich hiermit für PHP 8 ohne viel Aufwand fixen - ein Warp 6 hatte ich noch nicht.
https://github.com/bulgaru/warp7-php8.0/tree/main/warp
Umbau auf Astroid wäre auch eine Option.
https://www.joomlaplates.com/f…arp-6-warp-7-astroid.html
...oder eben der Umstieg auf ein anderes, modernes Template.
Das mit der Domain verbundene Verzeichnis kann man bei one.com nicht ändern / keine Zuweisung vornehmen.
Es ist Protostar, siehe oben und der Rest steht schon dort geschrieben
plugins/system/yt/
kann auch erst mal gelöscht oder umbenannt werden und wenn das Backend dann wieder läuft, kann, sofern überhaupt benötigt, das YT Plugin v2.2.3 nachinstalliert werden.
Es ist nicht aktuell, denn in /yt/includes/libs/resize/tool.php on line 369 steht in aktueller Version nur ein Kommentar.
Welche Version hat das YT Framework Plugin?
2.2.3 ?
Steht in
plugins/system/yt.xml
Das Framework Plugin gehört zu einer Erweiterung von smartaddons.
Hier die aktuelle Version - schau mal was passiert, wenn du das installierst.
Unter Joomla 3 kann idR alles mit PHP 8 zum Laufen gebracht werden.
Der aktuelle 3.10.x Core ist vollständig mit PHP 8 kompatibel.
Erstelle eine path.php mit folgendem Inhalt:
<?php
echo $_SERVER["DOCUMENT_ROOT"];
?>
Dann wird dir beim Aufruf dieser Datei im Browser der absolute Server Pfad angezeigt - daran noch jeweils /administrator/log bzw. /tmp anhängen in den entsprechenden Zeilen der configuration.php
Das mit der Domain verbundene Verzeichnis kannst du bei one.com nicht ändern.
Bei Subdomains läuft es so:
https://help.one.com/hc/de/art…%20Subdomains%20erstellen.
Also kannst du dir den Weg über die path.php auch sparen und einfach den Subdomain Namen = Verzeichnis Name aus den Pfaden entfernen, wenn du die Subdomain Website eine Ebene nach oben, auf die Hauptdomain schiebst.
Das erreichst du, indem du alles im Basisverzeichnis in einen Archiv Ordner verschiebst und anschließend die Dateien/Verzeichnisse aus dem Subdomain Verzeichnis auf die geleerte Hauptebene verschiebst.
Gelöst.
Es wurde das J3 Backup wiederhergestellt (J! 3.3.6) und manuell per File Manager auf 3.10.11 hochgezogen + der veraltete JCE Editor aktualisiert, sodass nun alles fehlerfrei unter PHP 8 läuft und bei Zeiten das J4 Upgrade mit der Template Modernisierung angegangen werden kann.
Welche Joomla Version lief denn vor dem PHP 8 Update?
3.10.11 sollte es sein (die neuste) und scheint es nicht gewesen zu sein.
Denn in /libraries/vendor/joomla/string/src/phputf8/utf8.php Zeile 38 der 3.10.11 steht etwas anderes.
Da es noch eine ältere 3.x Version war, kannst du über den one.com Filemanager
- das Joomla 3.10.11 Upgrade Package hochladen.
- das /libraries Verzeichnis in /libraries_alt umbenennen.
- das Joomla 3.10.11 ZIP Paket extrahieren.
- die Drittanbieter Verzeichnisse aus /libraries_alt wieder in /libraries kopieren.
Sobald du wieder ins Backend kommst, unter Erweiterungen -> Verwalten -> Datenbank den [ Reparieren ] Button klicken. Damit wird die Datenbank auf Stand gebracht und alte/überflüssige Dateien werden entfernt.
Das vormals aktive Template (Protostar) funktioniert unter Joomla 4 nicht mehr.
Du könntest das nehmen:
https://github.com/StefanSTS/protostar4
Oder auf Cassiopeia umsteigen.
Was da nun gerade (auch im Backend) Fehler erzeugt, ist eine andere Geschichte..
Da wird wohl das J4 Update schiefgelaufen sein.
ZitatÜber FTP in der configuration.php debug auf 1 setzen und error_reporting auf maximum.
Dann sieht man den Verursacher.
Das Haben wir schon versucht dachte hat sich leider gar nichts getan.
Bei Host Europe musst du noch das error_reporting (bzw. den output) in den Script Einstellungen im KIS aktivieren.
Ich würde empfehlen erst mal ein Backup wiederherzustellen und das J4 Upgrade dann in Ruhe anzugehen.
Joomla 3 PHP 8 Fehler können mit wenigen Ausnahmen schnell gelöst werden.
Das ist bei Strato völlig normal und treibt mich regelmäßig in den Wahnsinn.
Siehe auch
WordPress ist im Schnitt gefühlt noch 4x langsamer - aber auch Joomla Backends sind überwiegend sehr träge.
Lösung:
Umzug.
Kannst du der elfsight Map (dem Widget/Iframe) CSS hinzufügen?
Dann kannst du den Rahmen mit
body {
margin:0;
}
umgehen.
Denn der iframe body tag hat einen 8px user agentstylesheet margin (Standard des Browsers) - wird von elfsight nicht auf 0 gesetzt.
Genau. Wenn du nach awesome filterst und es lokal eingebunden ist, solltest du es unter der eigenen Domain sehen können.
In der Browser Konsole im Netzwerk Tab (Domain Spalte einblenden) kannst du sehen, von welchen Domains die Ressourcen geladen werden.
Kurzes Video dazu:
Oder du checkst die Seite mal bei
Analysiere | Webbkoll - dataskydd.net
- da werden dir alle 3rd Party Requests und Cookies angezeigt.
ZitatOder du hängst den aktuellen timestamp an die Bild URL an
/images/bild.jpg?t=1667250498
Das ist der Unix timestamp - ändert sich sekündlich.
Ausgeben kannst du den so:
<img src="/images/bild.jpg?t={source}<?php echo time(); ?>{/source}" alt="Nicht gecachtes Bild">
Ein PHP Plugin - damit kannst du PHP innerhalb von {source} {/source} nutzen:
Auch eine Möglichkeit. Das generell für die gesamte Seite, CSS, JS, alle Bilder so festzulegen, ist jedoch suboptimal wegen der Performance.
In den Header tag.
Per
Z.B. - damit kannste einzelne Seiten ansprechen.
Oder du hängst den aktuellen timestamp an die Bild URL an über ein Add PHP Plugin. Dann wird das jeweilige Bild auch immer neu geladen.
Ich glaub wenn die EU Datenschutzstandards eingehalten werden und du nen AVV hast sowie einen Abschnitt in der Datenschutzerklärung dazu, geht das.
Weebly, Wix & Co machen das so - läuft dann einfach über fonts.wixCDN.oä statt fonts.googleapis.com.
Das xssen Script ist ganz praktisch, wenn man den /administrator Passwortschutz nicht über die Hosting Verwaltung einrichtet:
Für die Haupt-.htaccess empfehle ich den .htaccess Generator der AdminTools Pro - in Verbindung mit der Firewall ein immenser Sicherheitsgewinn.
Ist yootheme aktuell?
Die Datei und Zeile, in der das Problem auftritt, kann man sich anzeigen lassen, siehe Link zum Call Stak
Ist idR mit einer kleinen Code Änderung behoben, wenn kein Update möglich ist.