Die Startseiten ID in WordPress ermitteln und diese im WPRocket Cache verwerfen

Bei einem Projekt werden auf der Startseite unter anderem auch die 10 neusten Beiträge eines eigenen Custom-Post Types aufgelistet.

Es gibt einige Aktionen, die relativ lang benötigen, darum wird WP Rocket als Cache Plugin eingesetzt.

Das Problem ist nun, das neue Beiträge nicht sofort auf der Startseite angezeigt werden, sondern erst, wenn die Zeitdauer des Caches abgelaufen ist.

Es gäbe verschiedene Wege, das zu lösen.

  1. Die Startseite nicht Cachen.WP Rocket bietet die Möglichkeit beim bearbeiten eines Beitrags das Caching der Seite abzuschalten. Da aber, wie oben beschrieben, einige Aktionen länger benötigen ist dies keine Ernsthafte Option, da dann die erhöhte Serverlast bei jeden Seitenabruf auftritt.
  2. Die Zeitdauer verringern, bis der Inhalt des Cache verworfen wird.
    Normal halten wir die Seiten für 24 Stunden im Cache. Da relativ wenige neue Beiträge hinzukommen im laufe eines Tages, würde das heruntersetzten auf Beispielsweise eine Stunde oder gar 30 Minuten eine entsprechend höhere Serverlast bedeuten, die dazu noch in ca 80 Prozent der Fälle unnötig wäre, da keine neuen Beiträge hinzugekommen sind. Außerdem bezieht sich diese Einstellung auf den globalen Cache und nicht auf die einzelne Seite. Und in der Installation sind derzeit rund 10.000 Beiträge vorhanden.
  3. Beim speichern eines Beitrags,  den Cache der Startseite ebenfalls ungültig machen.
    WP Rocket bietet eine Funktion rocket_clean_post() mit der ein Post und seine verbundenen Elemente wie Kategorie- und Schlagwort-Archive aus dem Cache entfernt werden können.

Mit rocket_clean_post() hab ich nun das Handwerkszeug, um beim Speichern eines Beitrag über den save_post Hook den Cache der Startseite zu verwerfen.

Dann brauch ich nur noch die Post-ID der Startseite. Unter Einstellungen / Lesen oder alternativ im Customizer kann ich festlegen, das WordPress statt den neusten Beitrögen eine der Seiten als Startseite verwenden soll.

Dies wird bei der Seite in der Seitenübersicht auch vermerkt.

Die Tatsache, das es unter Einstellungen im Backend bearbeitet wird, legt die Vermutung nahe, das es in der options Tabelle von WordPress in der Datenbank gespeichert.
Es gibt einen (unvollständigen) Codex Eintrag zu den Werten die WordPress dort speichert. Und es gibt sogar eine nicht verlinkte URL, unter der im Backend von WordPress (fast) alle options Eintröge angezeigt und bearbeitet werden können. Dazu ruft man, nach dem Anmelden die URL (domain.tld)/wp-admin/options.php auf.

Der in diesem Fall benötige Wert findet sich in der option page_on_front, der mit der Funktion get_option ausgelesen wird.

Daraus ergibt sich folgender Code, um auf das Speichern eines Beitrags zu reagieren und, wenn WP Rocket aktiv ist, die Startseiten ID zu holen und diese im Cache ungültig zu machen.

 
function my_clean_cache( $post_id ) {
	if (  function_exists( 'rocket_clean_post' ) ) {  // Nur wenn WP Rocket aktiv ist.
	    // Startseite ermittln und invalid machen.
	    $frontpage_id = get_option( 'page_on_front' );
	    if ( $frontpage_id ) { 
	    	rocket_clean_post( $frontpage_id );
	    }
	}
}

add_action( 'save_post', 'my_clean_cache' );

 

2 Kommentare zu „Die Startseiten ID in WordPress ermitteln und diese im WPRocket Cache verwerfen“

  1. Hallo Frank, was für ein praktisches Helferlein!

    Als ehemalige Support-Fee bei WP Rocket erinnere ich mich, dass WP Rocket die Startseite sowieso jedesmal aus dem Cache spült, wenn du einen Post speicherst (wp-rocket/inc/common/purge.php#L259). Klappt das bei dir nicht?

    (Absurd kleinliche Randbemerkung, die nichts weiter zur Sache tut: get_option( 'page_on_front' ) gibt einen String anstatt einer Integer zurück; ich jage den Wert deswegen grundsätzlich einmal durch absint(), wenn ich eine ID zurückbekommen möchte.)

    1. Hallo Caspar,

      Als ehemalige Support-Fee bei WP Rocket erinnere ich mich, dass WP Rocket die Startseite sowieso jedesmal aus dem Cache spült,

      Interessanterweise passiert genau das, bei der genannten Installation nicht. Darum hab ich mich ja überhaupt erst auf die Suche gemacht.
      Nachzuschauen warum, wäre dann ja eventuell mal ein weiter Artikel 🙂
      Und ja, natürlich ist es Sinnvoll, die Rückgabe von get_option erst noch nach int zu casten.

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert