Wildcard in WP_User_Query()

Für nutzerbezogene Daten steht in WordPress die Klasse WP_User_Query() zur Verfügung. Üblicherweise gibt man dort einen Schlüssel mit und bekommt die entsprechenden Werte zum User zurück. Durch ein Entwicklungsthema ist mir eine Besonderheit in der Query aufgefallen, die diesen kleinen Beitrag als Folge hat. Die Klasse erlaubt das Ergänzen von * als Wildcard. Innerhalb der Klasse wird dieser Stern dann für die SQL Abfrage ersetzt (%).

Im Codex findet man beispielsweise folgendes einfaches Beispiel zur User-Abfrage.


$user_query = new WP_User_Query( array( 'search' => 'Rami' ) );

Will man vor oder nach diesem String "Rami" per Wildcard schauen, was es weiter gibt, oder flexibler suchen, dann ist lediglich das Ergänzen von * notwendig. Dazu finde ich aktuell nichts im Codex, so dass der Hinweis hier ggf. hilfreich ist.

Im Core wird dies betrachtet:


// @see wp-includes/user.php#L599
if ( $search ) {
        $leading_wild = ( ltrim($search, '*') != $search );
        $trailing_wild = ( rtrim($search, '*') != $search );
        if ( $leading_wild && $trailing_wild )
                $wild = 'both';
        elseif ( $leading_wild )
                $wild = 'leading';
        elseif ( $trailing_wild )
                $wild = 'trailing';
        else
                $wild = false;
        if ( $wild )
                $search = trim($search, '*');

Damit kann also vor oder nach dem String ein Wildcard mitgegeben werden.


$user_query = new WP_User_Query( array( 'search' => '*Rami*' ) ); //%Rami%

$user_query = new WP_User_Query( array( 'search' => 'Rami*' ) ); //Rami%

Zum Ende nochmal der Hinweis, die Wildcard ist nur am Anfang oder Ende des Suchstrings möglich, nicht innerhalb des Strings.

Entscheidungshilfe: get_post() oder WP_Query

WordPress stellt oft verschieden Wege bereit um an Daten zu kommen. Im Umfeld von Inhalt - Einzelne Artikel, Kommentare, ... - beschränkt sich dies im Grunde auf zwei Wege. Beide sind im Netz zigfach in Tutorials hinterlegt und oft ist die Nutzung des jeweiligen Weges nicht zu Ende gedacht. Es gibt viele Artikel um die Hintergründe zu verstehen und sich mit dem gewonnen Verständnis für die entsprechende Methode zu entscheiden. Herausragend in Bildform und verständlich ist der Eintrag #1753 im WPSE.

Bitte nicht mit get_posts() verwechseln, get_posts() und get_post() sind für unterschiedliche Resultate erstellt. In kurzer Form dient get_posts() für viele Inhalte zum Type post. Die Entscheidungshilfe hier ist für die Ausgabe von einem Artikel, dessen Inhalte, dessen zugehörigen Daten. Im Grunde kann man aber von der Regel zu get_posts vs. WP_Query einiges ableiten.

Ich möchte nur eine kurze Entscheidungshilfe geben, die euch und mich in die Lage versetzt, aufgrund einiger weniger Punkte zu entscheiden, beim Holen einzelner Inhalte - get_post() oder WP_Query.

Tests

An folgendem kleinen Beispiel kann man die Unterschiede bspw. messen und an Hand der Anzahl der Queries vergleichen. Man kann wesentlich komplexere Beispiele bauen. Aber ich denke, dass gerade die Einfachheit das Verständnis fördert. Die Queries kann man entweder einfach per Ausgabe sehen $wpdb->queries oder alternativ bspw. mit Hilfe des Plugins Debug Objects ohne Aufwand einsehen.

Als erster wird der Artikel mit ID 1 geholt und Title und Content ausgelesen.


$post_1  = get_post( 1 );
$title   = $post_1->post_title;
$content = $post_1->post_content;

Den gleichen Inhalt holen wir nun über den WP_Query.


$query_1 = new WP_Query( 'p=1' );
$title   = $query_1->posts[0]->post_title;
$content = $query_1->posts[0]->post_content;

Welche Daten werden benötigt?

Wenn Daten zum Artikel, wie Kommentare, -Anzahl, Autoren-Daten oder Benutzerdefinierte Felder benötigt werden, dann nutze WP_Query. Wenn lediglich Daten aus der Tabelle posts benötigt werden, dann nutze get_post() und spare Datenbankabfragen.

Es wird ein Loop benötigt?

Werden im Loop Conditionals benötigt (if else, is_tag() etc.) dann nutze WP_Query. Sollen die Conditionals im Bezug auf den Artikel laufen, dann nutze get_post().

Code als Sprache?

WP-Query is komplexer, nicht so schnell zu durchschauen. Wenn man explizit auf verschiedene Post Types will, dann WP_Query. Ansonsten kann das Lesen und verstehen des Codes bei der Verwendung von get_post() einfacher sein. Für Live-betrieb sollte aber die Anzahl der Datenbankabfragen ein gewichtige Zahl sein.

Hinweis WP_Query

Bei der Verwendung von WP_Query lohnt immer der Gedanke an einen Cache, beispielsweise ist der standard WP_Object_Cache oder alternativ der Transient Cache von WordPress dafür schnell genutzt.

WordCamp Europe steht bevor

Ab Freitag geht die Reise nach Leiden, Niederlande, zum WordCamp Europe, mein erstes WordCamp in dieser großen Dimension – 700 Gäste werden erwartet. Ich freue mich darauf Leute zu treffen, Leute wo ich oft seit sehr langer Zeit nur das Avatar kenne. Ich freue mich ebenso einige Kollegen aus dem Inpsyde Team persönlich zu sprechen, nicht immer nur online via Tools.

Eine ganze Reihe von Sessions sind angekündigt. Ich lasse mich überraschen, wie wertvoll sie sind und wie sich mich bereichern. Ich werde sicher die eine oder andere Session besuchen.
Parallel werde auch ich ein Teil einer Session sein, da unser Thema der Mehrsprachigkeit auf großes Interesse stößt und so werden wir drei Lösungen aufzeigen. Ich denke, dass unser Multilingual Press dabei einen guten Schnitt macht die Anwender den Vorteil für ihre Projekte erkennen. Für mich persönlich wird die Session nicht leicht. Viele Zuhörer und die englische Sprache machen nervös und meine Stärke ist eher in meiner Muttersprache zu vermitteln, trotzdem werde ich die Herausvorderung annehmen und mein bestes geben – auf das man mich versteht.

Ich sehe euch also am Sonntag, den 6.Oktober 2013 um 16:45 Uhr.
Kurz und gut: ich freue mich auf das Event und auf viele Gesichter.

WordCamp Themenliste

In diesem Jahr werde ich vermutlich zwei Camps zum Thema WordPress besuchen -WordCamp EU und WPCamp Berlin. Es gibt eine ganze Reihe weiter toller Veranstaltungen, die ich leider nur seltem im Kalender unter bekomme und die Veranstaltungen zum Thema WordPress haben eine erhöhte Priorität, da Leidenschaft und Job in Inpsyde zusammen fließen. In erster Linie besuche ich die Veranstaltungen zum Netzwerken und Leute treffen. Trotzdem empfinde ich eine gute und inhaltlcih wertvolle Session als große Bereicherung. Da spielt das Level der Session nicht die erste Priorität, das Vermittlen von Inhalten und der Spaß am Teilen sind wichtige Aspekte.

Da es immer wieder an Themen und Mut mangelt, möchte ich für den ersten Punkt etwas nachhelfen. Mut kann ich dem geneigten Leser nur zu sprechen - es ist kein Meister vom Himmel gefallen, aber man sollte merken, dass man sich mit dem Thema und dem Tun als Vortragender vor Zuhörern auseinandergesetzt hat. Alles andere findet sich.

Nun aber zu einer willkürlichen Liste von Themen, die ich spannend finde oder die mir zugetragen wurden. Vielleicht findet man sich und der eine oder andere von euch schnappt sich ein Thema oder ergänzt eigene Wünsche in den Kommentaren.

  • Bloggen - Spaß oder Job (Stichpunkt Geld verdienen)
  • Geschwindigkeit und WordPress -  was geht, was ist sinnvoll, Erfahrungen
  • Testen im Umfeld der Entwicklung
  • Erfahrungen als Agentur, Freelencer  - Tips für den Kollegen, Konkurrenten
  • Kosten/Nutzen - Erfahrungen beim Verkauf von WP PRodukten (Themes, Plugins, Garantie, Support ...)
  • Multiautorenlandschaft
  • Mehrsprachigkeit mit WP, lokales und internationales Blickfeld
  • Ethik beim Bloggen
  • WordPress APIs
  • WordPress im Unternehmen - Lizenz, Chancen
  • Corporate Blogging?
  • WP als Intranetlösung
  • Themes in der WP Multisite Welt - Vor- und Nachteile
  • Update, Update, Update - wer prüft Plugins und Themes in der zukünftigen Umgebung
  • Pluginentwicklung - Mitentwickler, - support finden
  • WordPress und Photografie
  • Ungeahnte Lösungen mit WordPress
  • Mitgliederverwaltung - Lösungswege
  • Applikation Development - WP werkelt im Hintergrund
  • Typische Probleme und ihre Lösungen
  • Git - Allgemeine Vorteile, Nutzung aufzeigen
  • WP als CRM
  • WP als PM
  • Frontendediting - Lösungsansätze, Erfahrungen
  • OOP (MVC) und WordPress
  • WordPress im Schulungsumfeld (ggf. allgemeiner in Schulen, Lehreinrichtungen)
  • Brücken bauen - Verbindungen zw. WP und anderen Applikationen schaffen
  • WP Core unterstützen - Erfahrungen, Wege, Hinweise
  • Theme Customizing
  • WordPress - Recht und Schlecht, GPL verstehen, Ratschläge für den Alltag im Kundenumfeld
  • PHP Basics für WP Starter
  • ...

HTML5 Support seit WordPress 3.6

HTML5 in Buchform
Eines der Themen, die uns seit WordPress 3.6 neu zur Verfügung stehen ist der HTML5 Support, der in Themes Unterstützung findet. Dabei können drei Bereiche in den Genuss kommen. Die seit Version 3.4 zur Verfügung stehende Funktion add_theme_support() ist auch hier Schlüssel und so können aktuell drei Funktionalitäten für den Support von html5 registriert werden.

Im Theme, üblicherweise via functions.php werden alle drei Funktionalitäten registriert.


add_action( 'after_setup_theme', 'fb_example_setup' );
function fb_example_setup() {
	add_theme_support(
		'html5',
		array( 'comment-list', 'comment-form', 'search-form' )
	);
}

Die Namen der Funktionen sollten für sich sprechen.

  • 'comment-list' - Kommentarliste, wp_list_comments
  • 'comment-form' - Kommentar-Formular, comment_form()
  • 'search-form' - Such-Formular, get_search_form()

In existierenden Themes gibt es nichts zu tun, alle Funktionen sind abwärtskompatibel und damit wird weiter das bekannte xhtml Markup genutzt. Attribute wie placeholder sind dann nicht genutzt.

Die Funktion für den Aufruf der Kommentarliste im Template ist damit auch kürzer geworden, ein Beispiel.


<ol class="comment-list">
	<?php
		wp_list_comments( array(
			'style'       => 'ol',
			'short_ping'  => TRUE,
			'avatar_size' => 74,
		) );
	?>
</ol><!-- .comment-list -->

Die Vorgaben werden in einem Array übergeben und folgende Standard-Einstellungen werden genutzt.


	$defaults = array(
		'walker'            => null,
		'max_depth'         => '',
		'style'             => 'ul',
		'callback'          => null,
		'end-callback'      => null,
		'type'              => 'all',
		'page'              => '',
		'per_page'          => '',
		'avatar_size'       => 32,
		'reverse_top_level' => null,
		'reverse_children'  => '',
		'format'            => current_theme_supports( 'html5', 'comment-list' ) ? 'html5' : 'xhtml',
		'short_ping'        => false,
	);

Damit ist WordPress perse nicht sauber in der Ausgabe im Hinblick auf HTML5, aber erste Zeichen sind gesetzt. Insbesondere das Markup, was zum Content erzeugt wird, macht da Schwierigkeiten, wo nur eigene Anpassungen als Plugin oder im Theme helfen können.

Einfaches PHP Debugging in Browser Console

Ich nutze die Console im Browser der gern um Debug-Inhalte auszugeben. Insbesondere bei Kunden-Sites kann ich so recht unscheinbar arbeiten und muss nicht die Oberfläche mit Debug-Meldungen zu zerstören, auch wenn man dies natürlich via Rechtabfrage filtern sollte. Im folgenden eine kleine Funktion, die mir den Inhalt in die Console schreibt, ohne Helferlein. Dies ist auch im Plugin Debug Objects untergebracht und kann beim Einsatz des Plugins direkt genutzt werden.

Der Screenshot demonstriert dies an einem komplexen Objekt in der Ausgabe und dient nur dem Verständnis. Den Inhalt, den ihr ausgeben wollt, liegt natürlich in eurer Hand.
debug-to-console

Die einfache Variante, die allerdings keine Objekte verarbeiten kann - lediglich Strings und Arrays. Im weiteren Verlauf dann eine etwas aufwendigere Funktion, die Objekte zulässt.


	/**
	 * Simple helper to debug to the console
	 * 
	 * @param  Array, String $data
	 * @return String
	 */
	function debug_to_console( $data ) {

		if ( is_array( $data ) )
			$output = "<script>console.log( 'Debug Objects: " . implode( ',', $data) . "' );</script>";
		else
			$output = "<script>console.log( 'Debug Objects: " . $data . "' );</script>";

		echo $output;
	}

Will man Objekte nutzen, so muss die Funktion erweitert werden. Will man Beispielsweise den Inhalt des globalen Objektes der WordPress Datenbank ausgeben, siehe folgende Zeilen


global $wpdb;
debug_to_console( $wpdb );

dann genügt die einfache Helferfunktion nicht, darum eine erweiterte Version, die auch Objekte ausgibt.


	/**
	 * Simple helper to debug to the console
	 * 
	 * @param  Array, Object, String $data
	 * @return String
	 */
	function debug_to_console( $data ) {
		
		$output = '';
		
		if ( is_array( $data ) ) {
			$output .= "<script>console.warn( 'Debug Objects with Array.' ); console.log( '" . implode( ',', $data) . "' );</script>";
		} else if ( is_object( $data ) ) {
			$data    = var_export( $data, TRUE );
			$data    = explode( "\n", $data );
			foreach( $data as $line ) {
				if ( trim( $line ) ) {
					$line    = addslashes( $line );
					$output .= "console.log( '{$line}' );";
				}
			}
			$output = "<script>console.warn( 'Debug Objects with Object.' ); $output</script>";
		} else {
			$output .= "<script>console.log( 'Debug Objects: {$data}' );</script>";
		}
		
		echo $output;
	}

Als schlanke und effiziente Lösung nutze ich gern folgende kleine Funktion, ohne Overhead.


	/**
	 * Simple helper to debug to the console
	 * 
	 * @param  object, array, string $data
	 * @return string
	 */
	function debug_to_console( $data ) {
		
		$output = '';

		// new and smaller version, easier to maintain
		$output .= 'console.info( \'Debug in Console via Debug Objects Plugin:\' );';
		$output .= 'console.log(' . json_encode( $data ) . ');';

		echo '';
	}

Den aktuellen Code findet ihr auf Github, dem Link folgen.

Liste aller Blogs in WordPress Multisite

WordPress Multisite ist seit der Zusammenlegung von MU und Single ab Version 3.0 populärer geworden. Nicht nur die Verwaltung meherer Sites, sondern auch in diversen Szenarios findet Multisite seinen Einsatz. Als ein Beispiel sei die Mehrsprachigkeits-Lösung genannt.

In diesem Umfeld werden des öfteren die Inhalte oder Daten aus allen Blogs gebraucht, wozu man ggf. alle Blogs kennen muss. Bemüht man eine Suche um eine Lösung zu finden, dann erscheinen sehr oft div. SQL Selects, die auch in vielen Lösungen verbaut wurden und daher zum Nachahmen aufrufen. Da ich aktuell in einem Projekt wieder damit zu tun hatte und ein Select nicht die erste Wahl sein sollte, wenn es Core Functionen gibt, hier ein kurzes Snippet, was alle Blogs im Network zurück gibt.


// Get all blogs of WordPress Multisite
$blogs = get_blog_list( 0, 'all' );

Das Auswerten ist dann schnell getan, da die ID der Blogs im zurückgegebenen Array steckt und darüber alle weiteren Daten geholt werden können, ein Beispiel soll es verdeutlichen.


foreach( (array) $blogs as $blog ) {
    
    $stylesheet = get_blog_option( $blog['blog_id'], 'stylesheet' );
    $blogname   = get_blog_details( $blog['blog_id'] )->blogname;

}

Natürlich hat diese Lösung einen Haken. Die Funktione wurde mit WordPress 3.0 abgekündigt, womit man sie aktuell noch nutzen kann, aber irgendwann ist sie im Core weg. Sie wurde aus Gründen der Performance deaktiviert, da sie mit sehr großen Netzwerken (> 1000 Blogs) Probleme macht. Alternativ ist also die Funktion bereit zu stellen. Daher im folgenden die Funktion, die ich abhängig ablege. Ich werde die Funktion mit Transients erweitern, so dass mit WP Core Mitteln performanter ist. Dazu bitte in den Code auf Github schauen. Dort wird er gepflegt. Ihr seit herzlich eingeladen, den Code zu verbessern, zu ergänzen - die Fork-Funktion kann gern genutzt werden.


 if ( ! function_exists( 'get_blog_list' ) ) {
	
	/**
	 * Returns an array of arrays containing information about each public blog hosted on this WPMU install.
	 * Only blogs marked as public and flagged as safe (mature flag off) are returned.
	 * 
	 * @param   Integer  The first blog to return in the array.
	 * @param   Integer  The number of blogs to return in the array (thus the size of the array).
	 *                   Setting this to string 'all' returns all blogs from $start
	 * @return  Array    Returns an array of arrays each representing a blog hosted on this WPMU install. 
	 *                   Details are represented in the following format:
	 *                       blog_id   (integer)ID of blog detailed.
	 *                       domain    (string) Domain used to access this blog.
	 *                       path      (string) Path used to access this blog.
	 *                       postcount (integer) The number of posts in this blog.
	 */
	function get_blog_list( $start = 0, $num = 10 ) {
	
		global $wpdb;
		$blogs = $wpdb->get_results(
			$wpdb->prepare( "
				SELECT blog_id, domain, path 
				FROM $wpdb->blogs WHERE site_id = %d 
				AND public = '1' 
				AND archived = '0' 
				AND mature = '0' 
				AND spam = '0' 
				AND deleted = '0' 
				ORDER BY registered DESC
			", $wpdb->siteid ), 
		ARRAY_A );
		
		foreach ( (array) $blogs as $details ) {
			$blog_list[ $details['blog_id'] ] = $details;
			$blog_list[ $details['blog_id'] ]['postcount'] = $wpdb->get_var( "
				SELECT COUNT(ID) 
				FROM " . $wpdb->get_blog_prefix( $details['blog_id'] ). "posts 
				WHERE post_status='publish' 
				AND post_type='post'" 
			);
		}
		unset( $blogs );
		$blogs = $blog_list;
		
		if ( false == is_array( $blogs ) )
			return array();
		
		if ( $num == 'all' )
			return array_slice( $blogs, $start, count( $blogs ) );
		else
			return array_slice( $blogs, $start, $num );
	}
	
} // end if fct exist

Eventuell hilft dieser kleine Hinweis dem einen oder anderen bei seinem Projekten.

10 Jahre WordPress – lose Gedanken

Nun denn, die Zeit vergeht und dieser Tage wurde WordPress zehn Jahre jung. Wobei im Software-Umfeld dies relativ zu sehen ist, denn hier lebt es sich schneller auf und nieder als so manchem Projekt lieb ist. Im Umfeld des Interntes kann die Lebensdauer einer Applikation noch viel relevanter sein und Vergleiche sind nur schwer anzustellen. Linux, ein wichtiger Baustein des www, ist in dem Vergleich alt, andere Tools, die sich wie WordPress um das Publizieren von Inhalten im www kümmern, dagegen sind sehr jung und nicht selten nach geraumer Zeit nicht in Wartung und damit unantraktiv.

Das Thema Wartung im Sinne von Tun und Veröffentlichen kann man WordPress nicht als negativen Punkt vorwerfen. Das Rad WordPress dreht sich, die Sichten der Nutzer und Entwickler ist sicher verschieden, was gut ist. Diskussionen sind wichtig, sie müssen nur sachlich sein. Nicht immer erreicht man damit die Adresse, die was ändern kann, aber die Diskussion kann dazu führen und darum ist sie wichtig...

WordPress und ich sind schon länger ein Paar, manchmal ein Team und manchmal verstrittene Freunde. Die Zeit vergeht wie im Fluge, man arangiert sich, tolleriert Ecken und Kanten oder wechselt die Freunde. Jeder ist für sich selbst verantwortlich und nur für mich muss ich schauen, was kann ich vertreten und will ich es tun. Über die Zeit gibt es besonders schöne und besonders harte Zeiten. Zum Glück verdrängt man die negativen Erinnerungen und die positiven Erlebnisse bleiben. Aus beiden Extremen lernt man und nimmt für sich relevante Themen heraus. So gibt es ebenso Themen, wo ich mich heraus genommen habe. Ich muss nicht mehr zu jedem Thema meine Meinung darlegen, die Welt aufklären, mich einbringen. Aber ich nehme mir auch heraus, es zu tun, wenn ich mag. Ich fühle mich oft missverstanden. Dazu trägt die Sprachbarriere die Kultur und die Sicht auf die Lösung seinen Beitrag. Ebenso ist das Einbringen ein Thema der Zeit. Zeit, die man sich nehmen muss und initiert man Ideen, Veränderungen, dann können schnell größere Aufwände darin resultieren. Diese Konsquenz ist wichtig und um so besser, wenn neue Leute in der Community heran wachsen, die noch weniger Verpflichtungen haben, die kampfeslustig in das Gefecht ziehen und Ideen einbringen wollen.

Ich verbringe noch immer viel Zeit mit WordPress, vielleicht zu viel - wieder eine Frage der Sicht. Aber der Stellenwert ist ein anderer. Ich erfreue mich jeden Tag an dem entstandenen Unternehmen Inpsyde, an einem großartigen Team, an Freunden und Talenten. Mal aus einer gemeinsamen Leidenschaft zu WordPress und Open Source in Allgemeinen ist ein Unternehmen gewachsen, ein Team, eine Familie. Viele neue Aufgaben und Themen sind hinzugekommen. Viele Themen die weit über das Konglomerat Code und Kundenlösung hinaus gehen. Tolle Menschen und tolles Wissen haben eine Familie, ein Zuhause gefunden und die Arbeit allein ist nicht mehr denkbar. Auch wenn ich dadurch weit weg vom "Frickeln" und schnellen Lösungen bin, was ich an sich sehr gern tue, so freue ich mich, dass Leute mit Ideen ein Dach gefunden haben um Ideen umzusetzen - mit allen Vor- und Nachteilen.

Aus diesem Umfeld entstand auch MarketPress, unsere Plattform für professionelle Lösungen und Support. Auch hier gab es viel zu lernen, so schnell hört es auch nicht auf und nicht immer ist der erste Schritt der richtige. Geduld und Kraft werden immer wieder auf die Probe gestellt. Aber es ist ein kleiner Kiesel, den WordPress mit in seinem Konlomerat vereinnahmt. Die folgenden Infografik aus dem Team wurde erstellt um die letzten 10 Jahre WordPress etwas zu visualisieren, um zum Nachdenken anzuregen, sei es über das eigenen Verhältnis als Entwickler oder Nutzer. Für viele Leute im www hat WordPress einen Wert, wie hoch man den auch messen mag.

10_Jahre_WordPress_Infografik_powered_by MarketPress.com

WordPress Puls? – Heartbeat API

Mit WordPress 3.6 wird es eine neue API geben - Heartbeat. Am Ticket 23216 im Trac sammeln sich alle Diskussionen und Hinweise. Da Heartbeat aber auch Einflüsse für Anwender haben kann, hier einige Worte und Hinweise. Heartbeat wird eingeführt um diverse Aktivitäten, wie Autosave, Sperren von Artikeln und An- und Abmelde-Benachrichtigungen zu händeln. Parallel kann die API auch für eigene Entwicklungen genutzt werden.

Am Puls

Im Standard wird Heartbeat mit einem Puls von 15 Sekunden schlagen - Arbeit die der Prozessor tun muss und so kann es sinnvoll sein, diesen Wert zu ändern. Dabei kann nicht beliebig geändert werden. Der Pulsschlag von Heartbeat muss zwischen 5 und 60 Sekunden liegen. Folgendes kleines Plugin ändert auf den maximalen Wert von 60s.

Die Heartbeat API hat vielleicht im ersten Blick nicht die großen Vorteile, schauen wir aber auf ein einfaches Beispiel. Deine Installation hat zehn verschieden Plugins, die einen Poll auf den Server brauchen. Dann finden diese Hits getrennt statt, 10 mal. Wenn die Plugins die Heartbeat API verwenden, dann werden die Polls gebündelt, ein Hit für 10 Polls, alle 15 Sekunden im Standard.


<?php
/**
 * Plugin Name: Set Heartbeat pulse
 */

! defined( 'ABSPATH' ) and exit;

add_filter( 'heartbeat_settings', 'fb_heartbeat_settings' );
function fb_heartbeat_settings( $settings = array() ) {

	$settings['interval'] = 60;

	return $settings;
}

Parallel kann man Heartbeat auch still legen, den Puls abklemmen, was das folgenden kleine Plugin tut.


<?php
/**
 * Plugin Name: Remove Heartbeat pulse
 */

! defined( 'ABSPATH' ) and exit;

remove_action( 'admin_init', 'wp_auth_check_load' );

Debugging

Im Core von WordPress wurde die API so implementiert, dass die Console Infos ausspucken kann. Dazu muss der Parameter wp.heartbeat.debug auf TRUE gesetzt werden und schon kann das JavaScript infos geben.


if ( typeof console !== 'undefined' ) {
	// Show debug info
	wp.heartbeat.debug = true;
}

Entwicklung

Ein einfaches Beispiel liegt dem Trac bei, wo das Dashboard Widget für Kommentare am Pulsschlag aktualsiet wird - man kann also alle 15s einen Refresh der Zahlen erleben, insofern neue Kommentare eintreffen. Das Beispiel zeigt die wichtigsten Hooks und Funktionen und daher hier auch keine weitere Erklärung.

Weitere Hinweise, Links zum Thema

Post Format UI deaktivieren

WordPress Version 3.6 kommt mit neuer Oberfläche für die Post Formats, präsenter ist das Schlagwort. Die Post Format UI ist eine wunderbare Möglichkeit mit wenig Aufwand Artikel besser uns sichtbar zu deklarieren, für den Leser verschieden aufzubereiten. Trotzdem ist sie nicht immer notwendig. Im Standard kann die UI in den jeweiligen Optionen des Users deaktiviert werden, siehe Screenshot.

post-format-ui

Alternativ kann der Filter Hook enable_post_format_ui genutzt werden. Mittels dieses Hooks kann die UI global in der Installation deaktiviet werden und kein User hat die Möglichkeit die Post Formats zu nutzen. Folgende Zeilen in einer php-Datei als Plugin abgelegt und aktiviert sind daher ausreichend.

<?php
/**
 * Plugin Name: Disable Post Format UI
 */

! defined( 'ABSPATH' ) and exit;

add_filter( 'enable_post_format_ui', '__return_false' );

WordPress Lightbox Plugin