WordPress Archives - FODINA 4 FOSS

Cookies — properly managed by bootScore

Karsten Reincke — Wed, 04 Oct 2023 19:01:35 +0000

Displaying an appropriate cookie dialog is one thing. Giving it a real meaning is another. Because asking permission alone is not enough. We also need to evaluate the responses: We must only store those cookies on our reader’s computers they — or the law — have consented to. A JavaScript function that implements this requirement sets the semantics of the cookie dialog. Based on such a function, we use properly managed cookies.

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:

[ en | de ]

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.

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.
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.

Cookies — properly used in bootScore

Karsten Reincke — Fri, 15 Sep 2023 10:03:01 +0000

Without permission, we may not write cookies to the hard disk of our reader. Because it belongs to her, not to us. By accessing our site, she has already implicitly given her consent to store our technically necessary cookies. Because they are technically necessary to read our post. But she must explicitly permit us to save the other cookies on her computer before we are going to do so. Moreover, we must have enabled her to query what these cookies are for before we offer her to answer our request. That’s the meaning if we talk about properly used cookies.

[ en | de ]

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:

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 _bscore_custom.scss:


// 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 …

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
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.
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.
e.g. with the Cookie Editor
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.

My Googlized Writing Style

Karsten Reincke — Sun, 27 Aug 2023 08:39:56 +0000

Last time it wasn’t hard anymore: Within two days my post about my ‘reset’ because of lacking an ‘inner linking’ and about the ‘right way to be crawled and indexed’ had been processed by Google. Like my revised posts, I had designed it in accordance with the recommendations of YOAST that take into account Google’s ‘unspoken’ specifications — as proclaimed by YOAST. However, by following these rules, I had also given in to the stylistic superiority of Google and YOAST:

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.¹

[ en | de ]

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: ????-??-??

by using the option of the search console to hand over a URL manually.
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.
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
If you shorten the resulting slug of your page, use at least speaking syntagms in your URL.
Don’t rely only on your updated sitmap.
If you don’t believe that, you may deliberately ‘torture’ yourself through this intentionally passivated paragraph
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
which — in this case — is equivalent to: in the first 6 paragraphs
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.”
“17% of the sentences contain passive voice”
“1 of the paragraphs contains more than the recommended maximum of 150 words.”
“31.9% of the sentences contain more than 20 words, which is more than the recommended maximum of 25%”
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.

Internal Linking — a Reset

Karsten Reincke — Wed, 23 Aug 2023 11:54:25 +0000

It’s a while ago, that I wrote about SEO. That should not be a big deal, I thought at that time. In its templates, bootScore thankfully uses semantic HTML tags by default. Thus, it should be sufficient to submit one’s own sitemap to Google & Co. Enriching the pages themselves with additional keywords should be superfluous. A good primary content would be enough. No need for a second text behind the actual one. That’s the way, I thought. Moreover, I saw no reason to talk about internal linking. Rarely has Google so embarrassingly proven me wrong:

[ en | de ]

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.

Pimp Your bootScore

Karsten Reincke — Sun, 23 Apr 2023 21:52:07 +0000

Linking Bootstrap and WordPress to get a responsive design is the task of bootScore, a WP-theme bringing along what the web designer actually does not want to program herself. Instead, she can now rely on an MIT-licensed preliminary work hosted on GitHub. But its ‘standard outfit’ still must be personalized, ‘pimped’ — by the work of a Web Designer? The theme is adapted — so bootScore — by modifying its “[…] .scss, .php, and .js files”. So you can pimp your bootScore easily. Here are my 13 steps from a pure bootScore to my personal ‘homepage’:

[ en | de ]

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

Font Awesome — one symbol says more than 100 words: ShortCodes and CSS classes
SEO from the beginning: HTML semantics, keywords, and sitemaps, and no dead links, please.
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.
Thinking multilingualism: bilingualism without WP globe
For clarity: the deeper branched menu with integrated shortcodes, clean layers, and readable stacking, which nevertheless has to be no H‑OVER menu.
Don’t fiddle, automate: The built-in hyphenation
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.
Easing the finding: TAG clouds and post lists in the sidebar
The walled overview: The Masonry Contribution List.
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.
Readability: bootScore and the custom general font and the font for special occasions
Respecting the law is a need: data protection, a proper cookie dialog, and cookie management.
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.

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

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

Data Privacy, DSGVO, and Cookies

Karsten Reincke — Fri, 21 Apr 2023 09:33:10 +0000

Often the website operator is told, that Data protection is complex and has to be organized by experts. But what if she doesn’t have the money for that? If it seems somehow nonsensical to shoot at a sparrow blog with the cannon of a paid team of experts? Then — maybe and with the help of Google — she installs some popular WordPress plugins for data privacy and DSGVO and/or cookies — in the hope that all goes well. Or she investigates it in more detail. And in the end, she perhaps gathers rules of thumb, from which at least one well-workable way results. Here are my 3.7 rules of thumb, applied to my own data privacy file:

[ en | de ]

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:

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.
Furthermore, I am aware that IP addresses are also considered personal data — although the internet would not function without them.
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.
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 …

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

Extra Fonts for Specific Cases

Karsten Reincke — Wed, 19 Apr 2023 08:37:00 +0000

bootstrap and bootScore use SCSS variables — as we know. Grouping fonts is done by variables. And we can define two groups. This is sufficient if we want to use only two font families. But if we want to use extra fonts — for example, a special google font in our menus -, we need to do things differently:

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:

[ en | de ]

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
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.

Suitable Web-Fonts

Karsten Reincke — Wed, 05 Apr 2023 10:24:43 +0000

Selecting good fonts is a matter of design, getting suitable web-fonts a matter of knowledge. Not only, if we need some for special cases. With bootScore we can incorporate Google Fonts directly. We are even told how to host them locally, so we can bypass the notice in the privacy policy. Nevertheless, we have to get a little involved with Bootstrap as well:

[ en | de ]

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.

cf. https://kinsta.com/de/blog/html-fonts/
cf. https://www.w3schools.com/cssref/css3_pr_font-face_rule.php
cf. https://technicalcommunicationcenter.com/2020/06/10/whats-a-font-font-family-typeface-font-face/
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’
cf. https://www.w3schools.com/cssref/css_websafe_fonts.php
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.

Discreet References to Previous Posts

Karsten Reincke — Fri, 31 Mar 2023 14:42:29 +0000

In bootScore Toppings, I’ve already offered two slim landing pages: mylap-sp1rp1 and mylap-sp0rp1. Both show the important things first: The blog topic. And the most recent post. One of them additionally puts the most recent Sticky Post in front of the other. But if we nevertheless want to show our readers the one or other sticky post more, we need a solution for integrated discreet references to previous posts:

[ en | de ]

Solution

Install the Recent Posts Widget With Thumbnails plugin.
Open Appearance/Widgets.
Copy the widget Recent Posts with Thumbnails into your general Sidebar Widget and configure it:
- Set the number of posts to show to 1, maximum 2.
- Select Show only sticks posts.
- Enable Show excerpt.
- Set the number of characters to show to 144.
- Set the width of the thumbnail to show to 120, the height to 75.
- Enable the option Use aspect ratios of original thumbnails.
Set up your site to use your own specific landing page.
Download the landing page mylap-sp0rp1.
Copy it into your child theme under the name mylap.php.

Background

The idea of this change is simple:

We only mark posts as sticky posts that outshine topicality anyway. That’s why we also want to point them to our readers. But we leave it at one or two posts. Sticky posts should not displace our recent posts.¹ Our previous landing page mylap-sp1rp1 put the sticky posts in front of the most recent ones. This can be done more elegantly and discreetly:

We install the plugin Recent Posts Widget With Thumbnails. It claims to be Open-Source software, in the repository the file Readme.txt refers to the GPL‑2.0 and the GPL‑2.0 license text is also located there. So we are on the side of the good guys here.

After that, we configure the plugin to help our reader. True to the maxim, less is more. And because we’ve thus moved the sticky posts to our general sidebar, we no longer need the landing page that shows both. So we can move to my-landing-page-stickposts-0-recentposts‑1.

Bingo.

And how does this …

And yes, that also means that we implement our sticky tags over and over again. Otherwise, it gets boring.

The post Discreet References to Previous Posts appeared first on FODINA 4 FOSS.