Quando você visita uma página de front-end, o WordPress consulta o banco de dados e, se sua página não existir no banco de dados, essa consulta não é necessária e é apenas um desperdício de recursos.
Felizmente, o WordPress oferece uma maneira de lidar com solicitações de front-end de maneira personalizada. Isso é feito graças ao 'do_parse_request'filtro.
Voltando falseao assunto, você poderá impedir o WordPress de processar solicitações e fazê-lo da sua maneira personalizada.
Dito isso, quero compartilhar uma maneira de criar um plug-in OOP simples que possa lidar com páginas virtuais de uma maneira fácil de usar (e reutilizar).
O que precisamos
- Uma classe para objetos de página virtual
- Uma classe de controlador, que examinará uma solicitação e, se for para uma página virtual, mostrá-la usando o modelo apropriado
- Uma classe para carregamento de modelo
- Principais arquivos de plug-in para adicionar os ganchos que farão tudo funcionar
Interfaces
Antes de criar classes, vamos escrever as interfaces para os 3 objetos listados acima.
Primeiro a interface da página (arquivo 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();
}
A maioria dos métodos são apenas getters e setters, sem necessidade de explicação. O último método deve ser usado para obter um WP_Postobjeto de uma página virtual.
A interface do controlador (arquivo 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 );
}
e a interface do carregador de modelos (arquivo 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();
}
Os comentários do phpDoc devem ser bem claros para essas interfaces.
O plano
Agora que temos interfaces, e antes de escrever classes concretas, vamos revisar nosso fluxo de trabalho:
- Primeiro, instanciamos uma
Controllerclasse (implementando ControllerInterface) e injetamos (provavelmente em um construtor) uma instância da TemplateLoaderclasse (implementando TemplateLoaderInterface)
- No
initgancho, chamamos o ControllerInterface::init()método para configurar o controlador e acionar o gancho que o código do consumidor usará para adicionar páginas virtuais.
- Em 'do_parse_request' vamos chamar
ControllerInterface::dispatch(), e não vamos verificar todas as páginas virtuais adicionado e se um deles tem o mesmo URL da solicitação atual, exibi-lo; depois de definir todas as principais variáveis globais ( $wp_query, $post). Também usaremos a TemplateLoaderclasse para carregar o modelo certo.
Durante este fluxo de trabalho que irá desencadear alguns ganchos do núcleo, como wp, template_redirect, template_include... para fazer o plugin mais flexível e garantir a compatibilidade com núcleo e outros plugins, ou pelo menos com um bom número deles.
Além do fluxo de trabalho anterior, também precisamos:
- Limpe ganchos e variáveis globais após a execução do loop principal, novamente para melhorar a compatibilidade com o código principal e de terceiros
- Adicione um filtro
the_permalinkpara fazê-lo retornar o URL da página virtual correta quando necessário.
Classes de concreto
Agora podemos codificar nossas classes concretas. Vamos começar com a classe da página (arquivo 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;
}
}
Nada mais do que implementar a interface.
Agora a classe do controlador (arquivo 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();
}
}
Essencialmente, a classe cria um SplObjectStorageobjeto em que todos os objetos das páginas adicionadas são armazenados.
Em 'do_parse_request', a classe do controlador faz um loop nesse armazenamento para encontrar uma correspondência para o URL atual em uma das páginas adicionadas.
Se for encontrada, a classe fará exatamente o que planejamos: acionar alguns ganchos, configurar variáveis e carregar o modelo por meio da extensão da classe TemplateLoaderInterface. Depois disso, apenas exit().
Então, vamos escrever a última aula:
<?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;
}
}
}
Os modelos armazenados na página virtual são mesclados em uma matriz com os padrões page.phpe index.php, antes de o modelo de carregamento 'template_redirect'ser acionado, para adicionar flexibilidade e melhorar a compatibilidade.
Depois disso, o modelo encontrado passa pelos filtros personalizados 'virtual_page_template'e principais 'template_include': novamente para flexibilidade e compatibilidade.
Finalmente, o arquivo de modelo é carregado apenas.
Arquivo principal do plugin
Nesse ponto, precisamos escrever o arquivo com os cabeçalhos do plug-in e usá-lo para adicionar os ganchos que farão nosso fluxo de trabalho acontecer:
<?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;
} );
No arquivo real, provavelmente adicionaremos mais cabeçalhos, como links para plugins e autores, descrição, licença, etc.
Gist de plug-ins
Ok, terminamos com o nosso plugin. Todo o código pode ser encontrado em um Gist aqui .
Adicionando páginas
O plug-in está pronto e funcionando, mas não adicionamos nenhuma página.
Isso pode ser feito dentro do próprio plugin, dentro do tema functions.php, em outro plugin, etc.
Adicionar páginas é apenas uma questão de:
<?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' );
} );
E assim por diante. Você pode adicionar todas as páginas necessárias, lembre-se de usar URLs relativos para as páginas.
Dentro do arquivo de modelo, você pode usar todas as tags de modelo do WordPress e escrever todo o PHP e HTML necessário.
O objeto global de postagem é preenchido com dados provenientes de nossa página virtual. A própria página virtual pode ser acessada via $wp_query->virtual_pagevariável.
Para obter o URL de uma página virtual, é tão fácil quanto passar para home_url()o mesmo caminho usado para criar a página:
$custom_page_url = home_url( '/custom/page' );
Observe que no loop principal do modelo carregado, the_permalink()retornará o link permanente correto para a página virtual.
Notas sobre estilos / scripts para páginas virtuais
Provavelmente, quando as páginas virtuais são adicionadas, também é desejável ter estilos / scripts personalizados enfileirados e usar apenas wp_head()em modelos personalizados.
Isso é muito fácil, porque as páginas virtuais são facilmente reconhecidas olhando para $wp_query->virtual_pagevariáveis e as páginas virtuais podem ser distinguidas uma da outra olhando para seus URLs.
Apenas um exemplo:
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;
}
}
} );
Notas para OP
A passagem de dados de uma página para outra não está relacionada a essas páginas virtuais, mas é apenas uma tarefa genérica.
No entanto, se você possui um formulário na primeira página e deseja passar dados de lá para a segunda página, basta usar o URL da segunda página na actionpropriedade de formulário .
Por exemplo, no primeiro arquivo de modelo de página, você pode:
<form action="<?php echo home_url( '/custom/page/deep' ); ?>" method="POST">
<input type="text" name="testme">
</form>
e depois no arquivo de modelo da segunda página:
<?php $testme = filter_input( INPUT_POST, 'testme', FILTER_SANITIZE_STRING ); ?>
<h1>Test-Me value form other page is: <?php echo $testme; ?></h1>