Another question that I unfortunately had to answer myself several times because I am so forgetful: How do I connect my Dell laptop XPS 129240 (WIN11), an Ubuntu machine (24.04), and my Dell curved monitor S3423DWC in a way, that I can use both machines with the same keyboard and monitor via the KVM switch integrated in the Dell monitor?

Solution

• Preparing the WIN11 computer (Dell laptop):
  • Connect the keyboard to the Dell monitor via USB‑2/Bluetooth.
  • Connect the Dell laptop to the Dell monitor via USB‑C cable and start it (WIN11).
  • Download the setup/installation file for the Dell Display Manager (ddmsetup.exe) from https://www.dell.com/support/home/de-de/drivers/driversdetails?driverid=g0v75 (version 2.3) and run it as administrator (and save a link in the menu during installation).

• Preparing the Ubuntu computer:
  • Connect the Ubuntu computer to the Dell monitor using a USB‑2 / HDMI cable.
  • Start the Ubuntu machine.
  • sudo apt-get install ddcutil ddcui
  • Start ddui, select View/Capabilities and select input source VCP/Feature 0x60.
    • Verify 0x1b: Unrecognized feature = USB‑C port for the Dell laptop with WIN
    • Verify 0x11: HDMI 1 = HDMI port of the Ubuntu computer
    • Check Dell’s own manual
  • Generate the following Bash script, save it as ~/bin/2dell.sh and make it executable.

#!/bin/bash

sudo ddcutil setvcp 60 0x1b

• Switch from WIN11 to UBUNTU-24.04:
  • On the Dell-Laptop (WIN11), start ddm, click Burger Menu/KVM-Rubrik
  • Define your own Hotkey and use it
  • Otherwise start the switch graphically.

• Switch from UBUNTU-24.04 to WIN11:
  • > ~/bin/2dell.sh

The post Using a Dell laptop and an Ubuntu computer via the same Dell monitor appeared first on FODINA 4 FOSS.

Another question that I unfortunately had to answer myself several times, because I am so forgetful: How can I reliably prevent my Dell Laptop with Ubuntu from going into suspend mode when the lid is closed? I need that feature because my devices use the same Dell screen with …

Switching from one machine to the other is done via a signal. But a computer in suspend mode would – surprise, surprise – not receive the “it’s your turn”-message.

To solve that issue, we traditionally would modify the GNOME settings under Settings/Power to

• Mode = Balanced
• Power Saver = off
• Screen Blank = Never
• Automatic Suspend = off

But — unfortunately — that does not work on DELL laptops with Ubuntu. Instead, we must use ‘the’ Dell-specific method:

Solution

• > sudo systemctl restart systemd-logind .
• > sudo systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target
• > sudo vi /etc/systemd/logind.conf
• Replace #HandleLidSwitch=suspend by HandleLidSwitch=ignore to do nothing
• Save the file

The post Supressing Suspend-Mode on Dell-Laptops with Ubuntu appeared first on FODINA 4 FOSS.

Another question that I unfortunately had to answer myself several times because I am so forgetful: How do I quickly set up a functionally identical Ubuntu duplicate?¹ In the past, we had to fiddle around with dpkg --get-selections and dpkg --set-selections. Today, it’s easier — with apt-clone:

Solution

• sudo apt-get install openssh-client openssh-sever apt-clone (@Master)
• Install the base version of the same Ubuntu Release (@Slave)
• sudo apt-get install openssh-client openssh-sever apt-clone (@Slave)
• sudo apt-clone clone . (@Master)
• scp apt-clone-state-[Master].tar.gz [Slave] (@Master)
• sudo apt-clone restore apt-clone-state-[Master].tar.gz (@Slave)

The post Cloning an Ubuntu Instance appeared first on FODINA 4 FOSS.

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.

Solution

• Use the Bootstrap JavaScript library as delivered by bootScore
• Use the JavaScript libraries as delivered by WordPress
• Create a table containing the JavaScript compliance information
• For each JavaScript library delivered by bootScore or WordPress create a respective row in your JS table.
• Embed this table into your Open Source Compliance Page
• Make this Open Source Compliance Page accessible by the footer of your pages

Background

bootSCore contains some JS components. For example, its own unfolded JavaScript libraries¹ — implicitly licensed under the MIT license but without any explicit licensing statement — and the minified Bootstrap JavaScript library² — explicitly licensed under the MIT by a respective licensing statement. But none of them contain the license text itself.

Also, WordPress brings with it some own and some minified 3rd party JavaScript libraries³, like the jQuery library⁴ that is licensed under the MIT and contains a respective licensing statement, but does not cover the license text itself. Regardless, of whom the site owner has got these libs — from bootScore or WordPress -, eventually it is she who has to fulfill the license requirements because it is her system that distributes the JavaScript libraries to her readers.

But what is actually the challenge?

Like the JavaScript libraries of Bootstrap and jQuery, most JS libraries are MIT licensed. It requires that the copyright line and the license text are distributed together with the open-source program. “The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.“⁵

For (L|A)GPL-licensed JavaScript libraries it is nearly the same. These licenses permit the distribution of the source code “provided that one conspicuously and appropriately publishes on each copy an appropriate copyright notice and disclaimer of warranty […] and gives any other recipients of the Program a copy of this License along with the Program”.⁶

So, we see a contradiction between the claim of the licenses and the everyday practice. On the one side, a browser not only loads down the page text (HTML) but also the JavaScript library. This download distributes the code and hence triggers the necessity to fulfill the open-source license requirements. On the other side, usually, the compressed libraries — although as a package often offered by the authors — no longer contain the required license information: the smaller the libs, the faster the machine can display the site using that libs.

As site owners, we have two options to deal with this challenge. Either we subsequently (and (semi) manually) heal the packages we implicitly have taken over by using WordPress and bootScore. Or we use them as we’ve got them. It’s clear: Healing would imply that we redo that job whenever we update WordPress or bootScore. So, we tend to go the other way.

The solution is this:

Whenever developers decide to distribute minified JavaScript libraries, they also assume that their ‘customers’ use their work in that version. That is a reasonable assumption. So, we may derive that they implicitly permit that kind of use even if it violated the license they’ve chosen. Nevertheless, we should offer our users another option to get the required information. A substitute for bundling the license text, the copyright information, etc. with the JavaScript libraries themselves. However, we must take care only to include the minified JavaScript libraries the developers themselves have provided. In the case of the Bootstrap-JS-Lib in bootScore and the Jquery-JS-Lib etc. in WordPress, we may assume that they did so.

If we apply this process to our 3rd. party JS libraries, we have a strong argument for our position in case of a legal dispute — I’ve never heard of one — and we’re in good company: Even the FSF is proposing to do so.⁷ And the FSF really doesn’t have a reputation for taking license compliance lightly.

And in what way is this …

… part of the overarching topic FOSS Compliance? For fulfilling the requirements of FOSS licenses, we have to consider specific individual cases as well as side effects — for software, pictures, or documents. We should unhide trends and write guidelines. Above all, however, we must drive forward the automation of license fulfillment, make our licensing knowledge freely available, cast it into smaller tools, and bring it into larger systems: Because FOSS thrives on freedom through license fulfillment, large and small. That’s what also this article is about.

1. cf. ./bootscore/js/theme.js
2. cf. ./bootscore/js/lib/bootstrap.bundle.min.js
3. cf. https://codex.wordpress.org/Javascript_Reference respectively ./wp-includes/js
4. cf. wp-includes/js/jquery/
5. cf. MIT License
6. pars pro toto cf. GPL‑2.0. Additionally, the (A)GPL requires that we license our code that uses the (A)GPL-licensed library, etc. also under the (A)GPL (copyleft effect). But that’s not the point in this context.
7. cf. https://www.gnu.org/licenses/javascript-labels.html, https://www.gnu.org/licenses/javascript-labels-rationale.html, and https://www.iusmentis.com/computerprograms/opensourcesoftware/license-notices-web-applications

The post Using JavaScript Compliantly appeared first on FODINA 4 FOSS.