Gestern fand der zweite Global WordPress Translation Day statt. Schon im April haben einige Freiwillige in Berlin zusammengefunden um an der Übersetzung von WordPress Core, Themes und Plugins zu arbeiten bzw. zu lernen, wie das genau funktioniert.
Beim ersten Translation Day gab es 39 Events auf 4 Kontinenten. Dieses Mal gab es stolze 67 lokale und 2 remote Events. In Deutschland gab es zwei Events, eines in Würzburg und eines bei unserem Meetup in Berlin:
Heute schreibe ich über ein Thema, dass ich bereits in früheren Beiträgen schon einmal beschrieben habe. Es geht um die Einbindung der Styles eines Child Themes. Im CODEX wird empfohlen, die style.css über die functions.php Datei einzubinden und nicht mit @import. Der Code hierzu sieht dabei in der Regel wie folgt aus:
add_action( 'wp_enqueue_scripts', 'my_theme_enqueue_styles' );
function my_theme_enqueue_styles() {
wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
}
Diese Einbindung kann aber bei einigen Themes zu unerwarteten Problemen führen, wenn man nicht genau weiß, wie die Einbindung von Parent und Child Theme abläuft.
An alle die jetzt denken „war der nicht erst letzte Woche in Mailand auf einem WordCamp?“, ja das war ich. Aber das ist ja kein Grund nicht gleich noch eines am Wochenende danach dran zu hängen 🙂
Mich hat es dabei zum insgesamt dritten Mal in die wunderschöne Domstadt verschlagen. Angereist bin ich am Freitagabend, aber da ich erst nach 23 Uhr in Köln angekommen bin, konnte ich leider nicht an der Warmup Party teilnehmen.
Heute schreibe ich euch von meinem mittlerweile 6. WordCamp, dass ich dieses Jahr besucht habe. Und es ich auch noch nicht das letzte. Aber hierzu dann nächste Woche mehr 🙂
Wie bin ich eigentlich dazu gekommen, ausgerechnet noch nach Mailand zu fliegen? Der Grund war Bego, der mich einfach mal angepingt hat und mir auch gleich mögliche Flugverbindungen rausgesucht hat 🙂
Heute möchte ich die kleine Artikelreihe zu den WordPress Coding Standards abschließen. Im letzten Kapitel soll es darum gehen, wie man die Überprüfung durch den PHP_CodeSniffer an die eigenen Anforderungen im Projekt anpassen kann.
Manche Funktionen oder Konstrukte von WordPress können potentielle Sicherheitslücken sein. In solchen Fällen warnen euch die „Sniffs“ für die WordPress Coding Standards vor solchen möglichen Sicherheitslücken. So muss beispielsweise jede Ausgabe geschützt werden. Nun gibt es aber Funktionen, die man nicht „schützen“ kann, also mit einer speziellen Funktion kombinieren kann. Sehen wir uns mal zwei Codezeilen an, bei der eine umgeschrieben werden kann, eine aber nicht:
Zwei Themen zu den WordPress Coding Standards habe ich noch für euch. Aber anders als letzte Woche angekündigt habe, möchte ich sie lieber auf zwei Artikel verteilen und nicht kurz in einem einzelnen behandeln. Aber damit könnt ihr euch nächste Woche auf einen weiteren Artikel der Reihe freuen 🙂
Die erste Möglichkeit, die euch vorstellen möchte ist die Behebung der gefundenen Fehler per Konsole. Schauen wir uns hierzu noch einmal einen Auszug des PHP_CodeSniffer an:
Nachdem ich euch im ersten Teil der Serie eine Einführung in die WordPress Coding Standards gegeben habe und ihr letzte Woche gelernt habt, wie man diese manuell über die Konsole testen kann, soll es heute um die Automatisierung dieser Tests in eurer IDE gehen.
In der README der WordPress Coding Standards auf Github findet ihr Kurzanleitungen für die Editoren Sublime Text sowie Atom. Meine bevorzugte IDE ist PhpStorm und ich möchte euch daher am Beispiel dieser IDE zeigen, wie eine solche Einbindung aussehen kann.
Zuerst einmal müssen wir den PHP_CodeSniffer in PhpStorm einrichten. Hierzu müsst ihr angeben, wo dieser installiert ist. Ihr findet die Einstellung unter „Settings | PHP | Code Sniffer“:
Nachdem ich euch letzte Woche erklärt habe, was Coding Standards sind und weshalb man sie einsetzen sollte, soll es heute um das manuelle Testen des eigenen Quellcodes auf die Einhaltung dieser Standards gehen. Denn es will ja wohl niemand den Code Zeilenweise selbst auf Fehler untersuchen 🙂
Glücklicherweise gibt es ein Tool, das genau diese Aufgabe zuverlässig und schnell erledigt. Dieses Tool ist der sogenannte PHP_CodeSniffer (PHPCS). Der CodeSniffer ist selbst in PHP geschrieben und kann entweder per PEAR oder per Composer installiert werden.
Auf dem WordCamp in Nürnberg habe ich auf dem Contributor Day einigen neuen Mitwirkenden die Einrichtung der WordPress Coding Standards in eine IDE erklärt. Hierbei kam dann die Bitte auf, doch mal mehr über die WordPress Coding Standards oder kurz WPCS zu schreiben. Dieser Bitte möchte ich gerne nachkommen. Doch bevor wir tiefgreifend in das Thema einsteigen, soll es heute erst einmal um die Grundlagen gehen.
Einige von euch können vermutlich mit dem Begriff nichts anfangen. Bei Coding Standard oder auch Coding Conventions geht es um die Festlegung eines einheitlichen Programmierstils. Einige Programmiersprachen setzen einen strikten Programmierstil voraus. So ist es in der Programmiersprache Python zum Beispiel unabdingbar, eine korrekte Einrückung mit Tabs oder Spaces zu verwenden, da ansonsten der Code nicht wie gewünscht ausgeführt wird.
In PHP gibt es diese Voraussetzung nicht. Man könnte also auch alle Codezeilen ohne Einrückung schreiben oder sogar alles in eine Zeile. Dies sollte man aber in jedem Fall vermeiden. Denn solcher Code ist nur sehr schwer für einen Menschen lesbar und eine spätere Fehlersuche wird dadurch erheblich erschwert.
Vor zwei Wochen hatte ich euch ja erzählt, die man bei ElasticPress die Volltextsuche anpassen kann. Hierbei habe ich einen Ausdruck aus der Suche entfernt, der für viele ungenaue Suchergebnisse zuständig war und somit zu einem schlechten Gesamtergebnis geführt hat.
Heute möchte ich ein wenig an diesen Artikel anknüpfen und die Suchanfrage noch ein wenig verbessern. Denn durch die vorherige Anpassung ist eine wichtige Funktion von Elasticsearch verloren gegangen: Die Unschärfesuche.
Sehen wir zunächst noch einmal die Suchanfrage an, die ElasticPress ohne Anpassungen an den Elasticsearch Server schickt: