Beiträge von j!-n
-
-
Gehe mal auf Menüs --> verwalten, und stelle dort von Site auf Administrator um. Vielleicht versteckt sich dort etwas, ist mir schon ein paarmal begegnet, vor allem, wenn Seiten über mehrere Versionen migriert wurden.
-
Ich hätte das im Frontend gemacht .
-
Das vielleicht (nicht getestet): https://www.joomshaper.com/joomla-extensions/sp-lms
-
Irgendwo da draussen findet sich die Wahrheit ...
ThemaGoogle Analytics verstößt gegen DSGVO
Meldung von Heise: https://www.heise.de/news/Oesterrei…VO-6326506.html
Österreichische Datenschutzbehörde sieht im Einsatz von Google Analytics wohl Verstoß gegen DSGVO.Lui_brempt13. Januar 2022 um 17:44 -
Wo war denn das Problem?
#2
-
Das BE läuft wieder. Alles ist aktualisiert, das BE zusätzlich abgesichert. Abschließend habe ich dem TE noch Hinweise gegeben, welche Einstellungen bei IONOS noch gemacht werden sollten.
Nun ist Feierabend, Grüße vom Fähnlein Fieselschweif .
-
Wenn man die Beiträge korrekt interpretiert, kommt man zu dem Schluß, dass das Backend gemeint ist, und der TE vorangekommen ist. Ich habe dem TE weitere Unterstützung per PN angeboten. Jeden Tag eine gute Tat.
-
Bedeutet dann auch, dass ich lediglich das Plugin aktivieren muss ohne Code in der Joomla-Config ändern zu müssen?
Zitat:
Zitat
Dieses Plugin lädt extern geladene Dateien oder Schriften in das lokale Dateisystem herunter und stellt sie von der lokalen Domäne aus zur Verfügung.Quelle: https://github.com/joomtools/plg_system_jtaldef
Wenn die Fonts dann lokal gespeichert sind, sollte man die Einbindung externer Fonts aus dem Template nehmen, bzw. dann das lokale Font definieren, wenn man wert darauf legt, dass keine externen Fonts geladen werden sollen. Klingt logisch, oder?
-
Ganz einfach: wenn auf deiner Webseite Google Fonts extern eingebunden sind, registriert Google das bei jedem Aufruf deiner Seite. Das ist quasi Datensammeln durch die Hintertür.
-
Gut möglich und sogar wahrscheinlich, dass dort irgendwo eine Sicherheitslücke besteht. Zuerst würde ich das BE mit einem Verzeichnisschutz versehen (htaccess), und die Installation auf Schadcode prüfen. Wenn du nicht weisst, wie, und auch kein Budget für professionelle Unterstützung hast, die Seite neu bauen.
-
Auch wenn nicht gewünscht, aber der Vollständigkeit halber ein Modul für das Dashboard, welches Hits zurücksetzen kann.
https://www.joomill-extensions.com/extensions/res…ws-hits-counter
-
Kann es sein, dass du früher Versionen von jgerman installiert hast? Soweit ich mich erinnern kann, waren auch die Installationsdateien mal eingedeutscht. Quasi ein Corehack, und wenn, dann kein Bug.
-
Hat jemand eine Idee wie ich diesen Fehler beheben kann?
In phpMyAdmin einloggen, Datenbank sichern. Dann oben auf SQL klicken, das dort einfügen. Achtung, das Präfix #__ (zwei Unterstriche) ist durch das Präfix deiner Installation zu ersetzen. Mit OK ausführen.
CodeCREATE TABLE IF NOT EXISTS `#__utf8_conversion` ( `converted` tinyint NOT NULL DEFAULT 0 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 DEFAULT COLLATE=utf8mb4_unicode_ci; INSERT INTO `#__utf8_conversion` (`converted`) VALUES (0);
Danach gehst du im Backend auf Erweiterungen --> Überprüfen. Ggf nachinstallieren. Dann auf Erweiterungen --> Datenbank, ggf fixen lassen.
Viel Glück.
-
Und das ist richtig. Das sind die Core Kategorien (in einer frischen J4 Installation):
Code(1, 0, 0, 0, 11, 0, '', 'system', 'ROOT', 'root', (2, 27, 1, 1, 2, 1, 'uncategorised', 'com_content', 'Uncategorised', 'uncategorised' (3, 28, 1, 3, 4, 1, 'uncategorised', 'com_banners', 'Uncategorised', 'uncategorised' (4, 29, 1, 5, 6, 1, 'uncategorised', 'com_contact', 'Uncategorised', 'uncategorised' (5, 30, 1, 7, 8, 1, 'uncategorised', 'com_newsfeeds', 'Uncategorised', 'uncategorised' (7, 32, 1, 9, 10, 1, 'uncategorised', 'com_users', 'Uncategorised', 'uncategorised'
-
Zitat
Bevor ich es vergesse - ich hatte auch ein Backup der Dateien über den FTP-Server gemacht und wieder eingespielt.
Davor alle Dateien auf dem Webspace gelöscht? Für mich sieht es noch nach einem Durcheinander von V3 und V4 aus.
Protipp: Migration mit einer Kopie der Seite auf einer Subdomain in einer eigenen Datenbank durchführen, so bleibt die produktive V3 unberührt.
Tipp 2: Erst auf 4.0.0 gehen. Wenn das Backend dann läuft, auf die aktuelle Version 4.0.6 updaten. Meinen Erfahrungen nach kommt es vor, dass sich ein eher suboptimaler Webspace bei dem relativ großen Versionssprung "verschluckt".
-
Ich habe mir die Zeit genommen, dir nach dem Lesen deiner Liste die Erweiterungen zu nennen, die wahrscheinlich inkompatibel sind. Deine Aufgabe ist es nun, durch simple Recherche auf den Seiten der Anbieter dieser Erweiterungen herauszufinden, was mit J4 geht, und was nicht. Also die Wahrscheinlichkeit zu prüfen.
Was genau verstehst du daran nicht?
-
Sind die Dateien auch per FTP nicht mehr da? Wenn der Speicherplatz ausreichend ist, schau dich beim Sicherheitsgedöns bei Strato um. Joomla löscht keine Dateien.
-
Ein Teil der wahrscheinlich inkompatiblen Erweiterungen hast du dort schon gepostet: RE: Kann verwendetes Template ein Update auf Joomla! 4 erschweren?
ZitatSystem - JT – ALDEF
Prüfen.
-
Oh man. Ruhe in Frieden, Anka .