Blöcke für bestimme Post-Types deaktivieren

In dem Projekt, in dem ich WordPress als Backend für eine native App einsetze, habe ich zwei Custom-Post-Type implementiert. Für beide soll nur eine eingeschränkte Auswahl an Blöcken verfügbar sein. Das hat einfach damit zu tun, dass nicht alle Arten von Inhalten in einer nativen App angezeigt/verwendet werden können.

Erlaubt Blöcke filtern

Wir können den Filter allowed_block_types nutzen, um die verwendbaren Blöcke einzuschränken oder um alle Blöcke zu erlauben/verbieten. Wenn ihr also für einen spezifischen Post-Type erlauben möchtet, könnt ihr den Filter wie folgt verwenden:

function cpt_allowed_blocks( $allowed_block_types, $post ) {
	if ( 'my_post_type' === $post->post_type ) {
		return array(
			'core/paragraph',
			'core/list',
			'core/quote',
			'core/code',
			'core/table',
			'core/image',
			'core/video',
			'core/audio',
		);
	}

	return $allowed_block_types;

}
add_action( 'allowed_block_types', 'cpt_allowed_blocks', 10, 2 );

In der Callback-Funktion überprüfen wir zuerst, ob gerade unser Custom-Post-Type bearbeitet wird. Wenn dem so ist, dann liefern wir ein Array mit genau den Blöcken zurück, die verwendet werden dürfen. Ansonsten liefern wir Originalwert unverändert zurück.

Der Originalwert kann entweder ein Array oder ein boolscher Wert sein. Wenn hier true zurück geliefert wird, sind alle Blöcke erlaubt, bei false sind keine Blöcke erlaubt.

Bonus: Ein Block-Template für den Post-Type setzen

Wenn ihr die Auswahl der Blöcke einschränkt, dann möchtet ihr damit vermutlich ein bestimmtes Layout in eurem Post-Type erreichen. Ihr könnt das vereinfachen, indem ich ein paar Blöcke standardmäßig hinzufügt, wenn ein neuer Eintrag im Post-Type erstellt wird. Das Template wird in der Funktion zur Registrierung eines Post-Types angegeben:

function cpt_register_post_type() {
	register_post_type(
		'my_post_type',
		array(
			'label'                 => __( 'My Post Type', 'text_domain' ),
			'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' => __( 'Lorem ...', 'text_domain' ),
					),
				),
				array(
					'core/image',
				),
			),
		)
	);
}
add_action( 'init', 'cpt_register_post_type' );

Mit dem template Parameter könnt ihr mehrere Blöcke definieren, die bei jedem neuen Eintrag eingefügt werden. Jeder Block wird in einem eigenen Array definiert. Für viele Blöcke können darin zusätzlich Eigenschaften gesetzt werden. In diesem Beispiel wird für den Absatz-Block ein Platzhaltertext (nicht der Inhalt) gesetzt. Der zweite Block ist ein Bild-Block, ohne Eigenschaften. Er sieht genau so aus, wie direkt nach dem Hinzufügen der Block, er befindet sich also im „Bearbeitungsmodus“:

Fazit

Wenn ihr mit Custom-Post-Types arbeitet, dann könnt ihr recht einfach einschränken, welche Blöcke verwendet werden dürfen. In Kombination mit einem Block-Template für neue Einträge könnt ihr die Erstellung von einheitlichen Einträgen erheblich vereinfachen.

Ändern der Standardwerte für Absender-Name und E-Mail-Adresse

In WordPress werden an vielen verschiedenen Orten E-Mails versendet. Meistens werden sie von Plugins versendet. In den meisten davon kann man den Absender-Name („From Name“) und die E-Mail-Adresse („From Mail“) selbst festlegen. Einige E-Mails werden aber auch vom WordPress Core verwendet. Eine solche E-Mail wäre etwa die zum Zurücksetzen des Passworts. Aber auch andere Plugins schicken Mails an Nutzer oder Administratoren.

Ändern der Absender-Standardwerte

Wenn eine E-Mail versendet wird und dabei der Name und die Adresse nicht explizit gesetzt werden, dann wird immer „WordPress“ für den Namen und „wordpress@deine-domain.tld“ verwendet. Leider gibt es im Dashboard keine Einstellung um diese Werte zu ändern.

Überschreiben der Werte mit einem Filter

Es gibt zwei Filter, mit denen die Standardwerte für den Absendernamen und die E-Mail-Adresse geändert werden können. Fügt einfach folgendes in ein (MU-)Plugin ein und aktiviert es:

// Change the "from name"
function wp_email_set_from_name( $from_name ) {
	return 'Dein Name';
}
add_filter( 'wp_mail_from_name', 'wp_email_set_from_name' );
// Change the "from email"
function wp_email_set_from_email( $from_email ) {
	return 'dein-name@deine-domain.tld';
}
add_filter( 'wp_mail_from', 'wp_email_set_from_email' );

Das überschreibt die beiden Werte. Aber es überschreibt sie für alle E-Mails. Vermutlich nicht das, was ihr wollt. Leider werden die beiden Filter erst dann aufgerufen, wenn die Standardwerte schon gesetzt wurden. Man kann also nicht einfach prüfen, ob explizite Werte zum Senden der E-Mail verwendet wurden. Daher prüfen wir stattdessen, ob die Werte noch immer der Standardwerten entsprechen und ändern sie nur in diesem Fall:

// Change the default "from name"
function wp_email_set_from_name( $from_name ) {
	if ( 'WordPress' === $from_name ) {
		return 'Dein Name';
	}

	return $from_name;
}
add_filter( 'wp_mail_from_name', 'wp_email_set_from_name' );
// Change the default "from email"
function wp_email_set_from_email( $from_email ) {
	if ( false !== strpos( $from_email, 'wordpress@' ) ) {
		return 'dein-name@deine-domain.tld';
	}

	return $from_email;
}
add_filter( 'wp_mail_from', 'wp_email_set_from_email' );

Dies sollte also nur dann neue Werte setzen, wenn sie noch immer den Standardwerten entsprechen. Ihr könnt aber weiterhin einen anderen Namen oder eine andere E-Mail-Adressen, zum Beispiel in einem Formular-Plugin.

Fazit

Das Überschreiben der Standardwerte für den Absender-Namen und die E-Mail-Adresse kann mit Filtern umgesetzt werden. Ihr solltet dabei aber aufpassen, dass ihr es nur in den Fällen tut, in denen die Werte nicht zuvor auf einen anderen Wert schon gesetzt wurden.

Benutzer in WordPress mit der REST API erstellen

In einem aktuellen Projekt verwenden wir WordPress als Backend für eine native Mobile App. Die App selbst wird von einer anderen Agentur entwickelt. Ich bin für den WordPress-Teil zuständig. Der Inhalt der App wird über mehrere Custom-Post-Types und Custom-Taxonomies sowie einiger spezieller Blocks erstellt, für eine komfortable Verwaltung. Die App kann ohne Registrierung verwendet werden. Für erweiterte Funktionen, wie etwas die Synchronisation der Ergebnisse mit mehreren Geräten oder der Vergleich mit anderen, wird eine Registrierung benötigt.

Der Server für den Empfang von Requests vorbereiten

Um Anfragen von der App an den Server machen zu können, müssen einige Response-Header geschickt werden, damit diese akzeptiert werden. Die gilt besonders für die iOS-Version der App. Ich habe zuerst versucht die Header über die Server-Konfiguration umzusetzen, nur um dann festzustellen, dass einige davon zusätzlich noch von WordPress gesetzt wurden. Das Resultat waren dann doppelte Header mit gleichen Namen aber unterschiedlichen Werten. Nach ein wenig Debugging konnte ich ein paar Hooks finden, die ich verwenden konnte:

function app_rest_headers_allowed_cors_headers( $allow_headers ) {
	return array(
		'Origin',
		'Content-Type',
		'X-Auth-Token',
		'Accept',
		'Authorization',
		'X-Request-With',
		'Access-Control-Request-Method',
		'Access-Control-Request-Headers',
	);
}
add_filter( 'rest_allowed_cors_headers', 'app_rest_headers_allowed_cors_headers' );

Bei einem anderen Hook gab es leider keinen Filter, daher musste ich hier direkt die header() Funktion aufrufen:

function app_rest_headers_pre_serve_request( $value ) {
	header( 'Access-Control-Allow-Origin: *', true );

	return $value;
}
add_filter( 'rest_pre_serve_request', 'app_rest_headers_pre_serve_request', 11 );

Nach dieser kleinen Vorbereitung können wir versuchen über den Users-Endpoint zu erstellen. Das wird aber nicht funktionieren. Wieso nicht? Nun, ganz einfach aus dem Grund, dass man nicht einfach über die WordPress REST API einen Benutzer erstellen kann, ohne sich vorher zu autorisieren. Wenn das möglich wäre könnte ja sonst jemand auf einer beliebigen WordPress-Seite Benutzer erstellen.

Einen Nutzer mit der REST API authentifizieren

Wie müssen uns also an der REST API authentifizieren, aber wie machen wir das? Es gibt hier verschiedene Möglichkeiten. Eine neue Möglichkeit, die als erstes im Core langen wird und kurz vor der Aufnahme steht sind die Application Password.

Es gibt schon einen Vorschlag für die Integration des Feature-Projects in WordPress 5.6. Wenn ihr aber jetzt schon diese Möglichkeit testen wollt, könnt ihr einfach das Plugin Application Passwords installieren.

Einen Benutzer für die Benutzerverwaltung erstellen

Normalerweise können nur Administratoren die Benutzer verwalten. Aber ihr möchtet vermutlich nicht unbedingt einer App sämtliche Berechtigungen geben, die ein Admin auf einer WordPress-Seite hat. Daher macht es Sinn, einen speziellen Benutzer zu erstellen, der nur die Berechtigungen hat, die für die Benutzerverwaltung benötigt werden. Ihr könnt das mit einem Plugin wie etwa Members machen, oder aber ihr erstellt die Rolle und den Benutzer mit PHP Code oder ihr verwendet die WP-CLI:

wp role create app App --clone=subscriber
wp cap add app create_users
wp user create app-rest-user app-rest-user@example.com --role=app

Der Benutzer braucht mindestens die Berechtigung create_users, um Benutzer anlegen zu können. Wenn ihr zusätzlich die read Berechtigung setzt, könnt ihr euch auch mit diesem Benutzer anmelden und das Application Password setzen (daher wird in dem Beispiel oben auch die Rolle subscriber geklont). Alternativ könnt ihr als Admin das Application Password für einen Benutzer setzen.

Das Application Passwort für den neuen Benutzer erstellen

Nachdem ihr den Nutzer erstellt habt, könnr ihr euch mit diesem einloggen und auf die Profileinstellungen gehen (oder eben das Profil des Nutzers mit dem Admin bearbeiten). Hier findet ihr ein neues Feld, in dem ihr Application Passwords erstellen könnt. Wählt hier einen Namen aus und klickt auf „Add new“ (zum Zeitpunkt der Veröffentlichung des Beitrags gab es noch keine Übersetzung für das Plugin bzw. die Core-Funktionalität):

Daher öffnet sich ein Modal mit dem generierten Application Password. Ihr müsst dieses Passwort hier kopieren, da es nach dem Schließen des Modal nicht mehr als Klartext angezeigt werden kann.

Damit ist jetzt alles vorbereitet um einen Benutzer über einen Request an die REST API zu erstellen.

Deinen ersten Benutzer erstellen

Je nachdem welches System ihr verwendet, um Requests an die WordPress REST API zu schicken, sieht der Workflow hier anders aus. Daher zeige ich es heir am Beispiel eines curl Requests über die Kommandozeile:

curl --user "app-rest-user:younfj4FX6nnDGuv9EwRkDrK" \
     -X POST \
     -H "Content-Type: application/json" \
     -d '{"username":"jane","password":"secret","email":"jane@example.com"}' \
     http://example.com/wp-json/wp/v2/users

Wenn ihr zuvor alles richtig eingerichtet habt, dann solltet ihr eine JSON-Response mit den Daten zum neuen Benutzer erhalten.

Fazit

Die Verwaltung von Benutzern ist nach etwas Vorbereitung und (aktuell) noch externer Plugins möglich. Es wird durch das neue Applications Passwords Core-Feature aber um einiges leichter. In gleicher Weise könnt ihr dann natürlich auch andere REST API Requests machen, die einen autorisierten Benutzer erfordern. Für eine erhöhte Sicherheit solltet ihr hierzu aber immer einen speziellen Benutzer erstellen (es sei denn, ihr wollte Inhalte für einen bestehenden Benutzer erstellen und zuweisen).

Disclaimer

Seit fast genau vier Jahren versuche ich all meine Beiträge geschlechtsneutral zu schreiben. Das ist mir bisher auch recht gut gelungen (auch wenn ich sicher doch mal aus Versehen etwas übersehen habe).

Im Englischen ist es bei Personenbezeichnungen auch recht einfach, da es hier nur selten eine männliche und weibliche Form gibt. In der deutschen Übersetzung verwende ich einfach statt einer Personenbezeichnung einen andren Begriff. Dadurch ist der Satz meisten genauso einfach lesbar, manchmal sogar besser. Aber beim heutigen Beitrag habe ich mich aber für „Benutzer“ und „Benutzerverwaltung“ entschieden. Ich hätte zwar auch „Zugang“ und „Zugangsverwaltung“ verwenden können, aber damit hätte ich wohl einige von euch sehr verwirrt. Der Terminus im Core ist aktuell eben noch „Benutzer“ und daher musste ich heute mal diese Ausnahme machen. Ich hoffe meine treuen Leserinnen verzeihen es mir 🙂

Einzelne Block-Styles deaktivieren

In meinem letzten Beitrag habe ich euch gezeigt, wie man Seiten-Templates in einem Child-Theme deaktivieren kann. Diese Woche geht es um die Deaktivierung anderer Dinge, die über das Parent-Theme oder ein Plugin kommen können. Es geht um Block-Styles. Damit können verschiedene Stile für einen Block definiert werden, die entweder im Core, im Theme, aber manchmal auch in Plugins zu finden sind.

Deaktivierung über einen „Dequeue-Hook“

Block-Stile werden innerhalb von JavaScript-Dateien definiert. Diese Dateien müssen in die Seite eingebunden werden. Hier können wir ansetzen und die Datei wieder entfernen. Das könnte wie folgt aussehen:

function dibs_dequeue_assets() {
	wp_dequeue_script( 'editorskit-editor' );
}
add_action( 'enqueue_block_editor_assets', 'dibs_dequeue_assets', 11 );

In diesem Beispiel wird die Hauptdatei mit allen JavaScript-Funktionen für den Editor entfernt. Sie enthält also nicht nur Block-Styles, sondern den gesamten JavaScript-Code für das Plugin. Das ist also nur dann eine gute Option, wenn das Plugin mehrere Dateien verwendet und eine davon nur die Registrierung der Block-Styles übernimmt.

Deaktivierung ausgewählter Block-Stile

Wenn ihr also nur bestimmte Styles in backend deaktivieren möchtet, dann müsst ihr ein wenig eigenen JavaScript-Code verwenden. Hierzu laden wir zuerst die Datei mit diesem Code:

function dibs_enqueue_assets() {
	wp_enqueue_script(
		'dibs-remove-block-styles',
		plugins_url( 'remove-block-styles.js', __FILE__ ),
		array( 'wp-blocks', 'wp-dom-ready', 'wp-edit-post' ),
		filemtime( plugin_dir_path( __FILE__ ) . 'remove-block-styles.js' ),
		true
	);
}
add_action( 'enqueue_block_editor_assets', 'dibs_enqueue_assets', 11 );

Die hinzugefügt Datei lädt die Abhängigkeiten zu wp-blocks, wp-dom-ready und wp-edit-post um korrekt zu funktionieren. Nachdem die Datei hinzugefügt wurde, können wir die Block-Styles entfernen:

wp.domReady( function() {
	wp.blocks.unregisterBlockStyle(
		'core/image',
		'editorskit-diagonal'
	);
	wp.blocks.unregisterBlockStyle(
		'core/image',
		'editorskit-inverted-diagonal'
	);
	wp.blocks.unregisterBlockStyle(
		'core/cover',
		'editorskit-diagonal'
	);
	wp.blocks.unregisterBlockStyle(
		'core/cover',
		'editorskit-inverted-diagonal'
	);
} );

Nach dem Laden der Seite wird wp.blocks.unregisterBlockStyle() verwendet, deren erster Parameter den „Slug“ des Blocks angibt, für den wir einen Stil entfernen wollen. Der zweite Parameter ist der „Slug“ des Block-Style. In diesem Beispiel würden wir also zwei Block-Stile von den Blöcken core/image und core/cover entfernen.

Dieser Ansatz ist vermutlich derjenige, den ihr verwenden möchtet, da das Entfernen einer gesamten JavaScript-Datei wie im ersten Beispiel nur selten funktionieren wird. Aber auch, wenn ihr nur einzelne Stile entfernen möchtet, ist dies wohl die bessere Lösung.

Fazit

Falls ein Plugin neue Block-Styles mitbringt, die ihr nicht verwenden möchtet, dann reicht eine kleine JavaScript-Datei aus, um diese zu entfernen. Es ist aber zu beachten, dass dies nur die Auswahl dieser Stile im Backend entfernt. Bereits zuvor hinzugefügt Blöcke in Beiträgen und Seiten haben weiterhin den Stil in Form von CSS-Klassen. Sofern die CSS-Datei auch weiterhin die Anweisungen enthält, wird der Block-Stil weiterhin im Frontend angezeigt. Falls ihr das also ebenfalls deaktivieren wollt, müsst ihr entweder die CSS-Klassen von den alten Blöcken entfernen oder aber die CSS-Eigenschaften im (Child-)Theme entfernen oder überschreiben.

Seiten-Template im Child-Theme deaktivieren oder überschreiben

Vorletzte Woche hat ein Kollege an einem neuen Projekt gearbeitet, bei dem ein Seiten-Template im Parent-Theme defekt war. Es gab ein besseres und sehr ähnliches Template, das stattdessen verwendet werden konnte. Aber es besteht weiterhin die Gefahr, dass jemand das defekte Seiten-Template beim Erstellen einer Seite auswählen würde. Also habe ich mich mal auf die Suche nach einer Lösung begeben, mit der man ein Seiten-Template aus der Auswahl entfernen kann.

Deaktivieren eines Seiten-Templates

In einem Child-Theme kann man ja sehr einfach ein neues Seiten-Template hinzufügen oder ein bestehendes überschreiben, indem man es aus dem Parent-Theme kopiert. Aber wie kann man ein bestehendes Template aus dem Parent-Theme aus der Auswahl entfernen. Glücklicherweise gibt es fast immer einen passenden Hook. Wenn ihr also ein Seiten-Template deaktivieren wollt, dann verwendet diesen Filter:

function child_theme_disable_page_template( $post_templates, $theme, $post, $post_type ) {
	unset( $post_templates['page-templates/tpl-hero-light.php'] );

	return $post_templates;
}
add_filter( 'theme_templates', 'child_theme_disable_page_template', 10, 4 );

Der Filter theme_templates bekommt ein Array aller Templates übergeben mit den relativen Pfaden als Schlüssel und den (übersetzten) Namen als Werten. Es könnte in etwa wie folgt aussehen:

$post_templates = array(
	'page-templates/tpl-fullscreen-light.php'  => 'Fullscreen, light header',
	'page-templates/tpl-fullscreen.php'        => 'Fullscreen',
	'page-templates/tpl-fullwidth-notitle.php' => 'Full Width, no page title',
	'page-templates/tpl-fullwidth.php'         => 'Full Width',
	'page-templates/tpl-hero-light.php'        => 'Hero, light header',
	'page-templates/tpl-hero.php'              => 'Hero',
);

Das Array enthält sowohl die Seiten-Templates aus dem Parent-Theme, als auch die aus dem Child-Theme. Falls beide ein Template mit dem gleichen Pfad haben, ist dieses nur einmal im Array enthalten.

Ersetzen eines Seiten-Templates

Jetzt wisst ihr also, wie ihr verhindern könnt, dass jemand ein Seiten-Template verwendet, das ihr nicht haben möchtet. Aber was ist mir den Seiten, bei denen das falsche Template bereits eingestellt ist? Nun, eine Möglichkeit wäre es, in der Datenbank das „postmeta“ mit dem Schlüssel _wp_page_template mit dem neuen Wert zu ersetzen. Aber vielleicht möchtet ihr den aktuellen Wert in der Datenbank intakt lassen. Dann könnt ihr einen von mehreren Filtern verwenden, um den Pfad zum Template zu überschreiben. Dies ist einer der Filter, den ihr nutzen könnt:

function child_theme_overwrite_page_template( $template ) {
	if ( get_parent_theme_file_path( '/page-templates/tpl-hero-light.php' ) === $template ) {
		return get_theme_file_path( '/page-templates/tpl-hero.php' );
	}

	return $template;
}

add_filter( 'template_include', 'child_theme_overwrite_page_template' );

In diesem Beispiel würde also jede Seite, die das Template page-templates/tpl-hero-light.php aus dem Parent-Theme verwenden würde, stattdessen das Template page-templates/tpl-hero.php aus dem Child-Theme verwenden.

Fazit

Während es sehr einfach ist ein Seiten-Template in einem Child-Theme hinzuzufügen oder zu überschreiben ist es nicht so einfach eines zu deaktivieren. Aber da WordPress normalerweise für jede gewünschte Anpassung einen passenden Filter anbietet, ist es auch nicht wirklich schwer.

Plugins und Themes mit WordPress 5.5 aktualisieren oder zurücksetzen

Die aktuelle WordPress Hauptversion 5.5 wurde Mitte August veröffentlicht. Es gab viele schöne neue Funktionen. Aber eine davon wurde nur in wenigen Beiträgen zur neuen Version erwähnt. Die Möglichkeit ein installiertes Plugin oder Theme durch das Hochladen einer ZIP-Datei zu ersetzen.

Einige bisherige Möglichkeiten, um installierte Plugins oder Themes zu ersetzen

In WordPress ist es wirklich sehr einfach eine Plugin oder Theme auf die neueste Version zu aktualisieren (zumindest für solche, die auf WordPress.org verfügbar sind). Das Zurücksetzen auf eine ältere Version oder das aktualisieren einer Premium-Version ist nicht ganz so einfach.

Mit der WP-CLI

Falls du die WP-CLI verwendest, kannst du den install Befehle für Plugins oder Themes verwenden und dabei eine spezifische Version installieren. Falls das Plugin oder Theme bereits installiert ist, kann man die Installation erzwingen:

wp plugin install gutenberg --version=8.9.0 --force

Dies überschreibt die aktuell installierte Version mit der angegebenen Version. Möglich ist das aber nur für Plugins und Themes aus den WordPress.org Verzeichnissen.

Hochladen einer alten Version mit SFTP/FTPS/FTP

Wenn du keinen SSH-Zugang zum Server hast oder dort die WP-CLI nicht verwenden kannst, dann ist die Übertragung mit einem FTP-Programm eine Alternative. Hierzu löscht man zuerst die aktuelle Version und ersetzt sie dann mit der alten Version. Dies hat aber den Nachteil, dass während der Übertragung der Dateien, was je nach Größe eine Zeit lang dauern kann, die Seite eventuell Fehler produziert. Man kann diese Ausfallzeit ein wenig reduzieren, indem man die alte Version in einen anderen Ordner hochlädt, dann die aktuelle Version löscht und schließlich den zuvor hochgeladenen Ordner umbenennt. Aber diese Weg ist nicht wirklich ideal.

Deaktivieren und Deinstallieren der aktuellen Version

Manche von euch haben jetzt vielleicht die Idee, einfach die aktuelle Version zu deaktivieren und deinstallieren, um anschließend die alte Version zu installieren. Aber das ist sehr gefährlich. Viele Plugins löschen ihre Einstellungen, wenn sie deaktiviert/deinstalliert werden. Manche löschen sogar all ihre Daten. Dieser Weg sollte also vermieden werden.

Ersetzen der aktuellen Version mit der neuen WordPress 5.5 Funktion

Falls ihr eure Seite schon auf WordPress 5.5 aktualisiert habt, könnt ihr den neuen Weg versuchen. Hierzu müsst ihr einfach die alte Version als ZIP-Datei hochladen. Diese habt ihr entweder in einem Backup oder ihr ladet sie aus dem Plugin- oder Theme-Verzeichnis von WordPress.org runter.

Download einer alten Version of eines Plugins

Für Plugins ist das sehr einfach. Hierzu navigiert ihr auf die Plugin-Seite auf WordPress.org und klickt auf den Link „Erweiterte Ansicht“ auf der rechten Seite:

Auf der folgenden Seite scrollt ihr dann ganz ans Ende. Dort findet ihr ein Auswahl von ältere Versionen. Dass sind all die Versionen, die getagged/veröffentlicht wurden:

Wählt hier die gewünschte Version auf und klickt auf den Herunterladen-Button. Ihr erhaltet dann die ZIP-Datei für diese Version. Falls im Auswahlfeld keine älteren Versionen verfügbar sein, dann wurden leider keine explizit veröffentlicht.

Hochladen der alten Version und ersetzen der aktuellen Version

Jetzt könnt ihr die Version hochladen. Das funktioniert genau so wie bei der ersten Installation eines Plugins oder Themes. Navigiert also im Dashboard zu „Plugins | Installieren“ und klickt dort auf den „Plugin hochladen“ Button neben der Überschrift. Auf der nächsten Seite könnt ihr dann die zuvor heruntergeladene Datei auswählen und mit einen Klick auf „Jetzt installieren“ hochladen. Anschließend solltet ihr folgendes sehen:

Auf der Seite seht ihr eine Übersicht zur aktuell installierten und zur hochgeladen Version. Für beide wird euch angezeigt, welche Versionen von WordPress und PHP jeweils erforderlich sind. Wenn ihr fortfahren wollt, klickt einfach auf den „Ersetze bestehendes mit hochgeladenem“ Button.

Fazit

Manchmal sind es die kleinen Änderungen in einer neuen Version, die einen Großen Unterschied machen. Das Zurücksetzen eines Plugins oder Themes war bisher keine einfache Aufgabe. Wenn allerdings deine Seite nach einem Update nicht mehr funktioniert hat, gab es die Notwendigkeit ein Plugin oder Theme zurücksetzen zu können. Mit der neuen Funktion ist das nun sehr viel einfacher. Aber auch die Aktualisierung einer Premium-Version eines Plugins oder Themes, die sich nicht in den Update-Mechanisum von WordPress integrieren, wird hiermit sehr viel einfacher.

Beitragsnavigation nach Namen sortieren

Bei vielen Kundenprojekten gibt es die Notwendigkeit eigene Inhaltstypen zu hinzuzufügen. In der Regel erstelle ich diese über den wp scaffold post-type Befehl der WP-CLI. Das erstellt die notwendigen PHP Funktionen inkl. eines Arrays von Labels, die dann übersetzt werden können. In der einfachsten Form kann man einen eigenen Inhaltstyp wie folgt registrieren:

function optn_register_post_type() {
	register_post_type(
		'sponsor',
		array(
			'label'       => __( 'Sponsor', 'optn' ),
			'public'      => true,
			'has_archive' => true,
			'show_ui'     => true,
		)
	);
}
add_action( 'init', 'optn_register_post_type' );
Weiterlesen →

Organisation von WordCamps in Zeiten einer weltweiten Pandemie

Vor etwa drei Wochen haben die Global Leads, der Local Lead und die Mentorin des WordCamp Europe 2021 die schwierige Entscheidung getroffen, das Vor-Ort-Event 2021 in Porto um ein weiteres Jahr zu verschieben und auch das nächste WCEU online zu veranstalten. Nach einem sehr erfolgreichen Event in diesem Jahr wird das neue Organisationsteam die Chance haben, ein noch größeres Event im nächsten Jahr zu veranstalten, da sie mehr Zeit haben werden sich auf die speziellen Anforderungen an ein Online-Event einzustellen. Ich wünsche dem neuen Team das Allerbeste – dem ich nicht angehören werde.

Weiterlesen →

Verwendung von Startup-Tasks als Ersatz für File-Watcher in PhpStorm

Vor einigen Tagen habe ich ein neues Projekt begonnen und ein Theme mit Underscores als Basis-Theme entwickelt. Dabei verwende ich immer die „sassified“ Version und erstelle das Theme über den WP-CLI Scaffold-Befehl. Als ich mir danach die Dateien angesehen habe ist mir aufgefallen, dass es eine paar neue Dateien im Verzeichnis gibt. Einige Datei, die allerdings schon einige Zeit enthalten ist, war die package.json Datei, in der verschiedene npm Tasks definiert sind, die für die Komilierung von Sass-Dateien bzw. die Überwachung von Veränderungen an diesen zuständig sind.

Verwendung von File-Wachtern in PhpStorm

In der Vergangenheit habe ich File-Watcher verwendet und in einem früheren Beitrag erklärt, wie man diese nutzen kann um Sass-Dateien zu kompilieren. Das ist ein guter Weg, wann man kein anderen Mechanismus in der Software oder dem Theme/Plugin enthalten ist, der sich darum kümmert. Wenn man aber an etwas entwickelt, das einen solchen Task mitbringt, dann machen es File-Watcher schwieriger, vor Allem, wenn man in einem Team an dem Projekt arbeitet und jeder ein anderes Betriebssystem und andere Kompiler verwendet. In der Vergangenheit habe ich den empfohlenen Ruby-Kompiler verwendet, der allerdings seit März 2019 als veraltet gilt. Seitdem werden entweder Dart Sass oder Lib Sass für die Kompilierung empfohlen. Ich habe zuletzt Dart Sass verwendet, da es der einzige Kompiler war, der unter Windows, Linux und Mac in meinen Tests identische CSS-Dateien erstellt hatte.

Wieso sollte man also nicht einfach einen der neuen Kompiler in PhpStorm in Kombination mit File-Watchern verwenden? Nun, hierzu gibt es zwei Gründe. Zum einen sind die File-Watcher nicht einfach einzurichten, vor Allem dann nicht, wenn die Ordnerstruktur nicht dem Standard entspricht. So befindet sich zum Beipsiel bei Underscores die style.scss Datei im Unterordner sass, die style.css Datei allerdings im Hauptordner. Der Zweite Grund ist, dass in der package.json eventuell nicht nur Tasks zum Kompilieren von Sass-Dateien definiert sind. Ein häufiges Beispiel sind hier PostCSS Plugins wie etwa der Autoprefixer. Diese Kompiler würden beim File-Watcher in PhpStorm nicht ausgeführt werden.

Ausführen eines Watchers aus der package.json Datei

Man kann einen npm (oder ähnlichen) Task in PhpStorm auf zwei Wege ausführen. Entwedet startet man ein Terminal und führt den Befehl dort aus (was den Befehl aber beendet, sobald man das Terminal schließt) oder aber man verwendet „Task | Run Gulp/Grunt/npm Task“ aus der Menüzeile:

Screenshot des "Run npm Task" Fensters

Hier macht man einfach einen Doppelklick auf den Task, den man ausführen möchte und dieses startet in einem neuen Fenster innerhalb von PhpStorm. Allerdings muss man nun jedes Mal, bevor man mit der Arbeit an einem Projekt beginnt, daran denken, den Task manuell zu starten, währen ein File-Watch automatisch „starten“ würde. Gibt es also einen besseren Weg?

Verwebdung eines Startup-Starts für den Watcher

Glücklicherweise gibt es einen sehr einfachen Weg, den ich vor ein paar Wochen gefunden habe. Man kann Startup-Tasks definieren, die jedes Mal ausgeführt werden, wenn man ein Projekt in PhpStorm öffnet. Hierzu wählt man in den Settings den Punkt „Tools|Starup Tasks“ und kann dann hier aus einer Vielzahl von Tasks auswählen. Einer davon ist npm. Hier erstellt du zuerst einen solchen Startup-Task:

Screenshot des "Settings | Tools | Startup Tasks" Fensters mit "npm" ausgewählt als neuem Task

Falls du wie zuvor beschrieben den npm Task schon einem manuell ausgeführt hast, dann kannst du ihn auf der linken Seite einfach direkt auswählen. Ansonsten erstellst du einfach einen neuen Task, gibst ihm einen Namen, wählst die pcackage.json Datei aus und davon dann den passenden Task für den Start:

Screenshot of the npm run configuration setting

Wenn du das alles eingestellt hast, kannst du PhpStorm neustarten oder das Projekt schließen und wieder öffnen um den Startup-Task zu testen. Du solltest hierbei dann das gleiche Fenster wie beim manuellen Ausführen sehen.

Fazit

Die File-Watcher in PhpStorm sind wirklich sehr nützlich, wenn du an einem Projekt arbeitest, das keine Task-Runner verwendet. Aber sie sind recht limitiert und nicht einfach einzurichten. Die Verwendung von Startup-Tasks ist sehr viel einfacher, wenn das Projekt bereits Tasks mirbringt und es stellt sicher, dass alle im Team die gleichen Tasks verwenden. Das kann erheblich die Fehlersuche verringen oder das Auflösen von Merge-Konflikten vermeiden, falls Dateien mit unterschiedlichen Kompilern erstellt wurden.

Speicherplatz in deinem Entwicklungsordner frei machen

Selbst die größte Festplatte hat ein Limit. Von Zeit zu Zeit muss man daher aufräumen, um wieder Platz für neue Projekte zu haben.Wenn gleichzeitig an einer Vielzahl von WordPress Projekten arbeite, alten und neuen, kommt schnell einiges zusammen. In einem früheren Blogbeitrag habe ich euch gezeigt, wie man Speicherplatz sparen kann, indem man Bilder von einem Live-Server lädt. Da Bilder und andere Dateien im Uploads-Ordner oft den größten Teil einer WordPress-Website ausmachen, kann man hierdurch schon viel einsparen. Aber es gibt noch andere Arten von Dateien, die sehr schnell die Festplatte füllen: Datenbank-Dumps.

Große Datenbank-Dumps finden

Wenn du an Projekten arbeitest, die bereits Live gegangen sind, dann möchtest du dir sicher die aktuellen Datenbank von der Live-Seite holen, bevor du mit der Arbeit beginnst. Aber vielleicht hast du vorher Änderungen in der lokalen Datenbank gemacht, die du nicht verlieren möchtest, also machst du ein Backup, bevor du die Datenbank mit der Live-Datenbank überschreibst. Das sind also schon zwei Dumps. Während du an der Seite arbeitest und Dinge veränderst oder löschst, machst du nochmal zu Sicherheit ein Backup. Und da manche WordPress-Datenbanken auch mal mehrere hundert Megabyte groß sein können, kommt schnell einiges an verbrauchtem Speicherplatz zusammen. Der erste Schritt zum Freimachen ist es also, diese großen Datenbank-Dumps zu finden. Hierzu führst du einfach folgenden Befehl in deinem Entwicklungsordner aus:

find . -type f -size +10M -name "*.sql"

Dieser Befehl findet alle SQL-Dumps, die größer als 10 MB sind. Unter Umständen möchtest du sogar nach noch kleineren Dateien suchen, wenn es viele davon gibt, die ebenfalls in Summe mehrer hundert Megabytes groß sind. Wenn du die Dateien nicht nur finden, sondern auch sehen möchtest, wie groß sie sind, dann kannst du den Befehl ergänzen und die gefundenen Dateien an den du Befehl weitergeben:

find . -type f -size +10M -name "*.sql" -exec du -h "{}" \;

Nachdem du nun alle großen Dateien gefunden hast kannst du diejenigen löschen, die du nicht mehr brauchst. Aber was ist, wenn du sie noch immer brauchst?

Alle Datenbank-Dump komprimieren

Nun, das ist ganz einfach. Du verwendest einfach einen anderen Befehl und komprimierst alle Dateien in einem Durchlauf. Hierzu verwendet du einfach folgenden Befehl:

find . -type f -size +10M -name "*.sql" -exec gzip "{}" \;

Dieser Befehl komprimiert also alle Datenbank-Dump, die größer als 10 MB sind, mit dem gzip Befehl. Als ich diesen Befehl vor einigen Tagen auf meinem Arbeits-Laptop ausgeführt habe, konnte ich mehr als 3,5 GB auf der Festplatte frei machen. Der Befehl hat dazu nur etwa 90 Sekunden benötigt. Wenn ich nun einen der Dumps wieder einspielen möchte, dann muss ich ihn nur mit dem Befehl ungzip wieder enpacken, bevor ich ihn in die Datenbank importiere.

Andere große Dateien finden

Nachdem du alle Datenbank-Dumps komprimiert hast, könntest du doch gleich mal nach anderen großen Dateien such, die du einfach löschen oder komprimieren kannst. Gute andere Kandidaten sind hier etwa das debug.log im wp-content Ordner, wenn du bei einer Installation mal das WP_DEBUG_LOG aktiviert hattest. Um solche Dateien zu finden, kannst du entweder das Suchmuster anpassen oder einfach ganz weglassen, um alle großen Dateien zu finden:

find . -type f -size +10M -exec du -h "{}" \;

Wenn du ohne eine Dateiendung suchst, wirst du vermutlich auch Mediendateien finden. Dann kannst du den Trick verwenden, den ich zuvor erwähnt habe und die Dateien einfach von einem Remote-Server laden lassen.

Eventuell findest du auch XML-Dateien, die sehr groß sind. Diese könnten beispielsweise vom WordPress XML Exporter stammen. Es könnten aber auch andere Dateien sein, die eventuell unkomprimiert belassen werden müssen.

Einschränkung

Vielleicht fragst du dich nun „wieso komprimiere ich nicht einfach alle .sql Dateien?“, aber das verursacht eventuell Probleme. Wenn du die Suche mal ohne Filter nach der Dateigröße durchführst, dann wirst du vermutlich auch SQL-Dateien in Plugin-Ordnern finden. Diese Dateien werden in der Regel verwendet um notwendige Tabellen beim Installieren oder Aktivieren von Plugins anzulegen und dürfen daher nicht komprimiert werden. Verwende also keine zu kleine Dateigröße, wenn du die Datenbank-Dumps auf deinem System komprimierten willst. Auf meinem System hätte selbst eine minimale Dateigröße von 1 MB nur Datenbank-Dumps gefunden und keine dieser speziellen Dateien. Die gleiche Einschränkung gilt aber auch für einige XML-Datien und auch für Log-Dateien. Ist eine solche Datei komprimiert, kann nicht mehr darin geschrieben werden. Also komprimiere nicht einfach alle Textdateien, die zu groß sind.

Fazit

Wenn man an vielen Projekten arbeite ist der Speicherplatz schnell verbraucht. Zu wissen, wie man schnell wieder Speicherplatz freigeben kann ist daher wichtig, vor allem dann, wenn man die Festplatte im Gerät nicht einfach durch eine größere austauschen kann. Mir hat es in der Situation sofort geholfen, erst einmal alle Datenbank-Dump zu komprimieren und ich musste mir auch nicht lange Gedanken darüber machen, welche Dateien ich noch brauche und welche nicht.