WordPress URLs ohne Beiträge

Wir arbeiten an einem größeren System, das auf WordPress basiert, aber WordPress wird nur für “statische” Inhalte verwendet, der Hauptteil des Systems sollte die externe API konsumieren und die Daten anzeigen.

Mein Punkt ist: bin ich in der Lage, irgendwie URL Umschreiben zu sagen, das interne System von WordPress für einige URLs nicht zu benutzen und etwas anderes zu verwenden?

ZB mysite.com/news/news-title würde den Beitrag mysite.com/customcontent/anotherlink , aber mysite.com/customcontent/anotherlink würde einen Mechanismus aufrufen, um Daten aus der API zu laden und anzuzeigen.

Ich weiß nicht, ob das überhaupt mit WordPress möglich ist. Danke für deine Punkte.

Solutions Collecting From Web of "WordPress URLs ohne Beiträge"

Ja, es ist möglich.

WordPress Frontend Workflow kann wie folgt zusammengefasst werden:

  1. Eine URL wird besucht
  2. Durch Überprüfen der aktuellen URL gegen alle Standardregeln und benutzerdefinierten Umschreibungsregeln wird die URL in eine Reihe von Argumenten für WP_Query “konvertiert”. Dies geschieht durch die Methode parse_request einer Instanz der WP class, die in der globalen Variablen $wp gespeichert ist
  3. Eine Instanz von WP_Query (in der globalen Variablen $wp_query gespeichert) wird zum Abfragen der database und zum Abrufen der mit den in Punkt 2 abgerufenen Argumenten verknüpften Posts verwendet. Dies wird als “Hauptabfrage” bezeichnet
  4. Basierend auf den Abfrageargumenten wird eine Vorlage entsprechend der Vorlagenhierarchie ausgewählt und geladen und zur Anzeige der Ergebnisse verwendet

Selbst wenn Sie eine Reihe von benutzerdefinierten Rewrite-Regeln registrieren, werden diese zum Abfragen von Posts verwendet.

Wenn Sie jedoch die Quelle der parse_request Methode betrachten , sehen Sie in den ersten Zeilen parse_request :

 if ( ! apply_filters( 'do_parse_request', true, $this, $extra_query_vars ) ) return; 

Wenn Sie also einen Callback an den ‘do_parse_request’-Filter anfügen, können Sie den WordPress-Parsing-process stoppen und alles tun, was Sie brauchen.

Es gibt verschiedene Wege, diese Aufgabe zu erledigen, hier gebe ich der Einfachheit halber ein grobes Beispiel.

Wie gesagt, wir müssen eine benutzerdefinierte URL-Übereinstimmung mit … etwas herstellen , wahrscheinlich einem Callback, der einige Daten abruft, und einer Ansicht, um sie anzuzeigen.

Um Code wiederverwendbar zu machen, können wir eine class verwenden, die benutzerdefinierte URL-Einstellungen über einen Filter akzeptiert, und diese benutzerdefinierten URLs verwenden, um anzuzeigen, was wir benötigen, einen Callback zum Abrufen einiger Daten und eine Ansicht zum Anzeigen dieser Daten zu verwenden.

 class MyCustomUrlParser { private $matched = array(); /** * Run a filter to obtain some custom url settings, compare them to the current url * and if a match is found the custom callback is fired, the custom view is loaded * and request is stopped. * Must run on 'do_parse_request' filter hook. */ public function parse( $result ) { if ( current_filter() !== 'do_parse_request' ) { return $result; } $custom_urls = (array) apply_filters( 'my_custom_urls', array() ); if ( $this->match( $custom_urls ) && $this->run() ) { exit(); // stop WordPress workflow } return $result; } private function match( Array $urls = array() ) { if ( empty( $urls ) ) { return FALSE; } $current = $this->getCurrentUrl(); $this->matched = array_key_exists( $current, $urls ) ? $urls[$current] : FALSE; return ! empty( $this->matched ); } private function run() { if ( is_array( $this->matched ) && isset( $this->matched['callback'] ) && is_callable( $this->matched['callback'] ) && isset( $this->matched['view'] ) && is_readable( $this->matched['view'] ) ) { $GLOBALS['wp']->send_headers(); $data = call_user_func( $this->matched['callback'] ); require_once $this->matched['view']; return TRUE; } } private function getCurrentUrl() { $home_path = rtrim( parse_url( home_url(), PHP_URL_PATH ), '/' ); $path = rtrim( substr( add_query_arg( array() ), strlen( $home_path ) ), '/' ); return ( $path === '' ) ? '/' : $path; } } 

Dies ist eine grobe class, mit der Benutzer benutzerdefinierte URL-Einstellungen über einen Filter (‘my_custom_urls’) festlegen können. Benutzerdefinierte URL-Einstellungen müssen ein Array sein, in dem Schlüssel relative URLs sind und jeder Wert ein Array ist, das zwei Schlüsselwerte enthält: einen mit Schlüssel “callback” und einen mit Schlüssel “Ansicht”.

Der Callback ist aufrufbar (alles, für das is_callable true zurückgibt), und die Ansicht ist eine Datei, die zum Rendern der Daten verwendet wird, die von der aufrufbaren und in der View-Datei abrufbaren Datei in der Variable $data werden.

Hier ein Beispiel, wie man die class benutzt.

 // first of all let's set custom url settings add_filter( 'my_custom_urls', 'set_my_urls' ); function set_my_urls( $urls = array() ) { $my_urls = array( '/customcontent/alink' => array( 'callback' => 'my_first_content_callback', 'view' => get_template_directory() . '/views/my_first_view.php' ), '/customcontent/anotherlink' => array( 'callback' => 'my_second_content_callback', 'view' => get_template_directory() . '/views/my_second_view.php' ) ); return array_merge( (array) $urls, $my_urls ); } // require the file that contain the MyCustomUrlParser class require '/path/to/MyCustomUrlParser'; // attach MyCustomUrlParser::parse() method to 'do_parse_request' filter hook add_filter( 'do_parse_request', array( new MyCustomUrlParser, 'parse' ) ); 

Natürlich müssen wir my_first_content_callback und my_second_content_callback sowie my_first_view.php und my_second_view.php .

Als Beispiel würde der callback in etwa so aussehen:

 function my_first_content_callback() { $content = get_transient( 'my_first_content' ); if ( empty( $content ) ) { $api = a_method_to_get_an_external_api_object(); $json = $api->fetch_some_json_data(); $content = json_decode( $json ); // cache content for 1 hour set_transient( 'my_first_content', $content, HOUR_IN_SECONDS ); } return $content; } 

Beachten Sie, dass jeder Callback- $data in der Variablen $data gespeichert wird, auf die in der Ansicht zugegriffen werden kann. In Fakten würde eine Ansichtsdatei in etwa so aussehen:

 < ?php get_header(); ?> 

My Content from API

< ?php print_r( $data ); ?>

< ?php get_footer() ?>

Dies funktioniert und ist ziemlich wiederverwendbar. Sie können alle benutzerdefinierten URLs mit dem Filter 'my_custom_urls' .

Allerdings gibt es einen Nachteil: Der Abgleich mit der aktuellen URL erfolgt über eine exakte Übereinstimmung, aber mit einem Regex-Matching-System wäre es für große Projekte viel besser, da Sie die URLs verwenden können, um einige Variablen an Callbacks zu übergeben.

ZB wenn Sie eine URL-Einstellung wie folgt haben:

 '/customcontent/alink/page/{page}' => array( 'callback' => 'my_first_content_callback', 'view' => get_template_directory() . '/views/my_first_view.php' ) 

Mit einem Regex-System ist es möglich, die {page} -Teilvariable zu erstellen, und der übereinstimmende Wert kann an den Callback übergeben werden, um verschiedene Daten abzurufen.

Dies ist ein sogenanntes Routing-System , und es gibt einige nützliche PHP-Bibliotheken wie FastRoute , Pux und Symfony Routing Component , die Ihnen helfen können, den hier beschriebenen Workflow zu nutzen und Ihr eigenes Regex-basiertes Routing-System in WordPress zu erstellen.

Wenn Sie PHP 5.4+ haben (das ist wirklich zu empfehlen), gibt es ein Plugin namens Cortex , das Symfony Routing Component implementiert und es in WordPress sowohl für Standard-WordPress-Abfragen (Posts anzeigen) als auch für benutzerdefinierte Inhalte, die Sie benötigen, nutzbar macht.