Spanish (Español) translation by Eva Collados Pascual (you can also view the original English article)
En mi última serie de artículos, examinamos los conceptos de programación orientada a objetos desde la perspectiva de un principiante. El objetivo de la serie era iniciar a aquellos que no estaban familiarizados con la programación orientada a objetos en PHP, y explorar los aspectos fundamentales del paradigma dentro del contexto de WordPress.
Si no tuviste la oportunidad de leer la serie, puedes leer un breve resumen (acompañados de enlaces a cada artículo de la serie) en el artículo final.
Durante el transcurso de la serie, una de las cosas que hicimos para ayudar a demostrar los principios de la orientación a objetos, así como algunas de las características de la API de WordPress fue construir un plugin.
Específicamente, creamos un plugin que nos permitió ver todos los metadatos de entrada asociados con una entrada dada dentro del escritorio de WordPress.
El plugin está disponible para su descarga en GitHub donde también puedes navegar por el código fuente, ver los comentarios del código, y en general onbservar todo lo que intervino en la creación del plugin cuando lo desarrollamos.
Desde que se escribió esa entrada en particular, he recibido una serie de distintas preguntas una de las cuales era en relación a cómo tomamos los datos que se muestran en el escritorio, es decir, los metadatos de la entrada, y mostrarlo en el front-end del sitio web.
En este artículo, vamos a echar un vistazo a la extensión del plugin de tal manera que podamos mostrar los datos en la página de una única entrada. Vamos a hablar sobre cómo hacer esto dado nuestro existente código, cómo hacerlo, y también vamos a hablar sobre por qué esto podría no ser una buena idea.
Así que, dicho esto, empecemos.
Ramificaciones de la ampliación del plugin
Antes de empezar a planear cómo vamos a expandir realmente el plugin, creo que vale la pena tener una breve discusión sobre por qué, aunque sea posible, mostrar este tipo de información en el frontend podría no ser una buena idea.
Es decir, creo que este es un caso sobre cómo, al tratar con ciertos tipos de datos, es importante tener en cuenta las ramificaciones de lo que optamos por hacer al crear productos para otros y cómo gestionamos los datos.
En resumen, sólo porque podamos hacer algo no significa que debamos hacerlo.
Una mirada a los datos
Piensa en ello de esta manera: Los metadatos que están asociados con una entrada dada se almacenan en la base de datos, algunos por WordPress, algunos por los temas, y otros por plugins, todos los cuales utilizan la información para sus propias necesidades específicas.
Si echas un vistazo a la anterior imagen, observarás que algunas filas se identifican con claves prefijadas por un guión bajo. Por ejemplo, tenemos _edit_lock y _edit_last y, a continuación, algunos valores numéricos. Este es un ejemplo de datos que WordPress utiliza para administrar internamente el estado de las entradas.
Las otras claves que ves tienen que ver con plugins que he instalado en mi instalación local de WordPress y se utilizan para demostrar cómo otras utilidades pueden guardar datos en la tabla de metadatos y luego relacionarlos con la entrada en cuestión.
¿Cuál es el problema?
El problema con la visualización de toda esta información en el front-end es que podrías acabar mostrando demasiada información al usuario.
En el caso anterior, no hay nada que sea particularmente peligroso o sensible como para que pueda comprometer la instalación, pero eso no significa que vaya a ser siempre así. Aún más, hay una posibilidad significativa de que acabes mostrando información que esté relacionada con un plugin o un tema cuya información nunca quisiste mostrar.
Además, para muchas, e incluso la mayoría, de las personas que visitan un blog, ver la información que se muestra en la parte delantera del blog se sentirá como ruido. Es la jerga técnica que no tendrá ningún significado. Esta es la razón por la que creo que mantener esta información relegada al escritorio es el mejor lugar para hacerlo.
Pero, ¿vamos a extender el plugin?
En resumen, sí, pero no porque crea que mostrar este tipo de información al usuario sea buena idea, sino porque hay una aplicación práctica que viene con la extensión de un plugin existente, los beneficios de aprovechar el código existente, y ver las ramificaciones negativas de hacer tal cosa.
Así que sí, a veces, las mejores lecciones pueden venir de la implementación de ideas que vistas en restrospectiva pueden no ser buenas.
Pero está bien. Así es como aprendemos, ¿verdad?
Además, todavía existen algunas lecciones prácticas que vienen con el aprendizaje de cómo ampliar una base de código existente.
Ampliación de Single Post Meta Manager
Al igual que sucede con todos los tutoriales que comparto, trato de planear exactamente qué vamos ha hacer antes de llevarlo a cabo para no estar escribiendo código en base a un montón de conjeturas, y así tener un plan de acción sobre cómo diseñar nuestra solución.
Por lo tanto, antes de ir más allá, si no has revisado el Single Post Meta Manager, por favor, házlo ahora y continuaremos.
Una vez hecho esto, aquí tienes lo que planeamos hacer:
- Usaremos el tema predeterminado twentyfourteen como base para nuestro ejemplo.
- Presentaremos un directorio público que se usará para mostrar la información en el lado público (
public) del blog, en concreto, en el contexto de las entradas individuales. - Definiremos enlaces que nos permitirán anexar información al contenido de la entrada para que los metadatos de esta se puedan mostrar en la parte inferior del contenido. Para esto usaremos una tabla rudimentaria que heredará los estilos del tema actual. Ten en cuenta que al hacer esto, puedes acabar teniendo algunos estilos realmente limpios, y algunos otros realmente débiles. Estos estarán a la espera de que los implementes por tu cuenta.
- A continuación, aprovecharemos la plantilla que creamos en la versión inicial del plugin para asegurarnos de recuperar los metadatos de la entrada para la entrada dada con el fin de mostrarlos en el front-end.
Nada demasiado complicado, ¿verdad? Sólo tenemos que ser precisos en nuestros pasos. Así que empecemos.
Presentar el directorio público
Suponiendo que ya tengas twentyfourteen activado y el plugin instalado, vamos a trabajar en la introducción de nuestra funcionalidad. Lo primero que tenemos que hacer es
- introducir un directorio
public - añadir la clase
Single_Post_Meta_Manager_Public - incluir la clase en el archivo principal del plugin
Después de añadir los archivos, lo anterior se puede hacer incluyendo las siguientes líneas de código en la función load_dependencies en includes/single-post-meta-manager.php.
1 |
private function load_dependencies() { |
2 |
|
3 |
require_once plugin_dir_path( dirname( __FILE__ ) ) . 'admin/class-single-post-meta-manager-admin.php'; |
4 |
require_once plugin_dir_path( dirname( __FILE__ ) ) . 'public/class-single-post-meta-manager-public.php'; |
5 |
|
6 |
require_once plugin_dir_path( __FILE__ ) . 'class-single-post-meta-manager-loader.php'; |
7 |
$this->loader = new Single_Post_Meta_Manager_Loader(); |
8 |
|
9 |
}
|
Observa que la única nueva línea es la segunda instrucción require_once que importa el archivo de clase.
Después de eso, vamos a definir las propiedades, el constructor y los métodos para la clase Single_Post_Meta_Manager_Public:
1 |
<?php
|
2 |
/**
|
3 |
* The Single Post Meta Manager Public defines all functionality for the public-facing
|
4 |
* sides of the plugin
|
5 |
*
|
6 |
* @package SPMM
|
7 |
*/
|
8 |
|
9 |
/**
|
10 |
* The Single Post Meta Manager Public defines all functionality for the public-facing
|
11 |
* sides of the plugin.
|
12 |
*
|
13 |
* This class defines the meta box used to display the post meta data and registers
|
14 |
* the style sheet responsible for styling the content of the meta box.
|
15 |
*
|
16 |
* @since 1.0.0
|
17 |
*/
|
18 |
class Single_Post_Meta_Manager_Public { |
19 |
|
20 |
/**
|
21 |
* A reference to the version of the plugin that is passed to this class from the caller.
|
22 |
*
|
23 |
* @access private
|
24 |
* @var string $version The current version of the plugin.
|
25 |
*/
|
26 |
private $version; |
27 |
|
28 |
/**
|
29 |
* Initializes this class and stores the current version of this plugin.
|
30 |
*
|
31 |
* @param string $version The current version of this plugin.
|
32 |
*/
|
33 |
public function __construct( $version ) { |
34 |
$this->version = $version; |
35 |
}
|
36 |
|
37 |
/**
|
38 |
* Uses the partial located in the admin directory for rendering the
|
39 |
* post meta data the end of the post content.
|
40 |
*
|
41 |
* @param string $content The post content.
|
42 |
* @return string $content The post content including the given posts meta data.
|
43 |
*/
|
44 |
public function display_post_meta_data( $content ) { |
45 |
|
46 |
ob_start(); |
47 |
|
48 |
require_once plugin_dir_path( dirname( __FILE__ ) ) . 'admin/partials/single-post-meta-manager.php'; |
49 |
$template = ob_get_contents(); |
50 |
$content .= $template; |
51 |
|
52 |
ob_end_clean(); |
53 |
|
54 |
return $content; |
55 |
|
56 |
}
|
57 |
|
58 |
}
|
A continuación, necesitamos crear la función define_public_hooks de Single Post Meta Manager. Esto debería tener este aspecto:
1 |
<?php
|
2 |
/**
|
3 |
* Defines the hooks and callback functions that are used for rendering information on the front
|
4 |
* end of the site.
|
5 |
*
|
6 |
* This function relies on the Single Post Meta Manager Public class and the Single Post Meta Manager
|
7 |
* Loader class property.
|
8 |
*
|
9 |
* @access private
|
10 |
*/
|
11 |
private function define_public_hooks() { |
12 |
|
13 |
$public = new Single_Post_Meta_Manager_Public( $this->get_version() ); |
14 |
$this->loader->add_action( 'the_content', $public, 'display_post_meta_data' ); |
15 |
|
16 |
}
|
A continuación, necesitamos definir una llamada a esta función dentro del constructor. Es decir, justo bajo la línea $this->define_admin_hooks();, añadimos la llamada $this->define_public_hooks();.
Suponiendo que todo ha ido bien, deberías ser capaz de activar el plugin, cargar cualquier entrada, y ver ahora los mismos metadatos mostrandose en la parte pública de la entrada, así como en la página de edición de la misma:
Resumen
Como se mencionó anteriormente en este tutorial, mostrar este tipo de información en el front-end de una entrada no es necesariamente la mejor idea; sin embargo, aprender a añadirla de forma práctica a un plugin existente introducirá una funcionalidad completamente nueva al mismo tiempo que reutiliza algunos de los componentes existentes.
En última instancia, el aporte clave es doble:
- Aprovechar el código existente es algo poderoso
- Exponer datos que son irrelevantes para los usuarios es una idea peligrosa
Así que después de leer este tutorial en concreto, ten en cuenta que no estoy necesariamente respaldando que se haga esto en un entorno a nivel de producción, sino más bien como una herramienta de aprendizaje. Es decir, úsalo bajo tu propio riesgo.
Como de costumbre, por favor, ¡deja todas tus consultas, comentarios, o cualquier idea en el feed de abajo!
By
