Ich baue gerade an einer App für eine Einkaufsliste. Mehr so zum Spaß und um Angular.JS zu lernen – dachte ich anfangs.
Kategorie: Code
Oft findet man beim Thema WordPress Child Themes den Hinweis, dass man die Parent-Theme-CSS-Datei im Childtheme dann mittels @import übernehmen soll, wie z.b. so:
/* Use @import, to borrow the style sheet from the Waipoua parent theme */
@import url('../waipoua/style.css'); Das ist zwar richtig und funktioniert, kann aber durchaus nachteilige Effekte auf das CSS-Rendering und Ladeperformance haben. Schließlich wird erst die Child-Theme-Datei geladen, die stößt den Parent-Download und dann muss das ganze lustig berechnet werden.
Einfacher ist es, wenn man die Parent-Style-Datei entweder komplett kopiert oder direkt im HTML einbindet.
Methode 1: Kopieren des Parent-Styles
Vorteil: Nur eine Style-Datei, nur ein Request, kein Style-Merging: Optimale Performance
Nachteil: Beim Theme-Update müssen Differenzen ggf. mühsam per Hand übertragen werden.
Methode 2: Einbinden ins HTML statt per @import
Vorteil: Update-Kompatibel, nur geänderte Styles müssen in die Datei, Performance besser als bei @import
Nachteil: Perfomance ist schlechter als eine Kopie des Parents
Mein Senf: Methode 2 gewinnt
Aus meiner Sicht ist die Methode 2 besser geeignet, da hier der Wartungsaufwand bei Theme-Updates gegen 0 tendiert, genau wie bei @import. Aber wie funktioniert das?
Zuerst löscht man die @import-Zeile aus der style.css. Dann fügt man in die functions.php folgendes ein:
add_action('wp_enqueue_scripts', 'add_parent_css');
function add_parent_css() {
wp_enqueue_style('waipoua_main', get_template_directory_uri() . '/style.css', false, '');
wp_enqueue_style('waipoua_child', get_stylesheet_uri(), 'waipoua_main' );
} Hier passiert folgendes: Mit get_template_directory_uri() bekommt man das Verzeichnis des Parent-Themes, während man mit get_stylesheet_uri() die Stylesheet-URL des aktiven (in diesem Fall des Child-) Themes bekommt.
Die Namen für die Stylesheets (“waipoua_main” und “waipoua_child”) sind in diesem Fall der Umgebung bei Develovers.de geschuldet, die könnt ihr nennen wie ihr wollt.
Schon meckern Perfomance-Tools evtl. nur noch die Einbindung mehrerer Stylesheets an, aber nicht mehr die Verwendung von @import.
Hintergrundinformation: Ich arbeite aktuell in der Firma an einem größeren Projekt, welches unter anderem die Entwicklung einer komplett JS-basierten Oberfläche zur Konfiguration und Abfrage von Maschinen und der Erstellung eines Angebots für Kunden enthält. Das Projekt läuft seit 8 (“initial commit”: 22. Juli) Monaten und es arbeiten 2, stellenweise 3 Entwickler daran.
Ich habe mir mal den Spaß gemacht, nachzuschauen, wie viel Code da von unserer Firma drinsteckt:
Die Gesamtsumme aller “per Hand” bearbeiteten Daten beträgt knapp 600KB. Der Rest des Projekts setzt sich zusammen aus den benutzten Bibliotheken: cookie.js, Ember.js, Font Awesome, Handlebars, Holder.js, html5shiv, jQuery, jQuery Tools, jQuery UI, Normalize.css, spin.js, Underscore.js, Grunt
Insgesamt werden beim ersten Laden des Projekts im Browser 580 KB abgerufen, dazu kommen noch ca. 62,7 KB aus (bisher unkomprimierten) Dateien, die erst später Nachgeladen werden (können). Das schließt allerdings keine Abfrage von Daten, sondern nur den Payload des Projekts ein. HTML, JS, CSS/LESS, Bilder.
Ich schwanke meinungstechnisch noch zwischen: “Cool wie effizient” und “oh, das ist aber wenig” (Das Quantität keine Qualitätsaussage ist, ist mir dabei durchaus bewusst). Zum Glück werden wir nicht nach KB bezahlt. (Ausnahmen bestätigen die Regel aber meistens ist das dann eher eine Bezahlung pro gespartem KB)
Wie ist das bei euch? Wie viele Libraries haben eure großen Projekte? Ist das Verhältnis von eigenem vs. fremdem Code bei euch auch so ähnlich oder entwickelt ihr alles “from Scratch”? Sieht das bei “Backend”-Projekten ähnlich aus?
Bild: CC0 von Martin Wessely via Unsplash.com
Kategorien
Data, Data, Data!
success: function( data ){
$("<img />",{
"src": "data:" + data.data.mimetype + ";base64," + data.data.data
}).appendTo( $( 'li#i' + data.data.id ))Als Webentwickler kennt man das vielleicht: Für das x-te Kundenprojekt legt man eine neuen Ordner in seinem WWW-Root an und fängt an, entweder “localhost/kundenprojekt.de” zu nutzen oder lustige Spielereien mit VirtualHost-Konfigurationen und der Hosts-Datei zu veranstalten (“127.0.0.1 kundenprojekt.de”).
Das muss nicht mehr sein! Zumindest unter Linux, BSD und vermutlich Mac OSX.
Der Apache-Part funktioniert ohne Probleme auch unter Windows, das Problem ist hier das generische Domain-Auflösen. Wenn jemand dafür eine Lösung hat, her damit!
Was brauchen wir?
- Linux, BSD, Mac OSX, Windows
- Als Entwicklungswebserver benutzen wir den Apachen
- Unter Linux/Unix/BSD/OSX wird Dnsmasq installiert
Unter Ubuntu oder Debian mit “apt-get install dnsmasq” bzw. “aptitude install dnsmasq“ - Unter Windows gibt es das Tool “Acrylic DNS Proxy“
- Dnsmasq / Acrylic ist als primärer DNS-Server eingetragen.
Was macht dieses Dnsmasq eigentlich?
Dnsmasq is a lightweight, easy to configure DNS forwarder and DHCP server.
So weit, so gut. Dnsmasq kann einiges mehr und besonders interessieren wir uns für die Funktion, die in der Manpage mit “–address” beschrieben ist. Sehr unscheinbar, aber das ElDorado für uns. Die Option besagt, dass jede Domain, die in das Muster passt, mit der definierten IP aufgelöst wird.
Dafür legen wir unter Debian/Ubuntu die Datei /etc/dnsmasq.d/localdev.conf an. In diese kommt folgender Inhalt:
address=/localdev/127.0.0.1
Unter Windows bearbeitet man die Datei “AcrylicHosts” und fügt dort die Zeile “127.0.0.1 *.localdev” ein.
Man könnte auch eine beliebige andere TLD nehmen (“erfinden”), z.b. “.dev” oder “.locales-netz-von-chris”.
Damit werden alle Domains, die auf “localdev” enden, auf die lokale IP aufgelöst.
Okay, jetzt kann ich alles mit einer bestimmten Domain auf meinen Server umleiten. Und nun?
Dnsmasq löst nun Domains wie “kunde.localdev” und “kunde2.localdev”, alle auf den lokalen Webserver um.
Normalerweise hätte man dann ja immer noch das Problem, dass man mit den VirtualHost-Konfigs basteln müsste. Hierfür hat Uberspace eine super Lösung präsentiert:
Die Apache-Config wird in der VirtualHost-Direktive erweitert. XAMPP/LAMPP/MAMPP-User müssen diese erst erzeugen.
RewriteEngine On
# If there is a host-specific pseudo-DocumentRoot, use it instead of the default one
RewriteCond %{REQUEST_URI} !^/f?cgi-bin/
RewriteCond /var/www/%{HTTP_HOST} -d
RewriteRule (.*) /var/www/%{HTTP_HOST}/$1 Dieser nette Trick erlaubt folgendes: Wenn ein Verzeichnis existiert, welches den gleichen Namen hat, wie die URL, die aufgerufen wird, wird es als “DocumentRoot” verwendet. Bei der Verwendung von .htaccess-Rewrites innerhalb des Verzeichnisses muss allerdings ein “RewriteBase /” stehen.
Was bedeutet das für die Praxis?
Ich muss in Zukunft nur noch ein Verzeichnis “kunde123.localdev” anlegen und schon kann ich darin loslegen. Ich habe eine Top-Level-Domain und muss am Ende beim Umzug auf die Live-Seite nicht mehr soviel ändern. Im Falle von WordPress muss ich nur beispielsweise noch in der Datenbank das “.localdev” durch “.de” ersetzen und schon kann das Projekt live gehen.
Außerdem ist mein /var/www/ -Verzeichnis dann auch zwangsläufig gut organisiert.
Im Übrigen: eine spezifische Auflösung in der resolv.conf oder der Hosts-Datei hat Vorrang vor der Dnsmasq-Auflösung.
[green_box] Update
Ein Tool für Windows wurde nachgetragen
[/green_box]
[grey_box]
Dieser Eintrag entstand durch eine Verkettung von Inspirationen: Ich habe Alex zum testen von Uberspace inspiriert, deren VirtualHost-Konfiguration hat Alex zum testen von Dnsmasq (Wikipedia) auf seinem Notebook inspiriert und seine Demonstation davon hat mich zu diesem Eintrag inspiriert. Soviel zum Thema “geistiges Eigentum”.
[/grey_box]