Ankündigung

Einklappen
Keine Ankündigung bisher.

Google-Fonts und die Möglichkeiten Konflikte mit der DSGVO zu umgehen ....

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Google-Fonts und die Möglichkeiten Konflikte mit der DSGVO zu umgehen ....


    Moin Community



    in diesem Thread geht es um ein sehr aktuelles Thema. Es hat nur relativ indirekt mit PHP zu tun - vor allen Dingen dann wenn man z.B eine Webseite betreibt.

    Es geht um Google Fonts - und die derzeit in der Presse immer wieder berichteten Schwierigkeiten in Verbindung mit der DSGVO.

    Aber, es ist js noch viel viel umfassender: im Grunde ist das nicht nur ein Problem bloss mit Google Fonts: Ist es nicht vielmehr ein Problem mit Einbindungen aller Art.
    Ist es nicht vielmehr so: immer dann wenn etwas von US-Servern bzw. US-Diensten abgerufen wird, kriegen wie hier in Europa Stress mit der DSGVO. Es kommt nicht so sehr darauf an dass (!!!) wir was von US-Servern (oder whatever) beziehen. weil das die DSGVO interessanterweise kaum tangiert. Vor allen Dingen ist es ja so. Der Stress kommt dann, wenn personenbezogene Daten z.B. an US-Server transferiert werden.

    Bei dem Google-Fonts-Problem gehts m.E. darum, dass Website-Betreiber Inhalte aus EU-Drittländern holen bzw. sich besorgen oder man könnte auch sagen sich laden. Also kann man mit anderen Worten ja auch sagen: Im Grunde ist praktisch alles, was von extern kommt, ist erst mal ein Risiko. Und dabei ist es völlig egal, on das nun aus der EU, den USA oder aus Panama kommt.

    Es gab im Frühjahr ein Urteil bzgl. des Einsatzes von Google-Fonts: bei diesem Urteil gab es Stress wg. der Google-Fonts: Warum? Nun die die entsprechende Website hat Google Fonts genutzt und leider auch die IP-Adresse beim Abruf vom US-Dienst automatisch mit übertragen. Das hat den Stein ins Rollen gebracht. Es ist ja so: Bei jeder Verbindung zu den Google Fonts wird nämlich ebenfalls die IP-Adresse gesendet. Und genau das ist seit der Einführung der DSGVO (also seit Mai 201 nicht mehr erlaubt. Früher war das anders. Das - so kann man sagen ist jetzt nicht mehr erlaubt - und das auch deshalb, weil die betreffende Website leider vorab keine Einwilligung diesbezüglich von den Nutzern eingeholt hatte.

    Aber nun könnte man ja auch so argumentieren, dass in dem Falle ggf. eine DSGVO Verträglichkeit vorlag & vorliegen könnte. Übrigens: Der Webseitenbetreiber (in dem oben erwähnten Musterfall) argumentierte auch hier mit einem »berechtigten Interesse« im Sinne der DSGVO. Und ja: es gibt tatsächlich innerhalb der DSGVO die "Konstruktion" der Ausnahme - eines "berechtigten Interesses": Ja - man kann sagen, dass es diese Ausnahme gibt,
    Im Fall des Einsatzes von Google Fonts kann man sich aber leider nicht auf ein »Berechtigtes Interesse« nach DSGVO berufen. Es ist ja so: Die Google Fonts können problemlos heruntergeladen werden, um sie lokal einzubinden. Und wenn man das macht, dann ist der Kontakt zu den Google-Servern im Grunde genommen nicht mehr notwendig und deshalb kann man auch sagen dass demzufolge eben kein berechtigtes Interesse einer Verwendung von Daten besteht, die ihrerseits dann ggf. mit der DSGVO in Einklang zu bringen wäre.

    das Problematische daran: Also wenn wir gerade gesagt haben, dass hier Daten aus dem Ausland geholt werden, dann ist das noch nicht sehr genau beschrieben. Denn genaugenommen handelt es sich um das aussereuropäische Ausland. Steht es aber so, dann muss an sagen: außerhalb der EU bedeutet dann auch, dass es hier sehr die Frage ist, ob hier denn etwa ohne das Einverständnis der Besucherinnen und Besucher Inhalte geladen werden. Und jetzt kommt der springende Punkt: Um rechtlich hier also unproblematisch zu arbeiten, sollte man im Idealfall einfach die externe Quellen wie Schriftarten oder sagen wir - "Grafiken" ausschließlich lokal von dem eigenen Server zur Verfügung stellen. Dann wäre man auf der sicheren Seite. Dann handelt man im Grunde genommen ja auch DSGVO-konform.

    Demgegenüber: Alternativ dürften bei Aufruf einer Website im Grunde zunächst keine Inhalte wie zum Beispiel etwa Google Fonts geladen werden, sondern, wenn an auf der Sicheren Seite bleiben will, dann eben nur halt eine Basic-Standardschrift (Verdana, Times, etc.). Der Seitenbesucher- also der User - er müsste dann halt eine Einwilligung geben und dem Verfahren zustimmen. Das müsste im Grunde vorab passieren. Das wäre die Vorrausetzung für eine DSGVO-Compliance. Damit wär das Problem gewissermaßen abgefrühstückt. Und erst danach dürfen dann die entsprechenden Features (die vom Ausland) geladen werden.

    Umgehen könnt man das Problem m.E. mit mehreren - technischen - Verfahren:

    a. durch das lokale Zurverfügungstellen der Schriftarten (oder was auch immer) auf dem eigenen Server.
    b. durch „Mapping“.

    Was meint ihr denn hierzu?

    und weitergehend: Also - die Sache mit den Google-Fonts die ist so dass sie praktisch für alle (!!) Seitenbesucher gilt - also sobald ein Besucher die Seite aufruft, ist das Thema bereits "gesetzt" - m.a.W.: sobald der erste Aufruf der Seite erfolgt ist, sind wir schon mitten drinne in der Auseinandersetzung mit der DSGVO .#

    ...nicht erst, wenn er sich einloggen will oder irgendwie als "Kunde" auftritt - und sich gewissermaßen

    a, anmelden oder
    b. registrieren oder
    c. etwas kaufen will

    Stimmt das denn - haben wir es mit den Google-Fonts gewissermaßen so umfänglich und generell mit der DSGVO zu tun!?


    Viele Grüße
    Pregmatch

    und wie geht ihr mit dem Thema um!?


    Datenschutz-Grundverordnung: DSGVO als übersichtliche Seite https://dsgvo-gesetz.de

  • #2
    was ist maspping?

    und ja meines erachtens collidierd jedes nutzen eines cdn gegen die dsgvo und ist - wie leztens bei der js lücke beochtet werden konnte auch potentiell sciherheits relevant.

    zu google fonts :
    https://www.php.de/forum/php-de-inte...84#post1539484

    Kommentar


    • #3
      Zitat von pregmatch Beitrag anzeigen
      Aber, es ist js noch viel viel umfassender: im Grunde ist das nicht nur ein Problem bloss mit Google Fonts: Ist es nicht vielmehr ein Problem mit Einbindungen aller Art.
      Präziser könnte man sagen, dass es nicht um Google Fonts geht, sondern um das direkte Laden von Inhalten von einem (ausländischen/US-)Server mit der IP-Adresse eines Nutzers, ohne dass der Nutzer vorher danach gefragt wurde, ob das für ihn klar geht. Wenn man die Fonts (bzw. alles, was man dafür benötigt), die man über die statischen (cookie-losen) Google-Server beziehen kann, direkt über seinem eigenen Server bereitstellt (offline oder server-side proxy), dann ist das unproblematisch.

      Das betrifft im Prinzip dann aber auch alles, was auf diese Weise bereitgestellt wird. Beispielsweise Bilder, Javascript und CSS-Dateien über US-CDN.

      Zitat von pregmatch Beitrag anzeigen
      Umgehen könnt man das Problem m.E. mit mehreren - technischen - Verfahren:

      ...
      b. durch „Mapping“.
      Was ist mit "Mapping" gemeint?

      Zitat von pregmatch Beitrag anzeigen
      und weitergehend: Also - die Sache mit den Google-Fonts die ist so dass sie praktisch für alle (!!) Seitenbesucher gilt - also sobald ein Besucher die Seite aufruft, ist das Thema bereits "gesetzt" - m.a.W.: sobald der erste Aufruf der Seite erfolgt ist, sind wir schon mitten drinne in der Auseinandersetzung mit der DSGVO .#

      ...nicht erst, wenn er sich einloggen will oder irgendwie als "Kunde" auftritt - und sich gewissermaßen

      a, anmnelden oder
      b. registrieren oder
      c. etwas kaufen will
      Ja. Was die Seite (technisch) tut, ist unabhängig davon, was man als Besucher auf der Seite tun kann.

      Zitat von pregmatch Beitrag anzeigen
      Stimmt das denn - haben wir es mit den Google-Fonts gewissermaßen so umfänglich und generell mit der DSGVO zu tun!?
      Ich bin kein Anwalt und kann diese Frage nicht definitiv beantworten.

      In gewisser Weise (und meinem bisherigen Verständnis nach) wohl ja. Denn die DSGVO behandelt in erster Linie personenbezogene Daten und nicht Cookies. In wie fern eine IP-Adresse ein personenbezogenes Datum ist und in wie fern die Weitergabe an einen amerikanischen Server in diesem Sinne einen Verstoß gegen die DSGVO darstellt, müssen erst mal Gerichte einordnen. Bei Cookies war der Punkt ja, dass ein Profil von einem User über 3rd-Party-Cookies auf verschiedenen Seiten zugeordnet werden kann und der (anonyme und nicht anonyme) Nutzer, sowie sein Verhalten dadurch in gewisser Weise im Netz beobachtet werden kann, was beispielsweise für Werbezwecke genutzt werden könnte. Das geht bei einer IP-Adresse so erst mal nicht, aber das ist auch nicht unbedingt der Punkt.

      Ich glaube, da gibt es keine einfachen Antworten drauf. Ich sehe hier grundsätzliche Schwierigkeiten einen tatsächlichen Schaden zu definieren. Wenn das individuelle Unwohlsein am Ende tatsächlich reichen sollte, um hunderte Euros aus einem Webseitenbetreiber zu pressen, dann wird es interessant.

      Zitat von pregmatch Beitrag anzeigen
      und wie geht ihr mit dem Thema um!?
      CSR wird mEn bei größeren Projekten ein zunehmend wichtiges Thema. Die Offline-Bereitstellung von Inhalten sollte bevorzugt gemacht werden, wenn möglich.

      Kommentar


      • #4
        Soweit ich das Urteil verstanden habe, geht es nicht um US-Americanische Seiten, sondern um die Informationelle Selbstbestimmung, welche verletzt wird, da die Weitergabe der IPAdresse an dritte ohne Rechtfertigungsgrund erfolgt.
        dass in der Begründung etwas von US-amerikanischen Seiten und dem eigenwilligen Verständniss des Datenschutzes dort steht, ist richtig.

        Allerdings gebe ich hier zu bedenken, das Google schon mehrere Initiativen zum Datenschutz gestartet hat, wohl angefangen mit der HTTPS Pflicht.

        Bei Cookies war der Punkt ja, dass ein Profil von einem User über 3rd-Party-Cookies auf verschiedenen Seiten zugeordnet werden kann und der (anonyme und nicht anonyme) Nutzer, sowie sein Verhalten dadurch in gewisser Weise im Netz beobachtet werden kann,
        inwieweit man auch mit fonts tracken kann, diese diskussion will ich hier mal nicht anreissen.

        doch tracking ist es eine andere Geschichte und Google versucht da ja schon länger was dran zu ändern und hätte sich auch schon von Cookies verabsschiedet, (geplant für anfang 2020) wenn die Werbeindustrie in der lage gewesen wäre sich mit fledge https://developer.chrome.com/docs/pr...andbox/fledge/ auseinander zu setzen.
        Es bleibt spannend ob die Marktmacht von Google gros genug ist das durchzusetzen.

        Abmahnungen und Schadensersatz hat eine lange und sehr unrühmliche Tradition im Internet rkr .
        Die Sache mit den Fonts war wesentlich vorhersehrbarer als vieles andere, ein professioneller WebDeveloper hat das kommen sehen müssen.

        Kommentar


        • #5
          hallo und guten Morgen Tom und rkr,

          vorweg: hab im Mom. grad wenig Zeit. Aber bin sehr dankbar dass ihr geschrieben habt - und das gleich so viel. So viele Ideen und Anregungen. Werde die später durchlesen.
          Zum Thema Mapping. Hab das wo gelesen. Werde dazu hoffentlich später noch schreiben können.

          VG Pregmatch

          update: bezogen auf Wordpress gibts nun noch Neuigkeiten:

          Sarah Gooding hat in einem neuen Artikel ein sehr wichtiges Thema aufgenommen. "WordPress Punts Locally Hosted Fonts for Legacy Default Themes to 6.2 Release" https://wptavern.com/wordpress-punts...to-6-2-release

          Sarah (Zitatanfang) "Im Juni 2022 begann das Theme-Team von WordPress.org, Theme-Autoren nachdrücklich zu drängen, auf lokal gehostete Webfonts umzusteigen, nachdem ein deutsches Gerichtsverfahren gegen einen Website-Eigentümer eine Geldstrafe wegen Verstoßes gegen die DSGVO durch die Verwendung von von Google gehosteten Webfonts verhängt hatte. Seit Jahren binden Themenautoren Google Fonts aus dem Google CDN ein, um eine bessere Leistung zu erzielen, aber diese Methode legt die IP-Adressen der Besucher offen.

          Anm.: einer der Auslöser der Aktionen zu den Google-Fonts-Arbeiten war das Urteil des LG München vom 20. Januar diesen Jahres. Am 20.01.2022 hat das LG München in einem Urteil festgestellt, dass eine Einbindung von Fonts über die Google-Schnittstelle nicht datenschutzkonform ist.
          https://www.gesetze-bayern.de/Conten...-N-612?hl=true

          Das Theme-Team warnte davor, dass sich die Richtlinien zum lokalen Hosten von Schriftarten unmittelbar ändern werden und viele Theme-Autoren sich daran halten, bevor dies zur Pflicht wird.

          Ein Ticket für die Bündelung von Google-Schriftarten mit den alten Standardthemes von WordPress hatte Patches und sollte im November in WordPress 6.1 aufgenommen werden. WordPress-Mitarbeiter Hendrik Luehrsen bat um mehr Aufmerksamkeit für das Ticket und sagte, dass es „direkt das WordPress-Kernpublikum in Deutschland betrifft“. Er berichtete, dass Nutzer in Deutschland immer noch E-Mails mit Bußgeldandrohungen für die Verwendung von von Google geladenen Schriftarten erhielten.

          WordPress-Core-Committer Tonya Mork schlug vor, die aktualisierte Version jedes Themes separat von WordPress 6.1 zu veröffentlichen.„Wenn jedes Theme fertig ist, veröffentlichen Sie es im Theme-Repo von wp.org“, sagte Mork. „Benutzer können dann aktualisieren, um lokal gehostete Schriftarten zu erhalten, bevor WP 6.1 veröffentlicht wird.“

          Dadurch änderte sich die Richtung des Tickets und bei genauerer Prüfung stellten die Mitwirkenden fest, dass die Patches etwas mehr Arbeit vertragen könnten.

          „Das Erstellen neuer Themeversionen für diese spezielle Änderung könnte gut sein, wenn sie fertig sind“, sagte Stephen Bernhardt. „Die Verwendung lokal gehosteter Schriftarten wird bereits empfohlen, aber wir müssen unsere eigenen Themesreparieren, bevor wir dies zu einer Anforderung für andere machen können.“ Er hat eine Liste mit Problemen und potenziellen Verbesserungen eingereicht, nachdem er die Patches überprüft hat, und die Mitwirkenden arbeiten an einem besseren Ansatz.

          WordPress Core Committer David Baumwald änderte den Meilenstein auf 6.2, da Beta 2 für 6.1 gestern veröffentlicht wurde und das Ticket noch eine endgültige Richtung und einen Patch benötigt.

          „Obwohl ich das Problem verstehe, ist es dennoch traurig zu sehen“, sagte Luehrsen. „Dies ist in Deutschland (und anderen DSGVO-Gebieten) immer noch ein ernstes Problem, da Benutzer mit aktiven Google Fonts derzeit von Personen ins Visier genommen werden, die das Gesetz ausnutzen.“
          Luehrsen ging zu Twitter, um seine Enttäuschung darüber zu kommentieren, dass das Ticket das Fenster für 6.1. „Das ist der Grund, warum WordPress wahrscheinlich an Relevanz verlieren wird“, sagte er. „Echte Benutzer werden hier verletzt, aber sie befinden sich in DSGVO-Gebieten und das scheint nicht wichtig zu sein. „Hätte ich mehr tun können? Wahrscheinlich. Aber es ist etwas traurig zu sehen, wie schnell der Schwung auf diesem Ticket verpufft ist. Wenn Squarespace, Wix und Co. anfangen, Datenschutz gegen WordPress zu vermarkten, sind wir in den DSGVO-Ländern am Arsch.“

          In der Zwischenzeit können diejenigen, die die Standardthemes von WordPress verwenden, ein Plugin wie Local Google Fonts oder OMGF | verwenden DSGVO/DSVGO-konform, schnellere Google Fonts zum lokalen Hosten von Schriftarten.
          Benutzer können auch zu Bunny Fonts wechseln, einer Open-Source-Web-Font-Plattform, bei der der Datenschutz an erster Stelle steht, ohne Tracking oder Protokollierung, die vollständig DSGVO-konform ist. Bunny Fonts ist mit der Google Fonts CSS v1 API kompatibel, sodass es als Drop-in-Ersatz fungieren kann. Das Plug-in „Google Fonts with Bunny Fonts ersetzen“ macht es Benutzern leicht, dies zu tun, ohne den Designcode zu bearbeiten. Mitwirkende arbeiten daran, vollständig DSGVO-konforme WordPress-Standarddesigns für WordPress 6.2 bereit zu haben, das Anfang 2023 erwartet wird."

          Sarah (Zitatende) aus dem Artikel "WordPress Punts Locally Hosted Fonts for Legacy Default Themes to 6.2 Release" https://wptavern.com/wordpress-punts...to-6-2-release

          weitere Links zum Thema:

          wordpress-org-strongly-urges-theme-authors-to-switch-to-locally-hosted-webfonts
          https://wptavern.com/wordpress-org-s...osted-webfonts

          german-court-fines-website-owner-for-violating-the-gdpr-by-using-google-hosted-fonts
          https://wptavern.com/german-court-fi...e-hosted-fonts

          Am 20.01.2022 hat das LG München in einem Urteil festgestellt, dass eine Einbindung von Fonts über die Google-Schnittstelle nicht datenschutzkonform ist.
          https://www.gesetze-bayern.de/Conten...-N-612?hl=true

          wordpress-theme-authors-are-moving-to-host-fonts-locally
          https://wptavern.com/wordpress-theme...-fonts-locally


          bezogen auf WordPress:

          Also, die Idee, das mit einem Plugin umzusetzen, die hab ich hier auch schon des Öfteren gelesen, Das ist mir auch schon in dem ein oder anderen Thread hier begegnet. Die Alternative - das Einbinden de Fonts zu Fuß ist mir auch schon eingefallen. Ich hab mich mal umgeguckt und mir einen kleinen Plan zurechtgelegt. Weil es mir hilft, wenn ich diesen für mich zurecht gelegten Plan mal aufschreibe - hab ich gedacht dass ich das am besten mal mache - und hier in diesem Thread ists vielleicht am allerbesten. Also hier die Schrittfolge, mit der ich nächstens an meine Seiten gehe - um die Google-Fonts selber und lokal zu hosten:

          - Identifizieren der entsprechenden Fonts (die wir von Google beziehen) hier gibts mehrere Möglickeiten.
          - Herunterladen der Fonts
          - Hochladen auf den Server
          - Ändern der CSS - diese Daten dann einbinden, am besten via Child-Theme
          - deaktivieren der Fonts (entweder via Plugin oder auch mittels Skript)
          - finale checks durchführen und gucken ob wir wirklich alles lokal haben und keine Fonts mehr von Google eingebunden werden.

          Also es geht los: Zuallererst muss man halt gucken, welche Google Fonts die Seite (also das Theme oder ggf. auch der Plugin) wirklich aufruft und einbindet. Das kann man mit den Entwickler-Tools unter Chrome super gut machen. Also damit lassen sich die Fonts gut identifizieren.
          Man kann die Einbinden der Google-Fonts und die Details rausfinden - zum Beispiel mit der Entwickler-Konsole. Man kann also auch in der Entwickler-Konsole im Browser nachschauen, welche Google Fonts geladen werden. Wenn man die Untersuchungstools geöffnet hat, findet sich auf der rechten Seite die Überblicksdaten. Dort kann man dann gucken im dem Tab „Sources“. Das gute daran: hier kann man alle Quellen sehen, die die Website nutzt, um Ressourcen zu laden. Die Google Fonts - die verbergen sich unter folgenden Kategorien: und hier mach ich mal ein Beispiel: hier z.B.

          das Beispiel-Theme bei dieser Betrachtung: https://jobify-demos.astoundify.com/classic/

          hier werden die Fonts geladen via
          - fonts.gstatic.com
          - fonts.googleapis.com

          Ich muss schon zugeben: bis jetzt hab ich mich eigentlich eher sehr wenig mit den Google-Fonts beschäftigt. Also ganz ehrlich gesagt, wusste ich noch nicht einmal, welche Google Fonts ich mit meiner Seite überhaupt benutze: Aber seit dem die Google-Fonts wieder in aller Munde sind hab ich mich bemüht da etwas mehr zu erfahren. Und nun ist der allererste Schritt für mich der, zu gucken welche Fonts bei mir eine Rolle spielen - um welche es genau geht: Ich muss also erstmal eine Bestandsaufnahme machen und die Fonts gewissermaßen identifizieren.

          Und hier gehts schon los: Es gibt zum Glück gleich hier an dieser Stelle eigentlich auch mehrere Möglichkeiten, genauer zu schauen und auch herauszufinden was auf der Seite für Google-Fonts eingebunden werden. Weil es aber so ist, dass Google Fonts im Grunde über verschieden Wege (Pfade) eingebunden werden können gibt es auch bei diesem Schritt mehrere Möglichkeiten.

          bei Plugins: Wenn man z.B. ein extra Plugin einsetzt, welches die Google Fonts einbindet kann man sich dieses zu Hilfe nehmen und dort nachsehen: Dort orientiert, finden sich die Schriftarten - man guckt einfach in den Einstellungen des entsprechenden Plugins nach. Dort im Dashboard gibts Orientierungshilfen. Dort stehen in einer Extraabteilung die Google-Fonts meistens drinne.

          bei Themes: sehr sehr oft werden Google-Fonts-Schriften halt über ein spezielles Theme eingebunden. Hier findest du die eingebunden in Schriften in den Einstellungen des Themes oder über den Customizer (Design → Customizer → Fonts).

          Wenn man in diesem Zusammenhang dann auch herausgefunden hat, welche Fonts man konket brauchst, dann muss halt auch diese dann auch noch besorgen. Das Tolle: hier gibt mittlerweile auch sehr schönes Tools - ( z.B. Google Webfonts Helper ), die einem dann bei dieser Aufgabe helfen und die benötigten Dateitypen für die jeweiligen Google Fonts zur Verfügung bringen.
          Also - nachdem wir genau geguckt haben welche Fonts wir brauchen - welche in die Seite eingebunden werden, müssen wir, wenn wir die lokal hosten wollen die auch holen. Also ist das der nächste Schritt: wir besorgen die Fonts!

          Wenn wir die Fonts downgeloaded haben - dann müssen wir die einbinden und am Ende dann noch dem CSS sagen wo die Fonts liegen. Also mit anderen Worten dann muss das alles noch dem Code mitgeteilt werden, damit die aufrufenden Browser unserer Seitenbesucher dann auch im Grunde wissen wo die (Google-Fonts) Dateien sind.

          Es bietet sich hier an, das Notwendige hier über ein sogenanntes Child-Theme zu arrangieren. Ich jedenfalls würde ein Child theme anlegen - und wenn das dann angelegt ist, dann alles in die style.css-Datei des Child-Themes reinschreiben. Das hat den großen und meiner Meinung nach auch entscheidenden Vorzug, dass die notwendigen Änderungen auch nach dem Update deines WordPress-Themes noch bestehen bleiben. Das mit dem Child-Theme ist sowieso eine tolle und auch ansonsten wichtige Sache.

          Wenn das passiert ist, dann muss man lediglich nur noch die Verbindung zu Google Fonts deaktivieren - sodass eben sichergestellt ist. dass keine Fonts mehr von Google eingebunden werden. Also kurz gesagt müssen wir nun noch in einem weiteren Schritt jetzt auch die Verbindung zum Google Server kappen oder anders gesagt "trennen" - denn jetzt hosten wir ja lokal und die Schriften sind ab jetzt dann auch lokal eingebunden. ...

          ..wenn ich auf meinen Plan gucke, dann kommt jetzt folgendes - das Deaktivieren

          Das Deaktivieren: also es ist so, wenn man die etwa Fonts und Schriftarten über ein spezielles WordPress-Plugin eingebunden hat, dann würde es m.E. ja auch ausreichen, wenn man hergeht und dieses zu deaktiviert. Aber viele viele Leute binden die Fonts über ein WordPress-Theme ein; Hier muss nun ein extra Weg beschritten werden - es muss versucht werden, die Schrift-Optionen im jeweiligen Theme selber zu löschen.

          Das kann man mit einem kleinen Code-Snippet zum Beispiel machen: Ich hab mich mal umgesehen und mehrere Sachen gefunden - die ich zugegebenermaßen noch nicht selber ausprobiert habe. Da muss ich selber noch ausprobieren, was am besten passt:

          Was ich gefunden habe waren diese folgenden Sachen:

          Code:
          if ((strpos($href, "//fonts.googleapis.com/") === false) || !is_page(12345)) {
          Where you should replace 12345 with the ID or slug of the page you want to exclude.

          https://wordpress.stackexchange.com/questions/361524/how-to-remove-google-font-in-wordpress-for-only-single-page

          Code:
          wp_enqueue_style( 'olsen-light-style', get_template_directory_uri() . '/style.css', array(
                 // 'olsen-light-google-font',
                 'olsen-light-base',
                 'olsen-light-common',
                 'font-awesome',
                 'olsen-light-magnific',
                 'olsen-light-slick',
                 'olsen-light-mmenu'
             ), $theme->get( 'Version' ) );
          Commenting out line 108 and line 99 (registering the font) works, but breaks update possibility.
          siehe auch: https://wordpress.org/support/topic/how-can-i-remove-the-google-fonts/

          Code:
          function _remove_google_fonts() {
              wp_deregister_style( 'olsen-light-google-font' );
                 wp_register_style( 'olsen-light-google-font', '');
          }
          add_action( 'wp_enqueue_scripts', '_remove_google_fonts', 120 );
          [
          Inwieweit diese Snippets hier gut weiterhelfen, das kann ich im Moment leider noch nicht sagen. Das müsste ich selber noch austesten und probieren. Die obengenannten Snippets, die hab ich bei einer Recherche gefunden: die ich zugegebenermaßen noch nicht selber ausprobiert habe. Da muss ich selber noch ausprobieren, was am besten passt:

          Wenn ich dann weitergehe dann kommen noch ein paar Schritte, die ich entsprechend meines Planes noch abarbeiten muss:
          Und ganz ganz am Ende müsste man dann sinnvollerweise noch einmal prüfen ob nun wirklich auch alle Google Fonts lokal geladen werden.

          Wie ganz oben beschrieben könnte man diesen Schritt nun auch wieder zweckmäßigerweise über die Entwicklerkonsole des Browsers (ich verwende meistens halt Chrome, weil es einer der genialsten Browser überhaupt ist) und finde hier immer unter den Reitern „Sources“ mit dem entsprechenden Filter „Fonts“ ob denn jetzt an dieser Stelle (also wenn wir uns die ganze oben beschriebene Arbeit schon gemacht haben und alle (!) Schritte einzeln und der Reihe nach durchlaufen haben, ob denn nun jetzt immer noch von Google Schriften geladen werden. Das ist gewissermaßen die Probe aufs Exempel. Jetzt muss sich weisen ob wir alles sauber gearbeitet haben.

          An dieser Stelle kann es hilfreich sein auch darauf zu achten, dass der Browsercache geleert ist - denn manchmal stört dieser- etwa indem er, nicht den aktuellen CSS Code verwendet sondern vllt. noch einen alten CSS-Code.

          Wie gesagt - ich bin noch selber am Einarbeiten - ich hab die Arbeit mit dem Lokal hosten der Google-Fonts noch vor mir. Und wie ganz oben gesagt: weil es mir hilft, wenn ich diesen für mich zurecht gelegten Plan mal aufschreibe - hab ich gedacht dass ich das am besten mal mache - und hier in diesem Thread ists vielleicht am allerbesten. Also deshalb habe ich hier die Schrittfolge, mit der ich nächstens an meine Seiten gehe - um die Google-Fonts selber und lokal zu hosten mal aufgeschrieben.

          Freue mich von Euch wieder zu lesen.


          Also zusammenfassend: Hier für alle für mich wichtigen Ideen - nochmals in der Übersicht. Nebenbei bemerkt: Mit diesem Tools kann man google-fonts gut herunterladen - wenn man sie selber hosten will.

          https://www.ccm19.de/google-fonts-checker/

          zeigt die Google-Fonts und darüber hinaus auch noch
          #.... Weitere kritische Ergebnisse der Seite:
          #... etwa wenn ungefragt kein Cookie gesetzt wird
          oder aber wenn Daten von x fremden Domains eingebunden werden.. usw. usf

          .....ferner noch diese Seite: https://sicher3.de/google-fonts-checker/

          wenn man dann identiftziert hat, welche Fonts hier von Google kommen, dann kann man diese von Google holen:

          ich halte hier das Tool für sehr hilfreich: https://google-webfonts-helper.herokuapp.com/fonts

          wie her bemerkt wird: https://kopfundstift.de/google-fonts-lokal-einbinden/

          Und deine benötigte Schrift herunterzuladen, gibst du einfach in das Suchfeld (oben links in der Ecke) die gewünschte Schrift ein. Danach wählst du die jeweiligen Zeichensätze und Schriftschnitte aus. Unter dem Punkt 3 solltest du noch den Dateipfad angeben, indem du die Schriften später auf deinen Server laden solltest. Das kleine Tool wird die CSS Datei dahingehend anpassen.
          also das Tool hier: https://google-webfonts-helper.herok...?subsets=latin

          3. Copy CSS: (default is Best Support)
          Modern Browsers
          Choose Best Support if old browsers still need to be supported. Formats in this snippet: [eot,woff,woff2,ttf,svg]

          Code:
          /* montserrat-regular - latin */
          @font-face {
            font-family: 'Montserrat';
            font-style: normal;
            font-weight: 400;
            src: url('../fonts/montserrat-v25-latin-regular.eot'); /* IE9 Compat Modes */
            src: local(''),
                 url('../fonts/montserrat-v25-latin-regular.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
                 url('../fonts/montserrat-v25-latin-regular.woff2') format('woff2'), /* Super Modern Browsers */
                 url('../fonts/montserrat-v25-latin-regular.woff') format('woff'), /* Modern Browsers */
                 url('../fonts/montserrat-v25-latin-regular.ttf') format('truetype'), /* Safari, Android, iOS */
                 url('../fonts/montserrat-v25-latin-regular.svg#Montserrat') format('svg'); /* Legacy iOS */
          }
          und nun lässt sich noch der Pfad anpassen: Customize folder prefix (optional):

          Code:
          ../fonts/
          ehe es dann zum Download kommt...
          Click on code to select all statements, then copy/paste it into your own CSS file.
          Wenn man das dann heruntergeladen hat und alles auf den eigenen Server geladen hat - dann muss man noch die CSS auf der Webseite anpassen.

          die Schriftarten noch in eigene CSS einbinden. Und genau dafür hat uns ja das oben erwähnte Google Webfonts Helper Tool im Grunde schon den nötigen CSS Code besorgt - den konnten wir (wie oben ja beschrieben) customized und angepasst herunterladen.

          Nun kommt es darauf an, genau diesen Code einfach in die style.css-Datei einzubinden. Es ist meines Erachtens wichtig, dass wir - wenn wie auch ein Child-Theme verwenden, dann das auch die entsprechenden Änderungen auch nach dem Update deines WordPress-Themes machen.​​


          Abschließend: es gibt verschiedene Methoden und Ansätze die Fonts lokal zu hosten
          ohne Plugin - oder mit Plugin

          a. ohne Plugin:


          1. Google Fonts lokal in WordPress nutzen
          https://www.webtimiser.de/webfonts-lokal-in-wordpress/

          2. How to Host Google Fonts Locally in WordPress? (2 Methods)
          https://wpbuildermaster.com/host-google-fonts-locally/

          3. google-webfonts-helper: Get eot, ttf, svg, woff and woff2 files + CSS snippet
          https://google-webfonts-helper.herok...?subsets=latin

          4. How to Host Google Fonts Locally in WordPress?
          https://www.wplogout.com/host-google...lly-wordpress/

          5. In-Depth Guide on Hosting Local Fonts in WordPress
          https://kinsta.com/blog/local-fonts/

          6. How To Easily Host Google Fonts Locally In WordPress
          https://staxwp.com/how-to-easily-hos...-in-wordpress/



          b. mit Plugin:

          google-fonts: Local Google Fonts By EverPress
          https://wordpress.org/plugins/local-google-fonts/
          Version:0.19 Last updated:2 weeks ago Active installations:70,000+ WordPress Version:4.6 or higher Tested up to:6.1.1


          Hoffe, die Infos helfen ...

          Kommentar


          • #6
            leider dominiert leider pregmatch inzwischen #offtopic, so dass es wirklich schwer ist darin äöltere gesprächsfänden zu finden.
            mir wäre recht wenn die "infos" auf vier bis fünf themen thredas eingeschränkt und dort immer wwieder aktualisiert werden.
            muss denn wirklich zu jedem nuen nwordpress dingsn ein neuer thread gestartet werden - denk mal sozial !

            aber zurück zu den fonts :

            https://www.heise.de/news/Cloudflare...n-9319103.html

            cloudflare infos dazu :

            https://blog.cloudflare.com/rust-nginx-module/

            jetzt stellt sich mir natürlichg die frage, was speichert cloudflare - die meistens nutzen ja inzwischen cloudflare wegen soetwas :

            https://www.cloudflare.com/de-de/net...ices/products/

            Kommentar


            • #7
              servus tombuilder

              vielen Dank! Danke dass du geschrieben hast. Ja das kann ich einsehen. Das ist kein Problem.

              leider dominiert leider pregmatch inzwischen #offtopic, so dass es wirklich schwer ist darin äöltere gesprächsfänden zu finden.
              mir wäre recht wenn die "infos" auf vier bis fünf themen thredas eingeschränkt und dort immer wwieder aktualisiert werden.
              muss denn wirklich zu jedem nuen nwordpress dingsn ein neuer thread gestartet werden - denk mal sozial !
              kein Problem - das geht i.O.

              Dir einen schönen Tag.

              VG Pregmatch

              Kommentar

              Lädt...
              X