WordPress-Suchwidget auf bestimmte Post Types beschränken

Für eine WordPress-Installation war ich auf der Suche nach einer Möglichkeit die Suche bzw. im Speziellen das Suchwidget so zu beschränken das nur die Post Types page und post durchsucht und angezeigt werden. Möglich ist dies, indem ein Filter für pre_get_posts in die functions.php des Themens hinzugefügt wird:

function search_only_in_specific_post_types( $query ) {
	
  // Modify query (but only in frontend)
  if ( $query->is_search && is_admin() == false ) {
    $query->set( 'post_type', array( 'page','post') );
  }
	
  return $query;
}

add_filter( 'pre_get_posts', 'search_only_in_specific_post_types' );

Der Filter passt die Query an, wenn die Query für eine Suche genutzt wird und diese Nutzung aus dem Frontend heraus geschieht. Die Begrenzung auf des Frontend ist notwendig um keine Suchqueries im Backend zu stören. Damit würde die modifizierte Suche nur noch Dokumente mit dem Post Type page und post finden.

Composer für PHP nutzen

Composer ist ein Paket- bzw. Dependency-Manager für PHP. Damit ist es möglich die Abhängigkeiten von PHP-Projekten komfortabel zu verwalten und aktuell zu halten. Dazu wird in dem Projekt eine Datei mit dem Namen composer.json angelegt. In dieser Datei finden sich die Abhängigkeiten für das Projekt:

{
  "minimum-stability": "RC",
  "require": {
    "slim/slim": "3.*"
  }
}

Um diese Abhängigkeiten initial dem Projekt hinzuzufügen, muss der Befehl:

composer install

eingegeben werden. Anschließend werden die Abhängigkeiten aufgelöst und heruntergeladen:

Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 6 installs, 0 updates, 0 removals
  - Installing psr/container (1.0.0): Loading from cache
  - Installing container-interop/container-interop (1.2.0): Loading from cache
  - Installing nikic/fast-route (v1.3.0): Loading from cache
  - Installing psr/http-message (1.0.1): Loading from cache
  - Installing pimple/pimple (v3.2.3): Loading from cache
  - Installing slim/slim (3.12.1): Loading from cache
Writing lock file
Generating autoload files

Nach der initialen Installation, finden die sich die Abhängigkeiten im Ordner vendor. Daneben wird eine composer.lock-Datei angelegt. In dieser sind die genauen Versionsnummern, der installierten Abhängigkeiten hinterlegt. Würde das Projekt nun nochmal mit der install-Option aufgerufen werden, so würden exakt diese Versionen installiert. Sollen diese Abhängigkeiten später aktualisiert werden, kann dafür der Befehl:

composer update

genutzt werden. Dabei werden die Versionen, welche sich in der composer-lock-Datei befinden ebenfalls aktualisiert.

getcomposer.org

Bezogen werden kann Composer unter anderem auf der offiziellen Seite unter getcomposer.org. Der Quelltext von Composer ist auf GitHub zu finden. Die Software ist unter der MIT-Lizenz lizenziert und damit freie Software.

Code Snippets über Postman generieren

Mit der App Postman ist es möglich REST-API Aufrufe gegen beliebige Endpunkte durchzuführen. Allerdings bietet Postman weitere Funktionalität, welche vom normalen Tagesgeschäft der App abweicht. Eine dieser Funktionalitäten ist der Code Snippet Generator.

Code Snippets können für unterschiedliche Sprachen und Frameworks erzeugt werden

Mit diesem Generator kann ein beliebiger Request in Quellcode umgewandelt werden. Der Generator unterstützt unterschiedliche Programmiersprachen und Frameworks. Für Java würde, unter Nutzung der OK HTTP Bibliothek, das Ganze so aussehen:

OkHttpClient client = new OkHttpClient();

MediaType mediaType = MediaType.parse("text/plain");
RequestBody body = RequestBody.create(mediaType, "{\r\n\tfield: \"data\",\r\n\tfield2: \"data\",\r\n\tfield3: \"data\"\r\n}");
Request request = new Request.Builder()
  .url("https://example.com")
  .post(body)
  .addHeader("HeaderField", "headerValue")
  .addHeader("Content-Type", "text/plain")
  .addHeader("User-Agent", "PostmanRuntime/7.11.0")
  .addHeader("Accept", "*/*")
  .addHeader("Cache-Control", "no-cache")
  .addHeader("Postman-Token", "7dda208f-ba63-467d-99cd-98455c2b3a7a,9125dbf4-cd5c-4070-87e3-fcda7416ca08")
  .addHeader("Host", "example.com")
  .addHeader("accept-encoding", "gzip, deflate")
  .addHeader("content-length", "56")
  .addHeader("Connection", "keep-alive")
  .addHeader("cache-control", "no-cache")
  .build();

Response response = client.newCall(request).execute();

Erreichbar ist das Feature über den Code-Link, welcher unter dem Send-Button des Hauptfensters zu finden ist. Nach einem Klick auf den Link erscheint ein Dialog in welchem die gewünschte Sprach- und Frameworkkombination ausgewählt werden kann.

Unter dem Send-Button ist der Code-Link zu finden

Als Sprachen für die Generierung von Code Snippets werden unter anderem C#, Go, Java, JavaScript, Objective-C, PHP, Python und Swift unterstützt. Daneben werden bestimmte Tools wie curl und wget unterstützt. Postman selber kann unter getpostman.com bezogen werden.

Workaround für Episoden Seiten im Podlove Publisher

Im Podlove Publisher gibt es in den Experteneinstellungen die Möglichkeit Episoden Seiten zu aktivieren. Gemeint ist damit nicht anders als alle Podcastbeiträge auf einer zusätzlichen Seite anzeigen zu lassen. Seit der Version 2.7.0 des Podlove Publisher funktionierte dieses Feature bei mir nicht mehr.

Die Episoden Seite für alle veröffentlichenden Podcasts

Hintergrund war der Commit b4d9f14; hier gab es unter anderem eine Änderung in der Datei permalinks.php. Wenn nun die URL für die Episoden Seiten eingestellt wurde funktionierte diese nicht mehr. Stattdessen gab es nur die Meldung das die Seite nicht existiert. Als Workaround habe ich die permalinks.php-Datei wieder um folgenden Quellcode aus dem Commit erweitert:

// Add archive pages
if ( 'on' == \Podlove\get_setting( 'website', 'episode_archive' ) ) {
	$archive_slug = trim( \Podlove\get_setting( 'website', 'episode_archive_slug' ), '/' );

	$blog_prefix = \Podlove\get_blog_prefix();
	$blog_prefix = $blog_prefix ? trim( $blog_prefix, '/' ) . '/' : '';

	$wp_rewrite->add_rule( "{$blog_prefix}{$archive_slug}/?$", "index.php?post_type=podcast", 'top' );
	$wp_rewrite->add_rule( "{$blog_prefix}{$archive_slug}/{$wp_rewrite->pagination_base}/([0-9]{1,})/?$", 'index.php?post_type=podcast&paged=$matches[1]', 'top' );
}

Der Quellcode muss an das Ende der Funktion podlove_add_podcast_rewrite_rules angetragen werden. Damit funktioniert das Episoden Seiten-Feature bei mir wieder ohne Probleme. Natürlich muss dieses Prozess bei jedem Update des Podlove Publisher wiederholt werden.

Waipoua-Theme für den Podlove Publisher anpassen

Seit meinem letzten Wechsel des Designs auf seeseekey.net nutze ich eine stark modifizierte Version des Elmastudio-Themes Waipoua. Neben Anpassungen am Design wurden unter anderem die externen Einbindungen der Google Fonts deaktiviert. In den aktuellen Themes von Elmastudio werden diese leider immer noch extern eingebunden; was wohl auch auf absehbare Zeit so bleibt.

Leider hat das Waipoua-Theme einige Probleme mit dem Plugin Podlove Publisher. Der Podlove Publisher ist ein Plugin, welches einen Workflow für Podcasts, vom Anbieten bis zum Abonnieren bereitstellt.

Podlove Podcast Publisher
Preis: Kostenlos

Das erste Problem mit dem Podlove Publisher im Zusammenhang mit dem Waipoua-Theme ist die Anzeige der von Beiträgen mit dem Post Type podcast auf der Startseite. In den Experteneinstellungen des Podlove Publishers ist dies die Einstellung Blog und Podcast kombinieren. Damit dies mit dem Waipoua-Theme funktioniert muss die Datei index.php des Themes angepasst werden. Dort findet sich folgende Quelltextblock:

<?php /* Start the Loop */ ?>
<?php global $query_string;
query_posts( $query_string . '&ignore_sticky_posts=1' ); ?>

  <?php while ( have_posts() ) : the_post(); ?>

    <?php get_template_part( 'content', get_post_format() ); ?>

  <?php endwhile; // end of the loop. ?>

<?php wp_reset_query(); // reset the query ?>

An dieser Stelle werden sämtliche Manipulationen der Abfrage entfernt. Anschließend sollte der Code so aussehen:

<?php /* Start the Loop */ ?>

  <?php while ( have_posts() ) : the_post(); ?>

    <?php get_template_part( 'content', get_post_format() ); ?>

  <?php endwhile; // end of the loop. ?>

Nach dieser Modifikation tauchen die Beiträge mit dem Post Type podcast in der Beitragsliste im Startmenü auf. Das nächste Problem betrifft die Darstellung der Beiträge mit dem Post Type podcast, sobald diese einzeln angezeigt werden. Hierbei wird das Design zerschossen, da der Beitrag in voller Breite angezeigt wird. Eine Sidebar würde in diesem Szenario nach unten rutschen.

Nach dem Fix funktionieren die Einzelseiten mit dem Post Type podcast

Um dies zu verhindern muss die Datei header.php angepasst werden. Dort findet sich nach dem schließenden head-Tag die Zeile:

<body <?php body_class(); ?>>

Diese Zeile wird entfernt und stattdessen durch folgenden Quellcode ersetzt:

// Fix problem with single posts (post type: podcast)
$body_class = get_body_class();

// single-podcast exists in body class, replace
if (in_array("single-podcast", $body_class)) {

  echo "<body class=\"";

  foreach($body_class as $body_class_value) {
    if ($body_class_value == "single-podcast") {
      $body_class_value = "single-post";
    }

    echo $body_class_value . " ";
  }
  
  echo "\" >";
}
else {
?>
  <body <?php body_class(); ?>>
<?php
}
?>

Der Quellcode sorgt dafür das die Klasse single-podcast in single-post umbenannt wird. Damit greift das CSS für gewöhnliche Beiträge und die Darstellung der Podcast-Seiten funktioniert ohne Probleme. Als letzten Schritt habe ich die archive.php angepasst. In der Datei wurde der komplette header-Block entfernt. Diese Anpassung ist im Gegensatz zu den anderen Anpassungen Geschmackssache. Sie sorgt dafür das keinerlei Archivtexte mehr auftauchen.