Scripts und Styles effektiv einbinden

Wenn man JavaScript und CSS Dateien einbinden möchte, dann sollte man immer die Funktionen wp_enqueue_script() und wp_enqueue_style() verwenden. Falls ihr das noch nicht tut, dann fangt bitte ab sofort damit an. Die Verwendung der beiden Funktionen ist wirklich sehr einfach, aber um diese auch effektiv zu nutzen, sollte man ein paar Dinge beachten.

Einfache Verwendung

Die einfachste Art, die Funktionen zu verwenden, ist die Definition eines „handle“ sowie einer URL der Datei, die ihr einbinden wollt:

wp_enqueue_script(
	'chart-js',
	'https://cdnjs.cloudflare.com/ajax/libs/Chart.js/3.7.0/chart.min.js'
);

Dieses Beispiel würde eine JavaScript-Datei einbinden, sie sich auf einem externen Server befindet. Das ist so weit auch OK, aber es gibt viele Gründe, wieso man Dateien lieber lokal einbinden möchte, um beispielsweise Probleme beim Ausfall des CDN zu vermeiden oder aber, um den Datenschutz zu verbessern.

Verwendung einer lokalen Datei – schlechtes Beispiel

Um eine Datei aus einem Plugin oder Theme zu laden, würde es ausreichen, den Pfad wie folgt relative anzugeben:

wp_enqueue_script(
	'chart-js',
	'/wp-content/plugins/plugin-name/assets/chart.min.js'
);

Die Datei würde dann wie folgt in den Quellcode eingebunden werden:

<script type='text/javascript' src='https://theme-tests.docker.test/wp-content/plugins/plugin-name/assets/chart.min.js?ver=5.9'></script>

Das würde zwar funktionieren, es gibt mit dieser einfachen Methode aber ein paar Probleme.

1. Immer dynamische Pfade verwenden

Im Beispiel oben wurde ein relativer Pfad auf das Verzeichnis wp-content/plugins verwendet. Das mag für viele von euch richtig aussehen, aber der Ordner wp-content kann einen anderen Namen haben (und manche Sicherheits-Plugins tun das auch – obwohl es eine schlechte Idee ist). Ihr solltet daher immer eine Hilfsfunktion verwenden, um den relativen Pfad zu diesem Ordner zu erhalten. Wenn ihr eine Datei in einem Plugin oder Theme einbindet, dann könnt ihr hierzu verschiedene Funktionen verwenden. Diese hier werdet ihr dafür vermutlich in der Regel verwenden:

2. Immer eine Version der Datei angeben

Wie ihr in dem Beispiel oben sehen könnt, fügt WordPress immer eine Versionsnummer an. Wenn ihr selbst keine festlegt, dann wird WordPress immer seine aktuelle Version ans Ende der URL anhängen. Heute würde also 5.9 am Ende stehen. Diese Versionsnummer hat den Zweck, euch beim Caching zu helfen. Da sich eure Dateien aber sicher nicht (nur) dann ändern, wenn eine neue WordPress Version erscheint, solltet ihr hier einen anderen Versions-String verwenden. Das könnte einer der folgenden sein:

  • Eine statische Versionsnummer, die der Version des Plugins entspricht
  • Ein statisches Änderungsdatum des Plugins
  • Ein statisches Änderungsdatum der Datei, die eingebunden werden soll
  • Ein dynamisches Änderungsdatum der Datei, die eingebunden werden soll

In der Vergangenheit habe ich oft die erste oder dritte Option verwendet. Aber dabei musste jeder dieser Versions-String (für alle Dateien) immer manuell aktualisiert werden. Dabei vergisst man dann schnell mal einen und der Browser liefert eine alte Datei aus seinem Cache aus. Heutzutage verwende ich daher normalerweise den letzten Ansatz. Das hat auch den Vorteil, dass während der Entwicklung, bei jedem Speichern der Datei immer sichergestellt wird, dass der Browser stets die aktuellste Datei lädt. Ein Beispiel für diesen Ansatz – kombiniert mit dynamischen Pfaden – könnte wie folgt aussehen:

wp_enqueue_script(
	'chart-js',
	plugins_url( 'assets/chart.min.js', __FILE__ ),
	array(),
	filemtime( plugin_dir_path( __FILE__ ) . 'assets/chart.min.js' )
);

Das Resultat der Einbindung der Datei würde dann so aussehen:

<script type='text/javascript' src='https://theme-tests.docker.test/wp-content/plugins/plugin-name/assets/chart.min.js?ver=1644792351' id='chart-js-js'></script>

Wie ihr hier sehen könnt, wurde an das Ende der URL der aktuelle UNIX-Timestamp angehängt. Da sich dieser mit jeder Änderung der Datei ändert, wird der Browser immer die aktuellste Datei laden.

Fazit

Dieser Blogbeitrag behandelt ein sehr einfaches Konzept, aber ich sehe immer wieder Plugins und Themes, die Dateien nicht effektiv einbinden. Mit diesen kleinen Tricks könnte ihr viel Stress beim Finden von Fehlern vermeiden, die nur deshalb auftreten, weil der Fehler eigentlich nur darin bestand, dass der Browser noch immer eine alte Version der Datei aus seinem Cache geladen hatte.

Dynamische Formular-Hooks für GravityForms

Ich nutze wirklich sehr gerne GravityForm, wenn ich sehr dynamische Formulare erstellen muss. Der Formular-Builder ist sehr umfangreich und bietet viele Möglichkeiten. Manchmal muss man dann aber doch ein wenig eigenen Code schreiben und sich per Hook in die Formular-Abarbeitung einhängen. In diesem Blogbeitrag möchte ich euch zeigen, wie das auch über mehrer Installation eines Formulars hinweg funktioniert.

Verwendung eines Hooks für alle Instanzen

Nehmen wir als Beispiel mal den Hook gform_pre_submission. Wenn ihr euch hier einhängen wollt, dann funktioniert das, wie bei jedem anderen Hook in WordPress auch:

function my_pre_submission( $form ) {
    $_POST['input_1'] = 'updates value for field with ID 1';
}
add_action( 'gform_pre_submission', 'my_pre_submission' );

Dieser Code-Schnippsel würde den Wert jedes Formular-Feldes mit der ID 1 in jedem Formular überschreiben. Das ist sicher nicht, was ihr normalerweise wollt.

Verwendung eines Hooks nur für ein Formular

Wenn ich den Wert eines Feldes ändern wollt, dann in der Regel nur für ein spezifisches Formular. Dies kann recht einfach erreicht werden, indem ihr die Formular-ID an das Ende des Hooks anhängt:

function my_pre_submission( $form ) {
    $_POST['input_1'] = 'updates value for field with ID 1';
}
add_action( 'gform_pre_submission_1', 'my_pre_submission' );

Nun wird nur noch das Feld für das Formular mit der ID 1 überschrieben, sobald es übermittelt wurde. Das ist eine gute Lösung, bis zu dem Zeitpunkt, an dem ihr die Export/Import Funktion verwendet.

Umgang mit Formularen mit verschiedenen IDs

Sagen wir einmal, ihr habt ein Formular in einem Projekt erstellt und möchtet dieses nun in einem anderen verwenden. Hierzu könnt ihr dann einfach die Funktion für den Export und Import verwenden, was das Formular mit allen Einstellungen (aber ohne die Einträge) kopiert. Aber wenn das neue Projekt bereits Formulare hat, dann kann es passieren, dass das Formular hier eine andere ID bekommt. Das gleicht passiert auch recht schnell, wenn ihr in einer Entwicklungsumgebung ein Formular erstellt und es dann auf eine Live-Seite importiert oder aber wenn ihr nicht alleine neue Formulare erstellt.

In diesen Fällen müsst ihr dann die neue Formular-ID rausfinden und den Wert entsprechend in allen Hooks anpassen. Aber was ist, wenn ihr den Code in einer Versionsverwaltung habt und nicht einfach einen neuen statischen Wert verwenden könnt?

Verwendung einer Konstanten für die Formular-ID

In einem Projekt hatte ich genau dieses Problem und mich dazu entschieden, die ID des Formulars einfach in einer Konstanten zu speichern. Alle Hooks sehen dann in etwa wie folgt aus:

function my_pre_submission_contact( $form ) {
    $_POST['input_1'] = 'updates value for field with ID 1';
}
add_action( 'gform_pre_submission_' . PREFIX_CONTACT_FORM_ID, 'my_pre_submission_contact' );

function my_pre_submission_form_event( $form ) {
    $_POST['input_1'] = 'updates value for field with ID 1';
}
add_action( 'gform_pre_submission_' . PREFIX_EVENT_FORM_ID, 'my_pre_submission_form_event' );

Das ist natürlich nicht der echt Code, aber ich denke, ihr versteht den Ansatz damit. Ich habe also eine Konstante pro Formular (und hierbei den Formularnamen und nicht dessen ID verwendet). Damit kann dann die ID je nach System dynamisch gesetzt werden.

Setzen eines Standard-Werts für die Konstante im Plugin (oder Theme)

Ich speichere solchen Code normalerweise in einem Plugin. In der Hauptdatei dieses Plugins setze ich dann einen Standardwert, der dem System entspricht, auf dem ich das Formular zuerst verwendet/erstellt habe:

if ( ! defined( 'PREFIX_CONTACT_FORM_ID' ) ) {
	define( 'PREFIX_CONTACT_FORM_ID', 1 );
}
if ( ! defined( 'PREFIX_EVENT_FORM_ID' ) ) {
	define( 'PREFIX_EVENT_FORM_ID', 2 );
}

Mit der ! defined() Prüfung kann ich feststellen, ob die Konstante schon zuvor an andere Stelle gesetzt wurde und ansonsten den Standardwert setzen. Im zweiten Projekt kann ich daher dann in der wp-config.php Datei die anderen IDs setzen:

define( 'PREFIX_CONTACT_FORM_ID', 4 );
define( 'PREFIX_EVENT_FORM_ID', 5 );

Fazit

Obwohl GravityForms wirklich sehr viele Hooks anbietet und diese wirklich einfach genutzt werden können, kann es aufgrund der statischen IDs in den Namen schnell zu Problemen führen. Die Verwendung von dynaischem ID-Werten in Konstanten ermöglicht es euch, den selben Code in mehreren Projekten zu verwenden.

Das Gleiche gilt selbstverständlich auch für alle anderen Hooks von GravityForms, bei denen eine ID ans Ende des Hooks gehängt werden können, um nur bestimmt Formulare, Felder, etc. anzupassen.

Kategorie-Seiten alphabetisch sortieren

In einer Facebook-Gruppe wurde gefragt, wie man alle Beiträge auf einer Kategorieseite alphabetisch sortieren kann. In diesem Beitrag möchte ich darauf eingehen, wie man die Sortierung von Beiträgen auf Archiv-Seiten von Kategorien (und anderen) anpassen kann.

Sortierung von Beiträge auf allen Kategorie-Seiten

Selbst wenn ich nicht genau weiß, wieso die Person die Beiträge auf allen Kategorie-Seiten (und nicht etwa auf einer Archivseite eines anderen Post-Types) sortieren wollte, wäre das hier der passende Code dafür:

function aa_sort_all_archives( $query ) {
	// Only sort main query.
	if ( ! $query->is_main_query() ) {
		return;
	}
	// Only sort category archives.
	if ( ! is_category() ) {
		return;
	}

	$query->set( 'order', 'ASC' );
	$query->set( 'orderby', 'post_title' );
}

add_action( 'pre_get_posts', 'aa_sort_all_archives' );

Wann immer man die Query verändern möchte, sollte man eine Callback-Funktion zum pre_get_posts Hook verwenden. In dieser Callback-Funktion prüfen wir zuerst einmal, ob wir uns in der Haupt-Query befinden. Dann prüfen wir mit einer weiteren Bedingung nach für unseren Anwendungsfall. Ist diese Bedingung nicht erfüllt, verlassen wir die Funktion ebenfalls. Wenn alle Bedingungen erfüllt sind, dann passen wir die Query an. In Zeile 7 prüfen wir also, ob wir auf einer Kategorie-Seite sind. Wenn das der Fall ist, dann setzen wir die Sortierreihenfolge auf aufsteigend („ascending“) in Zeile 11 und das Feld, nach dem sortiert werden soll in Zeile 12 auf das post_title Feld. Das war’s!

Nur Beiträge in einer bestimmen Kategorie ordnen

Für manche Post-Types ist es wohl eher unwahrscheinlich, dass man die Posts nach für alle Kategorien sortieren möchte. Daher können wir auch den „slug“ (oder den Namen bzw. die ID) einer Kategorie an die is_category() Funktion übergeben. In diesem Beispiel habe ich eine spezielle Kategorie „alphabetical“ verwendet, um nur auf dieser Kategorieseite die Beiträge zu sortieren:

function aa_sort_alphabetical_archives( $query ) {
	// Only sort main query.
	if ( ! $query->is_main_query() ) {
		return;
	}
	// Only sort category archives.
	if ( ! is_category( 'alphabetical' ) ) {
		return;
	}

	$query->set( 'order', 'ASC' );
	$query->set( 'orderby', 'post_title' );
}

add_action( 'pre_get_posts', 'aa_sort_alphabetical_archives' );

In der gleichen Art und Weise lassen sich auch viele andere Archiv-Seiten unter Verwendung der „Conditional Tags“ überprüfen. Im CODEX findet ihr außerdem eine Seite über „Alphabetizing Posts“, darin wird aber die Verwendung einer sekundären Query gezeigt. Macht so etwas bitte niemals! Und lasst auch nicht alle Beiträge ausgeben! Macht also nichts von dem, was die Seite euch hier erzählt 😉

Fazit

Das Sortierung von Beiträgen (oder anderen Beitragstypen) kann auf einer Archiv-Seite am besten mit dem pre_get_posts Hook gelöst werden. Wenn ihr das erste Mal mit diesem Hook arbeitet, dann kann es passieren, dass es nicht gleich so funktioniert, wie ihr es gerne hättet, aber es lohnt sich wirklich sich mit dem Hook zu beschäftigen.

Ihr findet den Code zu diesem Beitrage auch als funktionierendes Plugin in einem GIST, wo ihr es euch auch als ZIP-Datei herunterladen und dann auf eurer Seite installieren könnt.

2022: Ein ereignisreiches Jahr

Ich veröffentliche normalerweise keine „Neujahrs“-Beiträge – ich habe normalerweise nur einen Beitrag zum Blog-Geburtstag – aber da noch immer die letzte Kalenderwoche von 2021 ist und ich nicht sicher bin, ob ich noch einen #projekt26 Beitrag veröffentlichen muss, möchte ich euch ein wenig über das neue Jahr aus meiner Sicht erzählen.

#projekt26 geht weiter

Das ist entweder der letzte Blogbeitrag des vergangenen Jahres oder der erste des neuen 😉 Auch wenn dieses Jahr einiges bei mir ansteht, möchte ich weiterhin versuchen alle zwei Wochen einen Beitrag zu veröffentlichen. Ich werde auch versuchen auf anderen Blogs zu kommentieren, auch wenn ich nicht einmal dazu komme genügend Beiträge zu lesen.

WordPress Releases und Full Site Editing (FSE)

Dieses Jahr könnte das erste sein, in dem es vier Hauptversionen von WordPress geben wird. Mit der anstehenden Version 5.9 in diesem Monat wird es auch ein neues Standard-Theme geben: TwentyTwentyTwo! Daher werde ich mir dieses Jahr endlich mal mein erstes FSE-Theme vornehmen. Entweder in einem Projekt oder aber, indem ich mein aktuelles Theme komplett neu schreibe.

Ein Plugin geht in Rente

Mit der Veröffentlichung von 5.9 wird es auch ein neues Feature geben: den Sprachumschalter auf der Login-Seite. Damit wird einer meiner ersten beiden Plugins endlich in Rente geschickt.

WordCamp Europe 2022 … in Porto!

Das große „Ereignis“ wird für mich das WordCamp Europe 2022 werden, das endlich in Porto stattfinden wird. Unser Organisationsteam arbeitet hart daran, die Community wieder zusammenzubringen. Da aber Corona noch immer da sein wird, werden wir sicherstellen, dass es so sicher wie möglich für alle sein wird. Nach dieser Auflage werde ich dann auch erst einmal von der Organisation des WCEU zurücktreten – zumindest für eine Zeit.

Fazit

Die letzten beiden Jahre waren schwer für viele von uns. Aber 2022 sieht nach dem Jahr aus, in dem wir endlich wieder viele Dinge tun können, die wir so sehr lieben. Ich kann es kaum erwarten viele von euch in Porto wiederzusehen oder auf einem anderen WordCamp dieses Jahr. Mit FSE am Horizont wird es sicher auch einige neue und spannende Themen geben, über die ich schreiben kann.

Block Patterns für neue Einträge eines Custom Post Types nutzen

In Projekten nutze ich sehr häufig Custom Post Types (CPT). In einem neuen Projekt wurde der Inhalt der Einträge komplett mit Core-Blöcken gebaut. Hierzu habe ich in der Vergangenheit normalerweise Post-Meta-Felder und ein festes Seitentemplate verwendet. Aber da die Erstellung solch komplexer Inhalte für einen CPT recht viel Arbeit und auch sehr fehleranfällig ist, wollte ich für die neuen Einträge ein Template verwenden.

Erstellung eines Block Pattern

Die einfachste Art ein Pattern für einen Post-Type zu erstellen ist es, den Inhalt zuerst mit dem Block-Editor zu erstellen und das HTML Markup dann über die „Kompletten Inhalt kopieren“ in die Zwischenablage kopieren:

Jetzt könnt ihr dieses Markup verwenden, um ein Block Pattern mit diesem Standardinhalt für neue Inhalte zu erstellen:

function cpt_register_block_pattern() {
	register_block_pattern(
		'my-cpt/my-cpt-pattern',
		array(
			'title'       => __( 'My CPT pattern', 'my-cpt' ),
			'description' => _x( 'The custom template for my_cpt', 'Block pattern description', 'my-cpt' ),
			'content'     => '
<!-- wp:paragraph {"placeholder":"Custom Post Type ..."} -->
<p></p>
<!-- /wp:paragraph -->

<!-- wp:columns -->
<div class="wp-block-columns"><!-- wp:column -->
<div class="wp-block-column"><!-- wp:image -->
<figure class="wp-block-image"><img alt=""/></figure>
<!-- /wp:image --></div>
<!-- /wp:column -->

<!-- wp:column -->
<div class="wp-block-column"><!-- wp:heading {"placeholder":"Name ..."} -->
<h2></h2>
<!-- /wp:heading -->

<!-- wp:paragraph {"placeholder":"Phone ..."} -->
<p></p>
<!-- /wp:paragraph --></div>
<!-- /wp:column --></div>
<!-- /wp:columns -->',
		)
	);
}
add_action( 'init', 'cpt_register_block_pattern' );

Erstellung eines Templates für neue Einträge

Wenn man einen neuen CPT registriert, dann kann man auch Standardinhalte definieren, indem man das template Argument verwendet und darin in einem mehrdimensionalen Array ein Template definiert:

function cpt_register_post_type() {
	register_post_type(
		'my_cpt',
		array(
			'label'                 => __( 'Custom Post Type', 'my-cpt' ),
			'supports'              => array( 'title', 'editor' ),
			'public'                => true,
			'show_ui'               => true,
			// ... other settings
			'has_archive'           => true,
			'show_in_rest'          => true,
			'template'              => array(
				array(
					'core/paragraph',
					array(
						'placeholder' => __( 'Custom Post Type ...', 'my-cpt' ),
					),
				),
				array(
					'core/columns',
					array(),
					array(
						array(
							'core/column',
							array(),
							array(
								array(
									'core/image',
								),
							),
						),
						array(
							'core/column',
							array(),
							array(
								array(
									'core/heading',
									array(
										'level'       => 2,
										'placeholder' => __( 'Name ...', 'my-cpt' ),
									),
								),
								array(
									'core/paragraph',
									array(
										'placeholder' => __( 'Phone ...', 'my-cpt' ),
									),
								),
							),
						),
					),
				),
			),
		)
	);
}
add_action( 'init', 'cpt_register_post_type' );

Wie ihr schon an diesem kleinen Beispiel erkennen könnt, kann ein solches Array schnell sehr komplex, unleserlich und schwer zu pflegen werden. Ihr müsstet außerdem das HTML des Block Pattern in das PHP Array Format konvertieren. Jede Änderung am Pattern würde also eine doppelte Anpassung notwendig machen, bei der man schnell mal einen Fehler macht.

Block Patterns und Custom-Post-Types kombinieren

Da mir die Lösung mit dem PHP Array nicht wirklich gefallen hat (das Template in dem Projekt war noch viel komplexer als das aus dem Beispiel oben), habe ich zuerst das folgende versucht:

// ...
'template'              => array(
	array(
		'my-cpt/my-cpt-pattern',
	),
),
// ...

Ich hatte gedacht, dass ich vielleicht einfach ein Block Pattern im template verwenden kann und nicht nur Blöcke. Aber leider hat das nicht funktioniert. Bei der Suche nach einer Lösung bin ich auf verschiedene GitHub issues gestoßen. Dort habe ich den core/pattern Block gefunden, mit dem es dann ganz einfach war:

'template'              => array(
	array(
		'core/pattern',
		array(
			'slug' => 'my-cpt/my-cpt-pattern',
		),
	),
),

Leider ist der core/pattern Block aber noch nicht in WordPress 5.8 vorhanden. Man kann ihn aber einsetzen, indem man das Gutenberg Plugin installiert und aktiviert. Ich hoffe aber sehr, dass es mit WordPress 5.9 verfügbar sein wird, was nächsten Monat erwartet wird.

Fazit

Block Patterns und Templates sind bei der Arbeit mit Custom-Post-Types wirklich hilfreich. Wann man beide mit dem core/pattern Block kombiniert, dann kann es die Arbeit wirklich sehr erleichtern.

PHP Funktionen in WordPress debuggen

Wenn man ein Plugin oder Theme entwickelt, dann möchte man manchmal eine spezielle Funktion debuggen. Diese Funktion wird eventuell in einem größeren Kontext verwendet, was das Debuggen recht schwer und/oder langsam macht. Schauen wir uns hierzu das folgende Beispiel für eine Callback-Funktion eines Shortcode (oder „Server-Side-Rendered“ Blocks an):

function my_shortcode_callback( $atts ) {
	$atts = shortcode_atts( array(
		'post_id' => '',
		// ...
	), $atts, 'my_shortcode' );

	$result = my_function_to_debug( $atts );

	return sprintf(
		__( 'Posted on %1$s by %2$s', 'my-textdomain' ),
		date_i18n( get_option( 'date_format' ), $result['date'] ),
		get_the_author_meta( 'display_name', $result['author'] )
	);
}
add_shortcode( 'my_shortcode', 'my_shortcode_callback' );

In diesem Callback rufen wir die Funktion auf, die wir debuggen wollen. Diese Funktion kann sehr einfach, aber auch sehr komplex sein. Nehmen wir einfach einmal diese hier als Beispiel:

function my_function_to_debug( $atts ) {
	$post = get_post( (int) $atts['post_id'] );
	// Maybe do something with the post and create some result
	// ...

	// Dummy result: select two values from the post
	$result = [
		'date'   => $post->post_date,
		'author' => $post->post_author,
	];

	return $result;
}

Wenn man das auf den Weg würde man nun eine Seite oder einen Beitrag anlegen und dort den Shortcode einbinden, damit die Funktion, die wir debuggen wollen, aufgerufen wird. Nehmen wir mal an ihr wollt dabei den Aufruf der Funktion mit verschiedenen Parametern testen. Dann müsstet ihr mehrere Shortcodes in Seite oder Beitrag einfügen oder sogar mehrere Seiten/Beiträge anlegen.

Debuggen mit der WP-CLI

Eine Methode, sich ich in einem solchen Fall gerne verwende, ist die Nutzung der WP-CLI. Hier kann man beliebigen Code mit wp shell Befehl „in einer WordPress-Umgebung“ ausführen lassen. So könnte das aussehen:

$ wp shell
wp> my_function_to_debug( [ 'post_id' => 1 ] );
=> array(2) {
  ["date"]=>
  string(19) "2021-09-26 21:57:32"
  ["author"]=>
  string(1) "1"
}

Nach dem Starten der Shell rufen wir einfach die Funktion auf und übergeben direkt die passenden Argumente, die wir für unseren Test benötigen. Da die Funktion ein Array zurückgibt, erhalten wir ein Ergebnis in Form einer var_dump Visualisierung.

In gleicher Weise können wir natürlich auch die Callback-Funktion des Shortcodes selbst, aber auch jede andere Funktion eines Plugins/Themes oder des WordPress Core ausführen:

$ wp shell
wp> my_shortcode_callback( [ 'post_id' => 1 ] );
=> string(34) "Posted on 5 December 2021 by wapuu"

Der Vorteil des Debuggings mit dieser Technik ist, dass hierbei keine (Frontend) Seite gerendert werden muss. Es lädt stattdessen „nur“ die WordPress-Umgebung und führt die Funktion direkt aus. Das ist also sehr viel einfacher und schneller. Es muss eben auch keine Seite erstellt und der Shortcode darin eingefügt werden.

Debugging der Funktion mit einem AJAX Callback

Das einzige Problem an diesem Ansatz ist, dass es nicht (einfach) möglich ist, beim Debugging auch XDEBUG zu verwenden, da XDEBUG in der Regel nur in Verbindung mit einem HTTP-Request funktioniert. Ihr könntet zwar einen solchen Request mit curl auch in einem Terminal ausführen, aber dann müsstet ihr noch immer eine Seite oder einen Beitrag erstellen und dort den Shortode mit den Parametern einfügen. Stattdessen könnt ihr einen AJAX-Callback „missbrauchen“, um die Funktion in einem HTTP-Request auszuführen:

function my_ajax_callback() {
	$result = my_function_to_debug( [ 'post_id' => 1 ] );
	var_dump( $result );
}
add_action( 'wp_ajax_my_ajax_action', 'my_ajax_callback' );

Wenn ihr nun einen HTTP-Request auf die URL /wp-admin/admin-ajax.php?action=my_ajax_action macht (entweder im Browser oder im Terminal), dann erhaltet ihr die gleiche var_dump Ausgabe. Dieses Mal könnt ihr dann Breakpoint für XDEBUG für das Debugging setzen.

Fazit

Das Debugging von Funktionen benötigt nicht immer ein komplexes Anlegen von Seiten/Beiträgen, um die zu testende Funktion aufzurufen. Mit Hilfe der hervorragenden WP-CLI oder einem AJAX-Callback könnt ihr dies viel einfacher und schneller erledigen.

Video-Dokumentation einer WordPress-Installation im Backend

Während ich letzte Woche an einer Website gearbeitet habe ist mir etwas aufgefallen, dass ich gerne mich euch teilen möchte. Auf dem Dashboard habe ich ein Widget entdeckt, in das ein YouTube-Video einer aufgezeichneten Schulung eingebunden war.

Hinzufügen eines Videos zum Dashboard

Die Lösung auf dieser Seite war ein eigenes Dashboard-Widgets. Die URL zum Video wurde hierbei auf einer Einstellungsseite der Agentur eingetragen, auf der auch viele andere Einstellungen für die vielen Features der Installation gesteuert werden konnten.

Ich fand dieses Video eine super Idee und mein erst Impuls war es natürlich, selbst so etwas zu programmieren. Aber „leider“ gibt es ja für fast alles in WordPress bereits von jemand anderem ein Plugin. Statt also ein eigenes Plugin zu programmieren habe ich potenzielle Plugins für eine solche Funktionalität gefunden. Das einfachste ist Video Dashboard von Brian Johnson. Hier kann man bis zu 50 Videos von YouTube oder Vimeo einstellen und auch festlegen, welche Rolle jemand haben muss, um die Videos sehen zu können. Ein ähnliches Plugin ist Videos on Admin Dashboard. Hier können aber nur zwei Videos von YouTube oder Vimeo eingestellt werden, ebenfalls mit einer Steuerung der Rolle. Interessanterweise verwendet dieses Plugin wohl die gleichen Namen für die Einstellungen, denn hatte man beim anderen Plugin bereits Video-URLs hinterlegt, dann werden diese auch in diesem Plugin verwendet.

Fazit

Ein Video auf dem Dashboard zu platzieren ist eine ziemlich clevere Art den Menschen, die eine WordPress-Installation verwenden müssen, bei der Arbeit zu helfen. Wenn ihr dabei eine Plattform wie YouTube oder Vimeo nutzt, dann solltet ihr bei (individuellen) Videos sicherstellen, dass diese „nicht gelistet“ sind oder sogar nur auch einer bestimmten URL angesehen werden können (z.B. mit Vimeo Pro).

Wie bietet ihr Dokumentationen für WordPress-Installationen an? Verwendet ihr auch (gehostete) Video, ein anderes Dokumentations-Plugin oder ein externes Dokumentations-Tool?

Den „Registrieren“ Link überschreiben

In einem früheren Blogbeitrag habe ich euch berichtet, wie ich Gravity Forms für die Benutzerregistrierung verwendet habe. Dies wurde auf einer statischen Seite anstelle der normalen WordPress Registrierungsseite umgesetzt. Wenn ihr also möchtet, dass sich Benutzer auf einer solchen Seite registrieren, dann solltet ihr auch von vielen Stellen aus dorthin verlinken. In diesem Blogbeitrag möchte ich euch zeigen, wie ihr einen Link zu dieser Seite von der Login-Seite aus setzen könnt.

Die WordPress Login-Seite

Unter „Einstellungen › Allgemein“ könnt ihr bei „Mitgliedschaft“ die Option „Jeder kann sich registrieren“ aktivieren. Damit findet dann jeder auf der Login-Seite einen Link zur normalen Regstrieungsseite:

Die WordPress Login-Seite

Wenn ihr lediglich die URL für diesen Link überschreiben möchtet, dann könnt ihr einen Filter verwenden. Dieser erhält als Übergabe den HTML Code für den Link, den ihr dann wie folgt überschreiben könnt:

function custom_register_link( $link ) {
	return sprintf(
		'<a href="%s">%s</a>',
		esc_url( '/register/' ),
		esc_html__( 'Register' )
	);
}
add_filter( 'register', 'custom_register_link' );

Dies setzt einen Link auf die statische URL /register/ unter Verwendung des normalen Linktexts.

Dieser Ansatz funktioniert nur dann, wenn ihr auch zuvor die Registrierung aktiviert habt. Aber hierdurch wird auch das normale Registrierungsformular verfügbar. Falls ihr die Registrierung nicht aktiviert habt, könnt ihr dennoch mit Gravity Forms (und vermutlich auch mit anderen Plugins) Benutzer registrieren. Da aber der „Registrieren“ komplett verschwindet, könnt ihr dann auch nicht mehr einfach die URL überschreiben. Stattdessen könnt ihr aber mit dem folgenden Code einen zusätzlichen Link an einer anderen Stelle einfügen:

function custom_login_site_html_link( $home_link ) {
	$register_link = sprintf(
		'<a href="%s">%s</a>',
		esc_url( '/register/' ),
		esc_html__( 'Register' )
	);

	return sprintf(
		'%s<br /><br />%s',
		$register_link,
		$home_link
	);
}
add_filter( 'login_site_html_link', 'custom_login_site_html_link' );

Dieser Filter hängt sich normalerweise in den „← Zurück zu <Seitenname>“ link. Dies ist die einzige Stelle, an der wir unseren eigenen Link einfügen können. Das Ergebnis sieht dann in etwa wie folgt aus:

Die WordPress Login-Seitemit eigenem „Registrieren“ Link

Durch diese Platzierung ist der Link vielleicht sogar besser sichtbar als an seiner ursprünglichen Stelle neben dem „Passwort vergessen?“ Link.

Fazit

Eine Selbstregistrierung kann wirklich vorteilhaft sein. Wenn ihr eine solche umsetzt, dann solltet ihr aber sicherstellen, dass ihr immer auf dieses eigene Formular verlinkt.

Den „Illegal mix of collations“ WordPress-Datenbank-Fehler beheben

Wenn ich Projekte aktualisiere, dann schaue ich mir auch immer die Logfiles an. In einem Projekt das ich warte habe ich dabei den folgenden Fehler im Logfile gefunden, der mit zuvor noch nie untergekommen war:

WordPress-Datenbank-Fehler Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8mb4_unicode_520_ci,COERCIBLE) for operation 'like' ...

Da WordPress nicht besonders strikt ist mit den Kollationen könnte auch in euer WordPress Website mehr als eine Kollation für die verschiedenen Tabellen verwendet werden. In diesem Project waren es sechs Kollationen!

Konvertieren der Kollationen

Um diesen Fehler zu beheben müssen wir alle Tabellen auf kompatible Kollationen konvertieren. Dabei ist es natürlich am besten, wenn wir für alle Tabellen die gleiche Kollation verwenden. Mit WordPress 4.2.0 wurde utf8mb4 der neue Standard. Alle Datenbank-Tabelle die danach erstellt werden, haben dann eine der Varianten davon. Für unsere neue Kollation verwenden wir also eine davon.

Datenbank sichern!

STOPP! Bevor wir anfangen irgendetwas an der Datenbank zu ändern, machen wir erst einmal ein Backup. Das Ändern der Kollation sollte eigentlich kein Problem darstellen, aber für den Fall der Fälle macht man am besten immer ein Backup. Ihr könnt dabei das Tool eurer Wahl verwenden. Ich verwende in der Regel die WP-CLI dafür:

wp db export

Jetzt können wir gefahrlos die Änderungen machen und im Notfall wieder das Backup einspielen.

Ändern der Kollation einer Tabelle

Wenn man etwas an einer Datenbank oder einer Tabelle ändern möchte, dann verwendet man das ALTER Statement, welches wir auch hier wie folgt verwenden:

ALTER DATABASE wp_project_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;

Dieses erste Statement ändert wert einmal die Kollation der gesamten Datenbank. Wenn ihr also danach mit einem Datenbank-Tool eine Tabelle erstellt, dann wird es diese Kollation verwenden. Das Statement ändert aber nichts an den Tabellen der Datenbank. Hierzu müsste ihr die Tabellen wie folgt verändern:

ALTER TABLE wp_project_name.wp_posts CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;

Dieses eine Statement würde die Tabelle wp_posts anpassen. Wiederholt das also nun für alle anderen Tabellen in euer Datenbank.

Aktualisierung einer Datenbank mit vielen Tabellen

In dem Projekt mit dem beschriebenen Fehler gab es 12 Sites mit 344 Tabellen! Da macht es natürlich keinen Spaß jede Tabelle einzeln zu aktualisieren. Glücklicherweise konnte ich einen kleinen Trick finden, der mir alle ALTER TABLE Statements für alle Tabellen generiert hat:

SELECT CONCAT("ALTER TABLE ",TABLE_SCHEMA,".",TABLE_NAME," CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;") 
FROM information_schema.TABLES
WHERE TABLE_SCHEMA="wp_project_name";

Setzt einfach in der letzten Zeile euren Datenbanknamen ein und führt den Befehl aus. Dann kopiert ihr euch die „generierten“ Queries und führt diese aus. Dabei könntet ihr eventuell einen Fehler wie den folgenden erhalten:

Invalid default value for 'comment_date'

In diesem Fall könntet ihr dann den sql_mode temporär anpassen, indem ihr vor den ganzen ALTER TABLE Statements die folgende Zeile einfügt:

SET sql_mode = '';

Nachdem ihr alle Statements ausgeführt habt sollten nun alle Tabellen die gleiche Kollation habe. In diesem Beispiel verwende ich die Kollation utf8mb4_unicode_520_ci, auf eurem Server könnte es aber eine andere Variante sein.

Aktualisierung der Kollationen mit einem Plugin

Beim Schreiben dieses Beitrags bin ich über das Plugin Database Collation Fix gestoplert. Wenn ihr also keinen Zugriff auf eine Datenbank-Tool habt oder es such nicht zutraut, dann kann euch das Plugin dabei helfen. Der einzige „Nachteil“ ist, dass hier Tabellen nur in die Kollation utf8mb4_unicode_ci (oder eine von drei Alternativen) nicht aber in die neuere utf8mb4_unicode_520_ci Kollation konvertiert wird. Das sollte aber in der Regel kein Problem darstellen.

Fazit

Auch nach vielen Jahren Arbeit mit WordPress gibt es noch immer Fehler, die mir zuvor noch nicht untergekommen sind. In diesem Fall ist es nicht einmal ein spezifisches WordPress-Problem, aber da WordPress nicht sehr streng beim Umgang mit Kollationen ist, kann das Problem wohl häufiger mal auftreten. Vor allem dann, wenn die Installation schon etwas älter ist (beispielsweise vor Version 4.2.0 installiert). Wenn ihr also einen ähnlichen Fehler bei euch im Logfile findet, dann habt ihr jetzt hoffentlich eine Idee bekommen, wie ihr es lösen könnt. Und falls ihr schon lange nicht mehr in die Logfiles gesehen habt, dann ist diese Blogbeitrag vielleicht eine Erinnerung, das mal wieder zu tun.

Dynamische Benutzernamen mit dem Gravity Forms User Registration Add-On in einer Multisite erzeugen

Wie ich schon in einigen frühen Blogbeiträgen erwähnt habe, nutze ich sehr häufig Gravity Forms bei der Erstellung von Formularen. Hierzu gibt es auch einige tolle Add-Ons. Eines davon ist die User Registation Erweiterung. Damit ist es möglich nach dem Absenden des Formulars ein neues Benutzerkonto zu erstellen.

Das „username“ Feld

Ihr erstellt im Grunde erst einmal ein ganz normales Formular. Darin fragt ihr dann einige notwendig Felder ab, die ihr für neue Benutzer benötigt. Das absolute Minimum sollte hierbei wohl die E-Mail-Adresse sein, damit neue Benutzer auch ihre Zugänge bestätigen können. Ein anders Feld könnte der Benutzername sein. Das Add-On bietet hierfür auch ein eigenes Feld ein. Wenn also neue Benutzer ihren Benutzernamen selbst wählen können sollen, dass wäre dies das perfekte Feld.

Verwendung des „email“ Feldes

Da es WordPress erlaubt sich mit Benutzername oder alternativ mit E-Mail-Adresse anzumelden, müssten die Benutzer noch nicht einmal ihre Benutzernamen kennen. Wenn ihr also einen „Feed“ zum Erstellen neuer Benutzer erstellt, könnt ihr auch einfach das E-Mail-Feld verwenden. Es sei denn, ihr erstellt neue Zugänge zu einer Multisite.

Einen dynamischen Benutzernamen aus anderen Feldern erstellen

In einer Multisite-Installation dürfen Benutzernamen nur aus Kleinbuchstaben und Zahlen bestehen. Der Grund dafür ist, dass dieser Benutzername verwendet werden „kann“, um eine Unterseite pro Benutzer zu erstellen. Selbst wenn ihr keine Seite pro Benutzer erstellen wollt (was das Add-On auch erledigen kann), gilt die Einschränkung für die erlaubten Zeichen dennoch. Wie gehen wir also damit um, ohne die Benutzer zu bitten, sich selbst einen Benutzernamen auszusuchen? Ich könnt einfach einen Benutzernamen dynamisch aus anderen Feldern erzeugen.

Verwendung der Felder für Vor- und Nachnamen

Auf vielen Plattformen wird der Benutzername automatisch aus der Kombination von Vor- und Nachname erstellt. Wir können daher einen Filter verwenden, um einen solchen Benutzernamen zu erstellen. Da dieser Benutzername aber noch immer ungültige Zeichen enthalten könnte, müssen wir diesen Namen noch „sanitizen“. Glücklicherweise bietet WordPress genau hierfür eine Funktion an. Und da zwei Personen die gleiche Vor- und Nachnamen haben können, müssen wir auch noch einen Weg finden, mit diesem Problem umzugehen. Aber fangen wir erst einmal mit der Callback-Funktion zu dem Gravity Forms Hook an:

function gf_ms_uf_set_username( $username, $feed, $form, $entry ) {
        // Get first and last name from the form submission.
        $first_name = rgar( $entry, rgars( $feed, 'meta/first_name' ) );
        $last_name  = rgar( $entry, rgars( $feed, 'meta/last_name' ) );

        // Generate a new username making it compatible with multisite constraints.
        $new_username = gf_ms_get_unique_username( sanitize_user( $first_name . $last_name ) );

        if ( ! empty ( $new_username ) ) {
                $username = $new_username;
        }

        return $username;
}
add_filter( 'gform_username', 'gf_ms_uf_set_username', 10, 4 );

Wir verwenden hier den Hook gform_username, der für das spezielle Username Feld verwendet wird. In der Callback-Funktion lesen wir die Werte aus den Feldern für Vor- und Nachname aus und übergeben diese an eine andere Funktion, die dann einen einmaligen Benutzernamen generiert. Erhalten wir einen solchen neuen Namen, geben wir diesen zurück.

Erstellen eines eindeutigen Benutzernamens

Wie erstellen wir nun einen Benutzernamen, der noch nicht existiert? Nun, wie verwenden hierzu eine Funktion, die ähnlich funktioniert wie die Funktionen, mit denen WordPress eindeutige Permalink für Beiträge/Seiten/Terms mit gleichen Namen erzeugt. Wir verwenden einen „Zähler-Präfix“, der so lange hochzählt, bis der Name einmalig ist:

function gf_ms_get_unique_username( $username ) {
        $number            = 2;
        $original_username = $username;

        while ( username_exists( $username ) || gf_ms_signup_exists( $username ) ) {
                $username = $original_username . $number ++;
        }

        return $username;
}

function gf_ms_signup_exists( $username ) {
        global $wpdb;

        return $wpdb->get_row(
            $wpdb->prepare(
                "SELECT * FROM $wpdb->signups WHERE user_login = %s",
                $username
            )
        );
}

In der while-Schleife prüfen wird, ob der Benutzename bereits existiert und weiterhin, ob eine Registrierung existiert, die den Namen verwendet, die aber noch nicht über den Bestätigungslink aus der E-Mail aktiviert wurde. Dies prüfen wir mit einer weiteren Hilfsfunktion, die ähnliche zu der aus dem Core aussieht.

Fazit

WordPress bietet selbst einen Weg an, um neue Registrierungen zu ermöglich – für eine Single- oder Multisite. Wenn ihr aber für die neuen Benutzer auch noch weitere Informationen abfragen wollt, dann kann ein Add-On wie das für Gravity Forms sehr hilfreich sein, um den Registrierungsprozess zu vereinfachen. Die Registrierung für eine Multisite ist dabei etwas schwierigen, aber mit ein paar Hilfsfunktionen ebenfalls möglich. Selbstverständlich findet ihr den Code zu diesem Beitrag auch wieder in einem GIST und könnt ihn dort als ZIP-Datei runterladen und als Plugin installieren.