Lösung

1. Konzipiere das Erscheinungsbild Deiner Site.
2. Wähle die entsprechenden Bootstrap-Farbcluster.
3. Schreibe die Funktionsfarben entsprechend um.
4. Definiere die eigenen CSS-Klassen gemäß Deines Konzeptes.
5. Weise die Klassen den intendierten Elementen Deiner Website zu.

Hintergrund

Bootstrap hat den RGB-Farbraum in 10 Farbcluster unterteilt: Blau (blue), Indigo (indigo), Violett (purple), Rosa (pink), Rot (red), Orange (orange), Gelb (yellow), Grün (green), Petrol (teal), Cyan (cyan), Grau (gray). Jeder Cluster beginnt mit einer entsprechend hellen Farbe und geht 9 Schritten bis zu einer entsprechend fast schwarzen Farbe. Definiert sind die Farben als SASS-Variablen, für jeden Cluster nach demselben Muster. Zugreifen können wir so etwa auf ein $green-100, $green-200, $green-300, $green-400, $green-500, $green-600, $green-700, $green-800, $green-900, wobei $green der Farbe $green-500 entspricht.

Wollen wir diese Farben in einem unserer Element verwenden, definieren wir in unserer Child-Themedatei scss/bscore_custom.scss eine CSS-Klasse .cdg600 { color: $green-600; } und weisen die dem intendierten HTML-Element zu, wie z.B. hier <code class="cdg600">$green-600</code>. Diese Technik verengt den RGB-Farbraum zwar, sie erleichtert es uns aber, farblich differenzierte und trotzdem einheitliche Themes zu erstellen.

Neben der rein technischen Farbbehandlung geht Bootstrap auch konzeptionell neue Wege: Es gäbe — so der Gedanke — Site-übergreifende kommunikative Aufgaben, die von verschiedenen Elementen einer Site ausgeführt werden (können). Bootstrap erlaubt es, diesen Funktionselementen typische “Funktionsfarben” zuzuordnen. Welche Elemente einer Site welche Funktion übernehmen, entscheidet die Web-Designerin — und ordnet diesen die entsprechend “Funktionsfarbe” zu.

Konkret geht Bootstrap davon aus, dass es in Sites typischerweise (mehrere) Elemente gibt, die Erfolg signalisieren, die abschrecken, warnen oder informieren. Oder, dass es primäre Elemente gibt, sekundäre oder teriäre¹, dunkle oder helle Elemente. Für diese seitenübergreifenden kommunikativen Funktionen definiert Bootstrap ‘funktionale Farben’. Das entsprechende Bootstrap-color-Howto zeigt die Vorbelegung dieser ‘Funktionsfarben’.

Ein Bootstrap-basiertes Theme muss also nur noch seine Elemente entsprechend der vorgesehenen Funktionen mit den zugehörigen CSS-Klassen auszeichnen, um ein minimal konsistentes Farbkonzept zu realisieren. Das hat bootScore vorbereitet. Allerdings verwendet es die Standard-Funktionsfarben von Bootstrap. So entsteht ein recht “buntes” Farbkonzept. Wir können die Farbwahl jedoch ‘entschärfen’, indem wir die CSS-Definitionen der ‘Funktionsklassen’ überschreiben und so die konzeptionell passende Farbe auf alle entsprechend markierten Elemente übertragen. bootscore demonstriert diesen Ansatz, indem es die Primärfarbe von Blau auf Rot umsetzt — mithilfe der Zeile $primary:#FF0000; in der Datei bscore_variables.scss.

Dabei müssen wir den Wert der gewünschten Farbe jedoch explizit zuweisen, anstatt eine der Variablen aus den von Bootstrap definierten Farbclustern zu verwenden. Das ist nicht das, was wir eigentlich wollen. Intuitiv würden wir $primary:$red; schreiben. Leider ist das nicht möglich, weil die bootScore-Datei bscore_variables.scss vor der entsprechenden Bootstrap-Datei geladen wird.². Um also die von Bootstrap definierten und von bootScore verwendeten Funktionsfarben anzupassen, müssen wir die bestehenden Definitionen überschreiben, in denen wir explizit die Werte der beabsichtigten Clusterfarben verwenden. Dazu nutzen wir unserer Datei bscore_variables.scss.

Die Umdefinition einer Funktionsfarbe passt dann allerdings auch abgeleitete Farben an: Setzen wir die Primärefarbe auf rot, werden die Links rot eingefärbt, die Hintergrundfarbe der Badgets auf ein helleres Rot und deren Linktext auf ein dunkleres. bootScore reicht dabei ’nur’ die Entscheidungen von Bootstrap durch.³

Als Ausgleich für die Komplikation können wir dann alle vordefinierten Bootstrap-Variablen in unseren eigenen CSS-Definitionen verwenden, die wir in unserer Bootscore-Datei bscore_custom.scss definieren. Mehr noch: wir können auch die von Bootstrap vordefinierten CSS-Klassen (text|bg|…)-(primary|secondary|…|danger|…‘) direkt unseren HTML-Elementen zuordnen, sodass auch diese unseres Konzeptes entsprechend eingefärbt werden. Und noch weiter und feiner: Wir können auch bestehende Klassen — wie etwa die CSS-Klasse card — mit der SASS orienierten Definition .card { backgroundcolor: var(--#{$prefix}dark); in unserer Datei bscore_custom.scss auf einen schwarzen Hintergund umsetzen.⁴ Damit würden alle Karten in unseren Übersichtsdatei ‘verdunkelt’.⁵

Weil wir jedoch oft genug nicht alle Elemente ändern wollen, die mit vordefinierten Klassen ausgezeichnet sind, landen wir zum Schluß doch wieder bei der traditionelle Methode: wir definieren unsere eigenen Klassen, nutzen dabei Farben aus den Bootstrap-Clustern, und weisen unsere Klassen dann in den Templates den von uns intendierten Elemente zu. Und wie finden wir diese? Indem wir den Quellcode unserer bisherigen bootscore-Seiten studieren — und etwas ‘rumprobieren.

Um es zusammenfassen: Für einheitliches und technisch eingebundenes Farbkonzept, müssen wir

1. unsere Ziele definieren (hier:
   • Unsere Site soll blau-weiß-grau erscheinen = in Datei _bscore_variables.scss einfügen:
     • $primary: #0d6efd; // Wert von $blue-500
     • $secondary: #6c757d; // Wert von $gray-600
     • $info: #6ea8fe; // Wert von $blue-300
   • Hervorstechende Elemente sollen violett erscheinen = in Datei _bscore_variables.scss einfügen:
     • $danger: #520dc2; // Wert von $indigo-600
     • $warning: #8540f5; // Wert von $indigo-400
   • Nebensächlicher Text soll lesbar ausgegraut sein.
   • Die weißen Artikelteaser sollen schwach-blau umrandet sein = in Datei _bscore-sustom.scss einfügen: .card { border-color: $blue-600; }
   • Die Teaser auf der Landingpage und auf den Übersichtsseiten sollen auf einem leicht blauen Hintergrund abgelegt werden. = in Datei _bscore-sustom.scss einfügen: .page-template-mylap , .hfeed { background-color: $blue-100;}
   • Header und Footer sollen weiterhin auf grauem Hintergrund dargestellt werden.
2. die funktionalen Farben entsprechend umschreiben — in unserer Datei bscore_variables.scss
3. unsere Siteelemente entsprechend ihrer Funktion mit den Funktionsklassen auszeichnen⁶
4. unsere eigenen CSS-Klassen entsprechend unserer Ziele definieren — in unserer Datei bscore_custom.scss
5. unsere Klassen den vorgesehenen Elementen unserer Site zuweisen⁷

Und in welchem Zusammenhang …

… steht das mit unserer Migration zu bootScore? Nun, einmal angefangen mit Verbesserungen der Bildbehandlung, werden der Web-Designerin auch die verwischten ‘primären Beitragsgilder’ auffallen. Sie wird Lösungen ausprobieren und verfeinern. Und sie wird sie u.U. auch mit neuen HTML‑5 Techniken angehen. Denn damit wird eine ausgefallenere Bildstrategie samt integrierter Lizenzerfüllung und das eigene Logo erst richtig sinnvoll. Wie auch immer: Bilder bringen Farbe ins Leseleben. Zuletzt sollte all das also auch in ein eigenes Farbkonzept eingebunden sein. Zu dieser Thematik trägt auch dieser Post etwas bei.

Im Übrigen: Männer sind mitgemeint.

1. semantisch ist dies wohl eine Abstufung der Wichtigkeit
2. bootScore sagt, dass es damit der Bootstrap-Richtlinie folgt.
3. Mehr noch: Gefragt danach, welche HTML-Elemente welcher Funktion zugeordnet sind, empfiehlt bootScore, das einfach auszuprobieren.
4. oder wie auch immer die Funktionsfarbe ‘dark’ gerade definiert ist
5. Das ginge zugegebenermaßen auch einfacher, nämlich mit der Anweisung .card { backgroundcolor: $dark}.
6. wie in u.a. Tabelle demonstriert
7. wie oben vorgeführt

The post Das eigene Farbkonzept mit bootScore appeared first on Freigiebigkeit.

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.

Lösung

• Verwende die JavaScript-Bibliothek Bootstrap so, wie sie von bootScore bereitgestellt wird
• Verwende die JavaScript-Bibliotheken so, wie sie von WordPress geliefert werden
• Erstelle eine Tabelle mit den Informationen zur JavaScript-Konformität
• Erstelle für jede von bootScore oder WordPress gelieferte JavaScript-Bibliothek eine entsprechende Zeile in der JS-Tabelle.
• Binde diese Tabelle in Deine Open Source Compliance Page ein.
• Mache die Open Source Compliance Page über den ‘Footer’ Deiner Seiten zugänglich

Hintergrund

bootSCore enthält einige JS-Komponenten. Zum Beispiel seine eigenen entfalteten JavaScript-Bibliotheken((vgl. ./bootscore/js/theme.js)) — implizit lizenziert unter der MIT, aber ohne explizites Lizenzierungsstatement — und die minifizierte Bootstrap JavaScript-Bibliothek((vgl. ./bootscore/js/lib/bootstrap.bundle.min.js)) — durch ein entsprechendes Lizenzierungsstatement explizit unter der MIT-Lizenz gestellt. Aber keine davon enthält den Lizenztext selbst. Auch WordPress bringt einige eigene und einige minimierte JavaScript-Bibliotheken von Drittanbietern mit((vgl. https://codex.wordpress.org/Javascript_Reference bzw. ./wp-includes/js)), wie z.B. die jQuery-Bibliothek¹, die ebenfalls unter der MIT lizenziert ist und ein entsprechendes Lizenzstatement enthält, aber nicht den Lizenztext. Unabhängig davon, von wem die Website-Besitzerin diese Bibliotheken erhalten hat — von bootScore oder WordPress -, ist sie es letztendlich, die die Lizenzanforderungen erfüllen muss. Denn es ist ja ihr System ist, das die JavaScript-Bibliotheken an ihre Leser weitergibt.

Aber worin besteht denn nun eigentlich die Herausforderung?

Wie die JavaScript-Bibliotheken von Bootstrap und jQuery auch, sind die meisten JS-Bibliotheken MIT lizenziert. Diese FOSS-Lizenz verlangt, dass beides — die Copyright-Zeile und der Lizenztext — zusammen mit dem Open-Source-Programm verteilt wird. “The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.”((cf. MIT License))

Für (L|A)GPL-lizenzierte JavaScript-Bibliotheken gilt fast dasselbe: Diese Lizenzen erlauben die Weitergabe des Quellcodes, “[…] provided that one conspicuously and appropriately publishes on each copy an appropriate copyright notice and disclaimer of warranty […] and gives any other recipients of the Program a copy of this License along with the Program”.((pars pro toto vgl. GPL‑2.0. Zusätzlich verlangt die (A)GPL, dass jeder Code, der die (A)GPL-lizenzierte Bibliothek usw. verwendet, ebenfalls unter der (A)GPL lizenziert ist (Copyleft-Effekt). Aber darum geht es in diesem Zusammenhang nicht.))

Wir haben hier also einen Widerspruch: Auf der einen Seite lädt ein Browser nicht nur den Seitentext (HTML) herunter, sondern auch die JavaScript-Bibliothek. Dieser Download verbreitet den Code und löst damit die Notwendigkeit aus, die Anforderungen der Open-Source-Lizenz zu erfüllen. Auf der anderen Seite enthalten die komprimierten Bibliotheken — selbst wenn sie als Paket von den Autorinnen angeboten werden — in der Regel nicht mehr die notwendigen Lizenzinformationen. Denn je kleiner die Bibliotheken sind, desto schneller erscheinen die Seiten auf den Rechnern der Leser angezeigt.

Der Website-Betreiberin bieten sich zwei Möglichkeiten, mit dieser Herausforderung umzugehen: Entweder sie heilt die implizit von WordPress und bootScore übernommenen Pakete nachträglich (und (halb)manuell). Oder sie verwendet sie so, wie sie sie bekommen hat. Es ist klar: Heilen würde bedeuten, dass wir diese Aufgabe jedes Mal wiederholen müssten, wenn wir WordPress oder bootScore aktualisieren. Also wäre der andere Weg weniger aufwendig. Also besser — sofern es eine Option gäbe, die Idee und die Anforderungen freier Softwarelizenzen dabei (doch) nicht zu verletzen.

Die Lösung ist dies:

Geben Entwickler ihre JavaScript-Bibliotheken als ‘minified’ Versionen weiter, gehen sie davon aus, dass ihre JS-Bibliothek auch in dieser Version verwendet wird. Daraus schließen wir, dass die Copyright-Owner diese Art der Nutzung implizit (konkludent) zulassen. Auch, wenn die Bibliotheken dabei gegen die von den Entwicklern selbst gewählte Lizenz verstößt. Trotzdem sollten wir unseren Benutzern eine andere Möglichkeit anbieten, diese Informationen zu erhalten. Wir zeigen damit, dass wir die FOSS-Idee verstanden haben und respektieren. Außerdem müssen wir darauf achten, nur die minifizierten JavaScript-Bibliotheken in unsere Site einzubinden. Also nur die Form, die die Entwicklerin selbst zur Verfügung gestellt hat. Sonst unterliefen wir ja unsere Argumentation. Im Falle der Bootstrap-JS-Lib in bootScore und der jQuery-JS-Lib etc. in WordPress dürfen wir davon ausgehen, dass sie dies getan haben.

Wir haben so im Falle eines Rechtsstreits um die Lizenzerfüllung bei JS-Bibliotheken((Ich habe noch nie von solch einem Disput gehört!)) ein starkes Argument für die Legalität unseres Vorgehens. Und wir befinden uns in sehr guter Gesellschaft: Die Sekundärliteratur diskutiert es in diesem Sinne((vgl. https://www.iusmentis.com/computerprograms/opensourcesoftware/license-notices-web-applications/)) und sogar die FSF schlägt vor, so vorzugehen.((vgl. https://www.gnu.org/licenses/javascript-labels.en.html und https://www.gnu.org/licenses/javascript-labels-rationale.html)) Und die hat nun wirklich nicht den Ruf, die Einhaltung von Lizenzen auf die leichte Schulter zu nehmen.

Und in welchem Zusammenhang …

… steht das mit einer systematischen Erfüllung von FOSS-Lizenzen? Nun, dazu müssen wir halt auch politische Konnotationen bedenken, konzeptionelle und kontextuelle Aspekte analysieren — einzeln oder gemeinsam auf Konferenzen. Wir müssen konkrete Fälle und allgemeine Nebenwirkungen durchdenken, für Software, Bilder oder Dokumente. Wir müssen Trends benennen und Leitfäden erstellen. Vornehmlich aber müssen wir die Automatisierung der Lizenzerfüllung vorantreiben, unser Lizenzwissen frei zur Verfügung stellen, es in kleinere Tools gießen und in größere Systeme einbringen: Denn FOSS lebt von der Freiheit durch Lizenzerfüllung, im Großen und im Kleinen.

Im Übrigen: Männer sind mitgemeint.

1. vgl. wp-includes/js/jquery/

The post Lizenzkonformes Javascript 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.