Ungenutzte JS und CSS Files aus WordPress entfernen

80% Deiner CSS und JS Dateien könnten auch gelöscht werden!

Krasse These? Nun gerade wenn man WordPress benutzt eigentlich eher der Standard als das krasse Extrembeispiel. Die Frage ist ja: Woher kommt das denn bitte?

Es gibt für alles ein Plug-In

In der WordPress-Welt wird sehr viel über Plug-Ins abgedeckt. Selbst für die Geschwindigkeits-Optimierung und JSS Reduzierung wird ein Plug-In installiert, dass sich selbst mit noch mehr JavaScript und CSS im Source Code festsetzt. Der Klassiker zum Beispiel wäre das Revolution Slider Plugin, das fein säuberlich auf jeder einzelnen Seite seine Dateien lädt obwohl nur auf der Startseite ein Slider eingebaut wurde.

Welche Scripte lädt meine Seite eigentlich?

Um ungewolltes JavaScript zu entfernen, sollte man wissen welche Dateien eigentlich geladen werden.

Eine Möglichkeit wäre nun den Source Code der Seite zu öffnen und eine Liste zu erstellen. Und das macht man dann für jede einzelne Seite, damit man feststellen kann wo welche Dateien geladen werden. Doch das ist umständlich, zeitaufwendig und nervig. Es geht auch viel leichter!

Ausgabe der benutzten JS Handles pro Seite

Einfach mal alles auflisten was mit wp_enqueue_script geladen wurde

Der erste Schritt besteht darin, sich ein eigenes Plug-In anzulegen. Alternativ könnt Ihr natürlich auch das Beispiel Plugin nutzen, dass ich euch hier zur Verfügung stelle.

Erstellt also eine Datei mit dem Namen wp_remove_unused.php (oder etwas Vergleichbares, in der Namensgebung bin ich relativ kreativlos) und tragt den Plug-In Header ein.

<?php
/*
 * Plugin Name: SameMission räumt auf
 * Plugin URI: https://benjamin-mylius.de/ungenutze-js-css-dateien-entfernen/
 * Version: 1.0
 * Description: Gibt im Frontend für Administratoren eine Handle-List aller JS und CSS Dateien aus. Handles die nicht geladen werden sollen können hier definiert werden.
 * Author: Benjamin Mylius
 * Author URI: https://www.samemission.de/
*/

Was das Plug-In als erstes können muss: Auflisten was überhaupt auf der Seite geladen wird.

Es gibt zwei globale Variablen in WordPress um Scripte und Styles zu speichern:

  • $wp_scripts
  • $wp_styles

Lässt man sich nun also einen var_dump für beide Globalen ausgeben würde man sehen, welche Scripte und Styles von allen Plug-Ins und von WordPress registriert worden sind. Uns interessieren aber nur die, die geladen wurden.

// Liste alle Assets auf, die geladen werden. Nur für Administratoren sichtbar!
add_action('wp_print_footer_scripts', 'sm_list_stuff', 900000);

function sm_list_stuff(){
    if ( !current_user_can('delete_users') ){
        return;
    }
 
    echo '<h2>Liste aller Scripte, die auf dieser Seite geladen wurden.</h2>';
    echo '<p>Die Ausgabe kann von Seite zu Seite verschieden sein, je nachdem welche Scripte geladen worden sind.</p>';
 
    // Zeige alle geladenen Scripte (JS)
    global $wp_scripts;
    sm_print_assets($wp_scripts);
 
    echo '<h2>Liste aller CSS Dateien, die auf dieser Seite geladen wurden.</h2>';
    echo '<p>Die Ausgabe kann von Seite zu Seite verschieden sein, je nachdem welche Scripte geladen worden sind.</p>';
    // Zeige alle geladenen Styles (CSS)
    global $wp_styles;
    sm_print_assets($wp_styles);
}

Also hängen wir uns an den wp_print_footer_scripts Hook mit einer sehr hohen Priorität um sicher zu gehen, dass auch alle Scripte geladen wurden, bevor sie aufgelistet werden.

Ausserdem soll nicht jeder User auf unserer Seite diese Liste sehen können, deswegen stellen wir sicher, dass die Ausgabe nur für Administratoren gilt.

Jetzt folgen noch Zwei weitere Funktionen: sm_print_assets und sm_asset_template:

function sm_print_assets($wp_asset){
    $nb_of_asset = 0;
    foreach( $wp_asset->queue as $asset ) :
        $nb_of_asset ++;
        $asset_obj = $wp_asset->registered[$asset];
        sm_asset_template($asset_obj, $nb_of_asset);
    endforeach;
}
 
function sm_asset_template($asset_obj, $nb_of_asset){
    if( is_object( $asset_obj ) ){
        echo '<div class="wra_asset" style="padding: 2rem; font-size: 0.8rem; border-bottom: 1px solid #ccc;">';
 
        echo '<div class="wra_asset_nb"><span style="width: 150px; display: inline-block">Nummer:</span>';
        echo $nb_of_asset . '</div>';
 
 
        echo '<div class="wra_asset_handle"><span style="width: 150px; display: inline-block">Handle:</span>';
        echo $asset_obj->handle . '</div>';
 
        echo '<div class="wra_asset_src"><span style="width: 150px; display: inline-block">Quelle:</span>';
        echo $asset_obj->src . '</div>';
 
        echo '<div class="wra_asset_deps"><span style="width: 150px; display: inline-block">Abhängigkeiten:</span>';
        foreach( $asset_obj->deps as $deps){
            echo $deps . ' / ';
        }
        echo '</div>';
 
        echo '<div class="wra_asset_ver"><span style="width: 150px; display: inline-block">Version:</span>';
        echo $asset_obj->ver . '</div>';
 
        echo '</div>';
 
    }

Was wir damit auflisten werden:

  • Die Nummer der JavaScript oder CSS Datei: um einen Überblick zu behalten.
  • Der Handle: Das ist nämlich der eindeutige Identifizierer der von der wp_enqueue_scripts genutzt wird
  • Die Quelle: Der Speicherort der Datei
  • Die Version: Die aktuelle Version der Datei

Für unsere Zwecke brauchen wir nur den Handle, aber mit additionalen Informationen sieht das ganze runder aus und man bekommt eine Idee davon warum und wo diese Dateien geladen werden.

Ungenutzes CSS und JS in WordPress entfernen

Zum entfernen von den Dateien stellt WordPress insgesamt 4 Funktionen zur Verfügung:

Mit WordPress conditional Tags und custom post types kann man das entfernen der Scripte und Styles noch gezielter steuern.

function sm_filter_scripts(){
    #wp_deregister_script($handle);
    #wp_dequeue_script($handle);

    if( !is_page( 'contact' ) ){
        // Contact-Form-7 soll nur auf Contact-Form-7 Seiten geladen werden.
        wp_deregister_script('contact-form-7');
        wp_dequeue_script('contact-form-7');
    }

}

Als Beispiel hier dient das Contact-Form-7 Handle, da ein Kontaktformular nur auf der Contact Page existiert soll auch nur auf dieser Seite das JavaScript geladen werden.

Eine Liste der verschiedenen conditional tags, die Seitens WordPress genutzt werden können, gibt es hier

Das fertige Plug-In

Wie versprochen, wer nicht die Muse hat sich bis hier hin durchzuarbeiten, kann das Plugin auch ganz einfach herunterladen. Eine Anleitung, wie das Plugin-gehandhabt wird folgt in kürze

Buttontracking mit Google Tag Manager

Ab und zu kommt es vor, dass der hundsordinäre Webseitenbetreiber gerne wissen möchte, was für Elemente auf seiner Seite angeklickt, beziehungsweise genutzt werden. Hier hat man nun mehrere Möglichkeiten. Zum einen könnte man, ein in Deutschland illegales Tool auf der Seite installieren und sich mit einem Bein in den Abmahnwahn begeben, man könnte raten oder man baut ein Buttontracking auf seiner Seite ein. Letztere Möglichkeit möchte ich hier einmal näher beleuchten.

TL:DR Version für ungeduldige

Benötigte Zeit: 45 Minuten.

Wie richte ich ein Buttontracking mit dem Google Tag Manager ein?

  1. Button erstellen

    Als erstes muss das Element, das getrackt werden soll auch vorhanden sein.

  2. Google Tag Manager einrichten

    Der Container muss eingerichtet werden, die Click Classes müssen hinzugefügt werden. Analytics muss verknüpft werden.

  3. Trigger anlegen

    Die Klicks auf bestimmte Elemente deiner Seite müssen vom Google Tag Manager aufgefangen werden. Dazu werden die Trigger eingerichtet.

  4. Testen

    Wenn alles richtig eingerichtet wurde, muss getestet werden ob die Klicks gefangen und als Event an Google Analytics weitergeleitet werden.

Zunächst brauchen wir einen Button, den wir tracken können

Aus rein wissenschaftlichen Gründen, braucht man natürlich erst mal einen Button, der es wert ist, getrackt zu werden.

Und jetzt kann es auch schon mit dem Google Tag Manager losgehen

Da ich davon ausgehe, dass Ihr bereits ein Google Tag Manager Konto habt gehe ich auf den Schritt, wie man es einrichtet nicht weiter ein.

Wenn Ihr in euren Container eingeloggt seid, besteht der erste Schritt darin, zu prüfen ob die richtigen Variablen aktiviert sind.

Google Tag Manager Click Classes

Hier findet man die Click Classes

Im Workspace vom Tag Manager wählt man Variablen (1), geht danach auf Konfigurieren (2) und wählt, wenn dies noch nicht geschehen ist, bei Klicks die Click Classes (3) aus. Natürlich kann man hier auch die Click ID auswählen, je nachdem wie man seine Buttons identifizieren möchte.

Google Analytics Konstante einrichten

Damit man nicht immer die Google Analytics ID einhämmern muss, legt man diese als Konstante an.

Benutzerdefinierte Variablen sind dein Freund

Um die Konstante anzulegen, wählt man unter Variablen (1) und Benutzerdefinierten Variablen -> Neu (2)

Variablen benennen, für bessere Auffindbarkeit

Nun gibt man der Variable einen Namen (1), der auch einen Wiedererkennungswert hat. Und klickt auf den Legostein bei “Variable konfigurieren” (2)

Variablen Typ: Konstant

Abschließend wählt man den Variablen Typ “Konstant” aus dem Flyout Menü aus und trägt in den Wert die UA Nummer aus dem Analytics Konto ein. Mehr braucht es an dieser Stelle nicht um die Konstante zu erstellen und wir können uns an den nächsten Schritt machen.

Debug Mode – Herausfinden, was wir tracken wollen

Um die Class oder ID der Elemente herauszufinden, die wir tracken wollen müssen wir zunächst den Debug Mode des Google Tag Managers aktivieren.

“In Vorschau ansehen” aktiviert den Debug Modus vom GTM

Über den Button “In Vorschau ansehen” aktiviert man den Debug Modus für den Google Tag Manager. Ob der Vorschau Modus aktiviert ist, kann man an dem folgenden Bild erkennen:

Vorschau Modus ist aktiv

Ruft man jetzt seine Seite auf, wird man feststellen, dass sich etwas geändert hat.

Kontrolle ob alles geklappt hat

Ein extra Fenster öffnet sich am unteren Bildschirmrand und bietet Informationen darüber, welche Ereignisse auf der Seite stattgefunden haben. Wenn Ihr dieses Fenster seht, seid ihr bereit für den nächsten Schritt.

Generischen Trigger anlegen

Damit wir die Klicks auf der Seite “einfangen” können, benötigen wir einen generischen Trigger.

Folgt diesem Pfad um einen Trigger zu erstellen

Wählt Trigger (1), geht danach auf “Neu” und vergebt dem Trigger wieder einen Namen (2), der selbsterklärend ist. Als letztes Konfiguriert Ihr den Trigger (3).

Wir wollen alle Klicks “auffangen”

In der Konfiguration wählt ihr jetzt noch “Klick -> Alle Elemente” und speichert den Trigger. Damit wir mit den angelegten Änderungen arbeiten können, wäre jetzt der Zeitpunkt, in dem alles einmal veröffentlicht wird.

Veröffentlichungsscreen in GTM

Zu diesem Screen kommt ihr, wenn ihr im Workspace oben auf “Senden” drückt. Anschließend könnt ihr für die interne Dokumentation Namen und Notizen hinzufügen, damit man auch später noch einen Überblick darüber hat, was man wann veröffentlicht hat.

Wozu das Ganze Geraffel?

Mit dem Vorgeplänkel im GTM haben wir uns die Möglichkeit eröffnet jedes anklickbare Element zu identifizieren. Getestet werden kann das Ganze folgendermaßen:

Buttonklick ausprobieren

Wenn alles richtig eingerichtet wurde, erscheint das Event “gtm.click (2)” sobald ich auf den Button geklickt habe (1).

Lifehack: wenn ein Link hinter dem Button steht und ihr den anklickt, werdet ihr auf eine andere Seite weitergeleitet. Damit man das tracking trotzdem kontrollieren kann sollte man mit STRG und Linkklick auf den Link klicken, damit dieser sich in einem neuen Fenster öffnet (Tjoa, funktioniert aber nur für Windowsnutzer)

Ein Blick in die gespeicherten Variablen

Wenn man jetzt auf den Tab “Variables” wechselt kann man sehen welche Daten gefangen wurden. Da wir die Click Classes und die Click ID gespeichert haben, werden diese hier auch angezeigt.

Man kann jetzt auch gut erkennen, warum es nicht immer Sinn macht die Click Classes einzufangen, denn die Klasse ist sehr allgemein und wird in diesem Fall für jeden Button genutzt. Ein Tracking über die ID macht hier also mehr Sinn.

Jetzt wo wir in der Lage sind, Elemente durch einen Klick zu identifizieren, sollten wir die Events an Analytics senden

Benjamin Mylius

Um das zu bewerkstelligen, benötigen wir Trigger.

Einen speziellen Trigger anlegen

All you need is a trigger

Wie bereits vorher schon geschehen, geht man über Trigger (1) und “Neu”. Man vergibt einen eindeutigen Namen, den man später wieder zuordnen kann (2) und wählt als Triggertyp “Klick – Alle Elemente” (3). Allerdings wollen wir jetzt nur bestimmte Klicks einfangen. Und zwar alle Klicks, die auf die Click ID mit dem Wert des Trackingbuttons (4) (hier trackingbuttontest) eingehen.

Das Analytics Tag einrichten

Da wir jetzt die auslösenden Trigger eingerichtet haben, fehlt eigentlich nur noch das Tag mit dem alles verknüpft wird. So können wir den Klick auf dem Button als Event an Google Analytics senden um alles zu tracken.

Tag Einrichtung leicht gemacht

Ihr geht über Tags (1) und wählt “Neu”. Dann vergebt ihr, wie sollte es auch anders sein, einen Namen (2) und wählt als Tag Typ “Google Analytics – Universal Analytics”. (3) Der Tracking Typ ist in diesem Fall ein Event. Nun könnt ihr das Ganze auch noch Katgorisieren. In meinem Fall ButtonClicks. Und eine Aktion, die gespeichert werden soll “Es wurde geklickt“. Als Label habe ich den Page Path angegeben.

Begründung: Wenn man z.B. über die Click Classes mehrere Buttons auf der gesamten Domain trackt, die sich eine gemeinsame Klasse teilen. Könnte man über die Variable Page Path nachvollziehen können auf welcher Seite der Button angeklickt wurde.

Nur noch die ID und den Trigger verknüpfen

Zum Schluss bleibt eigentlich nur noch, die Google Analytics ID zu verknüpfen, die wir vorher angelegt haben. Und als Trigger, wählen wir unseren “wichtigen Button Trigger

Wenn ihr alles eingerichtet habt, veröffentlicht ihr sämtliche Änderungen. Und testet ob alles so funktioniert wie geplant.

Qualitätssicherung

Der erste Part, in dem man testen kann ob das Tracking funktioniert, ist der noch aktivierte Debug Mode. Wenn man den Button jetzt anklickt sollte man folgendes sehen:

Tracking erfolgreich eingebaut

Im “gtm.click” Event wird angezeigt, das ein Tag gefeuert wurde. Und zwar genau das Tag, dass wir angelegt haben. Also durchaus ein gutes Zeichen, dass alles funktioniert. Abschließend können wir das aber nur in Google Analytics feststellen.

Auch in Analytics werden die Daten erfasst

Ein Blick in das Google Analytics Dashboard zeigt, dass auch hier die eingefangenen Daten archiviert werden. In der erweiterten Anzeige wird jetzt auch angezeigt auf welcher Seite der Button angeklickt wurde.

Funktioniert alles – erfolgreiches Tracking

Somit war das Buttontracking erfolgreich und ihr könnt anfangen euch zu überlegen, was genau ihr eigentlich tracken wollt. Viel Spaß beim ausprobieren.

Sicherheitslücken finden und schliessen

Gerade jetzt zur Zeit, wo Gutenberg veröffentlich wurde und noch nicht so läuft, wie man sich das vorstellt, sträuben sich viele User auf die aktuelle Version zu updaten. Warum Updates eine gute Sache sind und wie sie zur Sicherheit der WordPress Installation beitragen will ich hier kurz beleuchten.

Wenn Ihr meiner Anleitung Kali Linux in VirtualBox installieren gefolgt seid, habt ihr bereits eine Kali Installation. Solltet ihr diese noch nicht haben, macht es Sinn dies vorher einmal durch zu gehen.

Sicherheitslücken mit WPScan finden

WPScan öffnen
Hier findet Ihr WPScan

Unter “Anwendungen -> Webapplikationen -> wpscan” findet man das Tool, dass wir für den ersten Schritt benötigen. Zunächst wollen wir erst einmal schauen, ob unsere WordPress Installation wirklich Sicherheitslücken aufweist.

Der Befehlsaufbau lautet dabei wie folgt:

wpscan --url [URL einfügen]

Dieser Befehl ist der simpelste, den man mit wpscan ausführen kann. Würde uns interessieren welche Benutzer auf dem System angemeldet sind, könnte man noch den enumerate Befehl anhängen, dazu komme ich aber gleich nochmal.

wpscan start
wpscan beginnt zu arbeiten

Wpscan durchsucht die aktuelle URL nun nach allen Möglichen Parametern. Unter anderem: Versionen der WordPress Installation und Versionen der installierten Plug-ins.

Wenn alles in Ordnung mit dem geprüften Part ist wird dies mit einem grünen Plus versehen. Sollte das Programm eine Schwachstelle gefunden haben, wird diese mit einem roten Ausrufezeichen markiert.

Sicherheitslücken in WordPress gefunden!

Auf der aktuell geprüften Seite wurden insgesamt 17 Sicherheitslücken gefunden. Wer jetzt denkt, dass diese extra für diesen Beitrag offen gelassen worden sind liegt weit daneben. Diese Findings sind mehr die Tagesordnung in aktuell laufenden Systemen als die Ausnahme.

Folgende Sicherheitslücken wurden identifiziert:

Sicherheitslücke: Contact Form 7

Sicherheitslücken in Contact Form 7
register_post_type() Privilege Escalation found

Die erste Sicherheitslücke wird uns direkt von Contact Form 7 angeboten. Ausserdem werden auch die Erklärungen zu dieser Sicherheitslücke angezeigt, so dass sich der interessierte User mehr darüber informieren kann. Ausserdem sieht man auch, wie man das Problem beheben kann.

Fixed in: 5.0.4

wpscan – Kali Linux

Ein Update des Plug-ins wäre also dringend anzuraten.

Sicherheitslücke: LayerSlider

Sicherheitslücken im LayerSlider Plugin
Der LayerSlider beschert uns gleich 3 Sicherheitslücken

Die verwendete LayerSlider Version öffnet die Tore für Angriffe gleich so weit, dass man sich nicht mal mehr besonders anstrengen müsste um dem System schaden zuzuführen. Und auch hier können die Lücken geschlossen werden, indem man mindestens auf Version 6.2.1. updated.

Sicherheitslücke: Wordfence

Sicherheitslücken in Wordfence 1
Wordfence kommt gleich mit 12 Lücken daher

Wordfence, ein WordPress Plugin, dass für Sicherheit sorgt. Öffnet auch gleich Tür und Tor der WordPress Installation, aber das Plugin kann nichts dafür, dass der Admin es nicht geupdated hat.

Sicherheitslücken in Wordfence 2
XSS und Banned IP Bypasses – Ein Spaß für jeden Angreifer

Spätestens jetzt, sollte man kalte Füße oder Gänsehaut bekommen. Und sich bereits ein Backup der Installation ziehen, damit man sich ans updaten der Plug-ins machen kann. Aber da geht ja sicher noch mehr oder? -Na klar, einen haben wir noch.

Sicherheitslücke Wordfence 3
Und weiter gehts, XSS und Bypasses ohne Ende

Wer sich fragt was XSS bedeutet. Sollte sich ausgiebig über Cross Site Scripting informieren. Aber vielleicht gibt es dazu später noch einen Beitrag.

Sicherheitslücke: Yoast SEO

Sicherheitslücke: Yoast
Auch eine alte Verison von Yoast ist betroffen

Diese Sicherheitslücke von Yoast ist “nicht so schwerwiegend” und betrifft nur Systeme in denen die Rolle SEO-Manager vergeben wurde. Aber warum sollte man etwas riskieren, wenn man so eine lücke mit einem simplen Mausklick beheben könnte?

Fazit:

Der Scan der Seite hat Sage und Schreibe 3 Minuten gedauert und 17 mögliche Angriffsstellen offenbart. Alle 17 lassen sich durch das Update der Plugins beheben. Leider ist es oftmals so, dass gerade wenn man mehrere Seiten unter der Fuchtel hat. Gar nicht im Fokus hat auf welchem System welche Versionen installiert sind.

Double Check am Ende

Da ich ein Freund der Absicherung bin prüfe ich die Sicherheitslücken erneut mit einem anderen Programm. In meinem Fall mit wpseku. Die benötigten Dateien bekommt ihr hier.

Run WPSeku.py

WPSeku Help Console
Lieber auf Nummer sicher gehen bei der Sicherheit

Gestartet wird der Scan mittels:

python3 wpseku.py --url www.URL.com

Sicherheitslücke: Revslider

WPSecu Scan 1
17 waren ja noch nicht genug, hier kommt Nummer 18

Na zum Glück haben wir nochmal nachgeschaut, denn der RevSlider ist auch betroffen, bei wpseku.py wird auch noch der passende Exploit aus dem Metasploit Framework angeboten. Aber hier geht es nicht um das testen des Exploits.

Sicherheitslücke: js_composer

WPSeku Scan 2
Und der js_composer liefert uns Sicherheitslücke 19

Die letzte Sicherheitslücke liefert uns der js_composer mit einer XSS Verletzlichkeit.

Darum sollte man seine Plugins up-to-date haben

Wie der nächste Schritt für diese Seite aussehen muss, sollte jetzt jedem klar sein. Denn genau jetzt muss man damit beginnen die Plugins Stück für Stück zu updaten und dann eine erneute Prüfung durchzuführen.

wpscan und wpseku sind frei zugängliche Programme, die sich jeder installieren kann. Und es ist immer besser für die WordPress Seite, wenn man den Script Kiddies und Pseudo Hackern, die mal gehört haben, dass man leicht in ein WordPress einbrechen kann, nicht den Weg frei macht.

Progressive Web App Entwicklung [Teil 2]

PWA Node.js

In Teil 1 ging es ja vorrangig darum, wieso eine PWA Sinn macht. Im zweiten Teil wird jetzt auf die eigentliche PWA eingegangen. Welche Vorraussetzungen gegeben sein müssen, welche Software man braucht um loszulegen und dann eben auch die erste eigene PWA.

Erste Schritte – Node JS

Insofern noch nicht geschehen, benötigt man zum Entwickeln der PWA Node.Js. Grundsätzlich geht es darum, einen Server zu simulieren um die PWA ausgiebig testen zu können. Da die Entwicklung lokal stattfindet.

Durch einen Klick auf das Node.js Logo kannst du dir den latest build herunterladen.

Node.js

Workspace Setup

Um an dem Projekt arbeiten zu können muss der Package Manager installiert werden. Dazu nutzt man das Terminal oder die Powershell (im Administrationsmodus). In meinem Fall habe ich das Terminal im Atom Editor (bekommst du hier) integriert. Du navigierst in den passenden Ordner deines Projektes und führst den Befehl:

npm install

aus.

Mhm.. und mit welchen Daten arbeiten wir?

Das beigefügte ZIP File beinhaltet das Übungsprojekt aus dem Kurs. Ich habe vorher die Lizenz angeschaut und es handelt sich dabei um die ISC-Lizenz, von daher sollte einer Veröffentlichung auch nichts im Wege stehen.

Wenn du die Daten herunter geladen hast kannst du in dem Editor deiner Wahl den Ordner als Projektordner angeben und mit “npm install” weitermachen.

ZipFile Icon
Lade Dir die Übungsdaten herunter
npm install – wurde bereits erfolgreich ausgeführt (Atom Terminal Eweiterung)

Den Development Server starten

Wenn der Package Manager installiert wurde, besteht der nächste Schritt darin, den Entwicklungsserver zu starten. Der Befehl dazu ist relativ simpel:

npm start
Der Entwicklungsserver wurde gestartet

Die App aufrufen

Um die App aufzurufen öffnet man nun Google Chrome und gibt in der Adresszeile: 127.0.0.1:3000 (alternativ auch localhost:3000) ein. Als nächstes öffnet man die Chrome Developer Tools (F12) und schaltet zunächst auf die mobile Ansicht. Außerdem macht es Sinn den Cache für die Zeit der Entwicklung zu deaktivieren um weitere Funktionen testen zu können.

Google Chrome Developer Tools im Einsatz
Google Chrome Developer Tools

Turn it into a PWA

Alles was man jetzt zu sehen bekommt, ist eine völlig normale Webseite. Weit entfernt von einer PWA. Eine entscheidene Zeile Code fehlt noch in den Demodaten. Um das zu beheben fügt man in der Datei app.js (im js Ordner des Projektes) in Zeile 5 folgenden Code ein:

navigator.serviceWorker.register('/sw.js');

Diese Zeile sorgt dafür, dass die sw.js Datei als Service Worker registriert wird. Nachdem die Datei gespeichert wurde kann man die App erneut auf Funktionalität testen.

In den Developer Tools wird, nachdem ihr die Seite neu geladen habt folgendes angezeigt:

ServiceWorker Anzeige unter Applications
Der Service Worker ist aktiv und wurde geladen

Damit man die Funktionalität des Service Workers testen kann, schaltet man die Seite auf Offline und lädt sie neu.

Wenn jetzt die Inhalte dennoch laden zeigt es, dass die App auch Offline funktioniert. Wer das nicht glauben mag, kann den Service Worker einmal “unregistern” und die Seite neu laden.

Was man dann zu sehen bekommt ist der Offline Modus von Google.

Laufende Saurier im Google Offline Modus
Mein Google Offline Dinosaur Run Highscore liegt bei 4359

Fazit:

Die Integration von Node.js, das Herunterladen der Dateien und das Starten des Development Servers stellen keine größere Herausforderung dar. Dennoch zeigen die Demodaten eine erste Funktionalität der PWA.

Alles in allem freue ich mich schon darauf den nächsten Abschnitt zu beginnen.

Ptrogressive Web App
Zurück zu PWA Entwicklung Teil 1

Progressive Web App Entwicklung [Teil 1]

Ptrogressive Web App

Ich bin ja ein großer Freund von Weiterbildung. Und aus diesem Grund hab ich mich mal in die Welt von Udemy gewagt. Und einen Kurs belegt. Es geht, wie der Titel schon verrät um Progressive Web Apps. Damit alle was davon haben, werde ich meine Erkenntnisse aus den Videos und Lektionen hier gerne kundtun. Ob es was taugt, werden wir wohl erst am Ende der Kurse erfahren

PWA: Abschnitt 1, Lektion 1

Dann mal los – Über den Kurs an sich

Es beginnt damit, das ich erklärt bekomme warum das Entwickeln mit PWA Sinn macht. Das PWA der neueste Shice sind. Und was mich in dem Kurs erwartet. Ausserdem geht es um die Kernkompetenzen einer Progressive Web App

Das Interesse an PWA laut Google
  • Auf dem Homescreen installieren
  • Offline Erreichbarkeit
  • Push Notifications
  • User Standorte
  • Gerätekamera erreichen
  • Hintergrund Synchronisation

Zum Schluss wird noch erklärt was für eine PWA ich in diesem Kurs schreiben werde. Der Kursleiter stellt sich noch einmal vor und ich bin schon ganz heiß darauf los zu legen.

PWA: Abschnitt 1, Lektion 2

Dive into PWAs

In der zweiten Lektion wird die Frage geklärt, was Progressive Web Apps eigentlich sind. Und um dem Ganzen den Zauber etwas zu nehmen, sind PWAs eigentlich nur ein Sammelbegriff für Features die man seiner Webseite hinzufügen kann um sie zu verbessern.

You progressively enhance your existing web pages to feel and work more like native mobile apps.

Maximilian Schwarzmüller – Udemy

Es geht dabei nicht nur um Responsivität. Es geht viel mehr um die Funktionalitäten, die man aus bestimmten Apps bereits kennt. Wie z.B. Offline Modus, Icons auf dem Homescreen oder Datasynchronisierung im Hintergrund.

Die Vorteile der Progressive Web Apps können in drei Kernbereiche aufgeteilt werden.

  • Zuverlässig: Schnelle Ladezeiteun und offline Funktionalität
  • Schnell: User Interaktionen werden schnell “beantwortet”
  • Einnehmend: Der User soll sich öfter mit der PWA auseinandersetzen

PWA: Abschnitt 1, Lektion 3

Mobile Web vs Native Apps

Macht das Entwickeln einer PWA überhaupt Sinn? Lediglich 13% der User nutzen das mobile Web und die restlichen 87% verlassen sich auf die nativen Apps. Die Gründe, warum das so ist liegen aber in den Vorteilen der nativen Apps.

Und wie bereits weiter oben erwähnt greifen PWAs genau an dieser Stelle an und bieten die Funktionalitäten, die eine native App auch bietet.

Welche Nachteile haben native Apps?

Sollte man sich für das Entwickeln einer nativen App entscheiden, muss man berücksichtigen, dass man für zwei verschiedene Anbieter von Apps entwickeln muss: iOS und Android.

80% der User benutzen lediglich 3 Apps auf ihren Geräten und die Chance dass die eigene App dabei sein könnte ist eher schwindend gering. (Facebook, Whatsapp, Google)

PWA vs native Apps vs traditional web pages

Native Apps:
Bei den nativen Apps sind die Möglichkeiten das Gerät zu nutzen schier unendlich. Kamera, Standort, Gyrosensor und vieles mehr. Außerdem ist auch das Betriebssystem des Devices nutzbar. Dafür leidet die Reichweite aus dem Grund, dass im Durchschnitt nur die Top 3 Apps genutzt werden.

Web Apps:
Hier ist es genau gegenteilig. Die Nutzbarkeit von bestimmten Geräte Features ist bei einer traditionellen Web App sehr eingeschränkt. Dafür ist die Reichweite um ein vielfaches höher, denn man muss nur eine URL aufrufen und die Seite ist erreichbar. Installationen aus einem App Store hingegen fallen flach.

PWAs:
Die Progressive Web Apps vereinen jetzt genau diese Vorteile aus den beiden vorher gegangenen Typen. Man hat die Möglichkeit die Gerätefunktionen zu nutzen und man bekommt die hohe Reichweite der traditionellen App, weil man auch bei der PWA nur eine URL öffnen braucht um auf sie zuzugreifen

PWA: Abschnitt 1, Lektion 4

Demo PWA und Aussicht auf die eigene PWA

In der vierten Lektion wird eine Beispielseite genannt. An der man die Vorteile einer Progressive Web App testen kann. Unter https://app.ft.com befindet sich die PWA Version der Financial Times. Wer möchte, kann hier gerne etwas herum experimentieren. Gerade im Bereich “Was passiert wenn die Seite offline ist” kann man wunderbar sehen, dass die Inhalte immer noch lesbar sind.

Bildauschnitt der PWA Version, der Financial Times
PWA Version der Financial Times

Auf die Vorstellung der App die wir gemeinsam bauen, gehe ich erst einmal nicht weiter ein. Da ich nicht zu viel vorgreifen möchte. So viel nur dazu: Es handelt sich in dem Kurs um einen Instagram Clone. Ob ich diesen so nachbaue oder meine eigene Seite direkt zur PWA weiterentwickel weiß ich jetzt noch nicht.

Ein gut gemeinter Rat des Kursleiters:
Für das Entwickeln und testen der App, macht es Sinn Google Chrome zu verwenden, da der Browser besonders gute Developer Tools mit sich bringt. Und das Lighthose Plugin, das speziell zum testen der PWAs geeignet ist.

PWA Node.js
Weiter zu PWA Entwicklung Teil 2

Vier MySQL Querys die Dir das Leben leichter machen

Kennste oder?

Du entwickelst eine Website auf deiner Testumgebung oder Local mit Xampp, Lampp oder einem *ampp deiner Wahl. Der Kunde (insofern vorhanden) ist durchaus zufrieden bei der Präsentation und “das Teil soll jetzt online gehen”

Du fängst an deine Daten und die Datenbank zu kopieren, verknüpfst Deine Domain mit dem Webspace und dann:

Fehler beim Aufbau einer Datenbankverbindung
“Nanu? Dabei hab ich doch alles richtig kopiert?”

Natürlich! Du hast vergessen die wp-config.php anzupassen. Also gehst du nochmal über den FTP Server, öffnest die Datei und trägst deine Verbindungsdaten in der Datei ein.

Nach dem Abspeichern freust Du Dich schon auf eine schöne Tasse Kaffe.
Aber Pustekuchen: Deine Seite springt auf die URL der Testumgebung zurück.

Anpassungen der URLs in der Datenbank vergessen?

Spätestens jetzt sollten Dir Wörter wie “Better Search Replace” oder “Duplicator” in den Sinn kommen. Und wenn dem nicht so ist, dann wäre das spätestens jetzt der Fall. Was aber tun diese beiden Plugins?

Better Search Replace

Mit Hilfe dieses Plugins ist es möglich nach bestimmten Strings in der Datenbank zu suchen um diese durch andere auszutauschen. Wie mein alter Oberleutnant immer sagte :”Alles heißt so wie das was es tut”

Bildauschnitt Better Search Replace

Das Problem bei der Geschichte:
Du kommst gar nicht in dein Backend um das Plugin zu installieren. Denn wenn du das versuchst kommst du wieder auf deine Testumgebung. Mehr Glück bringt da eventuell das nächste Plugin

Duplicator

Duplicator WordPress Theme

Duplicator ist eine All in One Lösung für den Umzug oder eben dem Duplizieren von WordPress Seiten. Dabei wird ein Abbild deiner aktuellen Version gemacht. Du bekommst zwei Dateien, die du auf deinem FTP Server wieder hochlädst um dann mit dem Wizard die Installation auf dem neuen Server abzuschliessen.

Dabei ändert Duplicator deine URLs nach deinen Vorgaben direkt bei der Installation. Klingt erstmal sehr gut.

Das Problem bei der Geschichte:
Du hast die Daten bereits aufgespielt. Natürlich kannst du jetzt die Datenbank löschen, die Files vom Server löschen. Duplicator auf deinem Testsystem installieren, das Archiv generieren lassen, das Archiv dann hochladen und den Wizard zum installieren durchführen. Und jetzt kommt das große

ABER:

Je nach Verbindungsgeschwindigkeit dauert das Löschen, runter- und wieder hochladen je nach Seitengröße so lange, dass man da überhaupt keine Lust mehr zu hat. Ausserdem möchte man sich vielleicht auch kein externes Plugin installieren für einen Vorgang, den man mit Sage und Schreibe vier SQL Querys selbst erledigen kann.

Hier kommen die Querys

Query 1: Home Base

UPDATE wp_options SET option_value = replace(option_value, 'http://www.oldurl', 'http://www.newurl') WHERE option_name = 'home' OR option_name = 'siteurl';

Mit diesem Query passt du den Basepfad deiner WordPress Installation an, und sorgst dafür, dass das Backend erreichbar wird. Solltest Du Dich, aus welchen Gründen auch immer dazu entscheiden die anderen Schritte nicht durchzuführen.

Query 2: GUID

UPDATE wp_posts SET guid = replace(guid, 'http://www.oldurl','http://www.newurl');

Das Zweite Query passt die URLs bei den Global Unique Identifiern an.

Query 3: Post Content

UPDATE wp_posts SET post_content = replace(post_content, 'http://www.oldurl', 'http://www.newurl');

Nummer Drei ist dafür Verantwortlich, dass deine Beiträge wieder auf der richtigen URL auflaufen.

Query 4: Post Meta

UPDATE wp_postmeta SET meta_value = replace(meta_value,'http://www.oldurl','http://www.newurl');

Das Schlusslicht in der Liste sorgt dafür das auch erweiterte Optionen berücksichtig werden.

Was du also zu tun hast

Wenn du deine Datenbank auf deinem neuen Server aufgespielst hast, gehst du über phpmyadmin in deine Datenbank und führst die Querys nacheinander aus. Dabei ersetzt du natürlich den Tabellen Präfix und die URLs mit deinen aktuellen. Und das wars!