Das Plugin bs-Cookie-Settings selbst liefert nur die Cookie-Abfrage. Wie man die aktiviert, hatte ich bereits beschrieben. Die entsprechende Semantik zu implementieren, sieht bootScore als Aufgabe der jeweiligen Web-Designerin. Hier eine Variante, die gern allgemein wiederverwendet werden darf:

Lösung

• Lade die JS-Cookie-Bibliothek von z.B. cdnpkg.com herunter und lege sie (entpackt) unter dem Namen js/js.cookie.min.js in Deinem Child-Theme-Ordner ab.
• Erweitere in Deiner Datei functions.php die Funktion bootscore_child_enqueue_styles() um den Eintrag

wp_enqueue_script('js-cookie',get_stylesheet_directory_uri().'/js/js-cookie-min.js',false, '', true););

• Erweitere die Datei js/custom.js Deines Child-Themes so:

jQuery(function ($) {

  $(document).ready(function(){
    const bsCookieSettings='bs_cookie_settings';
    const analytics = 'analytics';
    const advertising = 'advertising';
    const analyticDemoCookie='bsAnalyticCookie';
    const advertisingDemoCookie='bsAdvertisingCookie';
    const necessaryDemoCookie='bsNecessaryCookie';
    const demoCookieValue='demo-cookie';

    // alert("adding cookie writing algorithm");
    const bsv=Cookies.get(bsCookieSettings);
    if (bsv) {
      const allowedCookies=JSON.parse(bsv);
      // alert(allowedCookies.level);

      if (allowedCookies.level.includes(analytics)) {
        // alert("writing analytic cookies");
        if (!(Cookies.get(analyticDemoCookie))) { 
          Cookies.set(analyticDemoCookie, demoCookieValue, { expires: 100, path: '/' });
        };
      };
      if (allowedCookies.level.includes(advertising)) { 
        // alert("writing advertising cookies"); 
        if (!(Cookies.get(advertisingDemoCookie))) { 
          Cookies.set(advertisingDemoCookie, demoCookieValue, { expires: 10, path: '/' });
        };
      };
      // alert("writing necessary cookies"); 
      if (!(Cookies.get(necessaryDemoCookie))) { 
        Cookies.set(necessaryDemoCookie, demoCookieValue, { expires: 14, path: '/' });
      };
    };
  });

  // Do your other stuff here

}); // jQuery End

Hintergrund

Cookies könnten wir mit nativem Javascript setzen und evaluieren. Mit fertigen Bibliotheken geht es einfacher. WordPress bringt jQuery bereits mit. Und bootScore hat dies schon aktiviert und uns eine Möglichkeit geschaffen, eigene JavaScript-/JQuery-Funktionen in unser bootScore-Childtheme einzubauen.

Früher gab es für das Cookie-Management ein echtes jQuery-cookie Plugin. Das ist mittlerweile archiviert und in eine von jQuery unabhängige Javascript-Bibliothek js-cookie überführt worden. Um die zu nutzen, laden wir Datei js-cookie-min.js herunter und legen sie im JavaScript-Ordner unseres Child-Themes ab. Außerdem erweitern wir die Funktion bootscore_child_enqueue_styles() in unser Datei functions.php so, dass die Bibliothek js/js.cookie.min.js auch geladen wird.

Den Algorithmus zur Evaluation der Cookie-Settings implementieren wir danach in der Datei js/custom.js. Er wirkt so:

• Zuerst versuchen wir den vom bs-Cookie-Plugin unter dem Namen bs_cookie_settings abgelegten Cookie zu lesen.
• Wenn es ihn noch nicht gibt, hat unsere Leserin der Nutzung von Cookies noch nicht zugestimmt. Also dürfen wir noch keine schreiben.((Übrigens auch die technisch notwendigen nicht. Die dürfen wir zwar von gesetzeswegen ablegen, wir müssen unsere Leserin aber zuvor informieren, dass wir das tun. Und dass wir das getan haben, können wir wiederum anhand des Cookies bs_cookie_settings ‘belegen’. ))
• Sobald unsere Leserin den Cookie-Dialog in welchem Umfang auch immer ‘bestätigt’ hat, legt das bs-Cookie-Plugin den Cookie bs_cookie_settings ab. Sein Wert enthält ein JSON-Objekt:

{  "level": 
    [   "necessary",
        "analytics",
        "advertising"
    ],
    "revision":0,
    "data":null,
    "rfc_cookie":false
}

• Das müssen wir also erst parsen lassen, bevor wir — auf JavaScript-Ebene — auf die Liste der erlaubten Cookie-Gruppen via allowedCookies.level zugreifen und über die Methode includes eines Listenobjektes abfragen können, welche der Cookie-Gruppen necessary, analytics und /oder advertising uns unsere Leserin zu schreiben erlaubt hat.
• Und zu jeder zugelassen Gruppen schreiben wir dann die entsprechenden Cookies.((wobei wir uns bei den technisch notwendigen Cookies auf die gesetzliche Erlaubnis berufen.))

Und ein letzter Tipp noch: JavaScript erzeugt Seiten dynamisch. Gecacht werden die Ergebnisse. Deshalb müssen wir gelengtlich den Cache löschen, um die Ergebnisse unserer Veränderungen sehen zu können.

Und in welchem Zusammenhang …

… steht das mit unserer Migration zu bootScore? Nun, zuletzt muss die Web-Designerin im Rahmen ihrer Anpassungen auch rechtliche Vorgaben beachten, seien es die der DSGVO, die für eine Cookie-Zustimmung und deren Beachtung oder die zur Erstellungen einer Datenschutzerklärung. In diesen Kontext gehören dann auch die Fragen nach dem Zweck eines Bildverzeichnisses, nach einem adäquaten Impressum oder nach einer hinreichenden Open-Source-Lizenzerfüllung. Dies ins rechte Licht zu rücken, will auch dieser Post unterstützen.

Im Übrigen: Männer sind mitgemeint.

The post Ein sauberes Cookie-Management — mit bootScore appeared first on Freigiebigkeit.

Den brauchen wirt nicht selbst zu entwickeln . Denn bootScore liefert uns mit seinem Plugin bsCookie einen konfigurierbaren Dialog auf der Höhe der Zeit:

Lösung

• Lade bsCookie herunter.
• Installiere die Zip-Datei über das Plugin-Management Deines WordPress-Backends.
• Ermittle die Cookies, die Du auf dem Rechner Deiner Leserin installieren willst.((Wir müssen dabei bedenken, dass auch unsere Plugins Cookies ablegen lassen können. Es reicht also nicht, nur nach den entsprechenden JavaScript-Befehlen in unseren eigenen Posts und Pages zu suchen.))
• Ordne jeden dieser Cookies der Gruppe ’necessary’((Cookies, die wir dieser Gruppe zuordnen, werden zuletzt auch ohne explizite Zustimmung auf der Festplatte unserer Leserin abgelegt, eben weil sie technisch notwendig sind. So müssen wir notfalls auch beweisen können, dass diese Cookies tatsächlich technisch notwendig sind.)), ‘advertising’ oder ‘analytics’ zu.
• Ziehe im Dialog ‘Appearance/Widgets’ ein Widget ‘Customer HTML’ in die Widget-Gruppe Footer‑4
• Trage dort die Scriptzeilen ein, wie sie die bsCookie-Dokumentation offeriert.
• Erzeuge für jedes Deiner Plugins in der entsprechenden Sektion einen Eintrag.
• Verlinke Deine Datenschutzseite in den Dialog, indem Du #yourprivacypolicy entsprechend ersetzt.
• Übersetze die Texte in die Sprache Deiner Site (bzw. erzeuge einen zusätzlichen Eintrag gemäß Deiner Mehrsprachigkeitsstrategie)

Hintergrund

Das Schreiben der Cookies über einen Dialog erlauben zu lassen, ist nur die eine Seite der Medaille. Denn Cookies können auch (personen-bezogene) (Wiedererkennungs-) Daten speichern, die auf Serverseite akkumuliert und an externe Stellen weitergereicht werden. Deshalb müssen wir solche Cookies außerdem in unserem Datenschutzkonzept erwähnen. Damit unsere Leserin dies auch direkt aus dem Cookie-Zustimmugsdialog heraus ausrufen kann, bietet der bsCookie-Dialogtext einen Link, dessen Wert #yourprivacypolice wir entsprechend (um)setzen dürfen.

Es ist mittlerweile gute Tradition, Cookies funktionsbezogen zu gruppieren und für die Gruppen als solche zu fragen, ob die ihr zugeordneten Cookies lokal abgelegt werden dürfen. Rechtlich notwendig ist so ein Clustern nicht. Wir könnten unsere Leserin die Nutzung von Cookies auch ganz generell erlauben oder ablehnen lassen.((Eine stärkere Granularität liegt aber in unserem Interesse. Denn möchte eine Leserin das eine nicht — z.B. Advertising -, könnte sie das andere — z.B. Analytics — immer noch erlauben. Damit würden wir wenigstens noch einen Teil dessen erfahren, was wir insgesamt zu erfahren hofften.)) Oder wir könnten jeden einzelnen Cookie an- oder abwählbar machen — und den Dialog damit überfrachten.

Wie dem auch sei: Erstmal müssen wir natürlich wissen, welche Cookies unsere Site schreibt und was diese tatsächlich tun. Welche es sind, können wir uns über die Browser anzeigen lassen. Etwa mittels seines ‘Privacy and Security’-Dialoges. Oder mit Hilfe eines Browser-Plugins((z.B. mit dem Cookie Editor)), das direkt für jede aufgerufene Site/Seite anzeigt, welche Cookies von ihr geschrieben worden sind. Was unsere Cookies tun, müssen wir dagegen gesondert ermitteln.

Haben wir diese Cookies dann funktional sortiert, brauchen wir im bsCookie-Dialog nur noch die entsprechenden Gruppen als Sektionen anzulegen und in diese für jedes zugehörige Cookie einen Eintrag zu erzeugen. Für die drei gängigen Gruppen ’necessary’, ‘advertising’ und ‘analytics’ bringt bsCookie die nötigen Codegruppen immer schon mit. Hier reicht es mithin, die Cookies in und mit den Einzeleinträgen zu beschreiben. Gesetzt, wir wollten die drei Cookies bsNec­es­saryCook­ie, bsAdver­tis­ing­Cook­ie, und bsAnal­iz­ing­BCook­ie gesetzeskonform ablegen lassen, müsste der Code für den bsCookie-Dialog so aussehen:

<script>
  // Init
  window.addEventListener('load', function () {

    // obtain plugin
    var cc = initCookieConsent();

    // run plugin with your configuration
    cc.run({
      current_lang: 'de',
      autoclear_cookies: true,
      page_scripts: true,

      languages: {
        'de': {
          consent_modal: {
            title: 'Cookie-Zumstimmung:',
            description: 'Wir nutzen Cookies, um Deine Entscheidungen bei zukünftigen Besuche wiederzuverwenden. Wenn Du auf "Alle akzeptieren" klickst, dürfen wir alle Cookies verwenden, die technisch notwendigen und die funktionell hilfreichen. Wenn Du auf "nur notwendige" klickst, untersagst Du uns, die  funktionell hilfreichen Cookies zu verwenden. Eine feinere Auswahl bieten Dir unsere expliziten <a data-bs-toggle="modal" href="#bs-cookie-modal">Cookie-Einstellungen</a>.',
            primary_btn: {
              text: 'alle akzeptieren',
              role: 'accept_all'
            },
            secondary_btn: {
              text: 'nur notwendige',
              role: 'accept_necessary'
            }
          },

          settings_modal: {
            title: 'Cookie-Einstellungen',
            save_settings_btn: 'Auswahl sichern',
            accept_all_btn: 'alle akzeptieren',
            reject_all_btn: 'nur notwendige',
            close_btn_label: 'schließen',
            cookie_table_headers: [
              { col1: 'Name' },
              { col2: 'Domain' },
              { col3: 'Verfall' },
              { col4: 'Beschreibung' }
            ],
            blocks: [
              {
                title: 'Cookie-Nutzung',
                description: 
'Wir verwenden Cookies, um zentrale Funktionen unserer Website bereitzustellen und Dein Leseerlebnis zu verbessern. Du kannst für jede Cookie-Gruppe entscheiden, ob Du sie zulässt oder nicht. Weitere Einzelheiten zu Cookies und anderen sensiblen Daten findest Du in unserem <a href="http://karsten-reincke.de/datenschutz">Datenschutzkonzept</a>.'
              }, {
                title: 'Notwendige',
                description: 
'Diese Cookies sind essentiell für unsere Website. Ohne sie würde die Site nicht richtig funktionieren.',
                toggle: {
                  value: 'necessary',
                  enabled: true,
                  readonly: true          // cookie categories with readonly=true are all treated as "necessary cookies"
                },
                cookie_table: [
                  {
                    col1: 'bs_cookie_settings',
                    col2: 'bootScore.me',
                    col3: 'wird gelöscht wenn Deine Session beendet wird',
                    col4: 
'Darin speichert bootScore bzw. das Plugin "bsCookies" Deine Cookie-Einstellungen',
                    is_regex: false
                  },
                  {
                    col1: 'bsNec­es­saryCook­ie', 
                    col2: 'http://karsten-reincke.de/',
                    col3: 'nach 100 Tagen',
                    col4: 'Demo-Cookie für "pimp your BootScore"',
                    is_regex: false
                  },                 
                ]
              }, {
                title: 'Analytics',
                description: 
'Diese Art der Cookies erlaubt es uns, Deine Entscheidungen beim nächsten Mal wiederzuverwenden.',
                toggle: {
                  value: 'analytics',     // your cookie category
                  enabled: false,
                  readonly: false
                },
                cookie_table: [           // list of all expected cookies
                  {
                    col1: 'bsAnal­iz­ing­Cook­ie',         
                    col2: 'http://karsten-reincke.de/',
                    col3: 'nach 10 Tagen',
                    col4: 'Demo-Cookie für "pimp your BootScore"',
                    is_regex: false
                  }
                ]
              }, {
                title: 'Advertising',
                description: 
'Solche Cookies vermerken, wie Du unsere Website verwendest, welche Seiten Du besuchts und welche Links Du anklickst. Alle Informationen sind anonymiziert und können nicht benutzt werden, um Dich zu identifizieren.',
                toggle: {
                  value: 'advertising',
                  enabled: false,
                  readonly: false
                },
                cookie_table: [             // list of all expected cookies
                  {
                    col1: 'bsAdver­tis­ing­Cook­ie',
                    col2: 'http://karsten-reincke.de/',
                    col3: '2 Wochen',
                    col4: 'Demo-Cookie für "pimp your BootScore"',
                    is_regex: false
                  }
                ]
              }, {
                title: 'Weitere Informationen',
                description: 
'Bei weiteren Fragen zu unserem Daten-Management, kontaktiere <a href="http://karsten-reincke.de/impressum">uns</a> einfach.',
              },

            ]
          }

        }
      }

    });
  });
</script>

Die Informationen in den Cookie-Zustimmungsdialogs einzubauen, ist das eine. Seinen Code zu aktivieren, das andere. Den angepassten bs-cookie-settings-JavaScript-Code tragen wir dazu in ein Custom-HTML-Element ein, das wir dem Widget Footer 4 hinzugefügt haben. Prinzipiell könnten wir das Custom-HTML-Element auch in andere Widgets einbetten. bsCookie schlägt Footer 4 vor, weil der JavaScript-Code so eher am Ende einer Seite eingebettet und damit direkt ausgeführt wird. Wie auch immer, der Cookie-Zustimmungsdialog wird dann beim Aufruf all der Seiten angezeigt, deren Templates den Footer 4 verwenden. Das Problem der ‘Deep-Links’((Es reicht nicht aus, nur unsere Einstiegsseite den Zustimmungsdialog anzeigen zu lassen. Denn gelegentlich reichen unsere Leserinnen auch Links auf tiefer eingebettete Seiten herum. Unsere Site muss auch in deisen Fällen erst um Erlaubnis bitten, bevor sie die Cookies ablegt.)) ist also gelöst, wenn jede Seite ein Template verwendet, das den entsprechenden JavaScript-Code enthält.

Blieben uns noch drei letzte Aufgaben:

• Zum ersten werden wir unseren Zustimmungsdialog oft auch sprachlich anpassen wollen. Auch das geht über die ‘Umprogrammierung’ des erwähnten JavaScript-Codes.
• Über das funktionalen Farbkonzept von Bootscore/bootStrap ist der Cookie-Dialog auf ‘Warning’ eingestellt. Wer ihn dennoch anders gestalten will, kann das in ihrer Datei _bscore_custom.scss so tun:

  // design the bsCookie-Dialog
  #c-inr {
    border-color: darkblue;
    border-width: 2px;
    border-style: solid;
    background-color: #eef;
    color: blue($color: #000000);
    padding: 5px;
  }
  
  #c-p-bn {
    border-color: darkblue;
  }
  
  #c-s-bn {
    border-color: darkblue;
  }
  

• Zum dritten müssen wir die Semantik des Cookie-Zustimmungsdialoges implementieren. Wenn wir mehr als nur reden wollen, müssen wir unseren ‘Schreibe-Cookie-JavaScript-Code’ so anlegen, dass er ohne Zustimmung nur die technischen notwendigen Cookies schreibt und dass er ansonsten nur die Cookies aus den Gruppen ablegt, für die eine Zustimmung vorliegt.

Diesen letzten Punkt werde ich in einem gesonderten Post aufgreifen …

Und in welchem Zusammenhang …

… steht das mit unserer Migration zu bootScore? Nun, zuletzt muss die Web-Designerin im Rahmen ihrer Anpassungen auch rechtliche Vorgaben beachten, seien es die der DSGVO, die für eine Cookie-Zustimmung und deren Beachtung oder die zur Erstellungen einer Datenschutzerklärung. In diesen Kontext gehören dann auch die Fragen nach dem Zweck eines Bildverzeichnisses, nach einem adäquaten Impressum oder nach einer hinreichenden Open-Source-Lizenzerfüllung. Dies ins rechte Licht zu rücken, will auch dieser Post unterstützen.

Im Übrigen: Männer sind mitgemeint.

The post Ein sauberer Cookie-Dialog — mit bootScore appeared first on Freigiebigkeit.

Um die Konsequenzen ihres Diktats zu verstehen, hier zuerst noch einmal meine aus dem YOAST-Angebot extrahierten 11 Gebote, mit deren Umsetzung ich YOAST bisher stets grüne Ampeln abringen konnte, eine für ‘SEO’ und eine für die Lesbarkeit. Unnötig zu erwähnen, dass ich di so aufbereiteten Seiten Google habe erfolgreich zum Indexieren((als Einzellinks via Search-Konsole, nicht per Sitemap allein)) übergeben können.

Lösung

• Definiere Dir eine Key-Phrase, die das Topik Deiner Seite((Der wolf-of-seo sagt, dass die Key-Phrase nicht erfassen sollte, worum es in Deinem Beitrag gehe, sondern wofür er perfekt sei. Wendet man jedoch die Regeln 2 und 3 an, schrumpft der Unterschied zwischen diesen Standpunkten erheblich.)) wiedergibt.((Achtung: 2 Wörter, allenfalls drei. Denn diese Key-Phrase muss in dieser Form an den Anfang des Titels passen und auch in den Fließtext eingebunden werden können. Vertraue nicht darauf, dass YOAST die syntaktischen Feinheiten der deutschen Sprache analysieren kann — auch wenn es das zu tun verspricht.))
• Setze die Key-Phrase((so, wie definiert)) an den Anfang Deines Seitentitels.((Wenn Du den so entstehenden slug’ Deiner Seite verkürzt, bleibe in Deiner URL wenigstens bei sprechende Syntagmen.))
• Integriere diese Key-Phrase((so, wie definiert)) in den ersten Absatz Deiner Seite.
• Baue die Key-Phrase((möglichst so, wie definiert)) in die mindestens 120 und höchstens 156 Zeichen lange Meta-Description Deiner Seite ein.
• Verlinke Deine Seite auf andere Seiten Deines Blogs zu dem Thema.
• Verlinke Deine Seite auf fremde Seiten zu dem Thema.
• Schreibe nur wenig Sätze mit mehr als 25 Wörtern.
• Nutze (logische) Konjunktionen, um (kurze) (Haupt)Sätze miteinander zu verknüpfen.
• Lasse Deine Absätze nicht über 150 Wörter ‘anschwellen’, bleib aber auf jeden Fall unter 200.
• Nutze nur wenig Passivkonstruktionen, mache aktive Aussagen.
• Beantrage in der Search-Konsole für Deine neue Seite explizit, dass Google sie indexiert((Verlass Dich nicht nur auf Deine aktualisierte Sitmap.))

Hintergrund

Eins gleich vorab: Wem jetzt schon schwant, dass dieser Post diesen Geboten nicht so richtig folgt, dem sei gleich gesagt: Yeep. Absichtlich. Testen wir doch einfach mal, was passiert, wenn wir unsere Posts nicht dem vereinheitlichenden Diktat von Google und YOAST unterwerfen.

Aus diesen ‘Empfehlungen’ ergibt sich nämlich ein anderer Schreibstil, als er Dir und mir (gelegentlich) vorschwebt. Dass passive Satzkonstruktionen schwieriger zu verstehen sind und damit mehr Lesearbeit erfordern, ist nachvollziehbar.((Wer’s nicht glaubt’, mag sich bewusst durch diesen absichtlich passivierten Absatz ‘quälen’)) Dass unser Lese(er)leben durch kurze Sätze erleichtert wird, ebenso. Werden wir von den Suchmaschinen gezwungen, so zu schreiben, tun sie unseren Leserinnen etwas Gutes. Auch wenn wir über die Drohung, unsere Texte würden nicht indexiert, ’sanft’ vom akademischen Schreibstil weggebracht werden.

Dies ärgert mich also nicht. Die Sache mit der Key-Phrase aber schon. Denn die verhindert, dass ich mit einem nur andeutenden Titel Leselust wecken und seine konkrete Bedeutung und seinen Kontext erst aus den ersten Sätzen erwachsen lassen kann. Freie Fahrt den Assoziationen — damit arbeite ich gern. Eigentlich. Darf es aber nicht, wenn ich die Gebote befolgen will. Ein Beispiel: Früher hatte ich meinen Artikel ‘Wolken und Listen — Zwei auf einen Streich!’ nur ‘Zwei auf einen Streich’ betitelt — und damit sogar ein wenig assoziative Nähe zum ‘tapferen Schneiderlein’ hergestellt.((Auch wenn mir das jetzt, wo ich das Märchen noch einmal ganz gelesen habe, selbst etwas unangenehm aufstößt. Es ist schon ein arger Blender, das kleine Schneiderlein, nicht nur ein Schlitzohr. Eigentlich kein Kontext, in den ich mich eingeordnet wehen möchte.)) Nur Zwei auf einen Streich, das ist ein eleganter Titel. Ihm die Key-Phrase ‘Wolken und Listen’ voranzustellen, nimmt dem Titel den Witz und macht ihn sperrig. Und spätestens, wenn wir die Key-Phrase im ersten Absatz noch einmal wiederholen, werden wir zu aufdringlichen Plapperinnen — nur um unsere grünen YOAST-Ampeln zu bekommen, will sagen: um indexiert zu werden.

Als ein aus SEO Sicht gutes Beispiel mag die Seite https://wolf-of-seo.de/was-ist/fokus-keyphrase/ betrachtet werden. Hier wird die Key-Phrase Fokus Keyword an den Anfang des Titels gestellt und gleich noch einmal im ersten, sehr kurzen Absatz wiederholt — zusammen mit ihrem Zwilling Fokus Keyphrase. Und in den ersten 6 Sätzen((was hier gleichbedeutend ist mit: in den ersten 6 Absätzen)) kommen die dann mehr als 10 ‘mal vor. Der ‘wolf of seo’ wird keine Schwierigkeit gehabt haben, seine Seite indexiert zu bekommen. Und mehr noch: inhaltlich ist dieser Artikel richtig gut! Nur stilistisch — stilistisch ist er grottig. Lest ihn einfach mal langsam, und Euch fällt dieses redundante Wortgeklingel sicher auch auf. Das Ärgerliche an dem Diktat einer guten SEOzität ist, dass wir offensichtlich so schreiben müssen, wenn wir indexiert werden wollen. Denn nur das, was indexiert ist, kann ja überhaupt gefunden und gerankt werden.

Habt Ihr den ’seo-wölfischen’ Text langsam gelesen, lest auch meinen Artikel so. Und es wird Euch direkt auffallen, dass er noch viel grottiger ist, als jener. Ich habe hier nämlich absichtlich viele der o.a. Gebote verletzt:

• Meine Key-Phrase ‘StilXpolizei’ kommt weder im Titel noch im ersten Absatz oder sonst wo vor, also auch nicht im slug.((Ich kann das Wort nicht riochtig schreiben, sonst meint YOAST: ”The keyphrase was found 1 time. That’s less than the recommended minimum of 3 times for a text of this length.”))
• Ich habe eine ‘Metadescription’ eingebaut, die absichtlich zu kurz ist und am Thema vorbeigeht.((Einfach mal den Sourcecode ansehen.))
• Dieser Post verwendet zwar Links nach extern, aber keine auf andere Seiten meiner Site.
• Mein Text verwendet zu viele Passivkonstruktionen((“15% of the sentences contain passive voice”)) und hat einen zu langen Absatz.((“1 of the paragraphs contains more than the recommended maximum of 150 words.”))

So bekomme ich für diesen Post eine orange YOAST-Ampel in Sachen SEO und eine rote in Sachen Lesbarkeit.

Damit können wir jetzt einfach mal testen, wie lange Google braucht, um diesen Artikel zu indexieren.((Um nicht Birnen mit Äpfeln zu vergleichen, werde ich Google zuerst nur über die Sitemap von dem neuen Post informieren. Und erst nach ein paar Monaten beantrage ich bei Google die Indexierung dieses Posts auch manuell.)) Sobald er im Index aufgenommen worden ist, sage ich Euch hier Bescheid. Ihr könnt es aber auch selbst testen. Sucht einfach nach SEOzität. Das Wort gibt es nämlich (bisher) nur in diesem Artikel.

• Sitemap aktualisiert: 2023-08-27 / evaluiert: 2023-08-28
• Post gefunden: 2023-08-28 / gecrawlt: 2023-08-28 / indexiert: 2023-08-28

Erstaunlich. So schnell. Ohne manuelle Bitte um Indexierung, ohne innere Verlinkung. Und das englische Pendant ist am 30.08. immer noch nicht gefunden, gecrawlt

The post Mein ‘googlierter’ Schreibstil appeared first on Freigiebigkeit.

Lösung

• Ersetze alle schematischen Slugs durch sprechende.
• Verlinke jeden Post und jede Seite mit allen anderen internen verwandten Posts oder Seiten.
• Installiere YoastSEO.
• Setze so viele seiner Verbesserungsvorschläge um, dass seine Ampeln auf grün springen.
• Beantrage bei Google für jede Seite und jeden Post gesondert die Indexierung.

Hintergrund

Was hatte mich zu dieser Einsicht getrieben? Nach der Anmeldung meiner Sitemap irgendwann im April hatte Google in 3 Monaten nur 6 meiner 109 Seiten indexiert. Über deren Qualität hatte es nicht gemeckert. Nur schlicht verkündet, dass es 81 Seiten oder Posts zwar gefunden und 17 zwar gecrawlt, aber nicht indexiert habe. Offensichtlich hielt Google meine Texte des Indexierens nicht für würdig. Trotz meines an sich ja interessanten Themas ‘bootScore’. Und trotz der ja immerhin so relevanten Artikel, dass sie das Projekt ‘bootScore’ zu Verbesserungen angeregt hatten. Über ein gutes Ranking brauchte ich also vorerst nicht nachzudenken. Ich musste mich ‘findbar’ machen.

Es hat mich eine Weile gekostet, zu verstehen, was passiert war. Und noch eine größere, es zu bereinigen:

Mit meiner Migration nach bootScore wollte ich auch meine Site verdichten. Sie leserinnen-freundlicher gestalten. Ihr die Redundanz austreiben. Weniger Schnick-Schnack sollte sie enthalten. Darum hatte ich meine thematischen Cluster sauber auf Kategorien und Tags abgebildet und denen meine Texte zugeordnet. Denn bootScore bot ja von Haus aus auf jeder Seite an, sich für jedes Schlagwort die zugehörigen Artikel anzeigen zu lassen. Warum also sollte ich in den einzelnen Seiten/Posts zusätzlich auf thematische verwandte Seiten/Posts verweisen? Warum händisch Seiten und Posts verlinken? Zu viel Schnick! Und warum sollte ich in mein Menü einzelne Seiten oder Posts einhängen? Zu viel Schnack! Ein Leitsystem aus den Kategorien und Tags sollte reichen. Damit hätten meine Leserinnen immer auf die zu diesem Thema auch relevanten Artikel zugreifen können. Eine zusätzliche ‘innere Verlinkung’ im Text, das wäre doch redundant. Dachte ich.

Genau das aber sieht Google anders! Seiten, auf die nicht einmal andere eigene Seiten verlinken, sind doch offensichtlich nicht einmal der Autorin wichtig. Sonst würde sie doch ihre Leserinnen dahinführen wollen. Warum also sollte Google sie indexieren? Darauf hatten meine Lehrbücher immer schon hingewiesen.((Pars pro toto: vgl. Czysch, Stephan: SEO mit Google Search Console, 2. Aufl., Heidelberg 2017, S. 168ff)) Mein Fehler, es zu ignorieren.

Wie der Fehler, meine Beiträge mit nichtssagenden ‘Slugs’ zu gruppieren. Wenn ich — zum Beispiel — ein Cluster ‘image’ benutzte, dachte ich, ich könnte meine Beiträge ‘image‑a’ , … ‘image‑i’. So hatte ich die gleichen Seitennamen auf der deutschen und der englischen Site. An sich keine schlechte Idee. Nur veranlasste da Google dazu, die Beiträge für unwichtig zu halten.((pars pro toto: vgl. Dziki, Julian: Suchmaschinenoptomierung für dummies, 2. Aufl., Weinheim 2021, S. 62)) Sie waren mir ja nicht mal einer Botschaft wert.

Nachdem ich diese Nebeneffekte verstanden hatte, überarbeitete ich alles. Ich ersetzte die symbolischen Seitennamen durch sprechende. Ich installierte YoastSeo und setzte so viele seiner Maßnahmen zu den Themen ‘SEO’ und ‘Lesbarkeit’ um, dass die entsprechenden Ampeln von rot auf grün wechselten. Oder zumindest auf gelb. Alles in allem eine sehr zeitaufwendige Arbeit.

Trotzdem fehlte damit noch die innere Verknüpfung. So schrieb ich für jedes Themencluster eine Zusammenfassung und verlinkte deren Wörter mit den verwandten Beiträgen und Seiten. Und da ich diese Zusammenfassungen in Zukunft absehbar häufiger würde aktualisieren müssen, erleichterte ich mir diese Tipparbeit, indem ich je Zusammenfassungen als ShortCodes implementierte. Jetzt reichte eine einfache Zeichenkette am Ende eines jedes Beitrags und er wäre intern passend verlinkt.

Den wirklichen Durchbruch in Sachen Indexierung erlebte ich aber erst, als ich jeden Post und jede Seite einzeln und händisch in der Google-Search-Konsole zur Indexierung angemeldet hatte — was auch hieß, jedes Mal zeitaufwendig die Indexierbarkeit überprüfen zu lassen. Heute hat Google von meinen 74 Artikeln und 18 Seiten meiner deutschen Site 84 indexiert. Und was nicht indexiert ist, muss — aus Leserinnensicht — nicht über Google gefunden werden. Wie z.B. meine Datenschutzseite oder der Bildernacheweis. Auf meiner englischen Site sieht es sogar noch besser aus: von den 53 Post und 15 Seiten sind 114 indexiert — was nur besagt, dass auch noch veraltete Links im Index enthalten sind. Diesmal bin ich den diesbzgl. Empfehlungen der Lehrbücher aber gleich gefolgt und habe die entsprechenden Weiterleitungen((pars pro toto: vgl. Eisenmenger, Richard u. Florian Brinkmann: WordPress 6. Das umfassende Handbuch, 2. Aufl., Bonn 2022, S. 517)) aktiviert — hier mit dem Plugin ‘Quick 301 Redirects’.

Was war nun die entscheidende Maßnahme für den Erfolg? Ich fürchte, es braucht alle. Auch wenn ich dafür meinen Schreibstil ändern musste. Vor allem bei der Umsetzung der YoastSEO-Empfehlungen. Aber dazu später mehr. So bald Google diese Artikel indexiert hat. Immer das Wichtigste zuerst.

Und in welchem Zusammenhang …

… steht das mit unserer Migration zu bootScore? Nun: Muss eine Web-Designerin ihr bisheriges WordPress-Theme aufgeben, braucht sie Ersatz. Ein freies Theme von der Stange wird sie personalisieren wollen. Zuerst etwas kosmetisch, dann in Sachen Grauwert, Mehrsprachigkeit und innerer Verweistechnik und Verlinkung. Schließlich wird sie besondere Footer aktivieren, ein Zweitmenü oder einen Copyright-Hinweis, bevor sie die ‘SEO-zität’ überprüft. Diesen Weg unterstützt auch dieser Post.

Im Übrigen: Männer sind mitgemeint.

The post Innere Verlinkung — ein Reset appeared first on Freigiebigkeit.

Als Ausgangspunkt hatte ich (bereits) WordPress installiert¹, (Test-) Daten eingegeben², bootScore installiert und es als Theme aktiviert³. So entstand — als Reihe von pimp your bootScore posts — folgender Weg:

1. Font Awesome — ein Symbol sagt mehr als 100 Worte: ShortCodes und CSS-Klassen
2. SEO von Anfang an: HTML-Semantik, Schlagwörter und Sitemaps und keine toten Links, bitte!
3. Das ‘(Un)Wichtige’ nach unten: Der dezente und umfassende Footer-Bereich für den ’nachrangigen’ Legalkram, das nachrangige Zweitmenü und die eigene Copyrightline
4. Mehrsprachigkeit mitdenken: Bilingualität ohne WP-Globus
5. Die Übersichtlichkeit: Das tiefer verzweigte Menü mit integrierten Shortcodes, sauberen Ebenen und lesbarer Stapelung, das dennoch kein H‑OVER-Menü sein muss.
6. Nicht frickeln, sondern automatisieren: Die eingebaute Silbentrennung
7. Ein Bild sagt mehr als 1000 Worte:
   • Das kann ein ‘manuell’ mit einer fancy Box in den Text eingefügtes Bild sein — gerne auch beschleunigt ausgeliefert per WordPress vorberechneter Bildgröße oder als SVG.
   • Oder ein automatisiert verwaltetes ‘Primäres Beitragsbild’. Nur sollte es möglichst wenig verwischt sein, wenn es des Responsiv-Designs wegen angepasst wird. Das organisiert das moderne IMG-Tag mit den Source-Angaben wohl am Besten. Schneller umzusetzen, aber weniger effektiv wäre es, WordPress eine weitere Bildgröße im Voraus berechnen zu lassen.
   • Wirklich freie Bilder gibt es im Netz, wenn wir ein Bildverzeichnis vorsehen, um die Lizenzvorgabn zu erfüllen.
   • Und die kleinen Browserbildchen neben der Url? Oder das Logo? Dafür nutzen wir bootScoores Logo- und Favicon-System.
8. Das Finden erleichtern: TAG-Wolken und Beitragslisten in der Sidebar
9. Der ‘gemauerte’ Überblick: Die Masonry-Beitragsliste
10. Das Wichtigste zuerst: eine eigene Landing-Page — selbst gestaltet - und dann weg mit dem, was ablenkt, auch mittels kontextsensitiven Sidebars und dezenterem Hinweise auf jüngere Posts
11. Designte Lesbarkeit: bootScore und der eigene generelle Font und ein Font für besondere Anlässe
12. Recht muss Recht bleiben: Datenschutz, DSGVO und Cookies, der Cookie-Dialog und seine Semantik mit bootScore
13. Der erste Eindruck: das Nutzerinnen orientierte Farbkonzept

So entsteht eine bootScore-basierte Website mit Responsive Design, die den Weg dorthin in sich selbst dokumentiert, auf dass ich auch in Zukunft nachschlagen kann, wie ich es in der Vergangenheit gemacht habe. Wenn dies auch anderen nützt, wäre das ein willkommener Nebeneffekt.

Im Übrigen: Männer sind mitgemeint.

1. Anleitung dazu gibt es zu Hauf, auch eine von WordPress selbst.
2. z.B. mit denen der zu migrierenden Site oder des Theme Unit Tests
3. z.B. gemäß bootScore-Anleitung

The post bootScore pimpen appeared first on Freigiebigkeit.

Lösung

• I. Verwende nur die personenbezogenen Daten, die Du für das Funktionieren Deines Systems wirklich benötigst.
• II. Wenn Du personenbezogene Daten erhebst, dann sage den Besitzerinnen,
  • dass Du das tust,
  • zu welchem Zweck Du die Daten verwendest,
  • welche Rechtsgrundlage Dich dazu berechtigt,
  • an wen Du die Daten weitergibst,
  • wie lange Du sie bei Dir speicherst,
  • wie sie bei der erfragen können, welche Daten Du über die Zeit gespeichert hast
  • wie sie die Daten wieder löschen lassen können.
• III. Wenn Du Daten auf dem Rechner Deiner Nutzerinnen speicherst, die sie nicht direkt oder indirekt angefordert haben (könnten), frage sie vorher um Erlaubnis.

Hintergrund

Gehe ich danach vor — so mache ich immer wieder glauben — werde ich meine Sites so gestalten, dass ich die gröbsten Fallen¹ und Fehler² vermeide. Denn eines habe ich immer im Kopf: mit einem bloßen Cookie-Banner ist es nicht getan:

1. Als Erstes überlege ich mir, wo mein Blog als System personenbezogene Daten erhebt. Die, die ich in und mit Formularen explizit abfrage, fallen mir am leichtesten auf und ein. Bei denen weiß ich — ‘qua Amt’ -, wofür ich sie nutze und an wen ich sie weitergebe etc.
2. Außerdem ist mir klar, dass auch IP-Adressen als personenbezogenen Daten gelten — obwohl das Internet ohne sie gar nicht funktionieren würde.
3. Zudem können WordPress, die von mir aktivierten Plugins, Javascript-Bibliotheken, Google-Fonts u.Ä.m. Daten erheben, notieren und an Dritte versenden.
4. Schließlich werden meine Kommentatorinnen üblicherweise über das gängige Gravatar-System wiedererkennbar gemacht.

Dieses Gemenge muss ich ordnen:

• Regel (I) sagt mir, dass Weniger im Mehr ist: Je weniger Daten ich erfrage, je weniger Plugins ich verwende, desto schlanker wird mein Datenschutzkonzept. Also miste ich hier aus, z.B., in dem ich Produktiv- und Developsytsem unterschiedlich behandele.
• Regel (II) sagt mir, dass ich die verbleibenden Datensets aber auch tatsächlich im Datenschutzkonzept beschreiben muss. Also ermittle ich nach bestem Wissen und Gewissen, welche Daten meine Plugins, Font-Requests und andere technische Komponenten erheben, wie sie sie speichern und wohin sie sie weitergeben.
• Regel (III) sagt mir, dass ich es ich es mir erlauben lassen muss, Dateien, will sagen: Cookies auf den Rechner meiner Nutzerin schreiben zu dürfen, sei es — wie bei technisch notwendigen Cookies — gesetzlich, sei es — wie bei den anderen — per Zustimmung durch meiner Nutzerin. Und um die gewährt zu bekommen, ist es hilfreich, Zweck und Auswirkung anzugeben.

Weitere Posts beschreiben, wie ich das konkret umgesetzt habe.

Und in welchem Zusammenhang …

… steht das mit unserer Migration zu bootScore? Nun, zuletzt muss die Web-Designerin im Rahmen ihrer Anpassungen auch rechtliche Vorgaben beachten, seien es die der DSGVO, die für eine Cookie-Zustimmung und deren Beachtung oder die zur Erstellungen einer Datenschutzerklärung. In diesen Kontext gehören dann auch die Fragen nach dem Zweck eines Bildverzeichnisses, nach einem adäquaten Impressum oder nach einer hinreichenden Open-Source-Lizenzerfüllung. Dies ins rechte Licht zu rücken, will auch dieser Post unterstützen.

Im Übrigen: Männer sind mitgemeint.

1. vgl. https://www.e‑recht24.de/artikel/datenschutz/8451-hinweispflicht-fuer-cookies.html
2. vgl. https://www.ihk.de/halle/recht/datenschutz/sonstige-rechtsinformationen/cookie-banner-fuenf-fehler-die-sie-vermeiden-sollten–4854218

The post Datenschutz, DSGVO und Cookies appeared first on Freigiebigkeit.

Lösung

• Definiere in Deiner Child-Theme-Datei scss/_bscore_variables.scs noch die Variable $menu-font-family: 'PT Sans', sans-serif, !default; (mit einem Menufont Deiner Wahl.)
• Trage in Deiner Child-Theme-Datei scss/_bsscore-custom.scs die folgenden Zeilen ein:

#bootscore-navbar{
  font-family: $menu-font-family;
}

.footerSubMenu {
  font-family: $menu-font-family;
}

• Weise über das WP-Backend den Widgets Footer 1 bis Footer 4, die eine Liste als Menü enthalten, mit <ul class="footerSubMenu"> die neue Klasse zu.

Hintergrund

Noch einmal kurz: Wie kann dieser Bedarf eigentlich entstehen?

Menüs sehen in der Regel mit serifenlosen Fonts besser aus. Haben wir in der Variable $font-family-base eh einen serifenlosen Default-Font festgelegt, ist alles gut. Verwenden wir aber einen Serifenfont, müssen wir — wenn wir es denn so wollen — nicht nur den Überschriften einen serifenlosen Font zuweisen, sondern auch die Menüs. Das Hauptmenu ist seitens bootScore in einem Bereich mit der ID bootscore-navbar eingebettet. Diese ID können wir weiterverwenden. Für die Submenüs im Footerbereich müssen wir uns eine entsprechende Klasse definieren und den Listen manuell zuweisen.

Und in welchem Zusammenhang …

… steht das mit unserer Migration zu bootScore? Nun, hat Web-Designerin im Rahmen ihrer Anpassungen die Frage einer guten Bebilderung beantwortet, kann sie entspannt Tags und Wolken in ihre Site einbinden, ihre Überblicksseite verbessern und eine eigene Landingpage gestalten. Ob die entstandene Fülle der eigenen Leserin wirklich nutzt, ob es nicht schlanker geht und wie, ob dezentere Verweise und spezielle Fonts auch für besondere Anlässe die Lesbarkeit erhöhen, all das gilt es zu bedenken. Das tut auch dieser Post.

Im Übrigen: Männer sind mitgemeint.

The post Fonts für besondere Anlässe appeared first on Freigiebigkeit.

Lösung

• Wähle aus den Google Fonts Deine Schriften aus:
  • eine Schrift mit Serifen (z.B. pt-serif oder noto-serif),
  • eine dazu passenden serifenlose Schrift (z.B. pt-sans oder noto-sans),
  • eine dazu passende Monospace-Schrift (pt-mono oer noto-sans-mono)
  • und vielleicht noch eine spezielle Schrift für Überschriften (z.B. arima-madurai oder eb-garamond)
• Wähle jede Schrift im google-webfonts-helper an und
  • belasse den Zeichensatz (charset) auf latin
  • selektiere — so weit vorhanden — die Größen 400 und 700.
  • selektiere dazu — so weit vorhanden, die Stile regular, regular italic, bold und bold italic.
  • kopiere den im google-webfonts-helper dazu erzeugten font-face-code in die Datei scss/_bscore_custom.scss
  • lade das Zip-Paket aus dem google-webfonts-helper herunter.
• Erzeuge einen Ordner fonts in Deinem Child-Thema.
• Entpacke alle heruntergeladenen Zip-Pakete im Ordner fonts
• Erweitere die Datei scss/_bscore_variables.scss um die Zeilen:

  $font-family-base: 'Noto sans', Verdana, sans-serif !default;
  $font-family-sans-serif: 'Noto Sans', Verdana, sans-serif, !default;
  $font-family-monospace: 'Noto Sans Mono', 'Courier New', monospace, !default;
  $font-family-code: 'Noto Sans Mono', 'Courier New', monospace, !default;
  $headings-font-family: 'EB Garamond', Garamond, serif !default;
  $display-font-family: 'EB Garamond', Garamond, serif !default;

Hintergrund

Schriften sind — begrifflich und inhaltlich gesehen — ein weites Feld¹:

In der Typografie ist es üblich zwischen Serifen-Schriften und serifenlosen Schriften zu unterscheiden. Serifenschriften seien — heißt es — für gedruckten Fließtext besser, weil sie durch ihre horizontalen Verlängerungen am Buchstaben das Auge besser führen. Im Web galt dagegen lange, dass seriflose Schriften am Bildschirm lesebarer seien. Je feiner aber die Bildschirme über die Zeit wurden, desto feiner ließen sich auch die Serifen darstellen. Das Auge ermüdete weniger. Und so wird heute gesagt, es gäbe von der Lesbarkeit her keinen wirklich Unterschied mehr: Serifenschriften und serifenlose Schriften können gleichermaßen verwendet werden.

Für alles nur eine einzige Schrift zu verwenden, langweilt allerdings. Wenigstens die Überschriften und die Textkörper sollten sich unterscheiden. Andererseits reduzieren zu viele Schriften — der Unruhe im Gesamtbild wegen — die Lesbarkeit. Und Lesbarkeit und unmittelbare Wahrnehmbarkeit ist nun einmal der Qualitätsmaßstab. So arbeitet die moderne Web-Designerin mit Paaren, mit einem Font für die Überschrift, einem für den Fließtext. Und eben deshalb werden uns heute so oft Fontpaare ‘empfohlen’, bei denen die Fonts doch recht wild kombiniert werden.

In diesem Kontext wichtig ist auch die Unterscheidung zwischen font-familiy und font-face. Mit der CSS-Anweisung font-family: XYZ; teilen wir dem Browser — ungenau gesprochen — mit, dass er den Text in einem HTML-Tag mit dem Font XYZ darstellen solle. Tatsächlich weisen wir ihn aber an, den Text mit einem passenden Font aus der Font-Familie XYZ darzustellen. Mit der CSS-Anweisung @font-face {...}² haben wir ihm zuvor gesagt, dass eine bestimmte durchgestaltete Schrift aus einer bestimmten Schriftfamilie (font-family: XYZ) mit einem bestimmten Stil (font-style: [normal|italic]) und einer bestimmten Stärke (font-weight: [<400<...<700<]) zur Verfügung steht und wo er sie findet. Es ist dann Aufgabe des Browsers, die für eine bestimmte Stelle im HTML-Quelltext am besten passende Schrift konkret herauszusuchen. Denn er muss ja nicht nur die Schrift selbst darstellen, sondern auch die Spezifikationen normal, italic, bold, bold-italic berücksichtigen.³

Wenn ein spezifizierter Font doch nicht zu Verfügung steht — etwa, weil der Browser ihn nicht hat herunterladen oder verstehen können -, dann wählt der Browser einen anderen, möglichst ‘ähnlichen’ Font aus seinem Bestand. Und ‘ähnlich’ meint hier nur, ob es sich dabei auch um einen serifenlosen Font oder auch um eine serifenlose Schrift handelt. Wenn für die anderen geforderten Eigenschaften kein genau passender Font einer Familie bereitsteht, kann der Browser diese Eigenschaften ‘herstellen’, indem er den gewählten Font rechnerisch kippt oder verstärkt. Solche ‘berechneten’ Schriftypen sehen aber schlechter aus, als die explizit so gestalteten.⁴

Im Prinzip kann die Web-Designerin also nicht sicher sein, wie ihr Text auf dem Rechner einer Leserin tatsächlich aussieht. Um die Wahrscheinlichkeit zu erhöhen, dass die Designerin ihrer Leserin das liefern kann, was sie vorhat, dürfen in der CSS-Anweisung font-family: XYZ; mehrere Font-Familien kombiniert werden — bis hin zur generischen Familie serif, sans-serif oder monospace. Der Browser sichert zu, — für jeden Buchstaben — den ersten Font aus einer der Familien zu nehmen, mit dem er den Buchstaben wie gefordert darstellen kann. Ob und wie gut das klappt, hängt auch von Art und Güte des Browsers ab. Und um der Designerin noch mehr Gewissheit zu bieten, ist das Konzept der Web Safe Fonts entstanden⁵: Fonts, von denen frau weiß, dass sie auf den Geräten (meistens) zur Verfügung stehen. Aus diesen wählt sie ersatzweise die, die ihren Designvorstellungen zwar nicht optimal, aber noch gut gerecht werden.

Damit entsteht eine Strategie, Google-Fonts lokal zu integrieren⁶:

Wir entscheiden uns für eine Font-Paar und nutzen — wie von bootScore empfohlen — den google-webfonts-helper, um die entsprechenden Google-Fonts herunterzuladen und die auch generierten @font-face-Anweisungen in Datei scss/_bscore_custom.scss einzufügen.

In der Datei scss/_bscore_variables.scss legen wir dann fest, wofür die Schriften überhaupt verwendet werden sollen. Dazu nutzen wir die Boostrap-Methodik:

Bei Bootstrap legen wir über die Variable $font-family-base die ‘Hauptschrift’ fest. Das kann die Familie einer Serifenschrift oder einer serifenlosen Schrift sein. Über die Variable $font-family-sans-serif legen wir die serifenlosen Hauptschrift fest. Eine Variable $font-family-serif gibt es nicht. Wollen wir für die Überschriften eine andere Familie nehmen, als die der generellen Hauptschrift, wären dafür die Variablen $headings-font-family und $display-font-family zuständig. So lassen sich alle Kombinationen einfach abbilden.

Und in welchem Zusammenhang …

… steht das mit unserer Migration zu bootScore? Nun, hat Web-Designerin im Rahmen ihrer Anpassungen die Frage einer guten Bebilderung beantwortet, kann sie entspannt Tags und Wolken in ihre Site einbinden, ihre Überblicksseite verbessern und eine eigene Landingpage gestalten. Ob die entstandene Fülle der eigenen Leserin wirklich nutzt, ob es nicht schlanker geht und wie, ob dezentere Verweise und spezielle Fonts auch für besondere Anlässe die Lesbarkeit erhöhen, all das gilt es zu bedenken. Das tut auch dieser Post.

Im Übrigen: Männer sind mitgemeint.

1. vgl. https://kinsta.com/de/blog/html-fonts/
2. vgl. https://www.w3schools.com/cssref/css3_pr_font-face_rule.php
3. vgl. https://technicalcommunicationcenter.com/2020/06/10/whats-a-font-font-family-typeface-font-face/
4. Deshalb ist es wichtig, die gewünschte Schriftfamilie mindestens in den Stärken ‘400’ und ‘700’ und die jeweils in den Typen ‘regular’ und ‘italic’ bereitzustellen.
5. vgl. https://www.w3schools.com/cssref/css_websafe_fonts.php
6. Die Alternative wäre, die Fonts fallweise direkt von Google-Font-Servern hinzuladen zu lassen. Das erleichtert Deine Arbeit. Und kompliziert Dein Datenschutzkonzept: Denn beim Herunterladen fragt Google Nutzerdaten ab, also die Deiner Leserin. Das verursacht Deine Site. Mithin müsstest in Deinem Datenschutzkonzept darauf hinweisen. Besser also, Du lädst die Fonts selbst herunter, integrierst sie in Deine Site und lieferst sie selbst mit aus.

The post Passende Web-Schriften appeared first on Freigiebigkeit.

Lösung

• Installiere das Plugin Recent Posts Widget With Thumbnails.
• Öffne Appearance/Widgets.
• Kopiere das Widget Recent Posts with Thumbnails in Dein allgemeines Sidebar Widget und konfiguriere es:
  • Setze die Nummer der zu zeigenden Posts auf 1, höchstens 2.
  • Wähle Show only sticks posts an.
  • Aktiviere Show excerpt.
  • Setze die Anzahl der zu zeigenden Zeichen auf 144.
  • Setze die Breite des zu zeigenden Thumbnails auf 120, die Höhe auf 75.
  • Aktiviere die Option Use aspect ratios of original thumbnails.
• Stelle Deine Site auf eine eigene Landingpage um.
• Lade die Landingpage mylap-sp0rp1 herunter.
• Kopiere sie unter dem Namen mylap.php in Dein Child-Theme.

Hintergrund

Die Idee dieser Änderung ist einfach: Als Sticky-Posts markieren wir ja eh nur die, die die Aktualität überstrahlen. Deshalb wollen wir sie unseren Leserinnen besonders ans Herz legen. Aber wir belassen es bei ein oder zwei Posts. Sie sollen unsere sonstigen nicht verdrängen.((Und ja, das heißt auch, dass wir unsere Sticky-Tags immer wieder umsetzen. Sonst wird es langweilig.)) Unsere bisherige Landingpage mylap-sp1rp1 stellte die uns übergreifend wichtigen Posts den zeitlich jüngsten voran. Das geht eleganter und dezenter:

Dazu installieren wir das Plugin Recent Posts Widget With Thumbnails. Es sagt von sich, es sei Open Source Software, die Datei Readme.txt im Repository verweist auf die GPL‑2.0 und der GPL‑2.0‑Lizenztext liegt auch dort. Damit sind wir hier auf der Seite der Guten.

Danach konfigurieren wir das Plugin so, dass es unserer Leserin hilft. Treu der Maxime, weniger ist mehr. Und weil wir damit die Stick-Posts in unserer allgemeinen Sidebar verschoben haben, brauchen wir auch die Landingpage nicht mehr, die beide Arten zeigt. Wir können also zu my-landing-page-stickposts-0-recentposts‑1 wechseln. Bingo.

Und in welchem Zusammenhang …

… steht das mit unserer Migration zu bootScore? Nun, hat Web-Designerin im Rahmen ihrer Anpassungen die Frage einer guten Bebilderung beantwortet, kann sie entspannt Tags und Wolken in ihre Site einbinden, ihre Überblicksseite verbessern und eine eigene Landingpage gestalten. Ob die entstandene Fülle der eigenen Leserin wirklich nutzt, ob es nicht schlanker geht und wie, ob dezentere Verweise und spezielle Fonts auch für besondere Anlässe die Lesbarkeit erhöhen, all das gilt es zu bedenken. Das tut auch dieser Post.

Im Übrigen: Männer sind mitgemeint.

The post Dezente Hinweise auf frühere Posts appeared first on Freigiebigkeit.