Beiträge von Pest

    Hallo zusammen

    Kleine Info an jene Person, die die Update-Server von Joomla mit den Paketen befüllt. Auf dem stabilen Kanal und dem Standard-Server wird gerade die 5.1.2-RC2 ausgeliefert, beziehungsweise zur Installation angeboten. Ich denke das soll wohl nicht so sein. Ja, Konfiguration auf den Seiten stimmt und die Meldung erscheint bereits auf mehreren Kundenseiten. Kurzfristige Änderung des Kanals / Servers ändert nichts an der Meldung.

    Gruß Jan

    Moin

    Die Reihenfolge unter "Beiträge" kann durch einen Menüpunkt überschrieben werden. Du hast doch ganz sicher einen Menüpunkt für Deine Startseite oder? Schau bitte mal dort nach der Reihenfolge.

    Nachtrag: Ebenfalls gibt es bei vielen Templates Optionen den Aufbau und die Sortierung der Startseite abweichend von Joomla zu verändern. Falls in Deinem Template in den Optionen / Funktionen vorhanden, würde ich auch dort einen Blick riskieren.

    Gruß Jan

    Moin

    Wenn ich richtig verstanden habe, hattet Ihr Euer Joomla bereits auf Joomla 4 gebracht, aber es war noch in der Hosting-Verwaltungsoberfläche (Plesk?) verknüpft? Und dort habt Ihr dann ein "Update" für Joomla 3 angeschoben und damit Euer Joomla 4 überschrieben? Falls ja, kannst Du das hier ausprobieren.

    1. Vollständige Sicherung Eurer (kaputten) Webseite inklusive Datenbank über Euren Hoster anlegen.
    2. Die passende Joomla 4 Version die vorher bei Euch lief von dieser Webseite herunterladen und das Paket dann bei dir auf dem Rechner entpacken. https://downloads.joomla.org/cms/joomla4
    3. In das entpackte Paket gehen und dort das Verzeichnis "installation" löschen.
    4. Per FTP auf den Webspace der kaputten Webseite gehen und dort in dss Hauptverzeichnis mit dem Joomla springen. Den Inhalt des Joomla 4 Verzeichnisses auf Deiner Festplatte öffnen und per FTP über die vorhandenen Dateien schreiben lassen. Vorhandene Dateien überschreiben, Verzeichnisse zusammenführen, falls Dein FTP-Programm dies nachfragen sollte.
    5. Per FTP schauen ob sich Dateien im "cache"-Verzeichnis des Joomla befinden. Falls ja, alles außer der "index.html" löschen.
    6. Cache Deines Browser löschen und die kaputte Seite wieder aufrufen. Sie sollte jetzt wieder funktionieren und Du solltest auch wieder in das Baackend kommen.

    So lange das Update keine Änderungen an der Datenbank vorgenommen hat sollte dies bereits als Lösung ausreichen. Soweit ich mit erinnern kann überschreibt z.B. Plesk beim Joomla Toolkit einfach nur stumpf die Dateien.

    Gruß Jan

    Ein möglicher Erklärungsansatz, welchen ich schon einmal bei einem Kunden erlebt habe...

    Wurde ein Joomla 3 als "App" durch die Verwaltungsoberfläche Plesk installiert und automatische Updates aktiviert, dann kann es passieren das diese Seite durch das System über diese automatischen Update überschrieben wird. Plesk kontrolliert nicht, ob ein Joomla zwischenzeitlich manuell auf Joomla 4 oder 5 aktualisiert wurde. Ist das Joomla per automatischen Update in Plesk verbunden, werden die Core-Dateien gnadenlos über das eigentlich neuere Joomla geschrieben, was zum Defekt der Seite führt. Daher sollte man das "alte" Joomla per Akeeba sichern, die Verbindung zum Plesk lösen, das Joomla wiederherstellen und dann die Migration vornehmen.

    Bei irgendeinem Kunden wurde mir vor ein paar Tagen ein solch automatisches Joomla 3.x Update auf dem Server gemeldet, aber das kann nur eine alte Testseite gewesen sein, die eh per htaccess geschützt war. Daher nicht relevant. Aber eventuell erklärt es das Problem hier.

    Gruß Jan

    Moin

    Meine Vermutung ist, dass Dein Browser bei der Änderung der Joomla-Konfiguration, dass Passwort für das Postfach, mit dem Passwort für Deinen Joomla-Benutzer überschrieben hat. Du hast dann nur noch auf "Ok" gedrückt und der Fehler war gespeichert. Daher würde ich Dich bitten noch einmal in die Joomla-Konfiguration zu gehen und dort das Passwort für das Postfach erneut einzutragen, Dir anzeigen zu lassen und dann erneut zu speichern.

    Funktioniert dies nicht, würde ich so vorgehen.

    1. Testen ob die Zugangsdaten richtig sind. Ich würde zuerst auf die Webmailing-Oberfläche Deines Hosters gehen und dort die Kombination aus Benutzernamen und Passwort testen. Funktioniert das, kannst Du zu Schritt 2 gehen.

    2. Testen ob alle anderen Daten richtig sind. Hierfür legst Du einen neuen Account in Deinem lokalen eMail-Programm an und übernimmst die Daten ganz genau so, wie sie auch in Deinem Joomla stehen. Funktioniert das nicht, stimmen zwar Benutzername und Passwort, aber Port, Server oder sonst was ist falsch. Kann das Mail-Programm zugreifen, liegt das Problem im Joomla oder einer Instanz die vorher eingreift. Weiter zu Schritt 3...

    3. Protokolle in der Verwaltungsoberfläche Deines Hoster kontrollieren. Tauschen dort die Aufrufe aus dem Backend und dem Test der eMail auf? Falls ja, mit welchem Fehlercode? Ist eventuell eine Firewall wie Mod-Security auf dem Server aktiv und versucht potenzielle Angriffe anzufangen? Kommt manchmal vor und würde man in den Log-Dateien sehen. Schauen ob man die Firewall mit Ausnahmen versehen oder testweise deaktivieren kann. Sieht alles gut aus? Dann zu Schritt 4...

    4. Störerhaftung. Kontrolliere bitte ob bei dir Erweiterungen / Plugins installiert sind, die in die Benutzerverwaltung oder den eMailversand eingreifen. Spontan kommen mir das Community- oder Newsletter-Komponenten in den Sinn. Gibt es etwas? Falls ja bitte testweise vollständig deaktivieren. Nichts zu finden, dann weiter zur Holzhammermethode unter Schritt 5.

    5. Keine Ahnung warum es so oft funktioniert. Ergibt sich kein logischer Ansatz für dieses Problem und auch Dein Hoster hat keine Idee wo es noch klemmen könnte? Dann würde ich persönlich zum (fast) letzten Mittel greifen und den Core ersetzen. also vorher eine vollständige Sicherung Deiner Seite anfertigen (inklusive Datenbank) und dann ins Backend gehen, dort unter System, dann "Joomla-Update", einmal nach Updates suchen lassen, und dann sollte Dir der Punkt angeboten werden, die Joomla Core Dateien erneut zu installieren.

    Klappt das alles nicht, scheint das Problem komplexer zu sein. Viel Erfolg.

    Gruß Jan

    Nein, Joomla selbst nimmt keine solchen Weiterleitungen vor.

    Schau mal bitte was mit Deinem Cookieeinstellungen nicht funktioniert, der Link im Footer der Seite führt ins Nirgendwo:

    Tausendfuessler Neu-Isenburg - top Qualität von Größe 18 bis 41
    Es ist ein besonderer Moment: die ersten Schuhe für das Baby, die ersten Schritte, der erste Kindergarten-Schuhe, die ersten Schuhe für die Schule. Jeder Fuß…
    www.tausendfuessler-schuhe.de

    Das kommt aber nicht von Joomla, sondern sollte ein extra Plugin / Erweiterung sein.

    Gruß Jan

    Also ich habe kurz nachgeschaut und der Aufruf der API über...

    Code
    $inputCookie = JFactory::getApplication()->input->cookie;

    ... soll noch mit Joomla 4 kompatibel sein. Wo es konkret klemmt kann ich ohne eigenen Test nicht sagen. Problem: ich habe für den Rest der Woche durchgehend Migrationen für Kunden vorzunehmen und komme jetzt nicht dazu. Eventuell komme ich am Wochenende dazu es mal kurz auf einer meiner Seiten zu testen, aber ohne Garantie.

    Moin

    Hast Du weiter nach unten auf der Seite gescollt? Dort ist eine Antwort die scheinbar funktionieren soll.

    How to use cookies to populate RSForm fields without notices/warnings?
    I have used this code to save the RSForm data in a cookie and if the user tries to fill in the same form again, the previously entered data is loaded as…
    joomla.stackexchange.com

    Wichtig --> Da muss auch Script-Code beim Ausführen der Formulars hinzugefügt werden. Steht dort aber was wohin gehört.

    Gruß Jan

    Moin

    Schau mal bitte in Dein Postfach, Du solltest schon seit Wochen eMails von Google bekommen haben.

    Zitat

    Betreff: : Google Analytics-Konto vor dem 1. Juli 2023 anpassen

    Sie müssen wichtige Änderungen an Ihrem Google Analytics-Konto vornehmen. Unser Analysetool der nächsten Generation, Google Analytics 4, ersetzt die Standardversion Universal Analytics. Ab dem 1. Juli 2023 werden in standardmäßigen Universal Analytics-Properties keine neuen Daten mehr verarbeitet. usw. usw.

    Habe selbst kein Analytics laufen, aber denke das es daran liegt.

    Gruß jan

    Driftet eh schon zu sehr in einem Joomla-WordPress-Vergleich ab, was so gar nicht wirklich beabsichtigt war.

    Was man in dieser Diskussion aber nicht ausblenden kann, weil die weitaus meisten ehemaligen Joomla-Anwender zu genau diesem System gewechselt sind.

    "Da steht ein Elefant im Raum, aber lasst uns bitte nicht über den Elefanten unterhalten..." :)

    Wenn man wissen möchte warum die Nutzer wechseln, muss man sich die Unterschiede eben ansehen und beim Namen nennen.

    Moin

    Ungetestet und ein älteres Thema, aber Du kannst Informationen in Cookies (zwischen)speichern lassen. Eventuell kannst Du das als Vorlage für Dein Vorhaben verwenden.

    How to use cookies to populate RSForm fields without notices/warnings?
    I have used this code to save the RSForm data in a cookie and if the user tries to fill in the same form again, the previously entered data is loaded as…
    joomla.stackexchange.com

    Gruß Jan

    Moin

    Sorry wenn ich das so deutlich sage, aber ob wir uns hier gegenseitig vom Standpunkt des anderen überzeugen lassen, spielt für die Welt da draußen absolut keine Rolle. Es geht nicht darum ob hier irgendwer Recht hat oder nicht, sondern das die Anwender seit Jahren zu anderen Systemen abwandern.

    Räumen wir den ganzen Pathos mal zur Seite, dann ist jedes CMS ein Werkzeugkasten mit dem man vorher definierte Arbeiten erledigt. Klar gibt es Leute die den Werkzeugkasten an sich mehr schätzen als die Arbeit die man damit verrichten könnte, die Abends die Schraubendreher herausnehmen, behutsam mit einem weichen Tuch abtupfen, begeistert ins Licht halten und sich am wohlgeformten, besonders ergonomischen Griff erfreuen. Aber für den weitaus größten Nutzerkreis ist es nur ein schnödes Mittel um eine Aufgabe zu erfüllen.

    Mal angenommen ein Anwender hat sich damit eine kleine Gartenhütte realisiert, viel Herzblut investiert und Alles nach seinen Vorstellungen eingerichtet. Jetzt kommt der Hersteller des Werkzeugkasten aber nach zwei Jahren und verkündet trocken, dass man die Schraubendreher von Kreuzschlitz auf Sternschrauben geändert hat und - um zukünftig noch Arbeiten an seinen Gartenhaus vornehmen zu können - alle Schlitzschrauben gegen Sternschrauben austauschen müsse. Im Koffer gibt es halt nichts anderes mehr. Warum? Weil es halt so ist!

    Davon betroffen sind aber ebenfalls alle Hersteller von Schrauben und anderen Zubehör die zum Bau der unterschiedlichen Projekte benötigt werden. Auch hier stellen sich die Verantwortlichen nach einiger Zeit die Frage, ob man für einen speziellen Werkzeugkoffer alle zwei Jahre die Produktion kostspielig ändern und anpassen möchte? Vor allem weil immer weniger Nutzer diesen sehr eigensinnigen Werkzeugkoffer einsetzen...

    Und dann gibt es da diesen anderen Werkzeugkasten-Hersteller, der zwar auch regelmäßig technische Änderungen vornimmt, aber statt fester Schraubendreher einen Griff und kleine Bits beilegt. Das macht über die Jahre hinweg zwar etwas zusätzliche Arbeit, aber er behält damit nicht nur seine bestehenden Kunden, sondern bekommt über die Zeit immer mehr hinzu.

    Aber wieder zurück in die Joomla-Welt --> Jede harte Migration bei Joomla kostet Nutzer, weniger Nutzer bedeutet weniger potentielle Kunden für Entwickler von Fremdkomponenten, bei gleichzeitig steigenden Ausgaben für die Anpassungen an die jeweils neue Version. Alles lange bekannt und in der freien Wildbahn zu beobachten. Gibt es immer weniger professionelle Erweiterungen, wird das CMS an sich unattraktiver und der Kreis schließt sich.

    Aber egal was wir hier auch schreiben, es ändert nichts am eigentlichen Problem. Alle Argumente (egal ob Pro oder Kontra) wurden zig mal genannt und bis zum Erbrechen erörtert. Die Nutzer werden so lange abwandern, bis Joomla den Erhalt seiner Nutzer in den Fokus stellt und "weiche" Migrationen einführt, von denen die Anwender nichts bemerken. Und ganz gleich wie man zu Wordpress auch stehen mag, dort funktioniert das seit 10+ Jahren praktisch reibungslos.

    Gruß Jan

    Moin

    Kurzfassung: Du kannst die genannten Erweiterungen nicht aktualisieren, weil sie kostenpflichtig sind und Du wohl kein aktives Abo dafür besitzt. Wahlweise Abo abschließen und behalten, oder komplett deinstallieren.

    Damit im Zusammenhang steht wahrscheinlich eine Inkompatibilität mit PHP 8, was zu den Fehlermeldungen führt. Wenn es Dein Hoster anbietet kannst Du testweise kurz auf PHP 7.4 umschalten und schauen ob die Fehler dann verschwinden. Geht das nicht, schau ob die neuesten Versionen der oben genannten Erweiterungen mit PHP 8 kompatibel sind (bei JCE bin ich mir sicher) und entscheide Dich eben für die Abos, Deinstallation oder schau nach Alternativen. Beim JCE gibt es z.B. eine eingeschränkte Core-Version.

    Gruß Jan

    Moin

    Dein Joomla muss nicht zwangsläufig das Problem gewesen sein. Ebenso kann es ein Trojaner auf Deinem Computer oder Handy gewesen sein, der die Passwörter für den Zugang zum Webhosting-Paket, dem FTP oder Joomla selbst abgefangen und ins Ausland übertragen hat. Dafür kommen prinzipiell alle Geräte in Frage, auf denen diese sensiblen Daten gespeichert haben. Auch sollte man in diesem Kontext mögliche Cloud-Speicher nicht außer Acht lassen.

    Deshalb: Alle beteiligten Geräte auf Schadcode / Viren überprüfen und dann ALLE Passwörter ändern. Erst danach kann man wieder eine saubere Grundlage schaffen auf der das Joomla läuft.

    Gruß Jan

    Alle Möglichkeiten funktionieren nicht. Es kommt maximal nur gb, obwohl es eingestellt ist.

    Wie Re:Later bereits schrieb, muss sich der Check welche Sprache benutzt wird zwingend (!) innerhalb des Joomla befinden und übermittelt den Parameter dann über die URL an das Script im iFrame. In der anderen Richtung kann es nicht funktionieren, da der Besucher des Browsers das iFrame direkt lädt, ohne Beteiligung des Joomla in dem es sich befindet.

    Das Gleiche würde auch auf Lösungsansätze mit einem Cookie zutreffen, da ein Server immer nur jene Cookies auslesen darf, die auch von ihm selbst über den Browser gesetzt wurden.

    Moin

    So gut wie alle mir bekannten Hoster bieten in Ihrer Verwaltungsoberfläche eine Option, alle Anfragen von HTTP auf HTTPS umzuleiten. Vorteil --> Man muss die htaccess nicht verändern und fängt die Anfragen direkt auf dem Server ab. Denn theoretisch könnte eine tiefer liegende htaccess die unsicheren Anfragen wieder zulassen.

    Gruß Jan