Como muchos de ustedes saben, la semana pasada Syed Balkhi asistió a WordCamp Raleigh 2012. Durante el evento, uno de sus tweets desató un gran debate. En este artículo, nuestro fundador Syed Balkhi debatirá si los tipos de publicaciones personalizadas de WordPress pertenecen al archivo functions.php o a los complementos. A continuación se muestra un tweet que inició este debate:
No agregue tipos de publicaciones personalizadas en functions.php -> SIEMPRE debe usar un complemento específico del sitio – http://t.co/bebYXq2F #wcraleigh
– Principiante de WordPress (@wpbeginner) 4 de noviembre de 2012
Después del tweet, intervinieron muchas personas de renombre en la comunidad de WordPress. Puede ver el conversación completa aquí. Curtis McHale dio un paso más y elaboró el tema en su nueva publicación de blog.
La conversación de Twitter sacó a relucir algunos puntos importantes.
Resumen de argumentos
Argumento de complementos: El usuario siempre tendrá los datos incluso si cambia el tema. Puede que no se vea tan bonito, pero permanecerá allí.
Argumento de Functions.php: Los datos sin diseño serían irrelevantes. Confundirá aún más a los usuarios.
¿Con qué lado estás más de acuerdo? Claramente, ambas partes tienen sus problemas, pero ¿cuál es el menor de dos males?
A continuación, se explica por qué creemos que los tipos de publicaciones personalizadas deben SIEMPRE vivir en un complemento específico del sitio o en un complemento completamente separado.
Datos de larga duración
Los tipos de publicaciones personalizadas son datos. En la mayoría de los casos, sus datos sobrevivirán al diseño actual. Habiendo cambiado nuestros temas algunas veces, entendemos esa declaración claramente. Las publicaciones, páginas, enlaces, archivos adjuntos y revisiones son todos los tipos de publicaciones que vienen integradas con WordPress. Además de eso, tenemos tipos de publicaciones como Libros, Testimonios, Ofertas, etc. ¿Te imaginas si cambiamos un tema y todos estos desaparecen? Seguramente, no quisiéramos que eso sucediera.
Tener desarrolladores en nuestro equipo, esto no debería importar mucho. Teniendo en cuenta que todos nuestros temas están diseñados a medida por nuestro equipo, ¿qué diferencia realmente hace? El secreto está en dos palabras: tiempo y centralización. Mientras tengamos todos los datos necesarios, todo lo que tendremos que hacer en el futuro es cambiar el estilo. No tendremos que preocuparnos por copiar y pegar las funciones de un archivo a otro cada vez. ¿Qué pasa si desea replicar la funcionalidad? Simplemente tome el complemento y colóquelo en su nuevo sitio. Cambia el estilo y listo.
Normas y estándares
Cuando usa la palabra SIEMPRE como lo hicimos en nuestro tweet, puede significar tanto reglas como estándares. Tanto las reglas como los estándares están hechos para la mayoría. Siempre habrá escenarios de casos especiales en los que las reglas se desvían y los estándares se rompen, pero eso no significa que debamos deshacernos de los estándares por completo.
Hay toneladas de tipos de publicaciones genéricas que en su mayoría requieren el mismo conjunto de metacampos adicionales. Algunos ejemplos que me vienen a la mente serían: Cotizaciones, Libros, Receta, Testimonios, Portafolio, etc.
Teniendo en cuenta la gran cantidad de temas de fotografía y portafolio que están disponibles en el mercado libre y comercial, casi no tiene sentido hacer que el usuario vuelva a ingresar toda la información de tipo de publicación personalizada cada vez que cambia un tema. Echemos un vistazo a un caso de ejemplo:
Fotógrafo – El usuario configura un WordPress que tiene una funcionalidad de blog (CPT de “publicación” predeterminada). Quiere agregar un portafolio de su trabajo (requiere un CPT de portafolio). Quiere mostrar testimonios de clientes (requiere un CPT Testimonial). Toda esta información seguramente vivirá más allá del diseño de un tema. Un año después, el usuario quiere cambiar el aspecto de su sitio y actualizarlo. Encuentra un nuevo tema que tiene todas las funciones similares. En el momento en que cambia el tema, BOOM. Todos los datos anteriores que ingresó se han desvanecido. Hay un menú llamado Portafolio y un menú llamado Testimonios, sin embargo, ninguno de los datos está allí. El usuario piensa “SANTA MIERDA, perdí todo mi contenido”. Crea nuevas preguntas de soporte en el foro. Envía correos electrónicos a sitios como adrimadiseño, etc. Si no reciben una buena respuesta, deberán volver a ingresar todos los datos. Esta es una experiencia de usuario horrible.
Entonces, ¿cómo resolvemos este problema?
¿Solución posible?
Creamos una nueva base estándar. Justin Tadlock Ya comencé a trabajar en este problema hace un tiempo mediante la creación de un complemento de cartera base. ¿Será la solución perfecta para todos? NO, pero será para la mayoría.
Como Justin pregunta en su publicación, qué campos estándar deben incluirse en el complemento de cartera (refiriéndose a la meta de la publicación). Este tipo de conversación debe ocurrir entre desarrolladores que están creando una funcionalidad similar en sus temas. ¿Por qué copiar y pegar lo mismo una y otra vez de un tema a otro cuando se puede hacer a través de un complemento? Una vez que se convierta en un estándar, otros autores de temas comenzarán a adaptarse a él.
Por ejemplo, estamos viendo un aumento en el soporte de estilo para Gravity Forms en marcos temáticos de WordPress como Genesis y otros. ¿Por qué? Porque entienden que sus usuarios lo están utilizando.
Hay algunos temas sólidos de WordPress que vienen cargados con funcionalidades que creemos deberían ser complementos. Temas de bolsa de trabajo, temas de seguimiento de problemas, tema de anuncios clasificados, temas de bienes raíces, etc. Todos deben estar impulsados por un complemento básico. Ya está sucediendo con WooCommerce. WooThemes ha lanzado numerosos temas que tienen soporte de estilo incorporado para el complemento. Otras compañías temáticas también han prometido lanzar temas de comercio electrónico basados en WooCommerce. Puede cambiar de un tema a otro y mantener todos sus productos como están. Es casi como si el tema cambiara, pero todo encajó en su lugar. Esa es la experiencia de cambio de tema por la que debemos luchar.
¿Por qué no hacer lo mismo con Portafolio, Testimonios y otros tipos de publicaciones personalizadas genéricas? ¿Es porque es demasiado simple versus el comercio electrónico es una bestia más grande para conquistar? Claramente, el comercio electrónico tiene demasiados campos en comparación con los otros, por lo que debería ser mucho más fácil para estos tipos de publicaciones genéricas. Es solo una cuestión de hacer un esfuerzo consciente para mejorar las cosas.
Echa un vistazo a Complemento ReciPress. Crea un metabox personalizado con campos de recetas y lo adjunta con publicaciones. Sin embargo, es posible adjuntarlo con tipos de publicaciones personalizadas. Cualquiera que use este complemento puede cambiar de tema sin tener que pasar por tal molestia.
Sería bueno ver que temas como AgentPress funcionaran con un complemento base centralizado. Sería fantástico ver que la transición de los temas cambiantes se vuelve más fácil. Por ejemplo, si un usuario cambia de un tema de fotografía a otro, no debería ser un caos. Pueden ocurrir errores menores, pero al menos en el panorama general, las cosas funcionarán.
Siempre puede dar ejemplos de tipos de publicaciones súper personalizadas creadas para un uso único del cliente, pero esa es la excepción, no la regla.
¿Qué piensan ustedes sobre este tema? ¿Dónde debería residir el código de tipos de publicaciones personalizadas? ¿En el archivo functions.php o en complementos?