Share
En la primera publicación de esta serie, revisamos algunas de las estrategias disponibles relacionadas con la organización de nuestros directorios de temas de WordPress para que sean más fáciles de mantener..
Específicamente, nos referimos a cómo organizar:
En última instancia, el objetivo era proporcionar un esquema de directorio en el que pudiéramos organizar nuestros archivos de manera que tuviéramos un nivel de cohesión, comprensión y mantenimiento del trabajo que estamos realizando..
Pero eso no es todo lo que hay para escribir temas de WordPress mantenibles. Otro es seguir las convenciones establecidas por los estándares de codificación de WordPress; Sin embargo, este artículo no va a echar un vistazo a las normas. El Codex hace un buen trabajo de eso y los hemos cubierto en otra serie..
En su lugar, vamos a analizar algunas de las estrategias y herramientas que podemos usar para asegurarnos de que nuestros temas sean lo más mantenibles posible. En esta publicación en particular, vamos a ver las estrategias, luego resumiremos la serie al observar algunas de las herramientas disponibles..
Como se mencionó anteriormente, una cosa es tener una manera lógica de organizar todos los directorios, archivos y bibliotecas que conforman su tema; Sin embargo, eso es realmente solo la mitad de lo que implica construir un tema..
Después de todo, hay plantillas, funciones, convenciones de nomenclatura y herramientas predefinidas que contribuyen a crear el tema o a probar el tema para asegurarse de que no esté usando ninguna llamada en desuso de la API y que sea compatible con la versión más reciente. de WordPress.
Para ese fin, creo que es importante entender cada uno de estos temas como alguien que recién comienza a crear temas de WordPress y como alguien que lo ha estado haciendo durante algún tiempo..
Después de todo, nunca hay un mejor momento para tratar de mejorar en lo que estás haciendo. Además, los comentarios son también un gran lugar para continuar la discusión para compartir ideas alternativas..
Pero antes de llegar, hablemos de algunas cosas prácticas que podemos hacer en relación con la temática de WordPress, y eso aumenta la capacidad de mantenimiento de lo que estamos haciendo..
Primero, si no está familiarizado con la jerarquía de plantillas, le recomiendo que lea la página correspondiente de Codex antes de continuar con este artículo..
En resumen, las plantillas se pueden describir como las siguientes:
Las plantillas de WordPress se combinan como las piezas de un rompecabezas para generar las páginas web en su sitio de WordPress. Algunas plantillas (los archivos de encabezado y pie de página de plantilla, por ejemplo) se usan en todas las páginas web, mientras que otras se usan solo bajo condiciones específicas.
Otra forma de verlo es esta: cuando se trata de WordPress, todo lo que se muestra al usuario proviene de la base de datos. Esto incluye el título de la publicación, los datos de publicación, las categorías de publicación, el contenido de la publicación, los comentarios, etc..
Las plantillas son los vehículos a través de los cuales se presenta la información al usuario. Están compuestos de marcado y PHP, con estilo a través de CSS, y pueden tener algunos efectos aplicados mediante el uso de JavaScript.
Pero, asumiendo que no está haciendo nada avanzado con cosas como los tipos de publicaciones personalizadas y / o taxonomías personalizadas (un tema para otra publicación, realmente), hay una cosa única acerca de la Jerarquía de plantillas de WordPress que puede servir como un lujo y Un problema de mantenimiento en función de cómo se mire..
Tenga en cuenta que en el artículo del Codex vinculado, WordPress tendrá por defecto index.php, header.php, y footer.php plantillas. La verdad es que realmente puede salir adelante creando un tema de WordPress completo usando solamente index.php.
Suena un poco atractivo, ¿verdad? Quiero decir, quién necesita crear tantos archivos diferentes cuando puedes crear un tema agradable, pequeño y delgado que haga todo lo que necesitas..
Pero luego piense en esto desde la perspectiva de trabajar con un equipo de sus propios compañeros, de aquellos que pueden estar contribuyendo a un repositorio abierto, o de aquellos que eventualmente pueden continuar donde lo dejó..
Si todo el código requerido para representar información de la base de datos está contenido en un solo archivo, las probabilidades de que la complejidad de ese archivo aumente desde su creación son muy altas.
En el nivel más básico, estamos viendo un solo archivo con una serie de condicionales, posiblemente algunas declaraciones de cambio, etc. Y todo esto se hace porque debe tener en cuenta las páginas de archivo, las páginas de publicación única, las publicaciones únicas, la lista principal, etc..
Mira lo que quiero decir?
Pero luego, creando un archivo separado. sólo mitigar esa complejidad puede ser una bestia por sí sola. Por ejemplo, digamos que tienes single.php para mostrar una sola publicación y tienes page.php para mostrar una página y ambas plantillas tienen exactamente la misma información excepto single.php ha publicado metadatos y page.php no.
Este es un excelente ejemplo de cuándo puede extraer metadatos posteriores en su propio parcial, como hemos comentado en el artículo anterior. O tal vez puede extraer el código responsable de representar el contenido en sus propia parcial.
Cualquiera que sea el caso, el punto que trato de señalar es que hay un equilibrio que se debe lograr cuando se trata de trabajar con plantillas de WordPress y la Jerarquía de plantillas de WordPress..
No creo que sea una buena idea usar una cantidad mínima de plantillas, pero tampoco creo que sea necesario usar todas las plantillas compatibles Si conduce a demasiada duplicación de código. Ahí es Un equilibrio entre plantillas y parciales..
En última instancia, creo que la experiencia sobre cómo usar que viene con el tiempo, pero tener este estado de ánimo desde el principio puede ayudar a proporcionar un nivel de organización y mantenibilidad que está a pasos agigantados por delante de donde usted se encuentra. mayo Empezar a no haber hecho solo un poco de planificación previa..
Cuando se trata de trabajar con funciones y convenciones de nomenclatura, usualmente hay dos reglas básicas a seguir:
Accentsconagua
regreso datos y que sera eco datosPero si eres alguien que recién está comenzando en el desarrollo de temas, o eres alguien que está buscando mejorar sus habilidades para hacer esto, ¿cómo se ve esto prácticamente??
Cuando se trata de nombrar de forma única sus funciones, las razones para hacerlo son para que no colisione accidentalmente con una función preexistente que esté definida dentro de WordPress o un complemento que pueda estar ejecutándose en su entorno..
Por ejemplo, supongamos que va a escribir su propia función que filtrará el contenido antes de representarlo en la página. La forma correcta de hacer esto es, obviamente, utilizar el Añadir filtro función; Sin embargo, ¿nombrarías tu función? el contenido?
No claro que no. La razón es porque WordPress ya define el contenido. Si cambia el nombre de una función con ese nombre, obtendrá errores. Con ese fin, siempre es mejor prefijar sus funciones con una clave única, como el nombre de su tema o algo similar..
Entonces, digamos que queremos anteponer una firma al final de nuestro contenido, y digamos que tenemos un tema al que estamos llamando Cumbre. Para hacer esto, recomiendo crear una función llamada acme_the_content porque identifica el nombre del tema e indica el nombre de la función a la que está enlazado.
Digamos que quieres terminar cada publicación con tu nombre y el nombre de Twitter. Para ello, puede definir esto en su funciones.php expediente:
'; $ firma. = 'Tom | @tommcfarlin '; $ firma. = ''; devolver $ contenido. = $ firma;
Es relativamente sencillo, ¿no? En resumen, trato de usar el siguiente formato cuando creo mis propias funciones enganchadas: nombre_tema_nombre-nombre_de_hook.
Esto hace que sea realmente fácil de entender y seguir, no solo cuando se navega por el código, sino también al ver las funciones que conforman el tema o el archivo que está actualmente activo en su IDE..
Como se mencionó anteriormente, WordPress tiene otra convención que usa y que tiene que ver con si la información que se va a devolver desde la función llamada o se hará eco desde la función llamada.
Afortunadamente, esta particular regla de oro es muy fácil de recordar:
obtener_ obtener_ Puedes encontrar algunos anomalías, pero esa es la idea general de cómo la API de WordPress indica cómo le devolverá los datos una vez que haya llamado a la función.
Para mantener la coherencia con nuestro ejemplo anterior, digamos que desea hacer eco de los datos cuando se llama a la función, entonces simplemente llamará el contenido(); sin embargo, si desea recuperar el contenido de una publicación, por ejemplo, desde un bucle personalizado, debería llamar get_the_content () y guárdalo en tu propia variable.
Quizás algo como esto: $ content_for_later = get_the_content (). Ahora ha leído los datos del contenido que actualmente está relacionado con la publicación activa en The Loop y lo ha almacenado en una variable que puede usar más adelante..
Pero saber cómo WordPress nombra sus funciones para ti es solo la mitad. Después de todo, estás planeando crear un tema o un complemento y quieres asegurarte de que te mantengas consistente con "la forma de WordPress" de hacer las cosas, ¿verdad??
Caso en cuestión: en el ejemplo anterior, donde filtramos el contenido, prefijamos la función de tal manera que fue nombrada acme_the_content, lo que indica que el Cumbre El tema devolverá el contenido desde donde se llame dentro del tema.
¿Qué pasaría si nombramos la función? acme_get_the_content () ?
Bueno, técnicamente hablando, la función todavía haría eco de los datos dondequiera que se llamara; sin embargo, sería inconsistente con la API de WordPress porque el desarrollador esperaría que los datos les sean devueltos de tal manera que pudieran almacenarlos en una variable o pasarlos a otra función.
Hay una discrepancia entre lo que el usuario espera que suceda y lo que realmente sucede.
Si estuviéramos hablando de algo en el mundo real, esto sería como tener un interruptor en la pared para el cual el usuario espera que cuando giran el interruptor, se encenderá una luz o un ventilador en la misma habitación cuando, en realidad, tal vez no pase nada o se encienda una luz o un ventilador en otra habitación.
Con ese fin, debemos tener cuidado al nombrar nuestras funciones para que no solo escribamos funciones que no coincidan con otras funciones, sino que también tengan un nombre claro, y que indiquen cómo Estarán manejando la información cuando la función sea llamada..
Como se mencionó al principio de este artículo, también hay una serie de herramientas y configuraciones que podemos instalar y configurar en nuestro entorno de desarrollo que nos ayudarán a detectar cualquier problema potencial antes de que iniciemos nuestro tema..
Esto significa que podremos identificar las funciones que finalmente se eliminarán de WordPress para que no escribamos código desactualizado. Además, hay formas de saber si las variables a las que intentamos acceder no tienen, por ejemplo, índices definidos u otras características similares..
En el artículo final de la serie, vamos a echar un vistazo a eso exactamente. Mientras tanto, revise lo que se ha cubierto aquí, siéntase libre de compartir sus preguntas y comentarios en la fuente a continuación, y luego veremos para terminar esta serie la próxima semana..
