WordPress Coding Standards: Die Grundlagen

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.

Was sind Coding Standards

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.

Zu PHP existieren diverse Standards, die sich etabliert haben. Einen einheitlichen Standard gibt es also nicht. Als den “offiziellsten” könnte man die Standards der PHP Framework Interop Group bezeichnen. Diese hat die beiden Standards PSR-1 (Basic Coding Standards) sowie PSR-2 (Coding Style Guide) definiert.

Das Ziel von Coding Standards im Allgemeinen ist es, dass sich alle Entwickler auf einen gemeinsamen Programmierstil einigen. Das erleichtert die Einarbeitung in den Code eines anderen Entwicklers. Es erleichtert auch die Fehlersuche und hierdurch den Aufwand bei der Wartung von Quellcode.

Die WordPress Coding Standards

Auch die WordPress Community hat sich auf einheitliche Coding Standards geeinigt. Diese umfassen Regeln für PHP, HTML, CSS und JavaScript. Ich möchte hier jetzt nicht im Detail auf alle Regeln eingehen, die könnt ihr selbst nachlesen, aber die wichtigsten Punkte aufzählen. Hier unterscheiden sie sich zum Teil sehr stark von den PSR Standards.

  • Tabs statt (4) Spaces zum Einrücken verwenden
  • Öffnende Klammern bei Klassen und Funktionen auf der gleichen Linie
  • Alle Bedingungen in Klammern
  • Leerzeichen ohne Ende 🙂 Fast überall, mit ganz wenigen Ausnahmen (beispielsweise bei statischen Keys von Arrays)
  • Verwendung der Yoda-Condition

Gerade die Verwendung von sehr vielen Leerzeichen ist für Entwickler, die neu in die Programmierung von WordPress Plugins und Themes einsteigen eher gewöhnungsbedürftig. Auch die Yoda-Condition kennen viele Programmierer noch nicht. Schaut man in den WordPress Core, dann findet man auch sehr viele Dateien, bei denen die Coding Standards noch nicht umgesetzt wurden. Das liegt einfach auch daran, dass die Standards erste später eingeführt wurden und es nicht gewollt ist, den gesamten Core umzuschreiben. Es passiert also schrittweise, wenn ohnehin eine Codezeile geändert werden muss.

Beispiel für die WordPress Coding Standards

Hier mal ein kleines Beispiel eine Funktion, die einige der WordPress Codings Standards visualisiert:

function debug_cf7_add_error_to_ajax_response( $items, $result ) {
	if ( 'mail_failed' === $result['status'] ) {
		global $phpmailer;
		$items['errorInfo'] = $phpmailer->ErrorInfo;
	}
	return $items;
}
add_action( 'wpcf7_ajax_json_echo', 'debug_cf7_add_error_to_ajax_response', 10, 2 );

In diesem Beispiel erkennt man die vielen Leerzeichen, inkl. der Ausnahme bei Arrays, sowie eine Yoda-Condition.

Fazit

Ich hoffe, ich konnte euch in diesem ersten Artikel erst einmal erklären, was Coding Standards sind und wieso man sie einsetzen sollte. Nächste Woche werde ich euch ein Tool vorstellen, mit dem ihr euren Code lokal auf die Einhaltung der Coding Standards hin überprüfen könnt. In einem weiteren Artikel beschreibe ich dann die Einbindung des Tools in eine beliebte PHP IDE. Ihr dürft euch also noch auf mindestens zwei weitere Artikel zu dem Thema freuen 🙂

Elasticsearch Unschärfesuche und Gewichtung nutzen

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.

Standard Suchanfrage in ElasticPress

Sehen wir zunächst noch einmal die Suchanfrage an, die ElasticPress ohne Anpassungen an den Elasticsearch Server schickt:

"query": {
	"bool": {
		"should": [
			{
				"multi_match": {
					"query": "wordcamp frankfurt folien",
					"type": "phrase",
					"fields": [
						"post_title",
						"post_excerpt",
						"post_content"
					],
					"boost": 4,
					"fuzziness": 0
				}
			},
			{
				"multi_match": {
					"query": "wordcamp frankfurt folien",
					"fields": [
						"post_title",
						"post_excerpt",
						"post_content"
					],
					"boost": 2,
					"fuzziness": 0,
					"operator": "and"
				}
			},
			{
				"multi_match": {
					"fields": [
						"post_title",
						"post_excerpt",
						"post_content"
					],
					"query": "wordcamp frankfurt folien",
					"fuzziness": 1
				}
			}
		]
	}
},

Es werden hier drei boolesche Suchen ausgeführt und mit “should” verknüpft. Die erste “multi_match” Abfrage ist vom Typ “phrase“. Diese sucht auf allen drei Feldern (post_title, post_excerpt und post_content) nach dem Suchbegriff. Der Parameter “fuzziness” ist hierbei allerdings auf 0 gesetzt, was eben bedeutet, dass kein Tippfehler vorkommen darf, da ansonsten die Suche kein Ergebnis liefert. Zuletzt wird die erste Suche noch um den Faktor 4 höher gewertet.

Die zweite Suche hat keinen Typ angegeben. Daher wird hier “best_fields” verwendet. Es wird also das Feld genutzt, in dem alle Suchbegriffe vorkommen. Dies wird durch den “and” Operator gesteuert. Auch hier werden Tippfehler nicht verziehen und die Suche wird um den Faktor 2 höher gewertet.

Die letzte Suche ist dann schließlich eine fehlerverzeihende Suche. Allerdings ist hier weder ein Typ, noch ein Operator angegeben. Es wird daher in allen Feldern gesucht und sobald eines der Suchwörter gefunden wird, liefert die Suche diesen Datensatz zurück. Zusätzlich darf es hier auch einen Tippfehler von einem Zeichen haben. Es werden hier also sehr viele Datensätze gefunden, die wir vermutlich nicht haben wollen. Zwar kommen diese ganz zum Schluss, da sie keinen “boost” erhalten.

Suche verbessern

Meine erste Lösung war es ja noch gewesen, einfach die letzte Suche zu entfernen. Somit habe ich alle ungenauen Suchen Treffer entfernt. Aber ich habe eben auch die Unschärfesuche dadurch deaktiviert. Wie könnte also eine bessere Suche für einen Blog aussehen?

Wie würde man selbst denn nach etwas in einem Blog suchen? Also welche Suchanfrage würde man verwenden und welche Wörter an welche Stelle setzen? Vermutlich würde man die wichtigsten Wörter vorne angeben und unwichtigere weiter hinten.

Welche Beiträge würde man dann am liebsten finden? Solche, die die Suchanfrage um Inhalt enthalten, oder eher solche, die sie im Titel tragen? Vermutlich eher letztere. Daher habe ich mir ein wenig Gedanken gemacht, wie eine bessere Suche aussehen könnte und bin zu folgendem Ergebnis gekommen:

function elasticpress_fine_tuning_ep_formatted_args( $formatted_args, $args ) {

	$search_fields = array(
		'post_title^4',
		'post_excerpt^2',
		'post_content',
	);

	$query = array(
		'bool' => array(
			'should' => array(
				array(
					'multi_match' => array(
						'query'                => $args['s'],
						'type'                 => 'phrase',
						'fields'               => $search_fields,
						'fuzziness'            => 'AUTO',
						'minimum_should_match' => '2<-25%',
					),
				),
				array(
					'multi_match' => array(
						'query'     => $args['s'],
						'fields'    => $search_fields,
						'operator'  => 'and',
						'fuzziness' => 'AUTO',
					),
				),
			),
		),
	);

	$formatted_args['query'] = $query;

	return $formatted_args;
}

add_filter( 'ep_formatted_args', 'elasticpress_fine_tuning_ep_formatted_args', 10, 2 );

Ich überschreibe in diesem Fall den gesamten “query” Teil der Anfrage an Elasticsearch. Da für mich das Feld Titel am wichtigsten ist, “booste” ich dieses Feld um das Vierfache. Hierzu verwende ich “per-field boosting“. Das Feld mit dem Auszug werte ich doppelt, da hier in der Regel auch eher relevantere Wörter vorkommen, als im Rest des Textes.

Die “fuzziness” stelle ich auf “AUTO” ein, womit dynamisch, je nach Wortlänge, ein Wert von 0 – 2 angesetzt wird. Als letzte Maßnahme setze ich noch den Wert von “minimum_should_match“, der dafür sorgt, dass bis zu einer Länge von 2 Suchbegriffen beide gefunden werden müssen und bei mehr Begriffen alle bis auf 25% (also 75% oder einer mehr).

Fazit

Wie ihr vermutlich gemerkt habt, gibt es sehr viele Möglichkeiten, eine Suche zu optimieren. Da Elasticsearch sehr viel komplexer als MySQL ist und da es sehr viele unterschiedliche Daten gibt, in denen gesucht werden kann, ist eine optimale Konfiguration nicht immer einfach zu finden. ElasticPress gibt hier vermutlich eine sehr grobe Standardsuche vor, die aber eben für meinen Blog nicht wirklich zu befriedigenden Ergebnissen geführt hat.

Ich wünsche euch auf jeden Fall viel Spaß beim Experimentieren mit Elasticsearch. Vermutlich werde ich noch einen weiteren Artikel hierzu schreiben, da das Projekt, in dem ich Elasticsearch einsetze, noch nicht vorbei ist 🙂

P.S. Ich habe euch den Code als Plugin mal wieder https://gist.github.com/2ndkauboy/7bfa7c544b0731cc000e39e91174267c, damit ihr es gleich mal testen könnt. Falls ihr eine bessere Konfiguration gefunden habt, dann hinterlasst doch gerne einen Kommentar oder erstellt einen Fork 🙂

Folien zu meiner Session “Child Plugins” auf dem WordCamp Frankfurt 2016

Vor wenigen Stunden habe ich auf dem WordCamp Frankfurt 2016 einen Vortrag zum Thema Child Plugins gehalten, in dem ich meine kleine Artikelreihe aus dem Blog noch einmal zusammengefasst habe. Die Folien könnt ihr euch hier in Ruhe noch einmal ansehen. Solltet ihr Fragen habe, hinterlasst einfach wie immer einen Kommentar 🙂

Child Plugins - WordCamp Frankfurt 2016

Wer die Themenreihe noch einmal inkl. ausführlicherer Erklärungen lesen möchte, findet hier die Links zu den Beiträge:

Auch hierzu darf man natürlich auch weiterhin Fragen stellen und Anmerkungen machen 😉

Rückblick auf das WordCamp Frankfurt 2016

An diesem Wochenende fand das erste WordCamp in Frankfurt am Main statt. Es war auch das zweite in Deutschland für dieses Jahr und das insgesamt sechste, das ich in diesem Jahr besuchen werde. An zweit Tagen gab es wieder viele spannende Sessions von deutschen und internationalen Speakern.

Freitag: Contributor Day

Anders als sonst in Deutschland gewohnt, fand der Contributor Day am Freitag und somit vor dem WordCamp statt. Ich bin morgens früh um halb sechs Uhr morgens aus Berlin direkt angereist. Nach anfänglichen Schwierigkeiten mit dem WLAN und einem dadurch notwendigen Wechsel des Gebäudes, war es noch ein recht produktiver Tag. Also nicht wirklich für mich, aber für die meisten um mich herum. Denn ich wurde mit hunderten Fragen zu VVV (eine Vagrant Umgebung für WordPress), PhpStorm, PHP Code Sniffer, WordPress Coding Standards und Co. gelöchert. Auch wenn ich also nicht an dem einen Ticket weitergekommen bin, war der Tag doch sehr gut.

Das Thema WordPress Coding Standards wollte ich ja ohnehin schon länger mal in meinem Blog verarbeiten. Aber auch die Einrichtung von VVV werde ich, vermutlich im Rahmen eines Screencasts, mal in Angriff nehmen.

Am Abend fand eine kleine Warmup Party statt, an der ich aber nicht teilgenommen habe. Stattdessen habe ich meine Brüder in meiner Heimatstadt Mannheim besucht. Wenn man schon mal so nah ist, muss das einfach sein 🙂

Weiterlesen →

ElasticPress Volltextsuche anpassen

Vor vier Wochen hatte ich euch ja berichtet, wie man Elasticsearch in WordPress verwenden kann und euch auch angekündigt, dass ich hierzu ein paar Artikel schreiben werde. Heute möchte ich damit beginnen und einen ersten kleinen Tipp geben, wie man die Volltextsuche optimieren kann.

Die Volltextsuche von Elasticsearch

Bei Elasticsearch werden alle Anfragen über die API abgewickelt. Hierbei kommt sowohl für die Anfrage, als auch für die Antwort JSON als Datenformat zum Einsatz. Abfragen werden in der Sprache Query DSL definiert. Eine Abfrage kann hierbei aus Queries und Filters bestehen. Diese unterscheiden sich in einigen Dingen, die wichtigsten möchte ich hier kurz auflisten:

Weiterlesen →