Estoy desarrollando un complemento en el que me gustaría habilitar páginas personalizadas. En mi caso, alguna página personalizada contendría un formulario como formulario de contacto (no literalmente). Cuando el usuario complete este formulario y lo envíe, debe haber el siguiente paso que requerirá más información. Digamos que la primera página con el formulario se ubicaría en www.domain.tld/custom-page/
y después del envío exitoso del formulario, el usuario debería ser redirigido a www.domain.tld/custom-page/second
. La plantilla con elementos HTML y código PHP también debe ser personalizada.
Creo que es posible lograr una parte del problema con reescrituras de URL personalizadas, pero las otras partes son actualmente desconocidas para mí. Realmente no sé dónde debería comenzar a buscar y cuál es el nombre correcto para ese problema. Cualquier ayuda sería muy apreciada.
fuente
Respuestas:
Cuando visita una página frontend, WordPress consultará la base de datos y si su página no existe en la base de datos, esa consulta no es necesaria y es solo un desperdicio de recursos.
Afortunadamente, WordPress ofrece una forma de manejar solicitudes frontend de una manera personalizada. Eso se hace gracias al
'do_parse_request'
filtro.Volviendo
false
a ese gancho, podrá evitar que WordPress procese solicitudes y hacerlo de manera personalizada.Dicho esto, quiero compartir una forma de construir un complemento OOP simple que pueda manejar páginas virtuales de una manera fácil de usar (y reutilizar).
Lo que necesitamos
Interfaces
Antes de construir clases, escribamos las interfaces para los 3 objetos enumerados anteriormente.
Primero la interfaz de la página (archivo
PageInterface.php
):La mayoría de los métodos son solo getters y setters, sin necesidad de explicación. El último método debe usarse para obtener un
WP_Post
objeto de una página virtual.La interfaz del controlador (archivo
ControllerInterface.php
):y la interfaz del cargador de plantillas (archivo
TemplateLoaderInterface.php
):Los comentarios de phpDoc deberían ser bastante claros para estas interfaces.
El plan
Ahora que tenemos interfaces, y antes de escribir clases concretas, repasemos nuestro flujo de trabajo:
Controller
clase (implementandoControllerInterface
) e inyectamos (probablemente en un constructor) una instancia deTemplateLoader
clase (implementandoTemplateLoaderInterface
)init
gancho, llamamos alControllerInterface::init()
método para configurar el controlador y disparar el gancho que el código del consumidor usará para agregar páginas virtuales.ControllerInterface::dispatch()
, y allí revisaremos todas las páginas virtuales agregadas y si una de ellas tiene la misma URL de la solicitud actual, muéstrela; después de haber establecido todas las variables globales centrales ($wp_query
,$post
). También usaremosTemplateLoader
class para cargar la plantilla correcta.Durante este flujo de trabajo vamos a desencadenar algunos ganchos básicos, como
wp
,template_redirect
,template_include
... para hacer el plugin más flexible y asegurar la compatibilidad con el núcleo y otros plugins, o al menos con un número bueno de ellos.Además del flujo de trabajo anterior, también tendremos que:
the_permalink
para que devuelva la URL de página virtual correcta cuando sea necesario.Clases de hormigón
Ahora podemos codificar nuestras clases concretas. Comencemos con la clase de página (archivo
Page.php
):Nada más que implementar la interfaz.
Ahora la clase de controlador (archivo
Controller.php
):Esencialmente, la clase crea un
SplObjectStorage
objeto donde se almacenan todos los objetos de páginas agregados.Encendido
'do_parse_request'
, la clase de controlador repite este almacenamiento para encontrar una coincidencia para la URL actual en una de las páginas agregadas.Si se encuentra, la clase hace exactamente lo que planeamos: desencadenar algunos ganchos, configurar variables y cargar la plantilla a través de la extensión de la clase
TemplateLoaderInterface
. Después de eso, soloexit()
.Entonces, escribamos la última clase:
Las plantillas almacenadas en la página virtual se fusionan en una matriz con valores predeterminados
page.php
yindex.php
, antes de que se active la carga de la plantilla'template_redirect'
, para agregar flexibilidad y mejorar la compatibilidad.Después de eso, la plantilla encontrada pasa a través de los filtros personalizados
'virtual_page_template'
y principales'template_include'
: nuevamente para mayor flexibilidad y compatibilidad.Finalmente, el archivo de plantilla se acaba de cargar.
Archivo de complemento principal
En este punto, necesitamos escribir el archivo con encabezados de plugin y usarlo para agregar los ganchos que harán que nuestro flujo de trabajo suceda:
En el archivo real probablemente agregaremos más encabezados, como plugins y enlaces de autor, descripción, licencia, etc.
Plugin Gist
Ok, hemos terminado con nuestro complemento. Todo el código se puede encontrar en un Gist aquí .
Agregar páginas
El complemento está listo y funcionando, pero no hemos agregado ninguna página.
Eso se puede hacer dentro del complemento en sí, dentro del tema
functions.php
, en otro complemento, etc.Agregar páginas es solo una cuestión de:
Y así. Puede agregar todas las páginas que necesita, solo recuerde usar URL relativas para las páginas.
Dentro del archivo de plantilla puede usar todas las etiquetas de plantilla de WordPress, y puede escribir todo el PHP y HTML que necesite.
El objeto de publicación global se llena con datos procedentes de nuestra página virtual. Se puede acceder a la página virtual en sí a través de la
$wp_query->virtual_page
variable.Para obtener la URL de una página virtual es tan fácil como pasar a
home_url()
la misma ruta utilizada para crear la página:Tenga en cuenta que en el bucle principal de la plantilla cargada,
the_permalink()
devolverá el enlace permanente correcto a la página virtual.Notas sobre estilos / scripts para páginas virtuales
Probablemente cuando se agregan páginas virtuales, también es deseable tener estilos / scripts personalizados en cola y luego usarlos
wp_head()
en plantillas personalizadas.Eso es muy fácil, porque las páginas virtuales se reconocen fácilmente mirando
$wp_query->virtual_page
páginas variables y las páginas virtuales se pueden distinguir una de otra mirando sus URL.Solo un ejemplo:
Notas a OP
Pasar datos de una página a otra no está relacionado con estas páginas virtuales, pero es solo una tarea genérica.
Sin embargo, si tiene un formulario en la primera página y desea pasar datos desde allí a la segunda página, simplemente use la URL de la segunda página en la
action
propiedad de formulario .Por ejemplo, en el primer archivo de plantilla de página puede:
y luego en el segundo archivo de plantilla de página:
fuente
wordpress/virtual-page
y la URL recortada de la página esvirtual-page
.Una vez utilicé una solución descrita aquí: http://scott.sherrillmix.com/blog/blogger/creating-a-better-fake-post-with-a-wordpress-plugin/
En realidad, cuando lo estaba usando, extiendo la solución de una manera que puedo registrar más de una página a la vez (el resto de un código es +/- similar a la solución que estoy vinculando desde el párrafo anterior).
La solución requiere que tengas enlaces permanentes permitidos aunque ...
fuente
content
en la matriz cuando está registrando, la página falsa se muestra en el cuerpo de la página; puede contener un HTML, así como texto simple o incluso un código corto.