Tipos de publicaciones personalizadas de WordPress Debate - Functions.php or Plugins?

Tipos de publicaciones personalizadas de WordPress Debate - Functions.php or Plugins? / Opinión

Como muchos de ustedes saben, la semana pasada, Syed Balkhi asistió a WordCamp Raleigh 2012. Durante el evento, uno de sus tweets provocó un gran debate. En este artículo, nuestro fundador, Syed Balkhi, debatirá si los tipos de mensajes personalizados 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 publicación personalizados en functions.php -> SIEMPRE debe usar un complemento específico del sitio - wpbeg.in/vcXr7j #wcraleigh

- Principiante de WordPress (@wpbeginner) 4 de noviembre de 2012

Después del tweet, muchas personas de buena reputación en la comunidad de WordPress intervinieron. Puede ver la conversación completa aquí. Curtis McHale lo llevó un paso más allá y explicó el tema en su nueva publicación en el blog..

La conversación de twitter trajo algunos grandes puntos..

Resumen de Argumentos

Argumento de los complementos: El usuario siempre tendrá los datos, incluso si cambian el tema. Puede que no se vea tan bonito, pero se quedará 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 que es el menor de los dos males?

Aquí es por qué creemos que los tipos de correos personalizados deben SIEMPRE vive en un complemento específico del sitio o en un complemento separado.

Datos de larga duración

Los tipos de correos personalizados son datos. En la mayoría de los casos, sus datos sobrevivirán al diseño actual. Habiendo cambiado nuestros temas varias veces, entendemos esa declaración claramente. Publicaciones, páginas, enlaces, archivos adjuntos y revisiones son todos los tipos de publicaciones que vienen incorporadas con WordPress. Además de eso, tenemos tipos de publicaciones como Libros, Testimonios, Ofertas, etc. Ahora, ¿te imaginas si cambiamos un tema y desaparecen todos estos temas? Seguramente, no queremos que eso suceda..

Tener desarrolladores en nuestro equipo, esto no debería importar mucho. Teniendo en cuenta que todos nuestros temas están diseñados a la medida por nuestro equipo, ¿qué diferencia hace realmente? El secreto está en dos palabras: tiempo y centralización. Mientras tengamos todos los datos necesarios, todo lo que tendríamos 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 quieres replicar la funcionalidad? Simplemente tome el complemento y suéltelo en su nuevo sitio. Cambia el estilo, y listo..

Reglas y normas

Cuando usa la palabra SIEMPRE como hicimos en nuestro tweet, puede significar tanto reglas como estándares. Ambas reglas y normas están hechas para la mayoría. Siempre habrá casos de casos especiales en los que las reglas se doblan y se rompen los estándares, 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 campos de metadatos adicionales. Algunos ejemplos que vienen a la mente serían: citas, libros, recetas, testimonios, cartera, etc..

Teniendo en cuenta la gran cantidad de temas de fotografía y cartera disponibles en el mercado libre y comercial, casi no tiene sentido hacer que el usuario vuelva a ingresar toda su información de tipo de publicación personalizada cada vez que cambie un tema. Echemos un vistazo a un caso de ejemplo de caso:

Fotógrafo - El usuario configura un WordPress que tiene una funcionalidad de blog (por defecto "post" CPT). Quiere agregar un portafolio de su trabajo (requiere un Portafolio CPT). Quiere mostrar testimonios de clientes (requiere un Testimonial CPT). Toda esta información seguramente vivirá más allá del diseño de un tema. Un año después, el usuario desea 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 "SANTO CANTO, perdí todo mi contenido". Crea una nueva pregunta de soporte en el foro. Envía correos electrónicos a sitios como WPBeginner, etc. Si no reciben una buena respuesta, tendrán que volver a ingresar todos los datos. Esta es una experiencia de usuario de mierda.

Entonces, ¿cómo resolvemos este problema??

Solución posible?

Creamos una nueva base estándar. Justin Tadlock ya comenzó a trabajar en este problema hace un tiempo creando 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 deberían incluirse en el complemento de cartera (en referencia a la publicación meta). Este tipo de conversación debe darse entre los 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 temas los autores comenzarán a adaptarse a él..

Por ejemplo, estamos viendo un aumento en el soporte de estilo para Gravity Forms en los marcos temáticos de WordPress como Genesis y otros. ¿Por qué? Porque entienden que sus usuarios lo están usando..

Hay algunos temas robustos de WordPress que vienen cargados con funcionalidades que creemos que deberían ser complementos. Temas de la tabla de empleos, temas de seguimiento de problemas, tema de anuncios clasificados, temas de bienes raíces, etc. Todos deben ser 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 de temas 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. Eso es casi como si el tema hubiera cambiado, pero todo quedó en su lugar. Ese es el tema de la experiencia de cambio que tenemos que luchar por.

¿Por qué no hacer lo mismo con Cartera, Testimonios y otros tipos de publicaciones personalizadas genéricas? ¿Es porque es demasiado simple vs. el comercio electrónico es una bestia más grande que 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 al complemento ReciPress. Crea un metabox personalizado con campos de receta y lo adjunta con publicaciones. Sin embargo, es posible adjuntarlo con tipos de correos personalizados. Cualquiera que use este complemento puede cambiar los temas sin tener que pasar por una molestia.

Sería bueno ver temas como AgentPress con un complemento de base centralizado. Sería genial ver que la transición de los temas cambiantes sea 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 el uso del cliente por única vez, 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 correos personalizados? En el archivo functions.php o en plugins.?