Debate sobre los tipos de publicaciones personalizadas de WordPress

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 discutirá si los tipos de publicaciones personalizadas de WordPress pertenecen al archivo functions.php o plugins.

Curtis McHale dio un paso más y elaboró ​​el tema en su propio nueva publicación de blog.

La conversación de Twitter sacó a la luz algunos puntos importantes.

Resumen de temas

Tema del plugin: El usuario siempre tendrá los datos incluso si cambia el tema. Puede que no se vea tan lindo, 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, ambos lados tienen sus problemas, pero ¿cuál es el menor de dos males?

Por eso creemos que los tipos de publicaciones personalizadas deberían SIEMPRE vivir en un plugin específico del sitio o en un plugin completamente separado.

Larga vida a los datos

Se dan tipos de publicaciones personalizadas. En la mayoría de los casos, sus datos sobrevivirán al diseño actual. Habiendo cambiado nuestros temas algunas veces, entendemos claramente esta declaración. Las publicaciones, las páginas, los enlaces, los archivos adjuntos y las reseñas son todo tipo de publicaciones integradas en WordPress. Además, tenemos tipos de publicaciones como libros, testimonios, ofertas, etc. Ahora, ¿te imaginas si cambiamos un tema y hacemos que todo esto desaparezca? Seguramente, no quisiéramos que eso sucediera.

Tener desarrolladores en nuestro equipo 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 tenemos que hacer en el futuro es cambiar el estilo. No tendremos que preocuparnos por copiar y pegar funciones de un archivo a otro cada vez. ¿Qué pasa si quiero replicar la funcionalidad? Simplemente tome el plugin y suéltelo 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 regla como estándar. Tanto las reglas como los estándares están hechos para la mayoría. Siempre habrá casos especiales en los que las reglas se modifiquen y los estándares se rompan, 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 son: citas, libros, recetas, testimonios, portafolios, etc.

Teniendo en cuenta la gran cantidad de temas de fotos y portafolios disponibles en el mercado libre y comercial, no tiene sentido que el usuario vuelva a ingresar toda la información sobre el tipo de publicación personalizada cada vez que cambia un tema. Echemos un vistazo a un caso de ejemplo:

Fotógrafo – El usuario ha configurado un WordPress que tiene una funcionalidad de blog (CPT “post” por defecto). Quiere agregar un portafolio de su trabajo (requiere un Portafolio CPT). Quiere mostrar testimonios de clientes (requiere un Testimonio CPT). Toda esta información seguramente vivirá más allá de un diseño temático. Un año después, el usuario quiere cambiar el aspecto de su sitio y actualizarlo. Encuentra un nuevo tema con todas las funciones similares. A medida que cambia el tema, BOOM. Todos los datos anteriores que ingresó han desaparecido. Hay un menú llamado Portafolio y un menú llamado Testimonios, sin embargo, ninguno de los datos está presente. El usuario piensa “SANTA MIERDA, he perdido todo mi contenido”. Crea una nueva pregunta de soporte en el foro. Envíe correos electrónicos a sitios como TrucosWP, etc. Si no obtienen una buena respuesta, deberán volver a ingresar todos los datos. Esta es una mala experiencia de usuario.

Entonces, ¿cómo resolvemos este problema?

¿Solución posible?

Creamos una nueva base estándar. Justin Tadlock ya ha comenzado a trabajar en este tema hace algún tiempo mediante la creación de un plugin de cartera básico. ¿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 plugin de la cartera (refiriéndose al 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 plugin? Una vez que se convierta en un estándar, otros escritores 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 características que creemos que deberían ser plugins. Temas de bolsa de trabajo, temas de seguimiento de problemas, tema de anuncios clasificados, temas de bienes raíces, etc. Todos deberían estar alimentados por un plugin básico. Ya está sucediendo con WooCommerce. WooThemes ha lanzado numerosos temas con soporte de estilo incorporado para el plugin. Otras compañías temáticas también han prometido lanzar temas de comercio electrónico basados ​​en WooCommerce. Puede cambiar entre temas y mantener todos sus productos como están. Es casi como si el tema cambiara, pero todo encajó. Esta es la experiencia que cambia el tema por el que tenemos que luchar.

¿Por qué no hacer lo mismo con las carteras, los testimonios y otros tipos de publicaciones personalizadas genéricas? ¿Es porque es demasiado simple y el comercio electrónico es una bestia más grande que conquistar? Claramente, el comercio electrónico tiene demasiados campos que los demás, 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 Plugin ReciPress. Cree un metabox personalizado con campos de recetas y adjúntelo con publicaciones. Sin embargo, puede adjuntarlo con tipos de publicaciones personalizadas. Cualquiera que use este plugin puede cambiar de tema sin tener que enfrentarse a tales problemas.

Sería bueno ver que temas como AgentPress funcionan con un plugin central centralizado. Sería bueno ver que la transición de los temas en evolución se vuelve más fácil. Por ejemplo, si un usuario cambia de un tema fotográfico a otro, no debería ser un caos. Pueden ocurrir errores menores, pero al menos en el panorama general, las cosas saldrán bien.

Siempre puede proporcionar ejemplos de tipos de publicaciones súper personalizadas creadas para el uso de un solo cliente, pero esta es la excepción, no la regla.

¿Qué opinas de este tema? ¿Dónde debería residir el código de tipo de publicación personalizada? ¿En el archivo functions.php o en los plugins?

¿Te ha resultado útil??

0 / 0

Deja una respuesta 0

Tu dirección de correo electrónico no será publicado. Required fields are marked *