Share
Hablamos mucho en este sitio acerca de consejos y trucos para obtener lo que desea de WordPress ... pero hoy vamos a dar un paso atrás en lo técnico para ver algunas prácticas, malos hábitos y la codificación de los pasos en falso que serían Será mejor dejarlo en nuestro pasado. Por lo tanto, perdonen el título de la publicación con mano dura (¡jaja!), Se trata de hablar con cinco prácticas sorprendentemente comunes que son imperfecciones en la plataforma..
Dos de las cosas más agradables de trabajar en los Temas de WordPress es el hecho de que tenemos un objetivo en un ambiente increíblemente flexible (Es decir, la web) y tenemos documentación sólida para ayudarnos a guiarnos a través del proceso (es decir, el Códice de WordPress).
Después de todo, si el tema funciona, el código limpio y de mantenimiento es importante?
Pero también existe un peligro en el desarrollo de temas: podemos renunciar completamente a las mejores prácticas para trabajar con la web e ignorar completamente la documentación. Específicamente, no hay nada que nos obligue a escribir código limpio y mantenible. Después de todo, si el tema funciona, ¿importa el código limpio y mantenible? Además, ¿por qué pasar por el esfuerzo de seguir las mejores prácticas de WordPress si el tema parece funcionar bien??
Argumentos débiles, ¿verdad? No lo sé, cuanto más he trabajado en el espacio de WordPress, más me he sorprendido de la cantidad de código erróneo que existe. Como tal, pensé que sería divertido delinear los cinco pecados cardinales de WordPress Theme Development.
Al igual que con la mayoría de los lenguajes de programación, marcos o bibliotecas, WordPress incluye una gran cantidad de documentación. El Códice de WordPress es posiblemente el mejor recurso que tienen los desarrolladores para trabajar con WordPress. Después de todo, proporciona documentación para la mayoría de la aplicación..
Pero el Códice de WordPress a menudo va más allá de la documentación estándar; además de proporcionar nombres y parámetros de funciones, el Códice proporciona abundantes ejemplos de cómo utilizar muchas de las funciones de la API. Después de leer un artículo dado, sería difícil no encontrar un ejemplo claro de cómo funciona la función en cuestión.
Además de la API, el Codex también presenta una variedad de otros artículos relacionados con el desarrollo:
Cada vez que estoy trabajando en un tema o un complemento y llego a un punto en el que creo que necesito escribir una función personalizada para lograr algo, primero buscaré en el Codex. La mayoría de las veces, ya hay una función disponible que me ayuda con lo que necesito..
Todo desarrollador serio de WordPress debe usar el Codex regularmente cuando trabaja en cualquier proyecto de desarrollo relacionado con WordPress. Ignorarlo a menudo puede llevar a soluciones creativas, pero no probadas e inestables que pueden causar más daño en la línea que bien.
Hace unos años, si me preguntara qué piensa sobre la localización de un tema de WordPress, le habría dicho que dependería de la comercialización a la que se dirige. Es decir, si crees que la audiencia va a utilizar un idioma diferente al tuyo, definitivamente hazlo; De lo contrario, no hay nada de malo en dejar el tema traducido en su propio idioma..
Avancemos unos años y WordPress está impulsando millones de sitios en Internet. Sitios de todo el mundo utilizan la aplicación para impulsar el contenido de su sitio. Además, es cada vez más común que los desarrolladores complementen sus ingresos o incluso se ganen la vida trabajando con WordPress..
Debido a que WordPress ha sido tan ampliamente adoptado y porque Internet ha hecho que el mundo sea tan plano, el mercado para cualquier tema dado no se limita a un solo idioma. Además de eso, WordPress hace que sea tan fácil de localizar su tema y requiere tan poco esfuerzo adicional, que ahora sostengo que localizar su tema ya no es opcional.
En su mayor parte, necesita entender tres cosas:
Aparte de eso, hay muy poca sobrecarga adicional que conlleva la localización de un tema; sin embargo, le recomiendo que eche un vistazo al artículo de Traducción de WordPress en el Codex. Esboza las tres cosas anteriores y profundiza más en cada una..
Los desarrolladores hablan mucho sobre la organización del código y la capacidad de mantenimiento. Personalmente, creo que es mucho más fácil prestar atención a esos principios que seguirlos, pero son importantes.
La cosa es que se ven diferentes para cada tipo de proyecto. Algunas aplicaciones están escritas en un solo idioma y se ejecutan en un escritorio, algunas aplicaciones usan dos idiomas y se ejecutan en un dispositivo móvil, otros proyectos, como los Temas de WordPress, pueden usar desde tres (HTML, CSS y PHP) a cuatro ( a través de JavaScript) idiomas. Además, ciertos componentes del tema se ejecutan en el lado del cliente, algunos se ejecutan en el lado del servidor, algunas comunidades directamente con WordPress y otras se comunican directamente con la base de datos.
Decir que hay un potencial para sacrificar la capacidad de mantenimiento es una subestimación.
Pero no tiene que ser problemático, ya que hay ciertos estándares que WordPress sugiere para organizar sus archivos de temas. Específicamente, el Codex detalla cómo organizar sus archivos de plantillas PHP, sus hojas de estilo, fuentes de JavaScript e imágenes..
Claro, se requiere un pequeño esfuerzo adicional para organizar sus archivos en lugar de hacer lo suficiente para "hacer que funcionen", pero los dividendos se reparten con el tiempo a medida que comienza a trabajar en la próxima versión de su tema o cuando varios desarrolladores comienzan a trabajar en la misma base de código.
Por supuesto, la organización de archivos es solo una parte del proceso de desarrollo que afecta la organización y la capacidad de mantenimiento. A continuación, debemos centrarnos en cómo escribimos el código que reside en nuestros archivos..
Después de todo, no solo deberíamos proporcionar archivos bien organizados, sino también códigos que cumplan con los estándares y que sean fáciles de seguir. Una vez más, el Códice de WordPress proporciona un conjunto estándar para los principales idiomas que contribuyen al código base de un tema:
Mucho para procesar, ¿eh? La cuestión es que pasar tiempo familiarizándose con todo lo anterior paga dividendos a lo largo del tiempo. Aplicar estos estándares al comienzo del desarrollo es exponencialmente más barato que tener que refactorizar un tema o complemento existente.
Además, se traduce en una mejor devolución de código a la comunidad..
Después de que se haya desarrollado un tema y esté listo para su lanzamiento, debe hacer, al menos, una sola prueba. Es decir, debe verificar que los diversos estilos de datos de publicación estén formateados correctamente, que su tema no esté usando funciones en desuso o que esté usando cualquier función de manera incorrecta.
Afortunadamente, el Codex proporciona una serie de sugerencias y herramientas para facilitar este proceso..
Por supuesto, también hay pruebas adicionales que puede realizar, como pruebas en varios navegadores, conformidad con los estándares HTML / CSS, etc. El Codex describe aún más sugerencias de pruebas en el artículo del Proceso de prueba de temas.
Dicen que a menudo aprendes de tus errores y seré el primero en admitir que durante mi tiempo con WordPress, he roto cada uno de estos. Pero, al igual que el resto de la comunidad de desarrollo, aprende y comienza a construir mejores proyectos con experiencia..
Este es el primero de este tipo de artículos de "cultura de WordPress" que publicaremos en el sitio ... así que comparta sus propias experiencias a continuación, o mejor aún, escriba sobre ellas y las publicaremos si es genial.!
Dicho esto, ciertamente esta no es la lista definitiva y estoy seguro de que hay más para agregar (ni siquiera hemos tocado piratear el núcleo, acosar la base de datos o elementos de codificación que deberían tener opciones). Deja caer tus propias manitas de mascotas en los comentarios.!
¿Cuáles son algunas de las prácticas más molestas, dañinas o insostenibles que ha encontrado??
Accentsconagua