Beiträge von deGobbis

Um das zumindest erwähnt zu haben:

JTALDEF ist nun in Version 2.1.0 veröffentlicht und läuft nativ unter Joomla 5 und Joomla 6.

Zitat von ManniG.

also bei mir funktioniert JT-ALDEF noch... Joomla 6.1.0 Plugin Verhalten – Abwärtskompatibilität 6 ist aktiviert, im Plugin beide Schalter auf JA...

Das habe ich dann beim Umbau auch festgestellt, aber egal.

Ich hab eben einen RC veröffentlicht, der läuft auf Joomla 6.1 nativ.

Joomla 5.4 ist noch nicht getestet, falls da jemand Erfahrungswerte posten will, gerne
Um es in Joomla 5.4 zu testen, muss das Paket aber heruntergeladen DL-Link und manuell installiert werden - ich hab das Update noch nicht freigegeben.

Fast vergessen: Version 2.0.11 wird für das Update vorrausgesetzt.

Und jetzt auf zum JUG-München Treff!
Gruß Guido.

Zitat von Rolf Dautrich

Mit JFormField ist in J5 Schluss.

Dann muss ich die Woche mal ran.

Ach Herrje...
Geht das auch nicht mehr mit dem Compatibilitätsplugin?

Falls nicht bedacht, das Abwärtskompatibilitätsplugin sollte während der Bereinigungsaktion natürlich aktiviert sein.

Hast Du NGINX nur als Proxy oder als alleinigen Webserver am laufen?
Wenn Alleinig, dann könnte es mit den Rewrites zu tun haben, die sonst über den Apache und der .htaccess abgefangen werden.

Mir wäre nicht bekannt, dass NGINX die .htaccess interpretiert.

Das ist ein Bug, für den es auch schon einen Fix gibt: https://github.com/joomla/joomla-cms/pull/44378

Ist dann mit dem nächsten Update behoben.

im foundry Plugin ist das hier das Problem:

$app = JFactory::getApplication();

Ersetz das mal durch:

$app = Joomla\CMS\Factory::getApplication();

Jetzt will ich auch:

Die Zugangsdaten zur Datenbank sind falsch?

Siehe configuration.php

    var $host = ''; // URL zur Datenbank (wahrscheinlich localhost)
    var $user = ''; // Datenbank-Benutzername
    var $db = ''; // Datenbankname
    var $password = ''; //Passwort zum Datenbank-Benutzer

Wenn du das über FTP ändern möchtest, achte bitte auch darauf, dass die Datei beschreibar ist.

Berechtigung rwx:r-x:r-x (644)

Besser Spät als nie, ich geb da auch mal meinen Senf dazu:

In den Headerinformationen des Browsers kann eingesehen werden, ob Brotli genutzt wird, oder nicht.

x-content-encoding-over-network: gzip oder

x-content-encoding-over-network: br

Hab das mal getestet mit einer Joomla 4 und der defautlt .htaccess:

Wenn ich gzip in Joomla aktiviere, wird es genutzt. Ist der Server für Brotli konfiguriert und ich deaktiviere gzip in Joomla, wird Brotli genutzt.

Mit dem Tool auf der Seite von cybergurk konnte ich dann sehen, dass Brotli die bessere Komprimierung macht

Hast du auch die Anweisung befolgt, die in Deinem Screenshot steht bezüglicht der htaccess.txt?

Kleine Info vorab:
Ich werde an einer Ubuntu 23.10 (gnome) Installation zeigen, wie meine (auf Docker basierte) Entwicklungsumgebung eingerichtet und eingesetzt wird.

Bei Windows wird WSL2 benötigt und bei OSX wird brew benötigt.

Soweit mir bekannt, geht das über das Terminal wie bei Linux.

Wo liegt denn dein htdocs Ordner, wem gehört er genau (Benutzer:Gruppe) und welche Berechtigung ist vergeben?

Hast du auch das Nutzen von E-Mail-Programmen bei GMX für die E-Mail-Adresse freigegeben?

Nachtrag: https://hilfe.gmx.net/pop-imap/einschalten.html

Ich würde meinen, den Suchindex neu erstellen könnte helfen.

Zitat von MaxKom

Wenn Sie Ihre Website auf der Grundlage eines beliebten CMS, z. B. WordPress, erstellt haben, können ungeeignete Erweiterungen, Themes oder andere Website-Komponenten den Fehler 500 verursachen. Die einfachste Möglichkeit, dies zu überprüfen, besteht darin, alle Add-ons in der Datenbank zu deaktivieren

Auch wenn die Wahrscheinlichkeit recht gering sein sollte, dass in einem Joomla Forum eine Wordpress Frage gestellt wird, so sind die Ausführung auch auf Joomla anwendbar und vielleicht hilfreich.

Eine Tabelle, welche Browser welche Bildformate unterstützen:
https://en.wikipedia.org/wiki/Compariso…_format_support

Vor der Wiederherstellung würde ich auch mal die Dateien löschen und die Datenbank leeren.
Vielleicht läst sich ja damit die vorherige Version sauber wiederherstellen.

Zur Info, das ist ein sog. Core-Hack und wird mit einem Update überschrieben.

Das kann sogar dazu führen, dass das Update nicht vollständig durchgeführt werden kann und die ganze Seite kaputt macht.

Es wird dringend empfohlen, den Hoster zu wechseln und auf einen zu wechseln, der keine Probleme hat

Ich würde ja annehmen, einer der Mitwirkenden hat sich lokal eine Kopie gemacht und nicht darauf geachtet PHP-Mail abzufangen.

Die lokale Entwicklungsumgebung ist dann mit der Domain http://test.test erreichbar und deshalb hast du diese E-Mail von der Domain erhalten.