Kategorie-Archiv: Development

WordPress to Jekyll – Migration und Fallstricke

Schon vor einiger Zeit hat Tobi gemeint, dass es doch eine ganz coole Idee wäre, das Blog webguys.de unter GitHub zu pflegen und so anderen zu erlauben, neue Blog-Beiträge per Pull-Request zu erstellen. Richtig Entwickler-Like eben. Wer seine Präsentation schon im git hat, der sollte auch seine komplette Website in einem Repo verwalten. Oder?

Nachdem ich dann vor einiger Zeit meinen Beitrag zu GitHub Pages geschrieben habe, hatte ich mich etwas näher mit Jekyll auseinander gesetzt. Dabei ist mir aufgefallen, dass genau hier wahrscheinlich die Lösung für die Idee von Tobi liegt. In diesem Beitrag möchte ich daher einmal Dokumentieren, wie gut oder schlecht das Ganze klappt. Und ob am Ende überhaupt etwas brauchbares heraus kommt. Scheinbar ist die Technologie auf dem aufsteigenden Ast – immerhin setzt Magento 2 mit der Dokumentation ebenfalls auf Jekyll. Auch hier kann man jede einzelne Seite mit einem Fork / Pull-Request bearbeiten.

Leider hat Tobi aber momentan nicht so die Lust sich in Jekyll einzuarbeiten und ist von der Technologie noch nicht so überzeugt – daher muss ich das wohl mit meinem Hausautomatisierungsportal machen. Auch nicht schlimm! Ist auch erstmal kleiner. Außerdem hat die Seite noch nicht so viele Kommentare… Die müsste man nämlich extern auslagern (z.B. zu Disqus).

Die Schwierigkeit besteht sicher darin, alles mit der gleichen Linkstruktur zu übernehmen um keine Einbußen bei Google zu haben. Ich bin gespannt – starten wir!

Grundgerüst

Im ersten Schritt habe ich einfach „View Page Source“ aufgerufen und alles in ein entsprechendes Template kopiert. Das ist natürlich auch DIE Chance, das Ganze HTML-Zeug gleich einmal aufzuräumen! Dabei fällt einem sicher das ein oder andere Verbesserungspotenzial auf! Die wenigen Bilder auf der Seite lade ich erst einmal herunter und übernehme soviel wie nur geht. Am Ende darf nirgendwo mehr die Domain auftauchen – gar nicht so einfach und erstmal eine Menge Arbeit! Puh…

Oder doch ganz anders… Also habe ich mir nach den ersten Schritten ein Bootstrap 3 Template gekauft und baue nun da drauf auf. Fühlt sich auch sauberer an und mit einem neuen Design geht auch gleich alles viel einfacher von der Hand (Soviel zur Theorie…). Das neue Theme habe ich dann erst einmal in seine Bestandteile zerlegt und ein erstes Layout mit den entsprechenden Includes zusammengeschustert.

Jekyll-Includes

So muss man nicht alles doppelt schreiben und kann die einzelnen Bestandteile immer wieder verwenden. Gerade der Header mit Logo, Navigation, etc. und der Footer sehen schließlich auf allen Seiten gleich aus. So hat man verschiedene Bausteine und kann diese zentral bearbeiten. Änderungen über die komplette Seite sind dabei also nach wie vor sehr einfach. Die Zeit, die man hier investiert, spart man am Ende auf jeden Fall. Eine saubere Struktur macht einem das Leben schonmal viel einfacher! Und gerade in Software-Projekten lege ich sehr viel Wert auf Ordnung, Wiederverwendbarkeit und Struktur.

Mit den Includes ist es mir dann relativ leicht gefallen, die folgenden Layouts zu erstellen. Ein Layout ist dabei die „fertige“ Seite, welche mit Daten gefüttert wird. Welches Layout genutzt werden soll, legt man im Kopf der einzelnen Seiten später fest.

Jekyll-Layouts

Dennoch müssen die alten Links ja weiter bestehen bleiben. Daher erstmal die ganzen Daten aus WordPress importieren. Weiterlesen…

Google Analytics API – Aktuelle Besucherzahlen auf dem Raspberry PI

Heute hat mich Jörg von meintechblog.de gefragt, wie er denn am besten einige Daten über die Google Analytics API abrufen könnte. Gewünscht sind

  • aktuelle Besucherzahl (live)
  • Seitenzugriffe des aktuellen und des letzten Monats

Dem nehme ich mich doch gerne an und mache direkt einmal einen Blog-Post daraus.

Grundlage für den Zugriff auf eine GA-Property per API ist ein sogenannter Service-Account. Dieser bekommt dann Zugriff auf die einzelnen Properties und kann von dort dann auch Daten über die API abrufen. Klingt erstmal einfach, oder? Weiterlesen…

WordPress: Beiträge als PDF-Download bereitstellen

Meine Freundin hat mich schon sehr oft nach einer Lösung gefragt, mit welcher man die Rezepte auf Ihrem Blog elegant-kochen.de als PDF herunterladen könnte. Das können ja schließlich alle Rezept-Seiten im Netz, nicht wahr? Heute bin ich durch puren Zufall auf den Dienst printfriendly gestoßen. Den Nutzen habe ich für mich noch nicht so richtig entdeckt. Fühlt sich ein wenig so an, als ob man dort die URL zu Seiten einfügen kann, welche nicht in der Lage sind eine print.css auszuliefern.

Hier wird also versucht, mit etwas Magie die gedruckten Informationen auf das Wesentliche zu beschränken. Das funktionierte bei einem Test mit den Links von Nadines Blog nur so mittelgut. Die Seite hat zwar erkannt, wo der Content anfängt, aber nicht genau wo er endet. Also wurden die Related-Posts mit angehängt. Sah nicht so schön aus.

Aber, wie es der Zufall will, gibt es ein WordPress-PlugIn für PrintFriendly. Damit kann man automatisch unter jeden Beitrag einen Button rendern lassen, welcher die Seite öffnet. Und dann funktioniert es lustigerweise auch mit der Erkennung des Beitragsendes perfekt. Wie der Button aussehen soll kann man frei gestalten, und sogar ein eigenes Logo hochladen.

Das beste ist aber eigentlich, dass man einstellen kann, dass sich alles in einer Lightbox öffnet! Das heißt, dass es sich für den Benutzer nichtmal so anfühlt, als würde er die Seite verlassen. Das ist natürlich top! Hier mal ein Screenshot vom Ergebnis:

PrintFriendly-Lightbox

Welche Buttons oben zur Verfügung stehen kann man frei entscheiden. Aber warum sollte man den User hier irgendwie bremsen. Egal was passiert, das Teilen kann ja nur positiv sein.

Nachteil: In der kostenfreien Variante wird unten ein Support-Button eingeblendet und wenn man ein PDF druckt, wird automatisch Werbung eingeblendet. Das ist natürlich extrem hässlich! Die Pro-Version kostet $6 im Monat oder $60 im Jahr. Das möchte ich aber nicht zahlen, bevor ich nicht weiß ob die Funktion bei den Besuchern gut ankommt. Aber natürlich möchte ich auch keine Affiliate-Werbung für andere hosten.

Also: Erstmal wird getestet, und wenn es gut ankommt, muss ich Geld ausgeben oder mich nach einer Alternative umschauen. Die Lösung gefällt mir an sich jedenfalls schon echt gut!

Ruck-Zuck eine Rest-API mit Slim auf die Beine stellen

Unser CRM in der Company ist selbst geschrieben – auf einer etwas spannenden Code-Basis, welche man als Einsteiger in das Projekt nicht unbedingt sofort versteht. Vieles wird global geregelt, Klassen sind eher dekorativ und wenig flexibel und eine Template-Engine oder Design-Patterns sucht man vergeblich. Es gibt kein Framework wie Zend oder Symfony drumherum – wirklich jede Zeile stammt aus eigener Hand.

Heute würde man das natürlich nicht mehr so machen – aber es ist, wie man so schön sagt, „historisch gewachsen“ und würde einen enormen Aufwand mit sich ziehen, den Code aufzuräumen oder gar komplett neu zu schreiben.

Ich wollte jedenfalls eine API für Alfred 2 schreiben, welche nach außen sicher ist und mir Kundendaten, SSH-Zugänge und allen nützlichen Kram rausgibt. Sodass ich am Ende das CRM gar nicht mehr öffnen muss. Hat im ersten Anlauf auch geklappt, sah nur nicht besonders schön aus. Wenigstens bei der API wollte ich ein richtiges Framework aufsetzen und das Ganze „2016-Style“ aufbauen. Mir schien es wie ein geeigneter Zeitpunkt, endlich mal etwas mit dem Slim-Framwork umzusetzen. Weiterlesen…

GPIO: Erste Schritte mit dem Raspberry Pi

Vor einiger Zeit habe ich eine Artikelserie über das Thema Hausautomatisierung geschrieben. Mittlerweile steht das ganze Zeug leider relativ ungenutzt in der Gegend rum. Das soll sich nun ändern. Und zwar möchte ich nun etwas mit GPIO rumspielen – also den Pins auf dem Raspberry. Ich habe sowohl das Model der ersten generation, als auch der zweiten Generation hier. Da die Pins vom neueren Modell vom Touch-Display belegt sind, nutze ich das ältere Modell. Aber es sollte alles auch mit der neusten Generation funktionieren.

Also habe ich mir ein Start-Kit bestellt, damit ich nicht alles einzeln zusammensuchen muss. Sicher etwas teurer, dafür hat man jede Menge Kram zum spielen dabei. Alles verpackt in einer kleinen praktischen Plastikbox.

Als erstes habe ich wiringPi installiert. Der Build dauert eine ganze Weile – also ruhig einen Kaffee holen in der Zeit. Weiterlesen…

Badge Poser: Jede Menge Badges für Packagist-Projekte

Falls Du dich schonmal gefragt hast, woher die ganzen Badges kommen, die andere so in Ihren GitHub-Repos pflegen: Badge Poser ist die Antwort. Mit diesem kleinen Tool kann man sich jede Menge Badges zu den eigenen Repos generieren. Voraussetzung: Das Ganze muss auf Packagist gelistet sein!

Badge Poser

Da ich diese Voraussetzung für so gut wie alle meine Repos erfülle, war es ein leichtes. Einfach auf Badge Poser suchen, in die Zwischenablage kopieren und fertig. Da man dann Markdown kopiert, ist eine Readme.md schnell angepasst. Bei mir sah das dann folgendermaßen aus:

BadgePoserErgebnis

Gut, TravisCI und CodeClimate hatte ich vorher schon drin. Jetzt ist es wenigstens schön bunt!

Viel Spaß beim Posen!

Mailcatcher unter OS X 10.11 (El Capitan) betreiben

Nach meinem (eigentlich problemlosen) Upgrade auf OS X 10.11 ging mein heiß geliebter Mailcatcher nicht mehr. Das Tool nutze ich, um in meiner lokalen Entwicklungsumgebung Mails abzufangen, damit diese während der Tests nicht an die Kunden verschickt werden. Außerdem kann ich mir so den Inhalt / das Design der Mail anschauen, ohne dass ich vorher irgendwelche Fake-Adressen anlegen muss. Das macht das Testen nur komplizierter.

Wie man das genau einrichtet, habe ich hier bereits beschrieben. Dort hatte ich ebenfalls geschrieben, dass man den Sendmail-Pfad (in der php.ini) wie folgt angeben muss:

Leider gilt das für El Capitan eben nicht mehr. Die Lösung ist relativ einfach, wenn man denn weiß wie es geht. Die Zeile einfach wie folgt abändern:

Fertig! Und schon werden die Testmails wieder brav aufgelistet.