Kategorien
Code Webentwicklung

Performance steigern für WordPress Child-Themes: Alternative zu @import

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.

Kategorien
Releases Webentwicklung Werkzeuge

Webeditor auf Basis von Webtechnologien: Brackets [Sprint 31]

Brackets Startscreen
Brackets Sprint 31

Adobe entwickelt Brackets, einen Webeditor, mit Webtechniken: Node.jsHTML und Javascript. Brackets ist Open Source und bietet aus meiner einen vielversprechenden Ansatz. Mit LESS und meinem Workflow kann das Teil allerdings auf den ersten Blick nicht das anfangen, was ich persönlich brauche, aber ich werde den Editor mal im Auge behalten…

wiederentdeckt durch Jens Grochtdreis

Kategorien
Linklove

Centering in the Unknown

Centering in the Unknown

Kategorien
Webentwicklung

3 Ressourcen für Templates unter Creative Commons Lizenz

Wenn die Zeit oder das Budget bei einem Kunden knapp ist, greife ich gerne zu Lösungen “von der Stange”. Das muss auch nicht zwingend etwas schlechtes sein. Viele Templates sind mit wenigen CSS-Änderungen durchaus Wandlungsfähig. Und wenn man nach Stunden abrechnet und die nicht komplett exklusive Lösung dem Kunden auch passt, ist das nicht mal ein oder anrüchig: Es verbessert das Preis-Leistungsverhältnis stellenweise enorm.

Zusätzlich zu einem Theme-Fundus für WordPress kann ich folgende Seiten für die Templatesuche empfehlen:

Die Templates sind, was den Funktionsumfang angeht sehr unterschiedlich. Die HTML5-Seiten haben sich allerdings fertige Responsive-Templates auf die Fahne geschrieben. Während diese die Templates zumindest auf den Seiten nur als CC-Lizenz anbieten, bietet Free CSS Templates auch die Möglichkeit, die Quellenangabe ab einer Spende von 5 Dollar zu entfernen. Die drei Seiten würde ich übrigens als prinzipiell seriös einstufen.

Weitere Links:

Kategorien
Code Webentwicklung

Wie sollte man Prototypen bauen?

Konzept: Von der Skizze zum Prototypen

Wir gehen in diesem Artikel davon aus, dass für ein neues Projekt Skizzen bestehen, die zeigen, wie die fertige (Web-)Anwendung etwa aussehen und sich verhalten soll. Basierend auf diesen Skizzen möchte der Kunde sehen, wie sich das “anfühlt”, wenn man es im Browser bedient. Wir gehen im folgenden davon aus, dass der Prototyp keinerlei Datenverbindungen oder serverseitige Entwicklung benötigt, also ein reiner “Klick-Dummy” ist.

Grundüberlegungen

Bevor die erste Code-Zeile entsteht sollte man sich schon über einige Dinge Gedanken gemacht haben:

  1. Code-Organisation / Ordnerstrukturen
  2. Zu verwendende Libraries und deren Lizenzen

Was davon in der Entwicklung davon übrig bleibt, ist egal, aber ein Plan sollte vorhanden sein. Mit am wichtigsten ist, dass alle “Screens” auf Atomisierbarkeit gecheckt werden:

  • Habe ich oft gleiche Strukturen?
  • Kann ich die kombinieren?

Dabei sind z.B. Dinge wie immer wiederkehrende Dinge wie Tabellen mit gleichem Aufbau. Hier lohnt sich unter Umständen recht schnell der Einsatz einer Templating-Engine wie Handlebarsjs oder Mustache.

Weitere Dinge: Welche Präprozessoren / DRY-Tools benutze ich, z.B. LESS, SASS und/oder Ajax (um Teile der Oberfläche nachzuladen).

Umsetzung: Was sollte bei der Entwicklung des Prototypen beachtet werden?

[red_box]Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle![/red_box]

Man kann es gar nicht oft genug sagen. Jeder nachvollziehbare Schritt ist ein sinnvoller Schritt in die richtige Richtung. Insbesondere, wenn mehrere Personen am gleichen Code arbeiten, ist ein SCM-Tool richtig wichtig.

Der Code sollte dabei im Code selbst gut dokumentiert sein, zusätzliche Dokumentation in einem Wiki oder ähnlichem wäre optimal. Nutzt eine Toolchain wie Grunt.js um Produktionsreifen Code zu erzeugen:

  1. Minifying
  2. Compressing
  3. Entkommentarisierung 😉

Request-Lagging

Wenn im Klick-Dummy Requests simuliert werden, die im Prototyp nicht oder lokal stattfinden, verzögert Sie im Prototypen mit JavaScript-

Diskussion: quick’n’dirty vs. Produktionsreife

Wieviel produktionsreifen Code soll eurer Meinung ein Prototyp enthalten? Werdet euch mit den Kunden einig darüber, was ihr unter einem Prototyp versteht und was der Übergang vom Prototypen zur “live”-Version bedeutet. Je nachdem sollten natürlich auch unterschiedliche Aufwände in den Prototypen gesteckt werden.