Share
Cuando se trata de crear temas de WordPress, como ocurre con muchos otros tipos de cosas, hay formas correctas y formas incorrectas de hacerlo. Para aquellos de nosotros que queremos ser desarrolladores profesionales de WordPress, para aquellos de nosotros que realmente nos importa el trabajo que estamos haciendo, y para aquellos de nosotros que queremos que nuestro trabajo dure, entonces tenemos que pensar en el futuro sobre cómo Estamos organizando los archivos y el código que entra en nuestro tema..
Sí, el Códice de WordPress ofrece un artículo fantástico sobre Desarrollo de temas, y creo que debería ser una lectura obligatoria para cualquier persona que se esté involucrando en la creación de temas. - especialmente Temas premium, pero hay algunas estrategias que no cubren que he encontrado muy útiles en lo que respecta a la creación, liberación y mantenimiento de temas a lo largo del tiempo..
En los siguientes dos artículos, vamos a echar un vistazo a algunas estrategias que profundizan un poco más en el desarrollo de temas que nos ayudarán a estructurar nuestros temas de tal manera que no solo sigan las pautas de WordPress. Codex, pero también facilitará mucho el mantenimiento, la actualización y la mejora no solo a medida que WordPress avanza, sino también a medida que nuestro tema madura..
La calidad de la organización de los archivos y del código que se utiliza para crear temas de WordPress es un tema candente..
Para ser claros, esta es una de esas cosas que a los desarrolladores y diseñadores les encanta referirse hasta un punto en el que se ha transformado en algo que la gente adora odiar. Es decir, los demás a menudo comentarán sobre temas de baja calidad que están disponibles para WordPress, y luego usarán ese argumento como una razón por la cual WordPress es una plataforma pobre no solo para bloguear, sino también por otras razones..
Ese no es el punto ni el argumento de lo que discutiremos aquí, ni pretende inspirar ese tipo de discusión en los comentarios. En su lugar, esta serie de dos partes asume lo siguiente:
Por supuesto nosotros Todos tienen nuestras propias formas de hacer las cosas, por lo que las recomendaciones que se comparten a lo largo de esta serie pueden no funcionar con su flujo de trabajo actual. Quizás no quieras cambiar, ¡y eso está bien! - O quizás estás buscando un cambio..
Independientemente del caso, todo lo que se comparte aquí se basa en la experiencia en la creación y el mantenimiento de temas de WordPress premium y ha hecho que sea mucho más fácil mantenerlos con el tiempo, tanto desde el punto de vista de un tema específico como desde el punto de vista de la compatibilidad de WordPress..
Una de las partes más difíciles del software de construcción no es el envío de la versión inicial (aunque eso es difícil en sí mismo), pero mantiene el producto después del lanzamiento.
Esto no solo implica asegurarse de que la base de código siga siendo compatible con la infraestructura subyacente (de lo que hablaremos en la siguiente sección), sino que los archivos estén organizados de tal manera que el equipo de desarrollo los comprenda. , que tienen un nivel de cohesión, y que tienen una rima y una razón de por qué son nombrados y colocados en la forma en que son.
Sabemos por el Codex que hay varios archivos que constituyen el núcleo del tema. Esto incluye plantillas, un archivo de funciones y al menos una hoja de estilo..
¿Qué pasa, sin embargo, cuando tu tema se complica más? Decir que usted…
Todo lo anterior se puede organizar limpiamente dentro de un directorio de temas de WordPress. Revisaremos cada uno de estos con un poco más de detalle y la justificación de su ubicación en el directorio de temas con la esperanza de que esto haga que el desarrollo del tema sea más limpio y que la facilidad de mantenimiento sea mucho más fácil..
Aunque en muchos contextos, estos pueden discutirse independientemente unos de otros ya que son responsables de diferentes cosas, su estructura organizativa dentro de un tema es tan similar que tiene sentido agruparlos.
Primero, asumiendo que no está usando ningún tipo de pre-procesador de CSS, entonces debería haber un directorio para cada uno de estos tipos de archivos. Es decir, deberías tener un css directorio y un js directorio (o tal vez los llames estilos y javascript).
En cualquier caso, cada tipo de archivo debe residir en su propio directorio. A partir de ahí, puedes usar funciones.php para registrar y poner en cola los archivos según sea necesario. Si es un archivo que se usa en todo el tema, entonces lo registrarás incondicionalmente.
Pero si se trata de un estilo o un script que solo se usa en una plantilla en particular, en un tipo de publicación en particular, o incluso en una parte del panel de control, entonces puede, y debe, poner en cola el archivo de forma condicional..
Pero digamos que usted son utilizando un preprocesador. En este punto, se quedará con su archivo preprocesado y sus archivos posprocesados. Dependiendo de la naturaleza de su proyecto, puede tener o no todo reducido a un solo archivo.
yo haría hacer recomendaciones sobre cómo nombrar archivos; sin embargo, la variación en los temas, cómo las personas construyen su trabajo y el problema de un tema determinado es tratar de resolver los problemas y eso nos lleva más allá del alcance de esta estrategia en particular..
De todos modos, si va a utilizar un preprocesador, le recomiendo crear un subdirectorio en el css y js directorios llamados dev (o desarrollo o como quieras llamarlo). En este directorio, escribe todos sus archivos preprocesados, luego deja que la herramienta que elija (ya sea CodeKit, Grunt o algo así) genere los archivos procesados en la raíz del css y js directorios.
De esta manera, aún tiene código procesado, combinado y / o minificado, y tiene un directorio que contiene la fuente de esos archivos. Cuando llega el momento de enviar el tema, no solo tiene los archivos de función functions.php en sus respectivos directorios, sino que también puede excluir la dev directorio de la compilación final para que el usuario final obtenga un paquete de tema más pequeño y no obtenga nada más de lo que necesita para ejecutar el tema.
Las partes de la plantilla a menudo se denominan parciales (más en otros idiomas que en WordPress) y con frecuencia se llaman usando get_template_part en WordPress. En resumen, su propósito es abstraer el código repetitivo que puede incorporarse fácilmente en múltiples plantillas.
Un ejemplo de esto sería, digamos, los metadatos posteriores. Esto usualmente incluye la siguiente información:
Dado que esta información puede existir en varias plantillas (piense en publicaciones individuales, páginas, archivos, etc.), entonces tendría sentido abstraerla en un solo archivo y solo hacer referencia a ese archivo cuando lo necesite..
La cosa es que los metadatos no son el solamente Tipo de información que se reutiliza a lo largo de un tema. Con ese fin, identifique los elementos centrales que se reutilizan, abstraídos en un archivo, luego cree un parciales directorio.
A partir de ahí, asigne un nombre a cada parte de la plantilla que indique lo que representa (como post-meta.php, gravatar.php, navegación.php, pagination.php, y así sucesivamente) y luego realice una llamada al parcial en la plantilla donde sea necesario.
Por ejemplo, en las plantillas de publicación, página y archivo, puede llamar get_template_part ('partials / post-meta');. Hace para una lectura mucho más fácil y hace para una soltero Lugar para hacer un cambio en lugar de en cada plantilla..
Si está escribiendo un tema que se internacionaliza, que si lo publica para el público, debería hacerlo, entonces hay una forma clara y clara de hacerlo..
Primero, si este es un tema nuevo para usted, entonces recomiendo leer el artículo en el Codex. Le dirá todo lo que necesita saber acerca de cómo preparar cadenas para la traducción, las herramientas disponibles, etc..
Luego, recomiendo asegurarse de tener un lugar dedicado en su tema para sus idiomas. En términos generales, recomiendo crear un directorio en su tema llamado lang o idiomas y luego soltando el .correos y .mes archivos en dicho directorio. Esta también es una práctica generalmente aceptada y esperada dentro de la comunidad de WordPress en general.
Esto no solo relega las traducciones a su propio lugar dentro de la estructura del tema, sino que también indica a los demás dónde buscar traducciones y dónde buscar los archivos que ofrecen las cadenas que necesitan ser traducidas..
De nuevo, se trata de la cohesión y de asegurarse de que las cosas de utilidad similar se agrupen de una manera razonable.
Dependiendo de su experiencia en el desarrollo, las funciones que utiliza para ayudar a realizar el trabajo y para ayudar a separar la lógica de negocios de la lógica de presentación (o, en muchos de nuestros casos, PHP directamente desde HTML), se denominan funciones auxiliares o funciones de utilidad.
Para el propósito de esta serie, nos referiremos a ellos como funciones de ayuda, aunque sabemos que todos son uno en el mismo.
Pero esto plantea dos preguntas:
Accentsconagua
funciones.php?funciones.php, dónde viven?En resumen, creo que los ayudantes y los servicios públicos deberían no vivir en funciones.php. Mi regla de oro es simplemente esta: si el código que estoy escribiendo se comunica directamente con WordPress, como add_theme_support, entonces pertenece en funciones.php. Pero si hay un código que estoy escribiendo que ejecutará una consulta personalizada para recuperar información y devolver el resultado procesado a la plantilla (o la parte de la plantilla), entonces pertenece a una función auxiliar.
Al igual que WordPress tiene etiquetas de plantilla o funciones de plantilla que se pueden llamar a través de una plantilla, como el contenido(), Trate las funciones de ayuda de manera similar: puede llamarlas en sus plantillas y en sus parciales, pero están ubicadas en su propio archivo..
Dado que estas funciones auxiliares no viven en funciones.php, entonces deberían vivir en su propio archivo y ese archivo debe ser referenciado en algún lugar del código base del tema, ¿verdad? Además de eso, también es completamente posible que pueda dividir a sus ayudantes en múltiples archivos según la complejidad de su tema..
Para ello, recomiendo introducir un Cía o un incluye Directorio en el núcleo de tu tema. Desde allí, coloque sus archivos de ayuda en ese directorio y de forma sencilla. include_once El archivo auxiliar en la parte superior de su archivo de funciones y las funciones serán fácilmente y fácilmente accesibles en el resto de su tema.
Finalmente, hay ocasiones en las que incluiremos bibliotecas de terceros en nuestros temas. En pocas palabras, estas son herramientas desarrolladas por otros que están disponibles de forma gratuita para su uso y distribución y que también nos facilitan el cuestionamiento del trabajo de otros..
Entonces, ¿dónde deberían vivir? Honestamente, esto depende del tipo de biblioteca con la que estés trabajando. Por ejemplo, las bibliotecas pueden venir en forma de CSS, JavaScript o PHP. Como tal, debería haber un lugar para eso:
lib directorio dentro de tu js directorio. Esto indica que la carpeta contiene bibliotecas de JavaScript..lib directorio dentro de tu css directorio. De nuevo, esto indica que tienes una biblioteca CSS.lib Directorio en la raíz del directorio de temas. Esto indica que no es JavaScript o CSS y que contribuye a la funcionalidad del tema central (que se compone en gran parte de llamadas a funciones de PHP, etiquetas de plantilla, etc.).Por supuesto, también he visto a algunos desarrolladores crear un lib directorio y luego crear js, css, y php subdirectorios dentro del lib directorio. Es una pequeña inversión de los consejos proporcionados anteriormente..
No es una mala estrategia; Sin embargo, la razón por la que no me gusta este enfoque es porque distribuye los archivos JavaScript, CSS y PHP en varios directorios del tema..
Crear una estructura de directorios organizada es solo una parte de ella. WordPress tiene una jerarquía de plantillas que requiere una cierta convención de nomenclatura. ¿No sigue lógicamente que nuestros archivos personalizados deberían hacer lo mismo??
Además, ¿qué pasa con las convenciones de nombramiento de funciones? Ellos eco datos o regreso ¿datos? Además, cómo sabemos que estamos haciendo las llamadas a la función de la API y que no estamos usando características obsoletas de WordPress?
En el siguiente artículo, hablaremos de todo esto, así como de las herramientas que podemos instalar y que nos ayudan a evitar esos inconvenientes. También discutiremos cómo funcionan y por qué, junto con las convenciones de nomenclatura de funciones, son importantes al crear temas..
Por ahora, sin embargo, hemos cubierto estrategias para la organización de archivos que deberían ser suficientes para mantenerlo ocupado hasta que se publique el próximo artículo de la serie..
Como de costumbre, si tiene algo que agregar, hágalo en los comentarios!
