MAMP: WordPress-Themes und Plugins über Symlinks zentral verwalten

Vor ein paar Monaten hatte ich eine Weile mit Local von Flywheel als lokale Entwicklungsumgebung gearbeitet. Inzwischen bin ich wieder zurück zu MAMP gewechselt. Mehr dazu in diesem Artikel.

Eine Eigenschaft von Local, die mir besonders gut gefiel, war der Volumes Manager. Damit konnte man Themes und Plugins für alle Hosts zentral verwalten. Alle lokalen Sites und alle WordPress-Installationen greifen dann auf dieselben Themes und Plugins zu. Das ist zum Entwickeln sehr praktisch, weil es keine Doubletten gibt und keine Verwirrung mit Versionen.

Diese Funktion kann man auch in MAMP nachbilden. Man muss dafür ins Terminal wechseln, aber was man dort tun muss, ist denkbar einfach.

  1. Plugins und Themes an zentraler Stelle ablegen.
    In meinem Fall ist das der Ordner sites
  2. Im Terminal zum Verzeichnis navigieren, in der die lokalen Sites liegen, die mit MAMP verwaltet werden.
    Bei mir ist es das Verzeichnis sites und ich navigiere dort hin mit cd sites
  3. Einen Symlink für das Theme-Verzeichnis setzen
    ln -s ~/Sites/themes ~/Sites/name-des-projekts/wp-content
  4. Einen Symlink für das Plugin-Verzeichnis setzen
    ln -s ~/Sites/plugins ~/Sites/name-des-projekts/wp-content

Im wp-content-Verzeichnis des Projekts erscheint dann jeweils ein Alias des zentralen Theme- bzw. Plugin-Verzeichnisses.

Damit es keine Fehlermeldung gibt, muss man die Verzeichnisse themes und plugins im wp-content-Verzeichnis vor der Aktion umbenennen. Es reicht ein kleiner underscore vor dem Namen, z.B. so: _themes.
Weiterlesen MAMP: WordPress-Themes und Plugins über Symlinks zentral verwalten

Local von Flywheel und MAMP 4.x im Schnell-Vergleich

Diesen Artikel habe in ursprünglich im Oktober 2016 geschrieben. Inzwischen ist viel passiert, so dass ich die Informationen noch einmal aktualisiert habe.

Local von Flywheel hat in der Zwischenzeit mehrere Updates bekommen. Leider haben die Entwickler beim letzten Update den Volumes Manager vergessen. („Sorry for the inconvenience! We underestimated the amount of people using this add-on.“ Tja, so verspielt man Vertrauen.)

Mit dem Volumes Manager konnte man Themes und Plugins in je einem Verzeichnis für alle Hosts zentral verwalten. Alle Installationen greifen dann auf dieselben Themes und Plugins zu, es gibt keine Doubletten und unklaren Versionszustände.
Flywheel hat zwar auf Github einen Fix für das Mapping AddOn nachgeliefert, aber der läuft bei mir nicht zuverlässig. Nach vielen Stunden Fehlersuche musste ich einsehen, dass das AddOn einfach nicht sauber arbeitet.

Ich habe ich mich entschieden zurück zu MAMP zu gehen. Local war superschnell und komfortabel. Aber ein Tool, das mich mitten in der Arbeit für Kundenprojekte für viele Stunden ausbremst und dann keine brauchbare Lösungen hat, das kann ich nicht gebrauchen. Dafür sind diese Setups zu wichtig.
Kommt dazu, dass Flywheel’s Hauptgeschäft das Hosting ist und Local ist ein Baustein in ihrem Business. Es ist z.B. nicht möglich, eine externe Seite zu klonen und in Local rüberzukopieren. Ich hab’s jedenfalls nicht geschafft. Für Flywheel-Kunden gehen solche Sachen selbstverständlich ganz einfach.

Das Mapping von Verzeichnissen z.B. für Themes und Plugins, kriegt man bei MAMP Pro übrigens auch hin (Über Symlinks, die man übers Terminar erzeugt hier ein Artikel dazu)

UPDATE 3. Dezember 2016
Pressmatic wurde von Flywheel aufgekauft und heisst jetzt Local by Flywheel. Die Software ist ab sofort kostenlos und Ihr könnt sie hier herunterladen.

Was ist Local?
Local tut das Gleiche wie MAMP, es ist eine Serverumgebung für lokale Rechner. Man kann damit WordPress lokal auf seinem Rechner installieren.
Weiterlesen Local von Flywheel und MAMP 4.x im Schnell-Vergleich

WordPress & Vagrant für visuelle Menschen

Letzte Woche habe ich mir angeschaut, wie sich MAMP und Pressmatic im direkten Vergleich so anfühlen. Um das Bild etwas zu erweitern, habe ich mir noch Vagrant angeguckt. 

Beim Zusammenbauen eines Vagrant-WordPress-Workflows haben mir diese beiden Artikel sehr geholfen:

WordPress Development mit VVV (Tuts+)
Setting up a WordPress VVV Workflow (WP Beaches)

In den Artikeln werden alle Schritte zur Installation genau beschrieben.

Optische Oberflächen für VVV und Vagrant

Für mich ist die Arbeit mit dem Terminal deshalb so schwierig, weil ich vor einer „Black Box“ sitze. Erst wenn ich einen passenden Befehl eintippe, spuckt mir das Terminal eine Rückmeldung aus. Weiss ich den Zauberspruch Befehl nicht, sitze ich nur dumm davor und komme nicht weiter.

Spannend fand ich deshalb diese beiden Module:

  1. VVV Dashboard
  2. Vagrant Manager

VVV Dashboard ist eine optische Oberfläche für eine VVV-Installation. Dort kann ich sehen, was sich in meiner Serverumgebung tut und ich kann direkt vom Dashboard aus Aktionen ausführen. Das VVV Dashboard hat mir den Zugang zur Vagrant-Welt sehr erleichtert.
Weiterlesen WordPress & Vagrant für visuelle Menschen

Performance-Experiment mit gzip und Browser-Caching

Auf dem WordCamp Nürnberg hat Jan Thiel einen tollen Vortrag zum Theme Performance gehalten: WordPress Performance Mythbuster. Den Vortrag könnt Ihr Euch hier auf wordpress.tv anschauen.

Performance ist ein wichtiges Thema, nicht nur seit Google ein Auge drauf hat. Je langsamer eine Seite lädt, desto schlechter ist die User Experience. Jede Millisekunde zählt, bei mobilen Geräten umso mehr.

Spannend fand ich, wie Jan herausgearbeitet hat, wo denn der Flaschenhals bei den Ladezeiten tatsächlich liegt. Vorsicht Spoiler: Weder die Server-CPU noch der PHP-Code vom WordPress-Core sind hier die Bremse, der PHP Code von Themes und Plugins ist es, der aufs Tempo drückt.

Was logischerweise bedeutet, dass noch’n Plugin Eure Seite nicht unbedingt schneller macht. Auch wenn Performance-Optimierung draufsteht. Ausnahmen bestätigen die Regel.

Das Experiment

Ich hab mir mal zwei Sachen vorgenommen, die Jan in seinem Vortrag erwähnt hat, mit denen man der Netzialisten-Seite Beine machen kann. Ich hab dazu das Google Page Speed Tool genutzt, obwohl ich ein etwas gespaltenes Verhältnis dazu habe: Die Angaben dort muss man mit Vorsicht geniessen und immer die Verhältnismäßigkeit im Auge behalten. Beispiel: Man kann schon „Punktabzug“ kriegen, wenn ein einziges 32KB-Bild nicht optimiert ist.

Die beiden Techniken, die ich mir angeschaut habe, sind:

  1. gzip -Komprimierung
  2. Browser-Caching

Weiterlesen Performance-Experiment mit gzip und Browser-Caching

Google Fonts über den eigenen Server einbinden

Es gibt verschiedene Methoden, um Google Fonts in eine Webseite einzubinden. Die klassische Methode ist, die Schriften über einen Link in der header.php oder – besser – über die functions.php ins Theme einzubinden. Ellen Bauer hat einen ausführlichen Artikel dazu geschrieben: Google Fonts in WordPress Themes

Bei dieser Methode liegen die Schriften auf den Google-Servern und werden über einen Link auf meine Webseite geholt. Wird meine Seite geladen, schickt sie eine Anfrage an den Google Server und der liefert dann die Schriften aus. Davon merkt man in der Regel nicht viel. Aber es bleibt die Tatsache, dass eine Abfrage passiert und das dauert ein paar Millisekunden.

Je nach der Qualität der Datenverbindung kann es auch passieren, dass die Schriften nicht schnell genug ausgeliefert werden. Dann erscheinen alle Texte plötzlich in Arial oder Times.
Auch Firewalls können ein Problem darstellen – in manchen Firmen gelten so strenge Regeln, dass die Mitarbeiter keine Google Fonts zu sehen kriegen.

Google Fonts herunterladen und Webfont erzeugen

Aus diesen Gründen bin ich in letzter Zeit dazu übergegangen, Google Webfonts nicht mehr per Link einzubinden, sondern direkt auf den Sever zu laden, auf dem auch das WordPress-Theme liegt. Ich gehe davon aus, dass das rechtlich kein Problem ist, denn die Google Webfonts haben eine SIL Open Font License, die das Herunterladen erlaubt.
Weiterlesen Google Fonts über den eigenen Server einbinden