Beiträge von Pest

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...

$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

Zitat von flotte

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

Zitat von reinhardmelz

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

Verwendet das Paket von Strato die Verwaltungsoberfläche Plesk? Hast Du zufällig einen Verzeichnisschutz vor die (neue) Seite gelegt?

Moin

Wenn ich Altlasten von bestehenden Projekten loswerden möchte, greife ich gerne auf die Komponente "SP Transfer" zurück. Damit kannst Du Inhalte, Benutzer, Dateien / Bilder, Module, Menüs usw. von einem Joomla in ein anderes übertragen. Auch von einem Joomla 3 in ein Joomla 4 hinein ohne Migration. Du erstellst quasi die neue Seite aus einer frischen Installation heraus und verbindest die beiden Joomla dann über die Komponente per FTP / MySQL. In der Komponente kannst Du dann auswählen welche Bestandteile übertragen werden sollen. So oft Du möchtest, mit einzelnen oder allen Bestandteilen. Bei Komponenten kannst Du (fremde) Felder aus der Datenbank auswählen und separat übertragen. Mache ich z.B. bei Erweiterungen, nachdem sie frisch in ebenso frischen Joomla installiert sind. Altlasten bleiben damit in der alten Installation zurück. Da die (alte) unverändert bleibt, kannst Du die Übertragung so oft probieren wie es notwendig ist.

Aber Achtung! Keinesfalls! Niemals! Wirklich NIE die Administrator-Module und Administrator-Menüs übertragen lassen! NIEMALS! Damit würdest Du Dir das Backend der frischen Seite zerlegen.

https://www.kainotomo.com/products/sp-transfer
PS: Musst ein Stück nach unten scrollen, dort kommt die Beschreibung und ein Video.

Gruß Jan

Moin

Das angesprochene Problem kann ich durchaus verstehen, aber wirklich akut war es eigentlich nur in der Vergangenheit. Also zu Zeiten, in denen es sehr rigide Upload-Limits von 8 oder 4 MB gab. Gerne in Kombination mit langsamen Internet-Verbindungen und kurzen Scriptlaufzeiten auf dem Server. Aber diese dunkle Epoche haben wir ja nun schon lange hinter uns gelassen.

Was schlanke Pakete angeht, lohnt sich ein Blick Richtung Typo3. Dort kann man per SSH und Composer selbst auswählen welche Bestandteile man installieren möchte, oder eben auch nicht. Aber Vorsicht! Typo3 ist nicht vergleichbar mit Joomla, verfolgt ein ganz anderes Konzept und ist in der Bedienung / Pflege sehr viel anspruchsvoller. Aber vielleicht als kleine Inspiration...
https://get.typo3.org/misc/composer/helper

Gruß Jan

Moin

Neben der Datenbank muss man auch die Dateien auf dem Webspace leeren / löschen. Das Backup schreibt nur jene Inhalte zurück, die eben in diesem Backup vorhanden sind. Zusätzlich hinzugekommene Tabellen (Datenbank) oder Dateien / Verzeichnisse werden hierbei nicht berücksichtigt.

Kleines Beispiel: Man zerlegt sich die Seite mit einer eigenen htaccess in einem Unterverzeichnis. Da diese nicht im Backup vorkommt und der Server oder Akeeba Backup die Dateien von sich aus nicht löschen, kann man die Backups zurückspielen so oft man möchte, der Fehler bleibt immer bestehen.

Aber Vorsicht! Immer absolut sicher sein, dass das Backup vollständig ist bevor man die Datenbank leert oder die Dateien auf dem Webspace löscht. Zur Sicherheit immer zusätzlich eine Sicherung beim Hoster selbst anschieben.

Gruß Jan

Moin

Front- und Backend laufen doch? Ich tippe darauf, dass noch alte Daten im Joomla- oder Browser-Cache gespeichert waren. Das Problem scheint sich jedenfalls erledigt zu haben.

Gruß Jan

Moin

Läuft auf der Seite bereits ein JCE (Pro) als Editor? Falls ja, kannst Du Audios und Videos ganz einfach auf Deiner Seite ablegen und darüber einbinden. Eventuell musst Du den Media-Button in der Leiste erst noch hinzufügen.

Gruß Jan

Moin

Nur damit ich das richtig verstehe...

- Du hast jetzt eine produktiv laufende Seite auf Deiner Domain?

- Auf dieser produktiven Seite funktioniert auch das Umschreiben der Adressen?

- Die Version Deiner lokalen Testseite ist die gleiche wie die der produktiven Seite?

- Hast Du vor der Übertragung Deiner lokalen Testseite dass Verzeichnis und die Datenbank der alten geleert?

- Hast Du mal testweise die htaccess und die configuration.php der alten Seite gesichert und nach der Übertragung der neuen zurückgespielt? Sind die Versionen gleich, sollte das kein Problem sein.

Gruß Jan

Gibt es einen Link zum Problem? Ohne Blick in den Quelltext kann hier nur raten...