Share
En el artículo anterior de esta serie, finalmente comenzamos a preparar las bases para el complemento que vamos a escribir..
Específicamente, echamos un vistazo a la organización de archivos, los componentes y los detalles reales de lo que hará el complemento. También eliminamos el código que completaremos en este tutorial..
Además de hacer que nuestro complemento realmente haga algo, vamos a hablar sobre varios principios, técnicas e ideas orientadas a objetos diferentes a medida que trabajamos a través del complemento..
Tenga en cuenta que en este tutorial vamos a hacer muy poca documentación. Hemos cubierto los detalles sobre esto en el artículo anterior; sin embargo, estaremos hablando Más al respecto en el articulo siguiente a este.
Al igual que con el resto de los artículos de esta serie, asegúrese de ponerse al día con todo lo que hemos cubierto hasta ahora en la serie, ya que todo lo que estamos haciendo se basa en los temas anteriores..
Para referencia, hemos cubierto:
Con eso dicho, vamos a continuar donde lo dejamos.
Cuando se trata de escribir software, independientemente del paradigma que se esté utilizando, no se hace de manera lineal. Es decir, no necesariamente estamos escribiendo en el punto de inicio del programa. Muchas veces, aunque no siempre, esa podría ser una de las últimas partes que consideramos correctas..
Dicho esto, vamos a comenzar a trabajar en cada archivo que conforma el complemento de una manera que tenga sentido a medida que trabajamos a través del complemento. Con eso, quiero decir que a medida que trabajamos en este artículo, las cosas pueden parecer dispersas al principio, pero esperamos que se vuelvan un poco más claras al mirar cada archivo..
La primera clase que vamos a completar se encuentra en incluye / class-single-post-meta-manager-loader.php. Si recuerda el artículo anterior, esta clase es responsable de coordinar acciones y filtros entre el complemento central y la clase de administración..
En cierto sentido, proporciona una envoltura alrededor de las API nativas de WordPress; sin embargo, nos permite separar (y por lo tanto imponer una separación de preocupaciones) nuestras clases para que cada uno pueda especializarse en un propósito específico.
Primero, echemos un vistazo a la clase:
Accentsconagua
acciones = array (); $ this-> filters = array (); función pública add_action ($ hook, $ component, $ callback) $ this-> actions = $ this-> add ($ this-> actions, $ hook, $ component, $ callback); función pública add_filter ($ hook, $ component, $ callback) $ this-> filters = $ this-> add ($ this-> filters, $ hook, $ component, $ callback); función privada add ($ hooks, $ hook, $ component, $ callback) $ hooks [] = array ('hook' => $ hook, 'component' => $ component, 'callback' => $ callback); devuelve $ ganchos; función pública run () foreach ($ this-> se filtra como $ hook) add_filter ($ hook ['hook'], array ($ hook ['component'], $ hook ['callback'])); foreach ($ this-> actions as $ hook) add_action ($ hook ['hook'], array ($ hook ['component'], $ hook ['callback'])); En este punto de la serie, deberías notar varias cosas clave sobre la clase en base a las discusiones que hemos tenido hasta ahora en la serie..
protegido atribuciones cada uno de los cuales se refieren a matrices como se define en el constructor. Uno está designado para acciones, el otro para filtros..público funciones Uno está diseñado para agregar acciones fácilmente, el otro está diseñado para agregar filtros fácilmente. Tenga en cuenta que cada uno acepta tres componentes: el nombre del gancho, el objeto principal que tiene la función que se debe llamar y la función que se debe llamar durante la ejecución real del gancho. Para más información sobre acciones y filtros, vea esta referencia..privado Función que se utiliza para simplificar los dos anteriores. público funciones tales que tenemos un solo lugar para agregar el gancho a la matriz adecuada.correr La función es la que se utiliza para cablear todos los ganchos definidos. Esto es lo que registrará todas nuestras funciones personalizadas con WordPress.A medida que continuamos compilando el resto del complemento, veremos esta clase en particular en uso..
Esta parte del complemento contiene todos los archivos que se encuentran en el administración directorio. Si recuerda el artículo anterior, tenemos una clase principal, una hoja de estilo y un solo archivo que se utiliza para representar la vista del contenido..
Examinaremos cada uno de estos archivos para que se utilicen a partir de la clase de administrador central..
Esta es la clase principal responsable de registrar las hojas de estilo, el cuadro de metadatos e incluir el archivo que representará el contenido del cuadro de metadatos..
Echemos un vistazo al código completo y luego revisaremos lo que está haciendo.
version = $ version; public function enqueue_styles () wp_enqueue_style ('single-post-meta-manager-admin', plugin_dir_url (__FILE__). 'css / single-post-meta-manager-admin.css', array (), $ this-> versión, FALSO); función pública add_meta_box () add_meta_box ('single-post-meta-manager-admin', 'Single Post Meta Manager', matriz ($ this, 'render_meta_box'), 'post', 'normal', 'core') ; función pública render_meta_box () require_once plugin_dir_path (__FILE__). 'partials / single-post-meta-manager.php'; Esta es una clase relativamente simple que asume que estás familiarizado con wp_enqueue_style y add_meta_box. Si no, revise los artículos vinculados y luego vuelva a esta publicación..
A continuación, echemos un vistazo a lo que está haciendo el resto de la clase:
privado atributo que se utiliza para rastrear la versión del complemento. Este valor se pasa al constructor de la clase y se usa principalmente para asegurarnos de que estamos incluyendo la versión más reciente del complemento al poner en cola nuestras hojas de estilo para asegurarnos de que estamos eliminando los archivos que se pueden almacenar en caché cuando se ejecuta este plugin.público función que se usa para registrar la hoja de estilo asociada con el tablero, y tenemos una función pública que se usa para agregar un meta box a la enviar tipo tablero de instrumentos.Aunque veremos que todo se desarrolla con más detalle más adelante, es posible que empiece a notar que la función que pone en cola las hojas de estilo no está referenciada en ningún otro lugar. Aquí es donde el Cargador la clase eventualmente entrará en juego.
A algunos desarrolladores les gusta escribir el marcado para las vistas de meta box dentro de PHP y almacenarlas en cadenas realmente largas.
No soy un fanático de ese enfoque porque las vistas (o parciales o plantillas, o como quiera llamarlas) y normalmente se usan para mostrar datos y, por lo tanto, consisten en más marcas que cualquier otra cosa. Para ello, creo que deberían ser su propio archivo..
En este caso, queremos tener un archivo que muestre todos los metadatos asociados con la publicación actual en un mesa Elemento que está contenido dentro de la caja meta.
El marcado para este archivo se ve así:
$ post_meta_value) ?>
A pesar de que el marcado y el PHP mínimo que está contenido en este archivo deben ser relativamente auto-explicativos, hace depende de su conocimiento de la get_post_meta y get_the_ID funciones.
Una vez que se recuperan todos los metadatos de la publicación, luego hacemos un bucle a través de la información (usando una de las construcciones de bucle que cubrimos mucho antes) y luego mostramos tanto la clave meta como el valor.
Lo último que debemos hacer para el contenido en el cuadro de meta es proporcionar los estilos en la hoja de estilo que hemos puesto en la clase de administración central..
Para ello, editaremos. css / simple-post-meta-manager.css.
# single-post-meta-manager-data width: 100%; # single-post-meta-manager-data .key font-weight: bold;
Obviamente, esto es muy simple. No proporciona nada sofisticado que no sea establecer el ancho de la tabla al 100% de su contenedor, y pone en negrita los valores de la clave meta.
Pero eso es suficiente para lo que estamos buscando hacer ahora..
En este punto, necesitamos definir el archivo del complemento del núcleo. Este es el archivo que define la versión del complemento, la bala del complemento (que normalmente se usa en la internacionalización y otras características), crea una instancia del cargador y registra todos los enganches necesarios con WordPress..
Echemos un vistazo al código, luego revisémoslo una vez que tengamos todo definido:
plugin_slug = 'single-post-meta-manager-slug'; $ this-> version = '0.2.0'; $ this-> load_dependencies (); $ this-> define_admin_hooks (); función privada load_dependencies () require_once plugin_dir_path (dirname (__FILE__)). 'admin / class-single-post-meta-manager-admin.php'; require_once plugin_dir_path (__FILE__). 'class-single-post-meta-manager-loader.php'; $ this-> loader = new Single_Post_Meta_Manager_Loader (); función privada define_admin_hooks () $ admin = new Single_Post_Meta_Manager_Admin ($ this-> get_version ()); $ this-> loader-> add_action ('admin_enqueue_scripts', $ admin, 'enqueue_styles'); $ this-> loader-> add_action ('add_meta_boxes', $ admin, 'add_meta_box'); función pública run () $ this-> loader-> run (); public function get_version () return $ this-> version; La clase contiene los siguientes atributos:
Los atributos anteriores están todos configurados en el constructor, pero también hay llamadas a otras funciones.
dependencias de carga se utiliza para importar todos los archivos que se utilizan en este complemento, como el Administrador de administración y el Cargador.define_admin_hooks Así es como aprovechamos el cargador para coordinar las funciones definidas en nuestra clase de administrador que ponen en cola nuestros estilos y nuestro meta box con WordPress. Así es como estamos separando las preocupaciones de nuestro complemento y asegurándonos de que cada clase sea un solo propósito..correr es la función que pone todo en movimiento para que toda la funcionalidad del complemento se ejecute cuando se active dentro de WordPress.Excepto que todavía nos falta una pieza final: ¿cómo podemos crear una instancia de la clase del complemento central y comenzar el proceso??
Para hacer esto, aprovechamos un archivo ubicado en la raíz del directorio del complemento. Algunas personas lo llaman un archivo bootstrap de complementos, otros lo llaman un gestor de arranque, y algunos lo llaman el archivo principal de complementos.
Como sea que optes por llamarlo, este es el archivo que se registra a sí mismo con WordPress y que pone todo en movimiento. Echemos un vistazo al código y luego revisaremos lo que hace después:
correr(); run_single_post_meta_manager ();
El comentario del código en la parte superior del archivo es responsable de decirle a WordPress que existe el complemento y de proporcionarle suficiente información sobre el complemento para que pueda mostrarlo dentro del panel..
El primer condicional que ve evita que se pueda acceder directamente al archivo de complemento. Esto no es más que una simple medida de seguridad..
Finalmente, hacemos una llamada a requerir una vez para incluir el archivo del complemento del núcleo que vimos anteriormente, y luego definimos una función y creamos una instancia de la Single_Post_Meta_Manager y después de lo cual llamamos correr que es lo que pone todo en movimiento.
Finalmente, hacemos una llamada a la función que definimos al final del archivo. Esto da inicio al proceso y le da vida al plugin..
En este punto, hemos completado la funcionalidad de nuestro complemento; Sin embargo, todavía no hemos terminado. Todavía hay una cosa más que debemos hacer para asegurarnos de que seguimos todas las mejores prácticas que se incluyen en un complemento y eso es proporcionar documentación..
En la próxima publicación, haremos una pausa en los artículos más largos del código de escritura, revisaremos los Estándares de documentación de WordPress y luego documentaremos el complemento para que podamos completar completamente su funcionalidad..
Mientras tanto, descargue el complemento de ejemplo, explore cómo encaja todo y asegúrese de dejar cualquier comentario o pregunta que tenga sobre nuestro trabajo hasta el momento..
