Solution

• Define the appearance of your site.
• Select the appropriate Bootstrap color clusters.
• Rewrite the function colors accordingly.
• Define your own CSS classes according to our goals.
• Assign these classes to the intended elements of your site.

Background

Bootstrap has divided the RGB color space into 10 color clusters: Blau (blue), Indigo (indigo), Violett (purple), Rosa (pink), Rot (red), Orange (orange), Gelb (yellow), Grün (green), Petrol (teal), Cyan (cyan), Grau (gray).Blue (blue), Indigo (indigo), Violet (purple), Pink (pink), Red (red), Orange (orange), Yellow (yellow), Green (green), Petrol (teal), Cyan (cyan), Gray (gray). Each cluster starts with a corresponding light color and goes 9 steps up to a corresponding almost black color. The colors are defined as SASS variables, following the same pattern for each cluster. For example, we can access a $green-100, $green-200, $green-300, $green-400, $green-500, $green-600, $green-700, $green-800, $green-900, where $green corresponds to the color $green-500.

If we want to use these colors in one of our elements, we define a CSS class like .cdg600 { color: $green-600; } in our child theme file scss/bscore_custom.scss and assign it to the intended HTML element as herein <code class="cdg600">$green-600</code>. Although this technique narrows the RGB color space, it makes it easier for us to create color-differentiated yet coordinated themes.

In addition to the purely technical color treatment, Bootstrap also breaks new ground conceptually: There would be — so the idea — cross-site communicative tasks that are (can be) performed by different elements of a site. Bootstrap allows you to assign typical “functional colors” to these functional elements. Eventually, the web designer decides which elements of a site take on which function — and assigns them the corresponding “functional color”.

Specifically, Bootstrap assumes that there are typically (several) elements in sites that signal success, deter, warn, or inform. Or that there are primary, secondary, or tertiary elements¹, dark or light elements. Bootstrap defines ‘functional colors’ for these cross-page communicative functions. The corresponding Bootstrap-color-Howto shows the default assignment of these ‘functional colors’.

Hence, a Bootstrap-based theme only needs to mark up its elements according to the intended functions with the associated CSS classes to implement a minimal consistent color concept. This is provided by bootScore. However, it uses the default function colors of Bootstrap. Ultimately, this results in a rather ‘colorful’ color concept. However, we can align the colors by overwriting CSS definitions of the ‘function classes’ and thus transferring the conceptually appropriate color to all correspondingly marked elements. Bootscore demonstrates this approach by switching the primary color from blue to red — with the help of the ‘command’ $primary:#FF0000; in the file bscore_variables.scss.

However, we have to explicitly assign the value of the desired color instead of using one of the variables from the color clusters defined by Bootstrap. That’s not what we actually want. Intuitively we would write $primaty:$red;. Unfortunately, that is not possible because the bootScore file bscore_variables.scss is loaded before the corresponding Bootstrap file.² Thus, for customizing the functional colors defined by Bootstrap and used by bootScore, we need to overwrite the existing definitions where we explicitly use the values of the intended cluster colors. To do that, we use our file bscore_variables.scss in our child theme.

However, redefining a function color implicitly also adjusts the dependent colors: If we set the primary color to red, the links become red, the background color of the badges becomes a lighter red, and their link text a darker red. But, bootScore ‘only’ passes the decisions of Bootstrap through.³

As compensation, we can then use all the predefined Bootstrap variables in our own CSS definitions we gather in our bootScore file bscore_custom.scss. Moreover: we can assign the CSS classes predefined by Bootstrap (text|bg|...)-(primary|secondary|...|danger|...' directly to our HTML elements for functionally coloring them according to our concept. And even further and finer: In our file bscore_custom.scss, we can also overwrite existing classes — such as the CSS class card by SASS-oriented definitions in the command card { backgroundcolor: var(--#{$prefix}dark); to get a black background.⁴ This would ‘darken’ all the cards in our overview file.⁵

However, because we often don’t want to change all the elements that are marked with predefined classes, we end up using the traditional method again: we define new classes, using colors from the bootstrap clusters, and then assign them to the elements we intend to use in the templates. And how do we find these? By studying the source code of our previous bootscore pages — and trying things out.

To make a long story short: For creating a unified color concept, we must

1. define our design goals — for example:
   • The site should appear green-white-grey. => To get that, add to your file bscore_custom.scss
     • $primary: #146c43; // $green-600
     • $secondary: #6c757d; // predefined value of $gray-600
     • $info: #0d6efd; // predefined value of $blue-500
   • Prominent elements should appear purple (or dark red). => To get that, add to your file bscore_custom.scss
     • $danger: #520dc2; // predefined value of $indigo-600
     • $warning: #8540f5; // predefined value of $indigo-400
     • $success: #20c997; // predefined value of $teal-500
   • Secondary text should be legibly grayed out.
   • The white article teasers should have a faint green border. => To get that, add to your file bscore_custom.scss
     • .card { border-color: $green-600; }
   • The teaser cards on our landing page should be presented on a slightly green background. => To get that, add to your file bscore_custom.scss
     • .page-template-mylap , .hfeed { background-color: $blue-100;}
   • The header and footer should continue to be gray, as it is by default designed by bootScore
2. select the Bootstrap color clusters we want to use (here: the clusters blue, purple, and grey).
3. rewrite the functional colors accordingly — in our bscore_variables.scss file.⁶
4. define your own CSS classes according to our goals — in our bscore_custom.scss file.
5. assign these classes to the intended elements of your site.⁷

And how does this …

… support our migration to bootScore? Well, once started with improving the image handling, a web designer will also notice the blurred ‘featured images’ of bootScore. She will try and refine solutions. And she may also tackle them with new HTML‑5 techniques. Because with that, a fancier image strategy combined with an integrated license fulfillment process and its own logo will really make sense. However, pictures bring colors to reading. So they should be integrated into a customized color concept. This post also contributes something to this topic.

1. which probably refer to different degrees of importance
2. bootScore says that by doing so it follows the Bootstrap guideline.
3. Moreover, asked which element has got which function, bootScore recommends trying it out.
4. or however we’ve defined the function color ‘dark’
5. Admittedly, this could also be done more simply, namely with the statement .card { backgroundcolor: $dark}
6. as shown in the table
7. as described above

The post Customized Colors With bootScore appeared first on FODINA 4 FOSS.

The plugin bs-cookie-settings itself only provides us with the cookie query. How to activate this, I had already described in a previous post. However, the bootScore developers leave the implementation of the corresponding semantics to the respective web designer. Here is a variant that can be freely reused:

Solution

• Download the JS cookie library from cdnpkg.com (or wherever) and place it (unpacked) under the name js/js.cookie.min.js into your child-theme folder.
• In your file functions.php extend the function bootscore_child_enqueue_styles() by the line

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

• Expand the file js/custom.js of your child theme in the following manner:

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

Background

We could set and evaluate cookies with native JavaScript. Nevertheless, it’s easier with ready-made libraries. WordPress already brings jQuery with it. For using that, bootScore offers us a way to add custom JavaScript/jQuery functions to our bootScore child theme.

There used to be a real jQuery-Cookie-Plugin for cookie management. This has since been archived and migrated to an independent js-cookie-JavaScript library. To use that, we must download it and place it into the JavaScript folder of our child theme — under the name js/js.cookie.min.js. As described above, we also must enforce the function bootscore_child_enqueue_styles() of our file functions.php to load that library.

Eventually, we should implement an algorithm for evaluating the cookie settings by expanding the file js/custom.js. That algorithm should work like this:

• First, we try to read the cookie bootScore-Cookie-plugin stores under the name bs_cookie_settings.
• If it doesn’t exist yet, our reader hasn’t agreed to use cookies. So we are not allowed to write any yet.¹
• Once our reader has ‘confirmed’ the cookie dialog to whatever extent, the bs cookie plugin stores the cookie bs_cookie_settings. Its value contains a JSON object:

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

• Thus, we must parse that JSON object before we can — on the JavaScript level — access the list of allowed cookie groups via allowedCookies.level and use the method includes of a list object to query which of the cookie groups necessary, analytics, and /or advertising our reader has allowed us to write.
• And for each allowed group we now may write the corresponding cookies.²

And a last hint: JavaScript modifies pages dynamically. But the cache stores the respective results. Thus, sometimes it’s helpful if we delete the cache for getting the results of our modifications run.

And how does this …

… support our migration to bootScore? Well, besides her normal design work, the web-designer must deal with some legal requirements, as — for example — those of the DSGVO privacy, of having a cookie consent dialog and the respective semantic, of having a data privacy page, an imprint, an image reference page, and a FOSS compliance page. This post shall support you to manage your legal issues.

1. Yes, formally we may write the technically necessary cookies without our reader’s consent. But before we do that, we must inform her that we are going to do so. And the only way to convince ourselves that she has indeed read it is to wait for the written cookie.
2. whereby we refer to the legal permission for the technically necessary cookies

The post Cookies — properly managed by bootScore appeared first on FODINA 4 FOSS.

For this, bootScore offers us a configurable cookie approval dialogue evaluated by the bsCookie-plugin:

Solution

• Download bsCookie.
• Install the zip file via the plugin management of your WordPress backend.
• Determine the cookies you want to install on your reader’s computer.¹
• Assign each of these cookies to one of the groups ‘necessary’², ‘advertising’ or ‘analytics’.
• In the dialog ‘Appearance/Widgets’ drag a widget ‘Customer HTML’ into the widget group Footer‑4.
• Enter the script lines into that sub-widget as offered by bsCookie documentation.
• For each of your plugins add an entry into the corresponding section.
• Link your privacy page into the dialog by replacing #yourprivacypolicy accordingly.
• Translate the texts into the language of your site (or create an additional entry according to your multilingual strategy).

Background

Asking for permission to write cookies via a dialogue is only one side of the coin. Cookies can also store (personal) (identification) data. So, the respective web server can ask for that information and hand it over to third parties. Hence, we must mention such cookies in our data protection concept additionally. To enable our readers to call this page directly from the cookie consent dialogue, the bsCookie dialogue text contains a link whose value #yourprivacypolice we should aling accordingly.

It has become a good tradition to group cookies functionally and to ask once for the complete group whether we may file the respective cookies. That’s legally not necessary: We could also let the use of cookies agree or disagree quite generally.³ Or we could make every single cookie selectable or deselectable — which would overload the dialogue.

However, at first, we need to know which cookies our site writes and what the cookies actually do. Our browsers can support us. For example, by means of its ‘Privacy and Security’ dialog. Or with the help of a browser plugin⁴, which shows directly for each called site/page, which cookies have been written by it. But what our cookies do, we have to determine separately.

Once we have grouped our cookies functionally, we only need to create the appropriate groups as sections in the bsCookie dialog. Then we must insert for each cookie — associated with that group — an entry in the respective section. For the three common groups ‘necessary’, ‘advertising’, and ‘analytics’ bsCookie already provides the respective code. If these groups fit our needs, it is sufficient for us to describe the cookies in and with the single entries. Assuming we wanted to get permission to write the three cookies necessaryBsCookie, advertisingBsCookie, and analizingBsCookie, the JavaScript code of the bsCookie consent dialogue should look like this:

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

    // obtain plugin
    var cc = initCookieConsent();

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

      languages: {
        'en': {
          consent_modal: {
            title: 'Cookie Consent Request',
            description: 
'We use cookies to remember and reuse your preferences for future visits. By clicking “Accept all”, you permit us to use all cookies, technically necessary as well as functionally helpful. By clicking “necessary only”, you forbid us to use the functionally helpful, but technically not necessary cookies. For a more detailed consent, visit <a data-bs-toggle="modal" href="#bs-cookie-modal">Cookie Settings</a>.',
            primary_btn: {
              text: 'accept all',
              role: 'accept_all'
            },
            secondary_btn: {
              text: 'necessary only',
              role: 'accept_necessary'
            }
          },

          settings_modal: {
            title: 'Cookie settings',
            save_settings_btn: 'Save settings',
            accept_all_btn: 'accept all',
            reject_all_btn: 'necessary only',
            close_btn_label: 'close',
            cookie_table_headers: [
              { col1: 'Name' },
              { col2: 'Domain' },
              { col3: 'Expiration' },
              { col4: 'Description' }
            ],
            blocks: [
              {
                title: 'Cookie usage',
                description: 
'We use cookies to provide core website functions and to enhance your reading experience. For each category, you can choose to use them or not. For more details about cookies and other sensitive data, please read our <a href="https://karsten-reincke.de/datenschutz">Privacy Policy</a>.'
              }, {
                title: 'Necessary',
                description: 
'These cookies are essential for our website. Without them, the website would not work properly',
                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: 'deleted if your session becomes invalid',
                    col4: 
'cookie into which bootScore and the plugin bsCookies stores your cookie preferences',
                    is_regex: false
                  },
                  {
                    col1: 'nec­es­saryB­sCook­ie', 
                    col2: 'https://karsten-reincke.de',
                    col3: 'next 100 days',
                    col4: 'demo cookie of "pimp your BootScore"',
                    is_regex: false
                  },                 
                ]
              }, {
                title: 'Analytics',
                description: 
'These cookies allow the website to remember the choices you have made in the past',
                toggle: {
                  value: 'analytics',     // your cookie category
                  enabled: false,
                  readonly: false
                },
                cookie_table: [           // list of all expected cookies
                  {
                    col1: 'anal­iz­ing­B­sCook­ie',         
                    col2: 'https://karsten-reincke.de',
                    col3: 'next 10 Days',
                    col4: 'demo cookie of "pimp your BootScore"',
                    is_regex: false
                  }
                ]
              }, {
                title: 'Advertising',
                description: 
'These cookies collect information about how you use the website, which pages you visited and which links you clicked on. All data is anonymized and cannot be used to identify you',
                toggle: {
                  value: 'advertising',
                  enabled: false,
                  readonly: false
                },
                cookie_table: [             // list of all expected cookies
                  {
                    col1: 'adver­tis­ing­B­sCook­ie',
                    col2: 'https://karsten-reincke.de',
                    col3: '2 weeks',
                    col4: 'demo cookie of pimp your BootScore',
                    is_regex: false
                  }
                ]
              }, {
                title: 'More information',
                description: 
'For further questions concerning our data management, feel free to <a href="https://karsten-reincke.de/impressum">contact us</a>.',
              },

            ]
          }

        }
      }

    });
  });
</script>

Entering the information into the code of the cookie consent dialogue is one thing. Activating the code is another. To do that, we put the customized bs-cookie-settings JavaScript code into a Custom HTML element that we added to the Footer 4 widget. In principle, we could embed the Custom HTML element in other widgets as well. However, bsCookie suggests Footer 4 because the JavaScript code should be embedded at the end of a page. Anyway, all pages using a template containing the Footer 4 widget will then display the cookie. That’s the method of how we solve the problem of ‘deep links’.⁵

That left us with three final tasks:

• First, we will often want to linguistically customize our consent dialogue as well. For that purpose, we can modify the JavaScript code mentioned above.
• Secondly, the dialog color is determined by the definition of the functional color $warning. Those who nevertheless want to customize the dialog may use her file <code>_bscore_custom.scss</code>:

  
  // 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;
  }
   
  

• Third, we need to implement the semantics of the cookie consent dialog. If we want to walk the talk, we need to implement our ‘storing the cookie JavaScript code’ in a way that it writes only the technically necessary cookies without consent, and that it otherwise stores only the cookies from the groups for which there is consent.

I will take up this last point in a separate post …

And how does this …

… support our migration to bootScore? Well, besides her normal design work, the web-designer must deal with some legal requirements, as — for example — those of the DSGVO privacy, of having a cookie consent dialog and the respective semantic, of having a data privacy page, an imprint, an image reference page, and a FOSS compliance page. This post shall support you to manage your legal issues.

1. We have to keep in mind that our plugins can also try to store cookies. So it’s not enough to just look for the corresponding JavaScript commands in our own posts and pages
2. Cookies that we assign to this group will lastly be placed on our reader’s hard drive even without explicit consent, precisely because they are technically necessary. So we must be able to prove if necessary that these cookies are indeed technically necessary.
3. However, greater granularity is in our interest. Because if a reader doesn’t want one thing — e.g. advertising — she could still allow the other — e.g. analytics. That way, we would still learn at least a part of what we hoped to learn overall.
4. e.g. with the Cookie Editor
5. We must keep in mind that our readers could directly call links to deeper embedded pages. Even in this case, we may only write cookies, if we are allowed to do so.

The post Cookies — properly used in bootScore appeared first on FODINA 4 FOSS.

To clarify the consequences of their force, let me first summarize the eleven commandments that I had taken from YOAST and with the implementation of which I have so far always been able to get green YOAST ‘traffic’-lights — one for “SEO” and one for readability. Just for the sake of completeness, let me second note that I could successfully apply for indexing at Google for the pages prepared accordingly.¹

Solution

• Define a key phrase that reflects the subject² of your page.³
• Just as defined, put that key phrase at the beginning of your page title.⁴
• Just as defined, integrate that key phrase somewhere into the first paragraph of your page, too.
• Include that key phrase in the meta description of your page, which must have at least 120 and no more than 156 characters
• Link your post to other pages on your blog about the respective topic.
• Link your post to external pages about that topic.
• Write only a few sentences with more than 25 words.
• Link your (short) (main) sentences by (logical) conjunctions.
• Do not let your paragraphs ‘swell’ over 150 words, or at least stay under 200.
• Use only a few passive constructions, and make active statements.
• Explicitly request Google to index your new page in the Search Console.⁵

Background

One thing in advance: If you already think that this post does not follow these rules, let me tell you: Yes, it doesn’t. Intentionally. Let us test by this article what happens if we don’t submit our posts to the unifying dictates of Google and YOAST.

The result of these ‘recommendations’ is a different writing style than you and I (occasionally) prefer. It’s known that passive sentence constructions are more difficult to understand and thus require more reading work.⁶ And it’s known, that our reading life is made easier by short sentences. If we are forced by search engines to write this way, they are doing our readers some good. Even if we are ‘gently’ moved away from the academic writing style via the threat that our texts will not be indexed.

Hence, this does not annoy me. The thing with the key phrase, however, does. Because it prevents me from arousing a desire to read the following article by a merely suggestive title, and from letting concrete meaning and context of the headline grow out of the first sentences. Free associations — that’s what I like to work with. Actually. But I can’t, if I want to obey the commandments. An example: In my first run, I had titled my article ‘Clouds and Lists — 2 on 1 Stroke’ as ‘2 in 1 Stroke’ by which I hoped to open a little associative space linking my post to the fairy tale brave little tailor.⁷ ‘2 in 1 Stroke’ — that is an elegant title. Prefixing it with the key phrase ‘Clouds and Lists’ takes the point out of the title and makes it unwieldy. Additionally, repeating the key phrase in the first paragraph turns us into pushy babblers — just to get our green YOAST traffic lights and become part of the Google index.

A good example — from a SEO point of view — is the page https://wolf-of-seo.de/was-ist/fokus-keyphrase/. Here, the key phrase focus keyword is placed at the beginning of the title and immediately repeated in the first, very short paragraph — together with its twin focus key phrase. And in the first six sentences⁸, these phrases occur more than 10 times. The ‘wolf of seo’ should not have any problems getting his page indexed. And even more: the content of his article is very informative! Only stylistically — stylistically it is grotty. If you read the post slowly, you will surely notice its redundant verbiage. The annoying thing about the dictates of good SEOcity is that we obviously have to write like this if we want to be indexed. Because only what is indexed can be found and ranked at all.

If you’ve read the wolf-of-seo’s article slowly, read my article in the same way. And you will notice that it is even more grotty than his! Because I have intentionally violated the above commandments:

• My key phrase ‘styleXpolice’ does not appear in the title, in the first paragraph, or anywhere else, hence not even in the slug.⁹
• I’ve included a ‘meta description’ that is intentionally too short and misses the topic.
• This post uses links to external sites, but internal links to other pages on my site.
• My text uses too many passive constructions¹⁰, has one too-long paragraph¹¹, and uses too long sentences¹².

Because of these deviations from the rules, I got an orange YOAST traffic light for this post in terms of SEO and a red one in terms of readability.

Thus, we can now test, how long Google takes to index this article.¹³ As soon as it has been indexed, I will let you know. But you can also try it by yourself. Just ‘google’ for ‘SEOcity’. This word exists as a noun (so far) only in this article.

• Sitemap updated: 2023-08-27 / evaluated: 2023-08-27 (maybe earlier than updated)
• Post found: ????-??-?? / crawled: ????-??-?? / indexed: ????-??-??
• Indexing manually ordered: ????-??-??
• Post found: ????-??-?? / crawled: ????-??-?? / indexed: ????-??-??

1. by using the option of the search console to hand over a URL manually.
2. The wolf of seo says that the keyword phrase should not capture what your post is about, but what your post is perfect for. But if you apply the rules 2 and 3, the difference between these viewpoints shrinks considerably.
3. Keep in mind: Use only 2 words, at most 3. Because in that form, the key phrase must be placed at the beginning of the title and integrated into the body text. Do not trust YOAST to be able to understand syntactic variants — even if it promises to do so
4. If you shorten the resulting slug of your page, use at least speaking syntagms in your URL.
5. Don’t rely only on your updated sitmap.
6. If you don’t believe that, you may deliberately ‘torture’ yourself through this intentionally passivated paragraph
7. Unfortunately — after having read story again in its entirety — it makes me a little uncomfortable myself. It is already a bad dazzler, that brave little tailor, not only a sly one. So, the story does not open an associative space into which I would like to blow myself
8. which — in this case — is equivalent to: in the first 6 paragraphs
9. Inside of the post, I can not write this word as I’ve really used it (without an X), because otherwise, YOAST says “The keyphrase was found 1 time. That’s less than the recommended minimum of 5 times for a text of this length.”
10. “17% of the sentences contain passive voice”
11. “1 of the paragraphs contains more than the recommended maximum of 150 words.”
12. “31.9% of the sentences contain more than 20 words, which is more than the recommended maximum of 25%”
13. In order not to compare pears with apples, I will first inform Google about this new post only by an update of my sitemap. Some months later, I will also request Google manually to index this post.

The post My Googlized Writing Style appeared first on FODINA 4 FOSS.

Solution

• Replace all schematic slugs with talking ones.
• Link every post and page to all other internal, related posts or pages.
• Install YoastSEO.
• Implement so many improvements suggested by YoastSEO that its traffic lights turn green.
• For every single page and post, explicitly ask Google via the Google Search Console to index that text.

Background

What has happened, that I changed my mind? After submitting my sitemap sometime in April, Google had indexed only 6 of my 109 pages over 3 months. It did not grumble about the quality. It simply announced that it had found 81 pages or posts and had crawled 17, but had not indexed any of them. Google did not consider my texts worthy of indexing. Despite my interesting topic, ‘bootScore’. And in spite of the articles being so relevant, they could inspire the project ‘bootScore’. In this situation, trying to improve my ranking was nonsense: what’s not indexed, is not found at all.

It took me a while to understand what had happened. And it took me even more time to fix that:

While migrating to bootScore, I wanted to condense my site. It should become more reader-friendly with less redundancy. Fewer bells and whistles. That’s why I mapped my thematic clusters onto categories and tags and properly assigned my texts to them. I wanted to take advantage of what bootScore brings to the table on its own. On each page, our readers can call the related posts by clicking on the assigned keywords. So why should I additionally link a post to related ones manually? Why should I hook individual pages or posts into my menu? A clever guiding system of categories without any additional inner linking should be enough.

But that’s exactly what Google sees differently! Pages that are not linked to other pages on the same site are not important — apparently, even in the eyes of the author. Otherwise, she would want to lead her readers there. So why should Google index them? My textbooks((Pars pro toto: cf. Czysch, Stephan: SEO mit Google Search Console, 2. Ed., Heidelberg 2017, pp. 168ff)) had always pointed out that! It was my fault to ignore that.

Just, as my fault for grouping my posts with nonspeaking ‘slugs’: If I — for example — used a cluster ‘image’, I thought I could name my posts ‘image‑a’ , … ‘image‑i’. So, I had the same page names on the German and the English sites. Also, a bad idea that causes Google to take the posts as unimportant.((pars pro toto: cf. Dziki, Julian: Suchmaschinenoptomierung für dummies, 2. Ed., Weinheim 2021, p. 62)

After having understood these side effects, I reworked everything. I replaced the symbolic page names with speaking ones. I installed YoastSeo and implemented so many of its measures concerning the topics ‘SEO’ and ‘readability’ that the respective traffic lights switched from red to green. Or at least to yellow. All in all a very time-consuming work.

Nevertheless, there was still no inner linking with it. That’s why I wrote a summary for each of my thematic clusters and linked its words to the intended ‘siblings’ of posts and pages. Moreover, because — in the Future — I would have to update these summaries often, I reduced my typing work by implementing these summaries as ShortCodes. So, a simple string at the end of each post and page would integrate the respective internal linking.

Nevertheless, the real indexing breakthrough came only after I had submitted each post and page individually and manually to Google Search Console for indexing — including the time-consuming indexability checks for each text. Now Google has indexed 84 of my 74 articles and 18 pages of my German site. What still is not indexed is indeed less important, like my privacy page or the image proof. And on my English site it looks even better: of the currently offered 53 posts and 15 pages, 114 are indexed — from which we may derive that the Google index still contains outdated links. For those, however, I preferred to follow the recommendations of the textbooks right away. I implemented respective redirects with the plugin ‘Quick 301 Redirects’.

So what was the decisive measure for success? I’m afraid it takes all of them. Even if I had to change my writing style to do it. Especially in the implementation of YoastSEO recommendations. But more about that later. As soon as Google has indexed this post. Always first things first.

And how does this …

… support our migration to bootScore? Well, if a web designer must abandon her current WordPress theme, she needs a replacement. A free ‘off-the-shelf’ theme, she probably wants to personalize. First a bit cosmetically, then in terms of the gray value of her pages, multilingualism and internal reference techniques and linking. Finally, she perhaps enables special footers, a secondary menu or a copyright notice before checking the SEO features of the selected theme. This is a way that this post supports too.

The post Internal Linking — a Reset appeared first on FODINA 4 FOSS.

As a starting point, I had (already)

• installed WordPress¹,
• entered (test) data²,
• installed bootScore, and activated it as my theme³.

Eventually, this results in a way

:

1. Font Awesome — one symbol says more than 100 words: ShortCodes and CSS classes
2. SEO from the beginning: HTML semantics, keywords, and sitemaps, and no dead links, please.
3. The ‘(un)important’ at the bottom: The discreet and comprehensive footer area for the ‘subordinated’ legal stuff, the subordinated secondary menu, and the custom copyright line.
4. Thinking multilingualism: bilingualism without WP globe
5. For clarity: the deeper branched menu with integrated shortcodes, clean layers, and readable stacking, which nevertheless has to be no H‑OVER menu.
6. Don’t fiddle, automate: The built-in hyphenation
7. A picture says more than 1000 words, for example,
   • an image with a fancy box manually inserted into the text — gladly accelerated delivered via WordPress pre-calculated image sizes or as SVG.
   • an automatically managed ‘primary post image’, not (less) blurred when adjusted for Responsive Design’s sake: That organizes the modern IMG tag with the source information probably best. Faster to implement, but less effective, would be to have WordPress calculate another image size in advance.
   • images, that are offered on the web as really free images if we provide an image directory to meet licensing requirements.
   • And the little browser images next to the URL? Or the logo? For that, we use bootScoore’s logo and favicon system.
8. Easing the finding: TAG clouds and post lists in the sidebar
9. The walled overview: The Masonry Contribution List.
10. First things first: a dedicated landing page — self-designed — and then get rid of what’s distracting, use context-sensitive sidebars and more discreet references to recent posts.
11. Readability: bootScore and the custom general font and the font for special occasions
12. Respecting the law is a need: data protection, a proper cookie dialog, and cookie management.
13. The first impression counts: customizing the color concept.

By following these steps, a bootScore-based website in responsive design is created, that documents the way to it in itself. So that I can also lookup in the future, how I have done it in the past. If this also benefits others, that would be a welcome side effect.

1. instructions on how to do this are aplenty, including one from WordPress itself.
2. e.g. with those of the site to be migrated or the Theme Unit Test
3. e.g. according to bootScore instructions

The post Pimp Your bootScore appeared first on FODINA 4 FOSS.

Solution

• I. Use only the personal data that you really need for the functioning of your system.
• II. If you collect personal data, tell the owners,
  • that you are going to do so,
  • for what purpose you use the data,
  • what legal basis authorizes you to do so,
  • with whom you share the data,
  • how long you will store it,
  • how they can ask you which data you have stored over time
  • how they can have the data deleted again.
• III. If you store data on the computer of your users, which they did not request directly or indirectly, ask them beforehand for permission.

Background

If I proceed according to this — so I make myself believe again and again — I will design my sites in a way that I avoid the roughest traps¹ and errors². Because I always have one thing in mind: with a mere cookie banner it is not done:

1. The first thing I consider is where my blog as a system collects personal data. The ones that I explicitly request in and with forms are the easiest for me to notice and remember. Here I know — qua office — what I do with them and to whom I pass them etc.
2. Furthermore, I am aware that IP addresses are also considered personal data — although the internet would not function without them.
3. Additionally, WordPress can collect, note, and send data to third parties — as well as the plugins I’ve activated, the JavaScript libraries I’ve installed, the Google fonts I’ve integrated, etc., etc.
4. Eventually, my commenters are usually made recognizable via the common Gravatar system.

I have to sort out this mishmash:

• Rule (I) tells me that less is more: the fewer data I ask for and the fewer plug-ins I use, the leaner my data protection concept can be. So I clean out here, e.g. by treating productive and developing systems differently.
• Rule (II) tells me that I must actually describe the remaining data sets in the data protection concept. So I also determine what data my plugins, font requests, and other technical components collect, how they store it, and where they pass it on.
• Rule (III) tells me that I have to get permission to write files, i.e. cookies, to my user’s computer — either by law, as in the case of technically necessary cookies, or by consent of my user. And to get this consent, it is helpful to specify the purpose and effect.

My next posts describe how I have implemented this in my bootScore-based site concretely.

And how does this …

… support our migration to bootScore? Well, besides her normal design work, the web-designer must deal with some legal requirements, as — for example — those of the DSGVO privacy, of having a cookie consent dialog and the respective semantic, of having a data privacy page, an imprint, an image reference page, and a FOSS compliance page. This post shall support you to manage your legal issues.

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

The post Data Privacy, DSGVO, and Cookies appeared first on FODINA 4 FOSS.

To group fonts, the file bootstrap/_variables.scss provides the variables $font-family-base, $font-family-sans-serif, $font-family-monospace and $font-family-code. A variable $font-family-serif does not exist. If we overwrite family-base in our _bscore_variables.scss file, we redefine the default. If we want to use a deviant font for our headings, we have to redefine the variables $headings-font-family and $display-font-family. This is sufficient if we want to use only two font families. Here is a way to use more groups:

Solution

• Define the variable $menu-font-family: 'PT Sans', sans-serif, !default; in your child theme file scss/_bscore_variables.scs
• Add the following lines to your child theme file scss/_bsscore-custom.scs:

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

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

• Assign the new class to the widgets Footer 1 to Footer 4 containing a menu list via <ul class="footerSubMenu">.

Background

Again, briefly, about the need to do that:

Menus usually look better with sans-serif fonts. If we have already assigned a sans-serif font to the $font-family-base variable, everything is fine. But if we have assigned a serif font and want to have a deviant font for our selectors, we must select a sans-serif font for the headlines and for the menus. bootScore has embedded the main menu into a div with the ID bootscore-navbar. We can reuse that. But for the submenus in the footer area, we must define a corresponding class and assign it to the lists manually.

And how does this …

… support our migration to bootScore? Well, when the web designer has completed her work on good illustrations, she can relax and integrate tags and clouds into her site, improve her overview page and design her own landing page. Whether the resulting fullness really benefits her own reader, whether it can become slimmer and how, whether more discreet references and specific fonts also increase the readability, all this she should nevertheless consider while implementing these features. This post supports these steps towards a personalized bootScore site.

The post Extra Fonts for Specific Cases appeared first on FODINA 4 FOSS.

Solution

• Choose from the Google Fonts:
  • a font with serifs (e.g. pt-serif or noto-serif),
  • a matching sans-serif font (e.g. pt-sans or noto-sans),
  • a matching monospace font (pt-mono or noto-sans-mono)
  • and maybe a special font for headlines (e.g. arima-madurai or eb-garamond)
• Select each font after another in the google-webfonts-helper and
  • leave the charset on latin * select — if available
  • select — if available — the sizes 400 and 700.
  • select — if available — the styles regular, regular italic, bold and bold italic.
  • copy the font-face-code created in google-webfonts-helper into the file scss/_bscore_custom.scss.
  • download the zip-package from *google-webfonts-helper
• Create a folder fonts in your child theme.
• Unzip all downloaded zip packages in the folder fonts.
• Extend the file scss/_bscore_variables.scss with the lines:

  $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;

Background

Dealing with Fonts is — in terms of concept and content — a wide field¹:

In typography, it is common to distinguish between serif fonts and sans-serif fonts. Serif fonts are better for printed running text because their horizontal extensions on the letter lead the eye in a better way. On the other hand, it was long thought that sans-serif fonts were more readable on screens. However, the finer the screens became over time, the finer the serifs could be displayed. The readability increased, and the eyes tired less. Thus — today — it is said that there is no longer any real difference in legibility: Serif fonts and sans-serif fonts can be used equally.

Using only one font for all, however, gets boring. At least the headings and body text should differ. On the other hand, too many fonts reduce readability due to the graphical unrest. And readability and immediate perceptibility is the measure of quality. Thus, the modern web designer works with pairs, one font for the headline, and one for the body text. This is why we are so often ‘recommended’ font pairs today, where the fonts are quite wildly combined.

In this context, the distinction between font-family and font-face is also important. With the CSS statement font-family: XYZ; we tell the browser — imprecisely speaking — that it should display the text in an HTML tag with the font XYZ. In fact, however, we are telling it to display the text with a suitable font from the font family XYZ. With the CSS statement @font-face {...}², we have previously told it that a certain well-designed font from a certain font family (font-family: XYZ) with a certain style (font-style: [normal|italic]) and a certain weight (font-weight: [<400<...<700<]) is available and where to find it. It is then up to the browser to pick the most suitable font out of the group font-family XYZ for a particular place in the HTML source code. After all, it must not only display the font itself but also take into account the specifications ‘normal, italic, bold, bold-italic’.³

If a specified font is not available — for example, because the browser could not download or understand it — then the browser chooses another ‘sans-serif’ resp. ‘serif’ font from those that are accessible. If a font of a font family does not exactly fit the other required properties, the browser can ‘produce’ them by tilting or amplifying a font computationally. However, such ‘calculated’ fonts look worse than those explicitly designed that way.⁴.

So, in principle, the web designer cannot be sure how her text will actually look on a reader’s computer. To increase the likelihood that the designer will be able to provide her reader with what she intends, the CSS statement font-family: XYZ; may combine several font families — up to the generic serif, sans-serif, or monospace family. The browser assures — for each letter — to take the first font from that family, with which it can display the letter as requested. Whether and how well this works also depends on the type and quality of the browser. To offer the designer even more certainty, the concept of Web Safe Fonts has emerged⁵: Fonts from that she knows that they are (mostly) available on the devices. From these fonts, she can choose a substitute that does not meet her design ideas optimally, but still well.

With respect to our context bootScore and Bootstrap, this creates a strategy for integrating Google fonts locally⁶:

We choose our preferred font pair and use — as recommended by bootScore — the google-webfonts-helper to download the corresponding Google fonts and insert the also generated @font-face instructions into file scss/_bscore_custom.scss.

In the file scss/_bscore_variables.scss we then apply the Bootstrap methodology to decide for which HTML elements the fonts should be used:

With Bootstrap, we specify the ‘main font’ via the variable $font-family-base. This can be the family of a serif font or a sans-serif font. Via the variable, $font-family-sans-serif we specify the main sans-serif font. There is no variable $font-family-serif. If we want to use a different family for the headings than the general main font, the variables $headings-font-family and $display-font-family would be responsible for this. Using this way, we easily can combine all combinations.

And how does this …

… support our migration to bootScore? Well, when the web designer has completed her work on good illustrations, she can relax and integrate tags and clouds into her site, improve her overview page and design her own landing page. Whether the resulting fullness really benefits her own reader, whether it can become slimmer and how, whether more discreet references and specific fonts also increase the readability, all this she should nevertheless consider while implementing these features. This post supports these steps towards a personalized bootScore site.

1. cf. https://kinsta.com/de/blog/html-fonts/
2. cf. https://www.w3schools.com/cssref/css3_pr_font-face_rule.php
3. cf. https://technicalcommunicationcenter.com/2020/06/10/whats-a-font-font-family-typeface-font-face/
4. Therefore it is important to provide the desired font family at least in the weights ‘400’ and ‘700’ and respectively in the types ‘regular’ and ‘italic’
5. cf. https://www.w3schools.com/cssref/css_websafe_fonts.php
6. The alternative would be to load the fonts directly from Google font servers on a case-by-case basis. That makes your work easier. And complicates your privacy concept: Because when downloading, Google asks for user data, i.e. your reader’s data. The cause for that is your site. Therefore you have to point this out in your data protection concept. So it’s better if you download the fonts yourself, integrate them into your site, and deliver them yourself.

The post Suitable Web-Fonts appeared first on FODINA 4 FOSS.