HARALD MELCHER

Macke im Aardvark-Theme

Das Aardvark-Theme in der Version 4.4 mit dem Aardvark-Plugin Version 2.3.1 produziert manchmal im CSS-Code für die Hintergründe einiger Elemente (wie z.B. h2) leere Urls, also background-image: url();. Das führt dazu, dass Browser, wenn sie das Hintergrundbild holen wollen, bei der Default-Adresse der Webseite landen und deren kompletten HTML-Code als Bild herunterladen. Das können die Browser zwar nicht als Bild anzeigen, aber die Performance leidet darunter, denn der Browser lädt dazu die Daten der Webseite ein weiteres Mal herunter.

Abhilfe

In der Datei wp-content/themesaardvark/lib/framework/settings/custom-css.php in Zeile 239 VOR die Anweisung $new_value = 'url(' . ghostpool_image_url( $new_value ) . ')'; folgenden Code einfügen:
if ('' !== $new_value)

Das sorgt dafür, dass das Plugin leere Urls nicht als Hintergrundbild ausgibt.

WordPress Gutenberg-Block mit RichText-Feld

Blöcke speichern statische Inhalte im content-Feld der attributes.

Die edit-Funktion speichert statische Inhalte im Backend darin, wenn sie einen geänderten Inhalt feststellt und die Funktion aufruft, die an onChange gebunden ist. Diese speichert die geänderten Werte in content zurück.

Hier ist der statische Inhalt ein benutzerdefinierbares RichtText-Feld.

Die save-Funktion im Frontent baut das RichText-Feld aus den Inhalten des content-Felds zusammen:

(function (blocks, i18n, editor, element) {
        var el = element.createElement;
        var __ = i18n.__;
        var RichText = editor.RichText;

        blocks.registerBlockType('harald-melcher-blocks/block-01', {
            title: __('Harald Melcher: Editable', 'harald-melcher-blocks'),
            icon: 'universal-access-alt',
            category: 'layout',

            attributes: {
                content: {
                    type: 'array',
                    source: 'children',
                    selector: 'p'
                }
            },

            edit: function (props) {
                var content = props.attributes.content;

                function onChangeContent(newContent) {
                    props.setAttributes({content: newContent});
                }

                return el(
                    RichText,
                    {
                        tagName: 'p',
                        className: props.className,
                        onChange: onChangeContent,
                        value: content
                    }
                );
            },

            save: function (props) {
                return el(RichText.Content,
                    {
                        tagName: 'p',
                        value: props.attributes.content
                    }
                );
            }
        });
    }    (
        window.wp.blocks,
        window.wp.i18n,
        window.wp.editor,
        window.wp.element
    )
);

Das PHP-Script sieht aus wie bei den einfacheren Blöcken, lediglich erweitert um ein Arrayelement, das WordPress sagt, den Javasctipt-Anteil des RichText-Editors (wp-editor) zu laden:

wp_register_script(
    'harald-melcher-blocks-01',
    plugins_url( 'block.js', __FILE__ ),
    array( 'wp-blocks', 'wp-i18n', 'wp-element', 'wp-editor' ),
    filemtime( plugin_dir_path( __FILE__ ) . 'block.js' )
);

Externer Style für einen eigenen WordPress Gutenberg Block

Inline-Styles für Blöcke machen nur dann Sinn, wenn es dort wenig zu stylen gibt. Mehr Stilangaben sammelt man sinnvollerweise in externen Stylesheet-Dateien.

WordPress erzeugt dabei zu jedem Block im Frontend einen Stylesheet-Klassennamen, den es aus “wp-block-“, Namespace, “-” und Blocknamen zusammensetzt. Der folgende Code baut den gleichen Klassennamen auch ins Backend ein, auch wenn das Backend später eine andere CSS-Datei verwendet.

/*
 * Copyright (c) 2019 by Harald Melcher
 */

( function( blocks, i18n, element ) {
    var el = element.createElement;
    var __ = i18n.__;

    blocks.registerBlockType( 'harald-melcher-blocks/block-01', {
        title: __( 'Harald Melcher: Basic', 'harald-melcher-blocks' ),
        icon: 'universal-access-alt',
        category: 'layout',
        edit: function(props) {
            return el(
                'p',
                { className: props.className },
                'Haralds editor block.'
            );
        },
        save: function() {
            return el(
                'p',
                { },
                'Haralds frontend block.'
            );
        }
    } );
}(
    window.wp.blocks,
    window.wp.i18n,
    window.wp.element
) );

Die Styles für den Backend-Editor wandern in editor.css:

/*
 * Copyright (c) 2019 by Harald Melcher
 * editor.css
 */

.wp-block-harald-melcher-blocks-block-01 {
     color: darkblue;
     background: dodgerblue;
     border: 2px solid #9c9;
     padding: 20px;
 }

… und das sieht im Backend dann so aus:

Im Frontend ziehen die Styles von style.css:

/*
 * Copyright (c) 2019 by Harald Melcher
 * style.css
 */

.wp-block-harald-melcher-blocks-block-01 {
    color: darkred;
    background: indianred;
    border: 2px solid #c99;
    padding: 20px;
}

Hier sind die Farben anders, damit man einen Unterschied sieht. Später sollten die Ansichten möglichst ähnlich sein, damit die Designerin ahnt, wie der Block rauskommen wird.

Eigener Block für den WordPress Gutenberg Editor

Aktuelle Versionen von WordPress beinhalten den “Gutenberg-Editor”, mit dem man Beiträge und Seiten aus einzelnen vorgefertigten Blöcken zusammenbauen kann. Das reicht von einfachen Textblöcken bis zu ganzen Galerien. Dies macht einen ganze Reihe von Themen oder Blockbuilder-Plugins überflüssig, weil WordPress nun von Haus aus Blöcke unterstützt.

Obwohl die mitgelieferten Block-Arten die meisten Einsatzfälle abdecken, wird es immer wieder Fälle geben, die einen eigenen, maßgeschneiderten Block erfordern.

Die einfachste Block-Art ist ein statischer Block, den ein zuvor registriertes Javascript zur Laufzeit aufbaut und anzeigt. Damit WordPress das Javascript zur Laufzeit finden und ansprechen kann, müssen es ein paar Zeilen Code bei WordPress anmelden. Insofert verhält sich ein Block zunächst wie ein Plugin und liegt daher auch im Plugin-Unterverzeichnis des WordPress-Verzeichnisbaums.

Block-Script anmelden

Damit WordPress das Block-Script und bei aufwändigeren Blöcken auch die Styles kennt, erhält es diese Information durch Aufruf der index.php im Blockverzeichnis – genau wie bei einem Plugin.

Kennt WordPress das Skript, versteht es auch die darauf folgende Anmeldung des eigentlichen Blocks, die auf das eben registrierte Skript Bezug nimmt.

<?php
/**
 * Plugin Name: Harald Melcher Blocks
 * Plugin URI: https://haraldmelcher.de/wordpress/plugins/haraldmelcherblocks
 * Description: More Blocks for the Gutenberg editor
 * Version: 0.0.1
 * Author: Harald Melcher
 *
 */

defined( 'ABSPATH' ) || exit;

function harald_melcher_blocks_01_register_block() {
    if ( ! function_exists( 'register_block_type' ) ) {
        // Gutenberg is not active.
        return;
    }

    wp_register_script(
        'harald-melcher-blocks-01',
        plugins_url( 'block.js', __FILE__ ),
        array( 'wp-blocks', 'wp-i18n', 'wp-element' ),
        filemtime( plugin_dir_path( __FILE__ ) . 'block.js' )
    );

    register_block_type( 'harald-melcher-blocks/block-01', array(
        'editor_script' => 'harald-melcher-blocks-01',
    ) );

}
add_action( 'init', 'harald_melcher_blocks_01_register_block' );

WordPress ruft das Javascript des Blocks an zwei Stellen auf, einmal im Backend beim Einfügen und Bearbeiten des Blocks und einmal im Frontend beim Anzeigen des Blocks.

Der vorangestellte Namensraum haraldmelcherblocks verhindert Namenskollisionen bei Blöcken.

Die Funktion edit() regelt, was die Autorin beim Einfügen des Blocks sieht. Da dies ein einfacher statischer Block ist, geht man davon aus, dass der Block die hier eventuell eingegebenen statischen Inhalte speichert und im Frontend bei Aufruf von save() wiedergibt.

/*
 * Copyright (c) 2019 by Harald Melcher
 */


( function( blocks, i18n, element ) {
    var el = element.createElement;
    var __ = i18n.__;

    var blockStyle = {
        backgroundColor: '#2A71B0',
        color: '#fff',
        padding: '20px',
    };

    blocks.registerBlockType( 'harald-melcher-blocks/block-01', {
        title: __( 'Harald Melcher: Basic', 'harald-melcher-blocks' ),
        icon: 'universal-access-alt',
        category: 'layout',
        edit: function() {
            return el(
                'p',
                { style: blockStyle },
                'Haralds editor block.'
            );
        },
        save: function() {
            return el(
                'p',
                { style: blockStyle },
                'Haralds frontend block.'
            );
        },
    } );
}(
    window.wp.blocks,
    window.wp.i18n,
    window.wp.element
) );

Beim Einfügen des Blocks erscheint die Backend-Ansicht:

Die Frontend-Ansicht unterscheidet sich in diesem Beispiel nur durch den statischen Text.

Beitragsbilder in WordPress-Theme einschalten

WordPress unterstützt Beitragsbilder, die es zum jeweiligen Betrag gehörend speichert und die ein Theme anzeigen kann, wenn es die Unterstützung von WordPress dazu im Skript functions.php anschaltet:

<?php
/**
 * functions.php
 * Harald Melcher
 */

if (!function_exists('mytheme_setup')){
    function mytheme_setup() {
        add_theme_support( 'post-thumbnails' );
    }
}
// Setup the theme when its loaded
add_action('after_setup_theme', 'mytheme_setup');

Seitentitel im WordPress-Theme einstellbar machen

Ein minimalistischen Theme kodiert den Titel einer Seite “hart” im PHP-Skript. Das ist für ein Theme, das Webseiten mit verschiedenen Namen steuern soll, nicht praktikabel. WordPress kann den Seitentitel automatisch aus dem Konfigurator lesen und an der richtigen Stelle einstreuen, wenn man es im Skript functions.php anschaltet:

<?php
/**
 * functions.php
 * Harald Melcher
 */

if (!function_exists('mytheme_setup')){
    function mytheme_setup() {
        add_theme_support( 'title-tag' );
    }
}
// Setup the theme when its loaded
add_action('after_setup_theme', 'mytheme_setup');

Die zentrale Vorlagedatei

Die zentrale Vorlagedatei, die auf jeden Fall vorhanden sein muss, ist index.php im Stammverzeichnis des Themes. Bei einem minimalistischen Theme könnte diese Datei das komplette Aufbereiten der Seiten übernehmen:

<?php
/**
 * Minimalistic Theme file
 * Harald Melcher
 */

// Let write HTML5
echo '<!DOCTYPE html>';
echo '<html '.get_language_attributes().'>';

// Start the head
echo '<head>';
    echo '<meta charset="'.get_bloginfo( 'charset' ).'">';
    echo '<title>'.get_bloginfo( 'name' ).'</title>';
    echo '<meta name="viewport" content="width=device-width" />';
    echo '<link rel="profile" href="http://gmpg.org/xfn/11" />';
    echo '<link rel="pingback" href="'.get_bloginfo( 'pingback_url' ).'" />';
    echo '<meta name="viewport" content="width=device-width, initial-scale=1"/>';

    // Let WordPress do its magic
    wp_head();

echo '</head>';

// Start the body
echo '<body class="'.join(' ',get_body_class()).'">';

    echo '<div id="wrapper">';
        echo '<div id="header">';
            echo '<h1>'.get_bloginfo( 'name' ).'</h1>';
        echo '</div>';

        // Main content loop
        echo '<div id="content">';
            while (have_posts()) {
                the_post();
                echo '<div class="blog-post">';
                    echo '<h2 class="blog-post-title">'.get_the_title().'</h2>';
                    the_content();
                echo '</div>';
            }
        echo '</div>';
    echo '</div>';
echo '</body>';
echo '</html>';

Kleinere Themen können in der zentralen Vorlagedatei die komplette Seite aufbauen. Aber schon ab zwei unterschiedlichen Seiten-Layouts lohnt sich das Aufteilen von Vorlagen-Stückchen auf einzelne Dateien, die das Hauptskript dann je nach Bedarf einbindet.

Eine sinnvolle Aufteilung auf mehrere Dateien ist zum Beispiel:

  • header.php
    Seitenkopf, der Informationen, die in den <head>-Tag der HTML-Seite gehen sollen, enthält. Oft enthält er auch den öffnenden <body>-Tag des sichtbaren Inhaltes sowie den sichtbaren Titel der Seite. Dazu kommen dann evtl. ein Banner oder Logo und Navigations-Menus.
    Andere Skripte können den Header mit get_header() einbinden.
  • Content
    enthält die eigentlichen dynamischen Inhalte wie Beiträge oder Seiten
  • footer.php
    zeigt den Nachspann der Seite, meist den Link auf die Datenschutzseite, Copyright, Kondaktinformationen. Hier ist eine gute Gelegenheit, den <body>– und den <html>-Tag zu schließen und das HTML-Dokument zu beenden. Andere Skripte können den Footer mit get_footer() einbinden.
Einfache Aufteilung auf mehrere Dateien

Zentrales Stylesheet (style.css)

Jedes WordPress-Theme hat ein zentrales Stylesheet in style.css. Es bestimmt die optische Darstellung der Seiteninhalte. WordPress sucht diese Datei im Stammverzeichnis des Themes.

Eigenschaften des Themes wie Name, Autor und weitere stehen in einem Kommentar am Anfang des zentralen Stylesheets. Beim Theme Twenty Nineteen sieht das folgendermaßen aus:

/* 
Theme Name: Twenty Nineteen 
Theme URI: https://github.com/WordPress/twentynineteen 
Author: the WordPress team 
Author URI: https://wordpress.org/ 
Description: A new Gutenberg-ready theme. Requires at least: WordPress 4.9.6 
Version: 1.0 
License: GNU General Public License v2 or later 
License URI: LICENSE 
Text Domain: twentynineteen 
Tags: custom-background, custom-logo, custom-menu, featured-images, threaded-comments, translation-ready
*/

Folgende Eigenschaften sind vorgesehen:

  • Theme Name
    Name des Themes – darf Leerzeichen enthalten
  • Author
    Die Autorin oder Organisation, die das Theme erstellt hat. Falls sie einen wordpress.org Benutzernamen hat, gehört er hier hin
  • Author URI
    Verweis auf die URI der Autorin oder der Organisation, die das Theme erstellt hat
  • Description
    Eine Kurzbeschreibung des Themes
  • Version
    Versionsnummer des Themes. WordPress erkennt durch Vergleich mit der Version auf wordpress.org, ob es das Theme aktualisieren sollte
  • License
    Die Art der Lizenz des Themes
  • License URI
    Veweis auf den Text der Lizenz des Themes
  • Text Domain
    Hilfestellung bei der Übersetzung von Inhalten
  • Tags
    Worte oder Phrasen, die beim Stöbern im Theme-Verzeichnis von wordpress.org dabei helfen, das Theme durch Filtern schneller zu finden
  • Domain Path
    Hilft WordPress, Übersetzungen von Theme-Texten auch dann zu finden, wenn das Theme abgeschalten ist. Voreinstellung ist /languages

Zentrale WordPress-Theme-Dateien

Um ein Thema im WordPress-Themenkatalog veröffentlichen zu können, muss es vier grundlegende Dateien beinhalten:

  1. style.css
    Diese Datei ist das zentrale Stylesheet des Themas. An dieser Datei erkennt WordPress, dass es sich um die Dateien in einem Theme-Verzeichnis überhaupt um ein Thema handelt. Sie enthält u.a. den Themen-Namen, den Autor und die Versionsnummer.
  2. index.php
    Diese Datei ist die zentrale Vorlagedatei (Template). Wenn es nur diese Datei gibt, bestimmt sie das Aussehen aller von WordPress erzeugten Seiten (außer im Fall einer statischen Eingangsseite). Daher muss sie dann auch die komplette Funktionalität aller Seiten abdecken. Bei stark wechselnden Aussehen der Einzelseiten ist das Verteilen der Funktionalität auf weitere Template-Dateien sinnvoll.
  3. screenshot.png
    In der WordPress-Themes-Übersicht zeigt dieses Bild eine Vorschau, wie das Theme aussehen kann. WordPress nutzt dieses Bild auch für den zentralen Themenkatalog, wenn das Theme veröffentlicht ist. Die Maximalgröße des Bildes ist 1200×900 Pixel.
  4. comments.php
    WordPress nutzt diese Vorlage (Template), wenn es Kommentare anzeigt. Sie sollte Kommentare von Autoren und Nutzern anzeigen sowie einem Verlauf verschiedener Kommentare folgen können. Diese Vorlage ist zum Veröffentlichen eines Themes von Belang. Bei Themes ohne Kommentaren oder bei privaten Themes spielt sie keine Rolle.

Die zentralen Dateien eines Themes müssen im Hauptverzeichnis des Themes liegen. Bei aufwändigeren Themes empfiehlt sich das Verteielen weiterer eingefügter Dateien auf Unterverzeichnisse, zum Beispiel bei Bildern, Skripten oder Vorlagen-Schnipseln.

Die beiden Dateien style.css und index.php allein reichen schon aus, damit WordPress das Theme erkennt und (mit einem leeren Vorschaubild) anzeigt.

Durchsatz bestimmt Google-Ranking

Die Google-Suchmaschine nutzt auch den gemessenen Durchsatz einer Webseite, um die Reihenfolge festzulegen, in der sie die gefundenen Webseiten präsentiert.

Web-Entwicklerinnen haben daher in Interesse, den Durchsatz ihrer Seite zu kennen, um die Auswirkung von Verbesserungen zu sehen.

PageSpeed Insights

PageSpeed Insights gibt an, wie gut eine Webseite beim Chrome User Experience Report abschneidet. Es führt eine ganze Reihe von Prüfungen durch, misst Reaktionsgeschwindigkeiten und gibt Empfehlungen zur Optimierung von Seiten.

Die Prüfungen lesen sich wie das 1×1 des Web-Entwickelns:

  • Medien
    • sind die Bilder richtig dimensioniert
    • sind die Bilder effektiv in modernen Formaten codiert
    • laden nicht sichtbare Bilder erst beim Anzeige-Versuch
    • Videoformate für animierte Inhalte verwendet
  • Texte
    • Textkomprimierung aktiviert
    • bleibt der gesamte Text während der Webfont-Ladevorgänge sichtbar
    • sind die Cascading Style Sheets gepackt
    • ist nur das benötigte CSS geladen
    • ist Javascript gepackt
  • Server
    • Antwortzeit niedrig
    • Vorverbindung zu erforderlichen Ursprüngen aufgebaut
    • mehrfache Weiterleitungen auf die Seite vermieden
    • wichtige Anforderungen vorab geladen
    • gutes Caching
  • überschaubare DOM-Größen

Das zusammengefasste Ergebnis ist ein Wert zwischen 0 und 100, an dem man gut ablesen kann, ob eine Veränderung positive oder negative Auswirkungen auf das Nutzungserlebnis hat:

Lighthouse

Lighthouse ist ein Werkzeug zum Qualitätstest von Webseiten, das automatisch Durchsatz, lesbare Darstellung und mehr prüft. Es ist in Chrome bereits eingebaut: Unter den Entwicklereinstellungen (F12 unter Windows) im Reiter Audits.

Hier sieht man ähnliche Ergebnisse wie bei PageSpeed Insights: Leistung, Darstellung, richtige Anwendung bekannter Technologien und Suchmaschinen-Tauglichkeit.

  • Die Leistung ist eine Messung der Zeiten bis verschiedene Teile der Seite gerendert sind – ähnlich wie bei PageSpeed Insights.
  • Die Darstellung prüft auf Lesbarkeit (Kontrast zwischen Vordergrund und Hintergrund) und auf das Vorhandensein bestimmter HTML-Elemente wie title, lang und logisch aufgebaute Listen.
  • Der Technologie-Teil bewertet HTTP2 und HTTPS positiv, sowie Verwendung aktueller APIs und das Ausbleiben von Browser-Fehlern.
  • Die Suchmaschinen-Optimierung prüft das Vorhandensein von Titel, Beschreibungstexten und einer gültigen Datei robots.txt zum Steuern von Webcrawlern.