Beiträge von Re:Later

    Nun habe ich im Verzeichnis mod_login eine dritte default.php (versehen mit dem Datum von heute), mit der ich nichts anfangen kann.

    Wenn du einen neuen Override anlegst via Backend-Geklicke und schon einer da ist, erhält der neue eine Datumsmarkierung.


    Ich muss aber zugeben, dass mir die Sinnhaftigkeit dahinter nicht wirklich klar ist ;) Irgendwo werden einem die Unterschiede der Overrides zu Original angezeigt. Aber wie gesagt blick ich nicht wirklich zu welchem Original eigentlich und wozu.


    Aber du kannst die Dateien löschen und fängst dann mit einem neuen Override an. Der heißt dann wieder default.php und ist frisch.

    Könntet ihr bitte prüfen, welche Cookies auf meinen Seiten aktiviert werden.

    Für den Firefox gibt es das kostenlose AddOn "Cookie Quick Manager". Damit kann man sehr gut die Cookies identfizieren, die dein Browser so sammelt.


    Klickerst also die Seiten einfach mal durch, nachdem du die Cookies alle gelöscht hast. Dann siehst, welche neu erscheinen.

    Ich verstehe nicht, woher der o. g. Code „#dokument...“ kommt.

    Der kommt vom eingebundenen IFrame. Findest du auch, wenn Inhalte des IFrames angezeigt werden. Hier ein willkürliches Beispiel:



    Kurz: "Ausgeführt/Abgeholt" wird er, aber irgendwas blockiert die Darstellung des Inhalts (in <html> und <body>). Das können u.a. Browsereinstellungen sein und/oder Sicherheitseinstellungen (Seite läuft unter https, aber IFrame wird via http abgefragt), Fremdseite mag es nicht, dass deine Seite nicht erreichbar ist usw. usf. Gibt es Diverses...

    Wenns so einfach wäre im DPCalendar-Wust die richtige Zeile zu finden ;) Deshalb mein Hnweis zu CSS.


    Overrides gehen da genauso wie in anderen Erweiterungen, anderen Modulen. Welches Modul es ist, weißt nur du. Ob PageBuilder mitspielt kann man nur hoffen. Machen ja oft ihr eigenes Ding.

    Ich habe auf einen Override im Template gehofft

    Man verliert irgendwann die Lust, puristische Codes abzuliefern, um dann hinterher zu erfahren, dass irgendwelche schrägen PageBuilder und/oder Frameworks, die komplett weg sind von Joomla-Standards, verwendet werden ;) Im Grunde einfach so eine Joomla-Override-Weiche, ob es sich um eine Kategorie- oder Einzelartikelansicht handelt.

    Sagen wir, dein neues Template liegt im Ordner "sonstwas".


    Lege in diesem neuen Template im Ordner /languages/ einen Unterordner /de-DE/ an.


    Gehe in den Joomla-Ordner /languages/de-DE/ und kopiere die beiden Dateien


    de-DE.tpl_beez3.ini

    de-DE.tpl_beez3.sys.ini


    in den neuen Ordner im Templateordner.


    Benenne diese Kopien dann um nach


    de-DE.tpl_sonstwas.ini

    de-DE.tpl_sonstwas.sys.ini


    Alternativ kannst die umbenannten Kopien auch im Joomla-Ordner /languages/de-DE/ ablegen.

    Hm, ich trage seit Ewigkeiten Umleitungen so ein, mal mit, mal ohne einleitenden Schrägstrich.

    Und funktioniert problemlos dann auf allen Plattformen (XAMPP, online, mit http, ohne https)


    Und noch mal, Die Umleitungskomponente leitet nur dann um, wenn die "Alte Adresse" nicht erreichbar ist.



    Zum Testen gebe ich dann im Browser ein

    Code
    http://example.org/de/anfrageliste
    example.org/de/anfrageliste
    https://example.org/de/anfrageliste
    
    http://www.example.org/de/anfrageliste
    usw.

    Und alle funktionieren.

    Wenn du die http -> https weiterleitung beim Provider aktivierst, wird die zuerst ausgeführt.


    Wenn du sie in der htaccess durch 3,4-Zeiler erzwingst, gehört sie halt an den Anfang (vor den anderen Weiterleitungen). htaccess-Umleitungen finden statt bevor Joomla ins Spiel kommt.


    So lange du in der Joomla-Umleitung die Umleitungen ohne Domain, also ohne den Part http://example.org anlegst (für das Sammeln kann man das im Plugin wegkonfigurieren), gibt es da keine Probleme, wenn man mittendrin auf https umstellt. Und ja, die Joomla-Umleitung ist die letzte.


    Auch in der htaccess brauchst du den Domainteil nicht. Machen viele falsch/unhandlich.


    Wenn du eine Weiterleitung

    von http: // domain / Beitrag
    auf http: // domain / neuerbeitrag

    in der Umleitungskomponente anlegst, muss gewährleistet sein, dass die alte URL eine Fehlerseite (404) ausgibt. Sonst tut die nämlich nichts.


    Da ist dann die htaccess der richtige Platz.

    Es ist nicht erlaubt durch eine Cookie-Abfrage den Zugang zur Seite zu versperren, wenn der Benutzer nicht zustimmt. Damit wird quasi Zwang ausgeübt und die Entscheidung ist nicht mehr freiwillig. Todsünde so was weiterhin zu verwenden.


    Wie schaffe ich es, ohne einen solchen Sperr-Cookie-Banner auszukommen?

    Das schafft man so, dass Cookies, die relavant sind (und Joomla-Core-Cookies sind das nicht) gar nicht erst geschrieben werden ohne Einwilligung. Klingt blöd, aber so ist es nun mal


    Bei Maps, Facebook, Video u.ä. kann man das verhindern, indem eben ein Abfrageknopf da ist, der den (meist) Iframe erst nach Klick anzeigt. Erst dann wird ja ein Cookie geschrieben.


    Es gibt auch intelligentere Bibliotheken, leider finde ich die um's verrecken nicht mehr, die ich damals ausprobiert habe, die auf der Basis läuft, JavaScripte, IFrame (und ähnliches)-ladende zu blockieren bis eine Zustimmung erfolgt ist. Die kann dann auch vorab eingeholt werden. Das ist dann so eine Häkchen-Seuche, wo man anhakt, was erlaubt sein soll.


    Versteh allerdings seit dem ersten Tage der Diskussionen nicht, warum man das nicht den Usern überlässt ihre Browser entsprechend zu konfigurieren. Alle 1000 Seiten habe ich mal ein Problem mit einer Seite, die ein Cookie schreiben möchte und ohne tatsächlich gravierend nicht funktioniert. Für die klickt man dann halt eine Ausnahme.


    Tracking-Cookies kann man in FF bspw. ohne zusätzliches AddOn deaktivieren. Hat mehrere pauschale Sicherheitsstufen (oder filigran).


    Wäre jedenfalls besser als ein weiteres deutsches Gesetz von Leuten, die gerade mal in der Lage sind auf ihren Geräten LustigLustig-Knöpfchen zu drücken (während der Parlamentssitzungen).