Beiträge von Synonym

    Danke euch schon mal. Ich habe aber wirklich keine Erklärung dafür. Noch nicht mal, dass Clarity "Beta" ist. Denn selbst da, sollten gleiche Layouts und gleiche Scripte ja gleich aussehen. Habe das aber entgegen der Vernunft ignoriert und dann eben vorhin hier selbst gesehen (FF 88.0).

    Ich bekomme das nicht gebacken, wie die Bilder entstehen können oder eben das, was ich selbst auf meinem Schirm hatte. Das ist eine Mischung aus mehreren CSS-Klassen. Die eine, die den grauen Rahmen da macht, der falsch ist, die müsste auch einen grauen Hintergrund machen. Tut sie aber nicht. "Grau" = Tablet-CSS. Da müsste die Navi aber auch horizontal über dem Content sein und nicht links daneben, denn das ist Desktop. Die Maps werden völlig falsch aufgezeichnet und die Farben darüber, im DIV "Filter" fehlen komplett. Darunter im DIV "Sortierung" sind die richtig. Das ist die gleiche CSS-Klasse !!!

    Und dazu kommt eben, was mich sehr stutzig macht. Ich habe nun Absprungraten von 8-12 Sekunden.

    Nun muss ich doch mal einen Fred dazu aufmachen. Eigentlich dachte ich, das ist ein Fehler von Clarity, aber just vor 30 Minuten habe ich das in meinem Firefox selbst gesehen, jedoch nur EINMAL !!!

    Wie man sieht, ist da alles völlig falsch. Hatte ich bisher nicht, Clarity zeichnet das aber schon seit Wochen auf. Aber nur auf der Domain und bei keiner anderen sonst, die die gleichen Scripte und Layouts benutzen. Wie gesagt, vorhin hatte ich das selbst so auf dem Schirm und habe keinen Schimmer warum.

    Kann das von euch mal bitte einer testen, gerne mit vielen unterschiedlichen Browsern?

    Edit: URL vergessen ^^

    https://www.ferien-netzwerk.de/unterkuenfte/a…/seite_1_1.html

    So sollte es aussehen, also eben völlig anders.:

    Das dachte ich mir auch Cura. Am 9.5. macht Bayern wieder auf, für Genesene oder doppelt Geimpfte. Also Kino, Hotel, Gastro etc. Finde ich auch zu früh. Aber wer schrieb das auf FB, warst das Du oder CatCat? Wer am lautesten schreit, der wird gehört?

    Also Clarity kann aber auch wahnsinnig machen..... Dachte schon ich hätte mein System zerschossen, aber nein, läuft hier alles normal. Clarity baut den Mist aber nur bei einer Seite, bei den anderen nicht.


    Und ja Alex, Du wirst nun gleich wieder sagen "BETA". Stimmt, aber auch in einer Beta sollen beide Domänen gleich sein, wenn sie den gleichen Code verwenden. Zumal die Navi da ganz komisch ist. Diese grauen Rahmen gibt es nur in der Tablet-Ansicht, wobei dort aber auch der Hintergrund grau ist und nicht weiß. Weiß gibt es nur bei Desktop. Oder in der Navi bei Allgäu / Ostallgäu / Westallgäu. Auf dem Desktop ist das "inline" und schwarze Schrift. Diese Blockansicht mit blauer Schrift ist ebenfalls Tablet. Wobei da aber Ost- und Westallgäu links 20px eingerückt sein müssten, sind sie hier aber nicht. Wie kommen die also auf den Style? Das ist weder Tablet noch Desktop, das ist eine Mischung aus beidem.

    Naja, das ist aber sein Vorhaben, daher sage ich, da liegt der Denkfehler. Er will ja die ganze URL aus der Sitemap im Index haben, also die http://index.php/page=irgendwas. Wenn die drinnen wären, dann würden die alle über die index.php laufen und erfasst werden. Zwar auch nur als counter.php, aber erfasst.

    Nur die Seiten werden halt wegen der Weiterleitung nie in den Index kommen.

    Also ist da ein Denkfehler. Beides zusammen geht nicht, das eine schließt das andere aus.

    Da gibt es auch nicht wirklich einen Sinn außer, dass es den kompletten Seitenabruf stört, die Indexierung und die Ladezeit. Matomo selbst würde ja auch nur einmal tracken, aber halt eben mit "User-Bewegung" über die Seiten hinweg. So gesehen ist die Statistik ja auch nutzlos.

    Nee, in der steht nix, also in der httpd.conf. Meine Anweisungen selbst sind in der vhost.conf, htaccess nutze ich gar nicht.

    Die Reihenfolge müsste Server -> PHP sein.

    Aber Du bringst mich gerade auf eine Idee. Einen "unset" in PHP senden. Denn der erste kommt ja von Apache, der zweite dann von PHP. Lösche ich den in PHP dann schickt php aber auf Grund der Session automatisch ein "cache-control: no-cache" raus. Vielleicht schicken die vorher ja auch einen "unset"? Würde erklären, warum der dann nicht doppelt ist und beide eigentlichen weg sind.

    Erste Frage ja, denn das ist ja genau das, was doppelt ist. Also in der htaccess steht es ohnehin drinnen (cache-control an, Etag aus), in PHP in dem einen Script auch, nur eben in unterschiedlicher Reihenfolge, also das "must-revalidate, proxy-revalidate, private". Wenn ich aber in PHP die Anweisung entferne, dann ist die von Apache auch weg. Dann kommt "cache-control: no-cache" (wohl durch die PHP-Session).

    Den Rest muss ich erst testen.

    Aber doch genau da liegt doch der Denkfehler! Über die index.php?page=xxx Seiten, also denen aus der Sitemap, wird kein Besucher kommen, denn die sind nicht im Index. Das war doch Deine erste Frage. Die Seiten werden auch nicht in den Index kommen, denn es sind Weiterleitungen.

    ^^ So mache ich das auch, aber in Deutsch halt. Anrufen lassen, nebenhin legen. Dann kommt der nächste Anruf und wieder das gleiche Spiel. Finde das immer witzig, denn der Lautsprecher ist ja an, das Mikro nur aus.

    Das mit dem Script habe ich mir auch schon überlegt, schon vorher. Hat einen Nachteil und nun eigentlich zwei.

    1. Nicht alle können Scripte einbinden. Ich bin schon froh, dass die meisten dieser Baukästen inzwischen IFrame können

    getestet habe ich das aber dennoch, vor meinem Thread hier als extra Script, das eben senden soll, wo es aufgerufen wurde. Ausgeliefert im IFrame.

    2. Problem: Das geht auch nicht, denn das Script (AJAX) unterliegt auch dem "strict-origin-when-cross-origin", denn er ruft ja Daten von extern ab.

    Mein Versuch war daher eher in die andere Richtung. Extra Script, dessen Referrer mir völlig egal ist, das dann die URI schnappt, verschlüsselt und zurückschickt. Das könnte theoretisch gehen, wäre aber ein gänzlich anderer Programmablauf als jetzt und es müssten alle 50.000 Kalender geändert werden, also nicht die Kalender, sondern die Codes für IFrame + Script. Und eben auch das Problem, dass viele das dann gar nicht eingebunden bekommen, also IFrame und Script.

    Und der Programmablauf wie gesagt auch völlig anders. Aktuell ist es ja so, dass da eine Anfrage an meine Kalender.php reinkommt. Die schaut nach, wann der Kalender das letzte mal geprüft wurde. Ist es älter als 7 Tage, dann wird erst erneut geprüft (URL vom Referrer), dann ausgeliefert, wenn alles ok ist. Mit einem extra Script müsste das ausgelagert werden, eine Art Liste, die dann abgearbeitet werden muss, denn einen direkten Zusammenhang zwischen Kalender ausliefern und testen gibt es dann ja nicht mehr.

    Irgendwie ist das alles doof. Die mit ihrem Datenschutzwahnsinn immer.

    Teilweise richtig verstanden. Die Kalender werden per iFrame irgendwo eingebunden. Alles was ich möchte ist zu wissen wo, damit mein System dann prüfen kann, ob das so auch passt und den Bedingungen entspricht. Der Kalender selbst tut nichts, das ist nur eine Ansicht.

    Bisher kein Problem, sobald der angezeigt wird kommt der Referrer http://domain.de/seite-x und zack, ich hab ihn. Nun kommt halt nur noch domain.de/. Und da läuft das System dann hohl, weil es den Kalender eben auf domain.de/ sucht und nicht findet. Klar, die Pfad-Angabe fehlt ja.

    Dein Link da ist genau das Problem, denn seit der Änderung fehlt eben der Pfad. Firefox änderte das so ca. vor 6 Wochen. Ich kann zwar dem iFame selbst ein referrerpolicy="no-referrer-when-downgrade" mitgeben (vorheriger Default-Wert), aber das bringt nicht viel, denn das kann ja jeder Nutzer einfach entfernen oder ändern. Und viele nutzen auch Joomla, Typo3 oder sonst was und deren Wrapper, also sind da meine Vorgaben eh futsch.

    Sagt mal, gibt es irgendeinen Weg, das strict-origin-when-cross-origin bei iFrames zu umgehen, also dauerhaft, ohne dass der User, der das einbindet, was ändern kann?

    Bisher war der Default-Wert der Referrer-Policy ja immer "no-referrer-when-downgrade". Er wurde also vollständig gesendet, wenn das Ziel das gleiche Schema (beide SSL oder beide nicht oder eben das Ziel ein besserer hatte) hatte. Das war unabhängig ob es der gleiche Host ist oder nicht.

    Das wurde nun geändert, erst bei Chrome, dann bei Edge und nun bei Firefox. Neuer Default-Wert ist nun "strict-origin-when-cross-origin" und der sendet nur noch vollständig, wenn es der gleiche Host ist. Bei cross-Origin kommt nur noch als Referrer der "Origin", aber kein Path mehr.

    Für mich mit meinen 50.000 externen Kalendern ganz schlecht, denn ich kann quasi keinen mehr erfassen, denn es kommt ja nur noch der Host als Referrer zurück und nicht mehr die eigentliche Seite.

    Das mit den Weiterleitungen wird noch abstrakter bzw. einen Teil hat er ja schon raus. Aber alleine die Startseite.

    "https://tamara-martin.ch" Das ist ja eigentlich das Ziel, denkt man

    Die leitet aber per 301 weiter an "https://www.tamara-martin.ch" . Genau die hat Google im Index mit einem Text, den es nur dort gibt.

    Diese wiederum leitet aber weiter an "https://www.tamara-martin.ch/wp/" und das per JAVASCRIPT!

    Die dann sendet wieder einen 301 an die "https://tamara-martin.ch/wp/" Juhu, wir sind am Ziel.

    Warum dann also die "https://tamara-martin.ch" nicht gleich per 301 an die "https://tamara-martin.ch/wp/" ist ein ungelöstes Rätsel. Google hört jedenfalls bei der JS-Weiterleitung auf zu folgen.

    Und eben noch dazu, dass in der Sitemap wieder ganz andere Ziele stehen, die noch eine weitere Umleitung auslösen.