Share
Trabajar en la comunidad de WordPress es tanto una bendición como una maldición. Debido a su naturaleza de código abierto, tenemos una plataforma fantástica en la que construir sitios web, temas, complementos e incluso aplicaciones. Tiene una comunidad inteligente a su alrededor, una rica documentación y estándares que pretenden proporcionar la manera escribir código para ello y la manera para construir herramientas a su alrededor.
Al mismo tiempo, la naturaleza de código abierto de WordPress, así como los idiomas con los que se construye, permiten a cualquier persona enviar su trabajo independientemente de si está a la altura de cualquier tipo de estándar o utiliza algún tipo de práctica recomendada. Para muchos usuarios, no se dan cuenta de lo que sucede debajo del capó. Si el producto funciona, están contentos..
Como personas que toman en serio su oficio, absolutamente no podemos conformarnos con "solo hacer que funcione". Nosotros tener preocuparse por lo que hay debajo del capó.
Si eres un desarrollador serio de WordPress, es probable que ya tengas un método para trabajar, pero si recién estás comenzando o buscas definirte como un desarrollador profesional de WordPress, existen estrategias, entornos y herramientas. que puede utilizar que puede ayudar.
En esta serie de tres artículos, vamos a ver exactamente qué son y cómo se aplican en nuestro trabajo de proyecto. Primero, comenzaremos con estrategias..
Una parte importante del software de construcción es en realidad mantenerlo después del lanzamiento inicial. La verdad es que realmente se gasta más tiempo en mantener proyectos que en construirlos. Tiene sentido, ¿verdad? Existe un producto por mucho más tiempo del que se necesita para crearlo y, si se asume que es de alta calidad, los usuarios encontrarán errores y solicitarán nuevas funciones..
Desafortunadamente, se gasta una cantidad significativa de tiempo de mantenimiento para resolver un error o agregar rápidamente una nueva función y, por lo general, se hace de una manera que se enfoca más en solo hacerlo en lugar de hacerlo correctamente. Esto tampoco es completamente incorrecto: cuando un producto está vinculado directamente a los resultados de una empresa, entonces el tiempo es una prioridad.
Pero hay cosas que se pueden hacer durante el desarrollo inicial que pueden hacer mucho para facilitar el mantenimiento de un producto después de su lanzamiento..
El Códice de WordPress proporciona una guía completa sobre cómo crear temas. Cubre guías de hojas de estilo, archivos de plantillas, información de JavaScript, pautas de prueba, listas de verificación y varias referencias. Incluso si está en el negocio de crear temas, le recomiendo revisar esta lista de vez en cuando.
Además de seguir el conjunto básico de pautas, hay cosas adicionales que se pueden hacer para mejorar el mantenimiento. Suponiendo que está siguiendo las directrices del Codex para la creación de temas, considere lo siguiente con respecto a algunos de sus activos y dependencias.
Una de las cosas que hago para cada uno de mis proyectos es asegurarme de que tengo directorios específicos para los activos que están fuera de los archivos normales requeridos para el desarrollo del tema. Con esto quiero decir que tengo directorios específicos para:
Por supuesto, cada tema requiere al menos una sola hoja de estilo, pero digamos que vas a proporcionar hojas de estilo específicamente para el tablero administrativo. Para el mantenimiento, es mejor mantenerlos separados que en una sola hoja de estilo y luego permitir que una herramienta los combine antes de lanzarlos..
Examinaremos las herramientas para esto exactamente en el artículo final de la serie..
Independientemente de dónde se encuentre en esto, hacer un poco de planificación por adelantado puede hacer mucho para tener un conjunto de activos bien organizado.
A medida que consideramos cómo organizar mejor nuestros diversos activos, las convenciones de nomenclatura pueden ayudar a proporcionar un nivel de claridad y proporcionar un estándar según el cual todos los archivos relacionados deben seguir. Por ejemplo, en cada uno de mis proyectos normalmente hago lo siguiente:
Por supuesto, hay algunos JavaScript universales y hojas de estilo que se aplican en todo el tema. En este caso, simplemente mantengo un conjunto de admin.css y style.css archivos.
La mayoría de los desarrolladores de WordPress saben que los complementos deben ser temáticos. Es decir, no deben depender de una característica de ningún tema dado ni deben imponer ninguna de sus hojas de estilo o JavaScripts sobre el tema existente, excepto por su característica específica..
Además de eso, hay dos formas de desarrollar complementos:
Para ello, hay algunas estrategias que se pueden emplear al escribir sus complementos para asegurarse de que las hojas de estilo, JavaScript, imágenes y otros activos no entren en conflicto con el tema existente.
Cuando se trata de escribir complementos, las distintas API suelen facilitar la combinación y combinación de los idiomas que utilizas para crear tu complemento. Con eso, quiero decir que es completamente posible incluir todos los estilos, JavaScripts, HTML y PHP en un solo archivo y luego enviarlos.
Pero no soy fan de esto..
Por lo general, cada idioma tiene un propósito específico y, debido a eso, trato de mantener cada idioma en su propio archivo tanto como sea posible. Considera esto:
Como tal, creo que tiene más sentido mantener los archivos separados para que sepa dónde enfocarse cuando surge un problema o es el momento de introducir una nueva función..
Esto no significa que en ocasiones no tendrá PHP escrito en su marca o que no creará elementos HTML dinámicamente en el lado del servidor, sino que le proporcionará una base sobre la que organizará su trabajo..
Además de asegurarme de que cada conjunto de hojas de estilo y archivos JavaScript tengan un nombre claro, tiendo a seguir la misma estructura que hago para los temas y es nombrar el código administrativo específico con el prefijo administración y tema o código público específico con monitor.
Es una estrategia simple, pero permite optimizar la ubicación de sus archivos y mantener los problemas a medida que se presentan una vez que su trabajo está en libertad..
El punto que cubre esto no es imponer. mi forma de organizar archivos en su sistema o incluso decir que esta es una forma estándar de hacerlo. Está destinado a proporcionar un punto de partida para el cual puede mantener sus proyectos..
En última instancia, el objetivo es minimizar el mantenimiento tanto como sea posible. Tener convenciones de nomenclatura claramente definidas y un estándar de organización le permite saber exactamente cómo y dónde colocar sus archivos sin hacer ninguna conjetura y le permite a sus colaboradores y / o miembros de su equipo saber dónde enfocarse para localizar los problemas a medida que llegan.
Uno de los desafíos que enfrentan los desarrolladores es asegurarse de que estén familiarizados con las formas adecuadas de aprovechar la plataforma en la que están trabajando..
En su mayor parte, cada idioma, marco y biblioteca incluye algún tipo de documentación y WordPress no es diferente. La cuestión es que WordPress está compuesto de varias piezas diferentes, no solo es la aplicación creada con PHP, sino que también hay API específicas de la aplicación, así como bibliotecas como jQuery que son necesarias para tener como referencia..
Debido a que lleva mucho tiempo familiarizarse íntimamente con los entresijos de cada idioma, aplicación y biblioteca, los desarrolladores profesionales de WordPress generalmente tienen referencias disponibles. Para los desarrolladores de WordPress, las siguientes referencias son extremadamente valiosas.
En la mayoría de los casos, ya está: marque los marcadores o téngalos a disposición en su IDE (si lo admite), pase tiempo en cada uno de ellos y estará en el buen camino hacia prácticas de desarrollo profesional..
En cuanto a las estrategias, esto lo cubre. En pocas palabras, tenga una forma definida de organizar y nombrar sus archivos, asegúrese de seguir las mejores prácticas de la API central de WordPress, y asegúrese de consultar los distintos documentos de la API de idioma al momento de construir su trabajo. una posición mucho mejor que simplemente construir su trabajo a partir del brazalete.
.
Accentsconagua