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.

Kali Linux in VirtualBox installieren

Kali Linux

[Plus Bonus am Ende]

Manchmal möchte man einfach auf Nummer sicher gehen, wenn man im Netz am Arbeiten ist. Ab und zu ist man darauf angewiesen auf ein anderes Betriebssystem zuzugreifen oder man möchte seine Hauptdaten auf dem Rechner schützen. Die Gründe, warum man nicht möchte, dass ein anderer auf die eigenen Daten zugreifen kann, sind vielseitig. Wer jetzt nicht unbedingt mit einem zweiten Computer arbeiten will, kann hier auf eine virtuelle Lösung zurückgreifen. Und wie das funktionieren kann, möchte ich hier gerne erklären.

Wie der Titel es schon verrät werden mindestens zwei Ressourcen benötigt. Zum einen VirtualBox und zum anderen ein Betriebssystem Deiner Wahl. In meinem Fall Kali Linux (weil ich es sehr gerne mag)

Virtualbox
Klick aufs Bild um dir VirtualBox zu holen
Die passende Kali Version bekommst du hier

Die Installationen

Der erste Schritt besteht darin, sich VirtualBox zu installieren. Viel gibt es zur Installation nicht zu sagen, außer das man sich einmal durch den Wizard klickt.

Auf der Kali Homepage gibt es verschiedene Versionen, die man herunterladen kann. Der Downloadlink aus dem oberen Bild führt aber direkt zu einer speziellen VirtualBox Version. Achtet also darauf, die richtige Version für eure Rechner Architektur auszuwählen.

Kali Linux VBox Version Download
VBox 64bit Version von Kali – Downloads dauern

Sobald der Download beendet ist kann man damit weitermachen, das Abbild in VirtualBox zu importieren.

Datei importieren in VirtualBox

Wählt in VirtualBox -> Importieren (1) und klickt dann auf das Ordnersymbol (2) um die Datei auszuwählen, die importiert werden soll. Anschließend bekommt Ihr eine Zusammenfassung, mit welchen Optionen Kali installiert wird. Hier könnt Ihr die Einstellungen importieren und müsst anschließend kurz warten, bis die Installation durchgeführt wurde.

Fast geschafft

Wenn alles glatt gelaufen ist, sollte Kali Linux 2018.4 (aktuelle Version) nun in der VirtualBox auswählbar sein.

Los gehts

Ihr könnt jetzt Kali starten.

Achtung Fehler!

Sollte die Installation nicht starten und folgender Fehler auftauchen. Müsst Ihr folgendes tun:

  • Ladet euch das VM VirtualBox Extension Pack hier herunter.
  • Oder deaktiviert den USB 2.0 Support unter
  • Ändern -> USB -> USB-Controller aktiveren

Ich empfehle die Installation des Extension Packs

Wenn Ihr Kali gestartet habt, Euch aber nicht einloggen könnt, solltet Ihr mal den Standardnutzernamen
„root“ und das Default Passwort „toor“  ausprobieren.

Herzlich Willkommen bei Kali

Bonus: Tor Browser installieren

Jetzt wo man die Kali Oberfläche vor sich hat, könnte man noch auf die Idee kommen, dass man einen Tor Browser braucht. Da Linux nicht Windows ist, geht die Installation hier etwas anders. Wenn man im Internet ein wenig recherchiert gibt es sehr viele Anleitungen, die zeigen wie man den root user check umgehen kann. Das ist allerdings nicht der richtige Weg um Tor auf Kali zu starten.

TOR Logo
The Onion Router – Oder auch einfach TOR

Warum sollte man den Tor Browser nicht als root starten?

  • Es funktioniert zwar, den root user check zu entfernen. Man öffnet so aber auch Sicherheitslücken, gerade wenn man auf Seiten surfen sollte die eventuell nicht so vertrauenswürdig sein sollten
  • Jedes mal wenn Du den Tor Browser updatest musst du diesen Schritt wiederholen
  • Einen nicht-root User anzulegen, der Anwendungen starten kann selbst wenn man als root angemeldet ist, ist nicht so schwierig.

Wie läuft das jetzt?

Einen Nicht-Root-User anlegen

Um einen neuen User anzulegen verwendet man folgenden Befehl:

adduser --home /home/kali kali

Nun wird man nach einem Passwort für den User gefragt, gefolgt von einigen weiteren Informationen, die man ausfüllen kann, aber nicht muss.

Gar nicht so schwer, eigentlich

Nun kann man sich auf diesem Account einloggen, um zu testen ob alles geklappt hat.

Den torbrowser-launcher installieren

Es gibt verschiedene Möglichkeiten den torbrowser-launcher zu installieren. Da ich persönlich aber auf einem Linux-System immer dem Terminal den Vorzug gebe, benutze ich den normalen apt prozess. Öffnet also ein Terminal und gebt folgendes ein:

apt install torbrowser-launcher

Grundsätzlich nicht so schwer zu realsieren oder?

Den torbrowser-launcher einstellen

Der folgende Schritt ist notwendig, weil der Torbrowser sich nicht einfach so als root starten lässt. Die Gründe waren oben bereits beschrieben. Als Erstes muss sichergestellt werden, dass der angelegte User in der xhosts eingetragen ist. Mit folgendem Befehl wird der User “Kali” eingetragen:

xhost si:localuser:kali

Wenn ihr jetzt immer noch als root-user angemeldet seid, könnt ihr den torbrowser-launcher mit dem Befehl:

sudo -u kali -H torbrowser-launcher

starten.

und damit ist dieser Exkurs auch schon beendet. Wenn Ihr bis hier hin durchgehalten habt. Solltet Ihr jetzt eine Virtuelle Maschine mit Kali Linux am laufen haben auf der ihr mit dem Tor Browser im Internet surfen könnt.

Keine Sorge, alles richtig gemacht

Thats all Folks

Diese Methode zum Starten eines Tor Browsers eignet sich durchaus besser, als den root-user-check zu umgehen. Allerdings sei dir gesagt, zu lange im Internet surfen ist auch nicht gesund. Also öfter mal abschalten.

Wikipedia fühlt sich gleich viel sicherer an

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!

Verschiedene Produktlayouts für WooCommerce?

Das Problem:

Es wurde ein Shop für einen Kunden geplant. Der Einsatz von WooCommerce wurde dafür vorgesehen. Allerdings benötigen wir für eine bestimmte Shop Kategorie ein abweichendes Produktlayout als für die anderen Kategorien.

Standardmäßig kann man aber kein anderes Layout für eine bestimmte Kategorie verwenden.

Aus diesem Grund wurde also eine Lösung benötigt, die für eine vorher definierte Kategorie ein anderes Layout verwendet, als das Default.

Eigene Templatefiles benutzen

Bevor definiert werden kann, welches Template geladen werden soll, muss dieses auch erst mal vorhanden sein. Das Bearbeiten von Corefiles ist nicht update sicher, deswegen kopiert man das Template das man umschreiben möchte in seinen eigenen Themepfad und behält dabei die Filestruktur bei.

Beispiel:

Aus:

/wp-content/plugins/woocommerce/templates/single-product.php

wird:

/wp-content/themes/yourtheme/woocommerce/single-product.php

Nachdem alle benötigten Dateien update sicher in das eigene Template Verzeichnis kopiert worden sind. Kann man die single-product.php auch ohne größere Schäden zu verursachen bearbeiten.

Auszug aus der single-product.php Datei

Modifizieren der single-product.php

Standardmäßig findet sich folgender Codeschnipsel in der single-product.php in Zeile 35, wenn die Datei nicht weiter bearbeitet wurde:

		<?php while ( have_posts() ) : the_post(); ?>
		     <?php wc_get_template_part( 'content', 'single-product' ); ?>
		<?php endwhile; // end of the loop. ?>

Hier befindet sich die Anweisung den Template Part “single-product” auszugeben, solange Posts vorhanden sind. Alles klar soweit. Hier ist also auch genau der Punkt, an dem ich ansetze, um eine andere Template Datei zu laden.

if ( has_term( 'quads', 'product_cat' ) ) {
    woocommerce_get_template_part( 'content', 'single-product-quads' );
} else {
    woocommerce_get_template_part( 'content', 'single-product' );
}

Prüfen der Funktionalität

Wenn man jetzt prüft ob das oben genannte Vorgehen funktioniert, sieht man folgendes:

Leere Shopseite, weil das Template noch nicht eingebunden ist

Das Template wurde geladen, aber es wird nichts angezeigt. Der Grund, der dahinter steckt, ist relativ simpel.
Die Zeile woocommerce_get_template_part( ‘content’, ‘single-product-quads’ ); definiert, dass die Datei content-single-product-quads.php geladen werden soll. Die ist aber schlichtweg einfach noch nicht vorhanden.

Deswegen wird diese Datei als Erstes im Woocommerce Verzeichnis des eigenen Templates erstellt. Ich habe dazu die content-single-product.php kopiert und umbenannt, da ich auf dieser Struktur aufbauen möchte. Lädt man die Datei dann auf den Server, sieht die vorläufige Anzeige so aus:

Standard Single Product Ausgabe

Da die Verknüpfung jetzt klappt, kann man die Datei nach allen Vorlieben umändern und abarbeiten die einem so einfallen.

Alle Deine Keywords in meinem Pool?

Wie ich es geschafft habe für alle Deine Keywords zu ranken erfährst Du hier!

Jede Idee hat einen bestimmten Auslöser, der sie Gang bringt. Und bei mir waren es diese dubiosen Mails, mit Suchmaschinenoptimierung für 299 Euro.Oftmals steht da dann nämlich drin: “Wir haben Ihre Domain analysiert und konnten feststellen, dass Sie für keine Keywords gefunden werden. Für nur ein paarPenunsen ranken wir Sie für alle Keywords.

Die Frage, die ich mir dann immer stelle ist folgende: “Für alle Keywords?” Auch die, die ich nicht brauche? Und dann ist das natürlich einmonströses Angebot. Man stelle sich die Monetarisierungsmöglichkeiten vor.

Wie bekomme ich also alle Deine Keywords?

Zunächst wird hier noch nicht viel mehr passieren, denn der erste Schritt um alle Deine Keywords zu erhaschen, ist bereits getan. Damit ich aber auch den,von Google geliebten Listen gerecht werde, werde ich eine Chronologische Liste mit den Maßnahmen festhalten die dazu geführt haben, dass ich alle Deine Keywords bekommen habe.

Alle Deine Keywords am 06.05.2018

Die erste Maßnahme um alle Deine Keywords zu bekommen besteht darin, hier erstmal auf zu räumen. Der alte Mist ist rausgeflogen und ein allgemeiner Text wurdeauf der Seite platziert. Achja das Noindex, nofollow Attribut wurde auch aus der Robots.txt entfernt. Sonst geht der ganze Plan schief. Danach wurde die Seite neuin der Search Console angepingt und das wars dann auch schon um alle Deine Keywords zu bekommen.

Hilfst du mir alle Deine Keywords zu bekommen?

Falls Du mich bei der Mission unterstützen möchtest, teile diese Seite doch bitte einfach großzügig in allen sozialen Kanälen, die dir so einfallen.

Mein Dank ist Dir gewiss!