Debate de tipos de publicaciones personalizadas de WordPress: ¬ŅFunctions.php o Plugins?

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 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: wpbeg.in/vcXr7j #wcraleigh

– WordPress Beginner (@wpbeginner) 4 de noviembre de 2012

Despu√©s del tweet, muchas personas de buena reputaci√≥n en la comunidad de WordPress intervinieron. Puedes ver la 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 trajo algunos grandes puntos.

Resumen de argumentos

Argumento de complementos: El usuario siempre tendrá los datos, incluso si cambian el tema. Puede que no se vea tan bonito, pero se quedará allí.

Argumento Functions.php: Los datos sin dise√Īo ser√≠an irrelevantes. Confundir√° a los usuarios a√ļn m√°s.

¬ŅDe qu√© lado est√°s m√°s de acuerdo? Es evidente que ambas partes tienen sus problemas, pero ¬Ņcu√°l es el menor de los dos males?

Aquí es por qué creemos que los tipos de publicaciones personalizadas deberían SIEMPRE vivir en un complemento específico del sitio o en un complemento por completo.

Larga vida a los datos

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 varias veces, entendemos esa declaraci√≥n claramente. Las publicaciones, las p√°ginas, los enlaces, los archivos adjuntos y las revisiones son todos los tipos de publicaciones que se incluyen con WordPress. Adem√°s de eso, tenemos tipos de publicaciones como libros, testimonios, ofertas, etc. Ahora, ¬Ņte imaginas si cambiamos un tema y desaparecemos? 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 medida por nuestro equipo, ¬Ņqu√© diferencia hace realmente? El secreto radica 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 de copiar y pegar las funciones de un archivo a otro cada vez. ¬ŅQu√© pasa si desea replicar la funcionalidad? Simplemente tome el complemento y su√©ltelo en su nuevo sitio. Cambia el estilo y listo.

Reglas 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 las normas están hechas para la mayoría. Siempre habrá escenarios de casos especiales en los que las reglas se doblen 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 requieren principalmente el mismo conjunto de metacampos adicionales. Algunos ejemplos que vienen a la mente serían: Citas, Libros, Recetas, Testimonios, Portafolio, etc.

Teniendo en cuenta la gran cantidad de temas de fotografía y cartera que están 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. Veamos un caso de ejemplo:

Fot√≥grafo – El usuario configur√≥ un WordPress que tiene una funcionalidad de blog (CPT “post” predeterminado). Quiere agregar una cartera de su trabajo (requiere una cartera CPT). Quiere mostrar testimonios de clientes (requiere un CPT Testimonial). Toda esta informaci√≥n seguramente va a 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√≥ han desaparecido. 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 WPBeginner, 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 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 deben incluirse en el complemento de cartera (en referencia a la meta meta). Este tipo de conversaci√≥n debe ocurrir entre los desarrolladores que crean 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 los marcos de temas 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 bolsa de trabajo, temas de seguimiento de problemas, tema de anuncios clasificados, temas de bienes ra√≠ces, etc. Todos deben funcionar con un complemento base. 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. Es casi como si el tema cambiara, pero todo simplemente 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 gen√©ricas personalizadas? ¬ŅEs porque es demasiado simple vs. 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.

Eche 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 publicación personalizados. Cualquiera que use este complemento puede cambiar los temas sin tener que pasar por tanta molestia.

Sería bueno ver que los temas como AgentPress funcionen con un complemento base centralizado. Sería genial 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 publicaci√≥n s√ļper personalizados creados para el uso de un 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 publicaci√≥n personalizados? ¬ŅEn el archivo functions.php o en complementos?