Wenn es möglich wäre, eine automatische Kontrolle des angegebenen Link url auf Viren... wäre sicher eine gute Sache.
Sind nur einfache Felder, dass so eine Prüfung möglich wäre, ist mir nicht bekannt.
Das Problem hätte man ja auch, wenn der Link im Post angegeben würde, meine ich...
Hallo,
ich habe gründlich darüber nachgedacht und mir ist nichts eingefallen, ausser eben ein Override.
Dass dein Template dads nicht unterstützen soll, halte ich für unwarscheinlich.
Overrides sind in Joomla eine der wichtigsten Möglichkeiten, die geschaffen wurden um die Ausgabe an die eigenen Bedürfnisse anzupassen.
Grundsätzlich halte ich diese Abfragen für Sinnvoll, vorallem, da mir zu oft Sätze wie dieser aufgestoßen ist:
ZitatBitte die Forenregeln lesen und Angaben machen...
Gerne können wir das verfeinern, gebt uns bitte Euer Feedback welche Infos für einen guten Support in welchem Forum wichtig sind.
Beispiel:
Programmierung / Entwicklung:
Wir sehen dann, was davon umsetzbar ist.
Danke 
Das sieht ganz nach der GZIP Komprimierung aus.
Kannst du mal in der configuration.php $gzip = false; einstellen, falls noch nicht geschehen und die .htaccess prüfen, ob sie mit dem Original übereinstimmt?
Hallo Alexander,
JDownloads is ein gewachsenes System.
Ich kann mir gut vorstellen, dass ma es so erweitern kann, dass der Download einer geschützten Datei auch über einen Token freigegeben werden kann.
Hast du mal bei JDownloads dirket im Forum nachgefragt?
Ich kenne den Entwickler und er ist eigentlich immer sehr aufgeschlossen.
Verweise dann bitte in beiden Foren auf Einander (Crossposting).
hast du möglicherweise in der globalen Konfiguration die GZIP Komprimierung an?
Wenn JA mal abstellen.
Hast du in der configuration.php etwas bei $live_site stehen?
Wenn Ja, nimm das mal raus.
Ich vermute mal deine .htaccess als Übeltäter.
Kannst du die mal umbenennen?
Ich persönlich finde es z.b. in Erweiterungen schon ziemlich wichtig...
Danke für dein Feedback, wir werden das intern besprechen 
gindi35510 das Problem liegt etwas teifgreifender.
Viele SQL Scripte verwenden nur utf8 als Collation und gehen davon aus, dass es mit utf8_general_ci/utf8mb4 gleichgesetzt ist.
In MySQL 8 wurde das nicht gemacht, sondern noch mit utf8mb3 verknüpft.
Das Problem kann nur der Datenbank Admin lösen, indem er die Standards anpasst.
Das scheint etwas zu sein, was dein Hoster korrigieren muss.
Ich hab hier was dazu gefunden:https://code.djangoproject.com/ticket/29678
Besser: https://dev.mysql.com/doc/reln…tml#mysqld-8-0-11-charset
Der Einfachheit halber kannst du hier https://fonts.google.com/ die Font suchen und den Import Befehl in deine custom.css packen.
Dann kann das von mir oben genannte Plugin die Font lokal herunterladen und alles passt wieder.
Hast du mal das Plugin JTALDEF versucht?
https://github.com/joomtools/plg_system_jtaldef
Nachtrag:
Komando zurück, die Fonts werden bei Dir über JS nachgeladen, da geht das Plugin nicht.
Sieht ganz danach aus, als wäre das ein Problem aufgrund der PHP Version und der Joomla Version.
Joomla kleiner 3.10.11 benötigt PHP 7.4, PHP 8.x benötigt Joomla min. 3.10.11.
Dann sind da noch die Erweiterungen...
versuch mal lieber :
.....
use Joomla\Utilities\ArrayHelper;
$displayData = ArrayHelper::pivot($displayData, 'title');
....Acymailing ist veraltet.
Oder wir holen den Entwickler vom KCM NielsNuebel mit ins Gespräch und fragen Ihn mal 
Alles anzeigenHast du mal deine .htaccess deaktiviert oder die Joomla 4 Vorlage (htaccess.txt) probiert (in .htaccess umbenannt)?
Ich denke damit könnte es zusammenhängen.
https://docs.joomla.org/J4.x:A…s_after_updating_to_4.0.4
Wenn nicht des Rätsels Lösung - was ist deine Ausgangsversion?
Der Tipp ist Gold wert, hast du die Änderung in der .htaccess mal geprüft?
Generell ist dieser Sicherheitsfix aber auch ein versteckter Appell an Administratoren, unnötige Erweiterungen zu deaktivieren, also z.B, alle zur Joomla-API gehörenden Plugins ("Web Services"), wenn man sie gar nicht nutzt oder nur die, für die Bereiche, die man per API nutzt.
Es gibt zahlreiche, anderweiige Erweiterungen in Joomla 4, die man oft deaktivieren kann.
Unter'm Strich tut man auch "Joomla gut", wenn nicht zu viel Unnötiges aktiv ist und es fördert die Übersichtlichkei (weswegen ich das eigentlich bei jeder Seite mach(t)e). Aber nicht zu blind vorgehen, wenigstens nicht ohne Sicherung der Tabelle #__extensions zuvor
Ich stimme Dir voll und ganz zu, aber wir haben es häufig mit Anfängern zu tun, die das nicht richtig einschätzen können.
Ich meine, man sollte bei der Installation auswählen können, was man an Core Erweiterungen braucht und das dann darüber steuern lassen.
Besser wäre es sogar, auch Core Erweiterungen nur zu installieren, wenn sie benötigt werden.
Das würde die Basis schmälern und das System sicherer machen.
Sollten die Eingabe in den Metaangaben eines Beitrag gemeint sein, und die damit verbundene Ausgabe der Keywords im <head>, dann ist das tatsächlich in Joomla 4 aus o.g. Grund entfernt worden.
Die dort hinterlegten Keywords spielen jedoch für das Modul "Ähnliche Beiträge" eine Rolle.
