WordPress auf SSL umstellen

Dank Lets Encrypt kann man erschwinglich ein SSL Zertifikat bekommen. Für die Inhaber von eigenen Servern bzw. mit SSH Zugriff geht die Einrichtung wohl auch recht schnell und unkompliziert. Was mich bisher dann doch davon abgehalten hatte, war mein Shared Host. Ich habe ja nur begrenzte Zugriff.

SSL mit Lets Encrypt bei all-inkl.com

Da mir die Erstellung für den Shared Host recht lästig vorkam und die Zertifikate auch nur 90 Tage vorhalten, schrieb ich vor kurzem den Support von meinem Hoster all-inkl.com an, ob sie mir denn bei der Einrichtung eines Zertifkates behilflich sein könnten und ob mich das was kosten würde. Die Antwort des Supports kam gewohnt schnell. Und auch die Antwort freute mich. Ich müsse lediglich die (Sub-)Domain nennen und mich authentifizieren. Gesagt, getan und nach weiteren 10 Minuten hatte ich ein Lets Encrypt Zertifikat auf der Domain. Jetzt die Umstellung meiner Domain anfangen.

URL-Optionen anpassen

Von nun an ist es nicht mehr weit. Im Adminbereich unter Einstellungen > Allgemein kann nun noch die URLs umgestellt werden. Habt ihr eine Multisite-Installation, dann wird diese Einstellung in den Netzwerkeinstellungen unter Webseiten > Webseite bearbeiten umgestellt.

Exkurs: Hauptdomain im WordPress MultiSite Netzwerk ändern

Wenn ihr, wie ich, die Hauptdomain eures Netzwerkes umstellen wollt, dann geht es nicht so einfach über die Adminoberfläche. Hierfür sind noch ein paar Anpassungen in der WordPress Konfiguration und in der Datenbank notwendig:

  • Die Optionen siteurl und home in der Tabelle wp_options*
  • Bei einem zusätzlichen Domainwechsel sind die Änderungen in den Tabellen wp_site und wp-blogs notwendig
  • Bei einem zusätzlichen Domainwechsel ist die Anpassung der Option DOMAIN_CURRENT_SITEin der wp-config.php notwendig

* wp_ ist ein Platzhalter für deinen Datenbankprefix.

URL Rewrite von http auf https

Nun wollen wir noch die normalen HTTP-Aufrufe auf HTTPS umleiten. Hierfür kann in der .htaccess folgender Codeblock genutzt werden. (URL anpassen nicht vergessen 😉 ):

# SSL for example.org in the multisite network
RewriteCond %{HTTP_HOST} ^example.org
RewriteCond %{SERVER_PORT} !443
RewriteRule ^(.*)$ https://org.org/$1 [R,L]
`</pre>

## SSL im WordPress Admin Bereich erzwingen

Neben den Anpassungen in der `.htaccess` kann man durch ein paar Zeilen in der `wp-config.php` die Verwendung von SSL im Adminbereich erzwingen:
<pre>`// just switch this domain in the multisite network
if ( $_SERVER["HTTP_HOST"] == "example.org" ) {
    define('FORCE_SSL_ADMIN', true);
    define('FORCE_SSL_LOGIN', true);
}

Alte Links im Content anpassen

Nachdem die Seite nun über HTTPS aufgerufen werden kann, sind dennoch Links auf den alten HTTP-Pfad in den Blogbeiträgen. Hier kann das Plugin Velvet Blues Update URLs Abhilfe schaffen. Es durchsucht den gesamten Content (Posts, Custom Post Types, Medien etc.) nach einer URL und ersetzt sie mit einer neuen URL. Genau das Richtige, um die Links von http auf https zu ändern.

Meine Seite verwendet ein Logo im Header, das über den Theme Customizer eingefügt werden kann. Solche Bilder ersetzt das Plugin leider nicht mit. Um hier den HTTPS-Link zu erhalten, konnte ich das Bild im Customizer aus dem Theme entfernt und erneut hinzugefügen.

Nun noch einen Blick in die Konsole des Browsers werfen um sicher zu stellen, ob alle HTTP-Verweise ersetzt wurden. Und fertig.

Edit: Web Fonts

Ein kleiner Hinweis, den ich noch von @bisonfute erhielt, war auch die Einbindung von WebFonts durchzusehen. Bei mir hatten sich noch ein paar mit eingeschmuggelt. Hier hilft es, um Stylesheet die Referenzierung von http://path.to.webfont auf //path.to.webfont zu ändern.

Zusammenfassung

Eine WordPressinstallation auf SSL umzustellen ist dank einiger Hilfmittel recht schnell zu bewerkstelligen. Die Seiten-URLs können in den meisten Fällen direkt in der Oberfläche von WordPress geändert werden, für die Ersetzung im Content unterstützen Plugins. Dank Lets Encrypt kann man Zertifikate frei erhalten. Selbst mit einen kleinen Änderungen in einem Texteditor kann eine WordPress Multisite-Installation unkompliziert umgestellt werden.

Retina testen ohne Retina

Moderne Seiten sollten ja auch auf Retina-Displays vernünftig aussehen. Nur wie testet man, dass das was man da in Code gegossen auch auf diesen Displays gut und richtig aussieht, wenn man grad keines zur Hand hat.

Ein kleine Hilfe bietet der Firefox:

1) In der Adresszeile about: config aufrufen
2) Den Eintrag layout.css.devPixelsPerPx anpassen. 2 ist für Retina, 1 ist normales Display

npm ohne sudo unter Ubuntu

Ich bin passionierter Linux Nutzer und war sehr froh, als ich meine Entwicklungsumgebung auch endlich im Ubuntu zum Laufen bekam.

Nodejs, Grunt oder Gulp und natürlich auch IntelliJ. 😀

Eine Sache war mit aber noch ein Dorn im Auge. Ich musste alle npm Module per sudo installieren. Aber auch da konnte abhilfe geschaffen werden:

npm config set prefix ~/npm

im Terminal ausführen und dann noch

export PATH="$PATH:$HOME/npm/bin"

in der .bashrc hinzufügen. Und nach dem Ausführen von

source ~/.bashrc

läuft nun auch das Installieren von den npm Modulen schön ohne sudo.

jit-grunt – Ein Modul für Ungeduldige

Grunt Tasks laden

Ich bin ja eher einer von der ungeduldigen Sorte. Ich warte ungern und freue mich drüber, wenn ich Prozesse optimieren, automatisieren und beschleunigen kann. Seit dem ich von GruntJS hörte, bin ich Fan. Man kann damit viele nervige und wieder kehrende Sachen automatisieren. Aber wem erzähl ich das..

Nun kommt es vor, dass mit forschreitender Projektdauer das Gruntfile und damit auch die Tasks, die der gute Taskrunner übernimmt, immer mehr werden. Aber man benötigt nicht immer alle Tasks, die auch im Gruntfile definiert sind. Dummerweise weiß das Grunt aber nicht und lädt immer alle Tasks. Das kann auch schon mal seine drei, vier, fünf Sekunden dauern. Wenn nun die Ausführung des eigentlichen Tasks nur den Bruchteil einer Sekunde dauert, ist das vergeudete Zeit.

Es gibt ein Node-Modul, mit dem man diesem Missstand abhelfen kann:

jit-grunt

Bindet man jit-grunt in seinem Gruntfile ein, werden nur noch die Tasks geladen, die auch zum Ausführen benötigt werden. Man mag meinen, dass es keinen sonderlichen Einfluss hat, ob die Auführung nun fünf oder nur zwei Sekunden dauert. Ich als ungeduldiger Mensch kann sagen: Es macht einen Unterschied. Wem es nicht anders geht, kann das Modul ja mal benutzen.

Stolpersteine

Es kann vorkommen, dass man bei der Arbeit mit jit-grunt auf folgende Fehlermeldung stößt:


jit-grunt: Plugin for the "cssmetrics" task not found.
If you have installed the plugin already, please setting the static mapping.
See https://github.com/shootaroo/jit-grunt#static-mappings
Warning: Task "cssmetrics" not found. Use --force to continue.

Diese Meldung kann zwei Herkünfte haben:

  1. Das Modul ist nicht installiert. Dann genügt in der Regel ein Aufruf von npm install um den Task laufen zu lassen
  2. Der Task heißt anders als das Modul (grunt-contrib-[name], grunt-[name] oder [name]), dann muss ein statisches Mapping eingebunden werden.

    require('jit-grunt')(grunt, {
    sprite: 'grunt-spritesmith',
    hello: 'custom/say-hello.js' // for custom tasks.
    });

Fazit

Das Modul ist für ungeduldige Menschen eine große Hilfe und kann zur Produktivitätssteigerung beitragen. Durch die wiederholte Ausführung der Tasks dürfte sich die Einrichtungszeit auch bald rentiert haben.

Projektübersicht

Hier findet ihr Links zu meinen Projekten auf BitBucket.
Die Projekte sind OpenSource und unterliegen der MIT Lizenz.

node_modules in Windows löschen

Ich habe vor kurzem eine Reihe an yeoman Generatoren ausprobiert. Von Natur aus generieren die einen node_modules-Ordner. Als ich meine Versuche löschen wollte, stellte Windows sich quer. Einige Ordnernamen wären zu lang.

Da das sehr ärgerlich ist und ich meine Festplatte nicht noch weiter vollmüllen wollte, machte ich mich auf die Suche. Und ich wurde fündig. Es gibt ein Node.js Modul, dass sich genau um solche Fälle kümmert. Darf ich vorstellen: rimraf.

Einfach rimraf node_modules in der Konsole aufrufen und er nunmehr ungeliebte Order wird gelöscht.

Agile? Ja, aber wie?

Agile Vorgehen sind ein gutes Mittel, um ein Produkt zu entwickeln. Ich bin ein Freund davon, Sachen, die sich in professionellen Bereichen bewährt haben, auch privat oder in ehrenamtlichen Projekten zu benutzen.

So auch agile Vorgehen. Ich persönlich habe praktische Erfahrungen nur in Scrum sammeln können. Also habe ich versucht, Scrum ehrenamtlich zu verwenden. Als Tool hilft mir dabei The Bug Genie. In PHP geschrieben unterstützt es gut bei der Planung und beim Arbeiten.

User Stories, Sprints, Bugs. Alles kann man abbilden.Aber wie lange wählt an den Sprint? Da ich in meinem Testprojekt allein entwickle, wählte ich zunächst einen Monat. Ich dachte mir, das wäre lang genug um auch wirklich was entwickeln zu können und kurz genug, um nach dem Sprint live gehen zu könnnen.

Zwei Monate lang klappte die Entwicklung so ganz gut, dann kam mehr und mehr das Leben dazwischen. In mir verdichtete sich der Verdacht, dass feste Iterationszeiten vielleicht doch nicht so praktikabel sind. Schließlich arbeitet man ja nicht jeden Tag am Projekt.

Der nächste Versuch ist: Ausliefern, wenn die Story fertig ist. Mal sehen, wie praktikabel das wird.

Javascriptkonsole im nativen Android Browser

Manchmal kommt soll es in der Entwicklung ja vorkommen, dass die Software oder eine Seite nicht so funktioniert, wie sie eigentlich soll. Manchmal stoppt die Ausführung durch einen Javascriptfehler.

Wenn man nun weinre oder andere Debuggingtools grade nicht zur Hand hat, kann die Konsolenausgabe vom nativen Androidbrowser helfen. Ein kleiner Trick, der vielleicht viele Nerven und viel Raterei sparen kann.

Man öffnet einen neuen Tab und tippt dann „about:debug“ in die Adresszeile sein. Zurückgewechselt zum Ausgangstab kann man nun mit einem Fingerstreif die Konsole einblenden.

Remote Debugging

Remote Debugging unterstützt beim Entwicklen von Webseiten. In Zeiten von Responsive Web Design und Mobile First wird ja die Unterstützung von diversen Endgeräten unabdingbar.

Google hat für das Debugging nette Unterstützung in den Chrome eingebaut, Apple in den Safari. So weit so gut. Aber auch da tun sich schnell die Grenzen auf.

Was also tun, wenn man sich abseits von Chrome oder Safari bewegt, weil man z.B. einen Fehler nur auf dem nativen Browser auf Android feststellt.

weinre kann da helfen. weinre ist über npm schnell installiert.

npm install weinre -g
weinre --boundHost 192.168.x.x --readTimeout 60

Der Server startet standardmäßig auf Port 8080. Die Seite kann direkt aufgerufen werden und man findet Installationshilfen für das Skript.

Ich habe den Skripttag in mein Entwicklungssystem eingebunden und kann somit Sachen abgreifen.

<script src="http://192.168.x.x:8080/target/target-script-min.js#anonymous"></script>

Unter Access Points kann man dann den Debugger aufrufen. Wenn man Firebug oder die Chrome Developer Tools kennt, dann fühlt man sich da wohl.

Der HTML-Code wird abgegriffen, CSS-Selektoren können angezeigt werden und das ausgewählte DOM-Element wird auf dem Gerät markiert.

Kickoff

Schon seit längerem habe ich nach einem Kanal gesucht, um meine Tätigkeiten im Webumfeld festzuhalten und mich ggf. auch mit anderen auszutauschen. Bisher hatte ich diesen Kanal nicht gefunden. Und nun gibt es ihn.

Mit the agile volunteer möchte ich Kleinigkeiten und Gedankengänge aus und für das Internet festhalten. Es wird um Themen gehen wie Scrum, agile Softwareentwicklung, Automatisierung, Testen und wie sich diese Sachen auch in ehrenamlichen bzw. Freizeitprojekten wiederfinden.

Ich bin gespannt, wie sich diese Seite entwickelt. Und wie ich mich entwickle. Ich freue mich. Kickoff and go.