Когда вы посещаете страницу веб-интерфейса, WordPress будет запрашивать базу данных, и если ваша страница не существует в базе данных, этот запрос не нужен и является пустой тратой ресурсов.
К счастью, WordPress предлагает способ обработки запросов к веб-интерфейсу индивидуально. Это сделано благодаря 'do_parse_request'
фильтру.
Возвращаясь false
к этому ловушке, вы сможете остановить WordPress от обработки запросов и делать это по-своему.
Тем не менее, я хочу поделиться способом создания простого плагина ООП, который может обрабатывать виртуальные страницы простым в использовании (и повторном использовании) способом.
Что нам нужно
- Класс для объектов виртуальной страницы
- Класс контроллера, который будет смотреть на запрос и, если он для виртуальной страницы, показывать его, используя соответствующий шаблон
- Класс для загрузки шаблона
- Основные файлы плагинов для добавления хуков, которые заставят все работать
Интерфейсы
Перед созданием классов давайте напишем интерфейсы для 3 объектов, перечисленных выше.
Сначала интерфейс страницы (файл PageInterface.php
):
<?php
namespace GM\VirtualPages;
interface PageInterface {
function getUrl();
function getTemplate();
function getTitle();
function setTitle( $title );
function setContent( $content );
function setTemplate( $template );
/**
* Get a WP_Post build using virtual Page object
*
* @return \WP_Post
*/
function asWpPost();
}
Большинство методов просто геттеры и сеттеры, объяснений не требуется. Последний метод должен использоваться для получения WP_Post
объекта с виртуальной страницы.
Интерфейс контроллера (файл ControllerInterface.php
):
<?php
namespace GM\VirtualPages;
interface ControllerInterface {
/**
* Init the controller, fires the hook that allows consumer to add pages
*/
function init();
/**
* Register a page object in the controller
*
* @param \GM\VirtualPages\Page $page
* @return \GM\VirtualPages\Page
*/
function addPage( PageInterface $page );
/**
* Run on 'do_parse_request' and if the request is for one of the registered pages
* setup global variables, fire core hooks, requires page template and exit.
*
* @param boolean $bool The boolean flag value passed by 'do_parse_request'
* @param \WP $wp The global wp object passed by 'do_parse_request'
*/
function dispatch( $bool, \WP $wp );
}
и интерфейс загрузчика шаблонов (файл TemplateLoaderInterface.php
):
<?php
namespace GM\VirtualPages;
interface TemplateLoaderInterface {
/**
* Setup loader for a page objects
*
* @param \GM\VirtualPagesPageInterface $page matched virtual page
*/
public function init( PageInterface $page );
/**
* Trigger core and custom hooks to filter templates,
* then load the found template.
*/
public function load();
}
Комментарии phpDoc должны быть достаточно понятны для этих интерфейсов.
План
Теперь, когда у нас есть интерфейсы, и прежде чем писать конкретные классы, давайте рассмотрим наш рабочий процесс:
- Сначала мы создаем экземпляр
Controller
класса (реализующий ControllerInterface
) и внедряем (возможно, в конструктор) экземпляр TemplateLoader
класса (реализующий TemplateLoaderInterface
)
- На
init
крючке мы вызываем ControllerInterface::init()
метод для настройки контроллера и запуска ловушки, которую потребительский код будет использовать для добавления виртуальных страниц.
- На 'do_parse_request' мы позвоним
ControllerInterface::dispatch()
, и там мы проверим все добавленные виртуальные страницы и, если одна из них имеет тот же URL текущего запроса, отобразим его; после установки всех основных глобальных переменных ( $wp_query
, $post
). Мы также будем использовать TemplateLoader
класс для загрузки нужного шаблона.
Во время этого рабочего процесса мы будем запускать некоторые основные крюки, как wp
, template_redirect
, template_include
... чтобы сделать плагин более гибким и обеспечить совместимость с ядром и другими плагинами, или , по крайней мере , с хорошим количеством их.
Помимо предыдущего рабочего процесса, нам также необходимо:
- Очистка хуков и глобальных переменных после запуска основного цикла, снова для улучшения совместимости с ядром и сторонним кодом
- Добавьте фильтр,
the_permalink
чтобы при необходимости он возвращал правильный URL-адрес виртуальной страницы.
Бетонные классы
Теперь мы можем кодировать наши конкретные классы. Начнем с класса страницы (файла Page.php
):
<?php
namespace GM\VirtualPages;
class Page implements PageInterface {
private $url;
private $title;
private $content;
private $template;
private $wp_post;
function __construct( $url, $title = 'Untitled', $template = 'page.php' ) {
$this->url = filter_var( $url, FILTER_SANITIZE_URL );
$this->setTitle( $title );
$this->setTemplate( $template);
}
function getUrl() {
return $this->url;
}
function getTemplate() {
return $this->template;
}
function getTitle() {
return $this->title;
}
function setTitle( $title ) {
$this->title = filter_var( $title, FILTER_SANITIZE_STRING );
return $this;
}
function setContent( $content ) {
$this->content = $content;
return $this;
}
function setTemplate( $template ) {
$this->template = $template;
return $this;
}
function asWpPost() {
if ( is_null( $this->wp_post ) ) {
$post = array(
'ID' => 0,
'post_title' => $this->title,
'post_name' => sanitize_title( $this->title ),
'post_content' => $this->content ? : '',
'post_excerpt' => '',
'post_parent' => 0,
'menu_order' => 0,
'post_type' => 'page',
'post_status' => 'publish',
'comment_status' => 'closed',
'ping_status' => 'closed',
'comment_count' => 0,
'post_password' => '',
'to_ping' => '',
'pinged' => '',
'guid' => home_url( $this->getUrl() ),
'post_date' => current_time( 'mysql' ),
'post_date_gmt' => current_time( 'mysql', 1 ),
'post_author' => is_user_logged_in() ? get_current_user_id() : 0,
'is_virtual' => TRUE,
'filter' => 'raw'
);
$this->wp_post = new \WP_Post( (object) $post );
}
return $this->wp_post;
}
}
Ничего больше, чем реализация интерфейса.
Теперь класс контроллера (файл Controller.php
):
<?php
namespace GM\VirtualPages;
class Controller implements ControllerInterface {
private $pages;
private $loader;
private $matched;
function __construct( TemplateLoaderInterface $loader ) {
$this->pages = new \SplObjectStorage;
$this->loader = $loader;
}
function init() {
do_action( 'gm_virtual_pages', $this );
}
function addPage( PageInterface $page ) {
$this->pages->attach( $page );
return $page;
}
function dispatch( $bool, \WP $wp ) {
if ( $this->checkRequest() && $this->matched instanceof Page ) {
$this->loader->init( $this->matched );
$wp->virtual_page = $this->matched;
do_action( 'parse_request', $wp );
$this->setupQuery();
do_action( 'wp', $wp );
$this->loader->load();
$this->handleExit();
}
return $bool;
}
private function checkRequest() {
$this->pages->rewind();
$path = trim( $this->getPathInfo(), '/' );
while( $this->pages->valid() ) {
if ( trim( $this->pages->current()->getUrl(), '/' ) === $path ) {
$this->matched = $this->pages->current();
return TRUE;
}
$this->pages->next();
}
}
private function getPathInfo() {
$home_path = parse_url( home_url(), PHP_URL_PATH );
return preg_replace( "#^/?{$home_path}/#", '/', esc_url( add_query_arg(array()) ) );
}
private function setupQuery() {
global $wp_query;
$wp_query->init();
$wp_query->is_page = TRUE;
$wp_query->is_singular = TRUE;
$wp_query->is_home = FALSE;
$wp_query->found_posts = 1;
$wp_query->post_count = 1;
$wp_query->max_num_pages = 1;
$posts = (array) apply_filters(
'the_posts', array( $this->matched->asWpPost() ), $wp_query
);
$post = $posts[0];
$wp_query->posts = $posts;
$wp_query->post = $post;
$wp_query->queried_object = $post;
$GLOBALS['post'] = $post;
$wp_query->virtual_page = $post instanceof \WP_Post && isset( $post->is_virtual )
? $this->matched
: NULL;
}
public function handleExit() {
exit();
}
}
По сути, класс создает SplObjectStorage
объект, в котором хранятся все добавленные объекты страниц.
Вкл 'do_parse_request'
, класс контроллера зацикливает это хранилище, чтобы найти соответствие для текущего URL на одной из добавленных страниц.
Если он найден, класс делает именно то, что мы запланировали: запускает несколько хуков, устанавливает переменные и загружает шаблон через расширение класса TemplateLoaderInterface
. После этого просто exit()
.
Итак, давайте напишем последний класс:
<?php
namespace GM\VirtualPages;
class TemplateLoader implements TemplateLoaderInterface {
public function init( PageInterface $page ) {
$this->templates = wp_parse_args(
array( 'page.php', 'index.php' ), (array) $page->getTemplate()
);
}
public function load() {
do_action( 'template_redirect' );
$template = locate_template( array_filter( $this->templates ) );
$filtered = apply_filters( 'template_include',
apply_filters( 'virtual_page_template', $template )
);
if ( empty( $filtered ) || file_exists( $filtered ) ) {
$template = $filtered;
}
if ( ! empty( $template ) && file_exists( $template ) ) {
require_once $template;
}
}
}
Шаблоны, хранящиеся на виртуальной странице, объединяются в массив со значениями по умолчанию page.php
и index.php
перед запуском загрузки шаблона 'template_redirect'
повышают гибкость и улучшают совместимость.
После этого найденный шаблон проходит через пользовательский 'virtual_page_template'
и базовый 'template_include'
фильтры: опять же для гибкости и совместимости.
Наконец файл шаблона только что загружен.
Основной файл плагина
На данный момент нам нужно написать файл с заголовками плагинов и использовать его для добавления хуков, которые сделают наш рабочий процесс:
<?php namespace GM\VirtualPages;
/*
Plugin Name: GM Virtual Pages
*/
require_once 'PageInterface.php';
require_once 'ControllerInterface.php';
require_once 'TemplateLoaderInterface.php';
require_once 'Page.php';
require_once 'Controller.php';
require_once 'TemplateLoader.php';
$controller = new Controller ( new TemplateLoader );
add_action( 'init', array( $controller, 'init' ) );
add_filter( 'do_parse_request', array( $controller, 'dispatch' ), PHP_INT_MAX, 2 );
add_action( 'loop_end', function( \WP_Query $query ) {
if ( isset( $query->virtual_page ) && ! empty( $query->virtual_page ) ) {
$query->virtual_page = NULL;
}
} );
add_filter( 'the_permalink', function( $plink ) {
global $post, $wp_query;
if (
$wp_query->is_page && isset( $wp_query->virtual_page )
&& $wp_query->virtual_page instanceof Page
&& isset( $post->is_virtual ) && $post->is_virtual
) {
$plink = home_url( $wp_query->virtual_page->getUrl() );
}
return $plink;
} );
В настоящий файл мы, вероятно, добавим больше заголовков, таких как ссылки на плагин и автора, описание, лицензия и т. Д.
Плагин Гист
Хорошо, мы закончили с нашим плагином. Весь код можно найти в Гисте здесь .
Добавление страниц
Плагин готов и работает, но мы не добавили ни одной страницы.
Это можно сделать внутри самого плагина, внутри темы functions.php
, в другом плагине и т. Д.
Добавить страницы это просто вопрос:
<?php
add_action( 'gm_virtual_pages', function( $controller ) {
// first page
$controller->addPage( new \GM\VirtualPages\Page( '/custom/page' ) )
->setTitle( 'My First Custom Page' )
->setTemplate( 'custom-page-form.php' );
// second page
$controller->addPage( new \GM\VirtualPages\Page( '/custom/page/deep' ) )
->setTitle( 'My Second Custom Page' )
->setTemplate( 'custom-page-deep.php' );
} );
И так далее. Вы можете добавить все нужные вам страницы, просто не забудьте использовать относительные URL-адреса для страниц.
Внутри файла шаблона вы можете использовать все теги шаблонов WordPress и написать все необходимые вам PHP и HTML.
Глобальный почтовый объект заполнен данными, поступающими с нашей виртуальной страницы. Сама виртуальная страница может быть доступна через $wp_query->virtual_page
переменную.
Получить URL для виртуальной страницы так же просто, как перейти по home_url()
тому же пути, который использовался для создания страницы:
$custom_page_url = home_url( '/custom/page' );
Обратите внимание, что в основном цикле в загруженном шаблоне the_permalink()
будет возвращена правильная постоянная ссылка на виртуальную страницу.
Заметки о стилях / скриптах для виртуальных страниц
Возможно, когда добавляются виртуальные страницы, желательно также ставить в очередь пользовательские стили / сценарии, а затем просто использовать их wp_head()
в пользовательских шаблонах.
Это очень просто, потому что виртуальные страницы легко распознаются по $wp_query->virtual_page
переменным, а виртуальные страницы можно отличить друг от друга по их URL.
Просто пример:
add_action( 'wp_enqueue_scripts', function() {
global $wp_query;
if (
is_page()
&& isset( $wp_query->virtual_page )
&& $wp_query->virtual_page instanceof \GM\VirtualPages\PageInterface
) {
$url = $wp_query->virtual_page->getUrl();
switch ( $url ) {
case '/custom/page' :
wp_enqueue_script( 'a_script', $a_script_url );
wp_enqueue_style( 'a_style', $a_style_url );
break;
case '/custom/page/deep' :
wp_enqueue_script( 'another_script', $another_script_url );
wp_enqueue_style( 'another_style', $another_style_url );
break;
}
}
} );
Примечания к ОП
Передача данных со страницы на другую не связана с этими виртуальными страницами, а является общей задачей.
Однако, если у вас есть форма на первой странице, и вы хотите передать данные оттуда на вторую страницу, просто используйте URL-адрес второй страницы в action
свойстве формы .
Например, в файле шаблона первой страницы вы можете:
<form action="<?php echo home_url( '/custom/page/deep' ); ?>" method="POST">
<input type="text" name="testme">
</form>
а затем во второй файл шаблона страницы:
<?php $testme = filter_input( INPUT_POST, 'testme', FILTER_SANITIZE_STRING ); ?>
<h1>Test-Me value form other page is: <?php echo $testme; ?></h1>